]> Afilias Canada Corp.

Suite 204, 4141 Yonge Street Toronto ON M2P 2A8 Canada +1 416 673 8371 shane@ca.afilias.info

Afilias Canada Corp.

Suite 204, 4141 Yonge Street Toronto ON M2P 2A8 Canada +1 416 673 4176 jabley@ca.afilias.info

This memo documents the methodology and results of an experiment which tested the availability of the DNS Extension Mechanism (EDNS0) on a large set of authority-only nameservers. The experiment was conducted in the bar during the IETF 72 meeting on 27 July 2008. The results of this experiment suggest that EDNS0 deployment is extensive: it was found that 94.4% of non-defective authority-only servers are EDNS0-capable.

specifies an extension mechanism for DNS (EDNS0), to be used between an authority-only DNS server and a DNS client (typically a DNS resolver). This memo documents the methodology and results of an experiment intended to estimate how widely-supported EDNS0 is in authority-only servers on 27 July 2008, almost 9 years after the EDNS0 specification was published.

The contents of 69 top- and second-level zones published by the Afilias DNS registry platform were mined to produce a list of unique nameserver names. A list of the zones mined in this fashion, together with the SOA serial numbers of the particular zones used, can be found in . For each nameserver name, a set of nameserver IPv4 addresses were obtained using the result of the query "<nameserver name> IN A?" obtained from a local DNS resolver. For each nameserver IPv4 address resulting from this process a single query was constructed "EXAMPLE.COM IN SOA?". This query was sent to <nameserver IPv4 address> using UDP transport with EDNS0. The server at each address was considered to be EDNS0-capable if the response to the query included an OPT resource record in the additional section, as specified in . If no OPT resource record was present, the server at the address was considered to be EDNS0-incapable. If no response was received within 3 seconds, the server was considered to be unresponsive. For each nameserver address that was tested and found to be EDNS0-incapable, an additional "EXAMPLE.COM. IN SOA?" query was sent using TCP transport. If no response was received, the server was considered to be incapable of responding over TCP. For each nameservers which were observed to be unresponsive to UDP queries with EDNS0, additional "EXAMPLE.COM. IN SOA?" queries were sent without EDNS0 over both UDP and TCP.

AERO [2007100130] AG [2008071160], CO.AG [2008062014], COM.AG [2008062794], NET.AG [2008062730], NOM.AG [2008062704], ORG.AG [2008062725] ASIA [2007193728] BZ [2008071161], COM.BZ [2008062518], EDU.BZ [2008062703], GOV.BZ [2008062506], NET.BZ [2008062732], ORG.BZ [2008062608] GI [2008070922], COM.GI [2008062713], EDU.GI [2008062704], GOV.GI [2008062503], LTD.GI [2008062604], MOD.GI [2008061703], ORG.GI [2008062704] HN [2008070999], COM.HN [2008062638], EDU.HN [2008062714], GOB.HN [2008062711], MIL.HN [2008052504], NET.HN [2008062704], ORG.HN [2008062706] IN [2008117115], AC.IN [2008062983], CO.IN [2008072985], EDU.IN [2008062896], FIRM.IN [2008062905], GEN.IN [2008062906], GOV.IN [2008062767], IND.IN [2008062986], MIL.IN [2006072621], NET.IN [2008063495], ORG.IN [2008065500], RES.IN [2008062422] INFO [2007991379] LC [2008070926], CO.LC [2008062302], COM.LC [2008062403], L.LC [2008062701], NET.LC [2008062704], ORG.LC [2008062708], P.LC [2008062301] ME [2008053552], CO.ME [2008043077], ITS.ME [2008043301], NET.ME [2008043018], ORG.ME [2008043022], PRIV.ME [2008043011], MN [2008071266] MOBI [2007383589] ORG [2008264551] SC [2008071107], COM.SC [2008062715], EDU.SC [2008062604], GOV.SC [2008062703], NET.SC [2008062706], ORG.SC [2008062706] VC [2008071137], COM.VC [2008062714], EDU.VC [2008062705], MIL.VC [2008062705], NET.VC [2008062505], ORG.VC [2008062707] Zone versions used during this experiment. Note that although in many cases the SOA serial numbers for these zones were once constructed in the format YYYYMMDD, as is a common convention, once hosted in the Afilias registry platform SOA serial numbers no longer specified using that convention; in normal operation serial numbers increase strictly monotonically.

The total number of delegations from all 69 zones was 13,747,646. The total number of unique nameserver names was 715,566. The number of nameserver IPv4 addresses obtained was 407,011. 9 nameservers had IPv6 addresses but no IPv4 addresses. No IPv4 or IPv6 addresses could be found for 100,913 nameserver names. Of the test queries sent to those 407,011 addresses, 322,992 responded and were EDNS0-capable, 19,030 responded and were were EDNS0-incapable, and 64,989 gave no response. Of the 19,030 servers which responded but which were EDNS0-incapable, 14,991 responded to the same query sent using TCP transport, and the remainder did not. Of the 64,989 nameservers which gave no response to an EDNS0 query, 5,326 gave a response to queries on both UDP transport without EDNS0 and TCP; 807 gave a response to a query on UDP transport without EDNS0 but not TCP; 919 gave a response on TCP but not UDP without EDNS0.

Assuming that the methodology described in this document has resulted in a representative sample, it may be concluded that: 16.0% of authority-only servers are defective, and provide no useful response at all to a query which specifies EDNS0. 94.4% of non-defective authority-only servers are EDNS0-capable. Of those authority servers which provide a response to a query which specifies EDNS0 but which are EDNS0-incapable, 79% respond to queries using TCP transport. 10.9% of servers which did not respond to a query which specified EDNS0 will respond to queries with TCP transport, or with UDP transport without EDNS0. Of all the servers tested from which it was possible to get a response (using UDP with EDNS0, UDP without EDNS0 or TCP) 92.5% support EDNS0 queries over UDP. Of all the servers tested from which it was possible to get a response, as above, 98.6% support either EDNS0 queries over UDP or TCP or both.

The results presented in this document are for queries and responses carried over IPv4 only. Since there are some nameservers in the test set which have published AAAA records, queries over IPv6 could be added to the test set. The set of zones from which authority server names were harvested could be expanded to include other gTLDs and ccTLDs. The set of measurement scripts could be packaged for unattended operation, and run regularly over a period of time, so as to confirm that the results presented here are indicative of normal behaviour, and not some isolated temporal phoenomenon. The measurement scripts could be run from more than one location, to reduce the possibility that the results are skewed due to topological query source. It appears that some server implementations do not respond to queries which appear to be lame delegations; the methodology might be modified such that instead of asking the same question of every server, we instead ask a question relating to a zone which is delegated to the server in question. This may reduce some systematic skew in the results, and reveal more servers to be EDNS0-capable.

&rfc2671;

This section to be removed prior to publication. Initial draft, circulated as draft-kerr-dnsop-edns0-penetration-00.