In message <9442FCB1-E039-4EDD-8A0F-F5F351BC99B4@truenet.com>, Eric Tykwinski w rites:
Ironically, I always wondered why I was told not to publish SPF records, since it did make more sense to have both, and slowly remove the TXT records later. Thanks for the heads up…
What do you think really is best practice now?
For SPF the decision was made to stay with TXT. The IAB wrote RFC 5507 - Design Choices When Expanding the DNS. As for testing there is: https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-04 There is general consensus that the tests are correct to the level that they cover. There can always be more tests added. There is less consensus on how we get from where we are now to where we need to be. The EDNS tests tool was the starting point for this draft. Mark
Sincerely,
Eric Tykwinski TrueNet, Inc. P: 610-429-8300
On Sep 15, 2016, at 7:30 PM, Mark Andrews <marka@isc.org> wrote:
So your helpdesks don't get problem reports when people can't look up domain names? Recursive DNS vendors don't get bug reports when domain names can't be looked up. We don't get fixes developed because there are too many broken servers out there.
Because some servers don't answer EDNS requests this leads to false positives on servers not support EDNS when they do. This in turn leads to DNSSEC validation failures as you don't get DNSSEC answers without EDNS.
IPv6 deployment was put back years because AAAA DNS lookups got wrong answers.
DANE deployment is slow because DNS servers give bad answers to _<port>._tcp.<server-name>/TLSA.
Then there is SPF. A fare portion of the reason why the SPF record failed, despite it being architectually cleaner than using TXT records, is that some nameservers gave bad responses to SPF queries.
I could go find more examples of the cost of non DNS protocol compliance. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org