Vanda Scartezini Polo Consultores Associados Av. Paulista 1159, cj 1004 01311-200- Sao Paulo, SP, Brazil Land Line: +55 11 3266.6253 Mobile: + 55 11 98181.1464 Sorry for any typos. To whom arinterested in technical issues, here some comments from Mark. Vanda Scartezini Polo Consultores Associados Av. Paulista 1159, cj 1004 01311-200- Sao Paulo, SP, Brazil Land Line: +55 11 3266.6253 Mobile: + 55 11 98181.1464 Sorry for any typos. On 7/5/16, 4:06 AM, "Mark Andrews" <technical-issues-bounces@atlarge-lists.icann.org on behalf of marka@isc.org> wrote: ICANN currently requires that registries use RFC standards compliant nameservers as part of the registry requirement for non CC TLDs. This covers both DNS (STD 13) and EDNS (RFC6891). This is a good thing and almost all TLD operators are running DNS and EDNS compliant nameservers. https://ednscomp.isc.org/compliance/ts/allok.html https://ednscomp.isc.org/compliance/tld-report.html https://ednscomp.isc.org/compliance/tld-fullreport.txt The same cannot be said of the servers that TLD registries delegate to with just over 50% of servers that are nominally EDNS aware actually being EDNS compliant despite the requirements being nearly 17 years old. This lack of compliance causes operational issues for recursive servers that use the newer features of the DNS and does result in DNS resolution failures. A modern DNS recursive server sends non-recursive EDNS queries with a DNS COOKIE option set and the DO bit set by default to all servers. The typical response profile to this query is shown in these graphs. https://ednscomp.isc.org/compliance/ts/gov.optfail.html https://ednscomp.isc.org/compliance/ts/alexa.optfail.html Similar issues exist when you look at unknown EDNS flag behaviour and unknown EDNS version behavior. These things for the most part are also easy to check for. The EDNS compliance checks performed to generate the pages at https://ednscomp.isc.org are done using these simple DNS queries which target individual EDNS features that should be supported. dig +nocookie +noedns +noad +norec soa -q "$zone" @$server dig +nocookie +edns +noad +norec soa -q "$zone" @$server dig +nocookie +edns=1 +noednsneg +noad +norec soa -q "$zone" @$server dig +nocookie +edns +dnssec +bufsize=512 +noad +norec +ignore dnskey \ -q "$zone" @$server dig +nocookie +ednsopt=100 +noad +norec soa -q "$zone" @$server dig +nocookie +ednsopt=100 +edns=1 +noednsneg +noad +norec soa \ -q "$zone" @$server dig +nocookie +dnssec +noad +norec soa -q "$zone" @$server dig +nocookie +ednsflags=0x80 +noad +norec soa -q "$zone" @$server dig +nocookie +edns +dnssec +bufsize=512 +noad +norec +vc dnskey \ -q "$zone" @$server dig +edns +noad +norec +nsid +subnet=0.0.0.0/0 +expire +cookie \ soa -q "$zone" @$server The errors themselves are trivial to fix in most cases. I fixed similar errors in named back before EDNS was specified and they took less than 5 minutes of coding to fix the errors. Writing the tests took longer. So to with the QA. A more exhaustive list of tests covering STD 13 behaviour as well is in: https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-03 We do a disservice to all the recursive server operators and their clients by allowing delegations to non RFC compliant servers to occur. All servers delegated to should be checked at or near initial registration time and the operators informed of errors detected with a request to fix the error and re-checked quarterly if they had a error and annually if they didn't with followups on detected errors. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ Technical-issues mailing list Technical-issues@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/technical-issues