[lac-discuss-en] FW: [technical-issues] Nameserver RFC compliance
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@xxxxxxxxxxxxxxxxxxxxxxx on behalf of marka@xxxxxxx>
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@xxxxxxx
_______________________________________________