[lac-discuss-en] FW: [technical-issues] Nameserver RFC compliance

Vanda Scartezini vanda at scartezini.org
Mon Jul 11 15:40:16 UTC 2016



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 at atlarge-lists.icann.org on behalf of marka at 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 at isc.org
_______________________________________________
Technical-issues mailing list
Technical-issues at atlarge-lists.icann.org
https://atlarge-lists.icann.org/mailman/listinfo/technical-issues





More information about the lac-discuss-en mailing list