EDNS0 Support in Authority Servers on 27 July 2008
draft-kerr-dnsop-edns0-penetration-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 29, 2009.

Abstract

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.

Table of Contents

1.  Introduction

2.  Methodology

3.  Results

4.  Summary

5.  Opportunities for Further Study

6.  References

Appendix A.  Change History

§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

[RFC2671] (Vixie, P., “Extension Mechanisms for DNS (EDNS0),” August 1999.) 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.

2.  Methodology

1. 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.
2. A list of the zones mined in this fashion, together with the SOA serial numbers of the particular zones used, can be found in Figure 1.
3. 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.
4. 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 [RFC2671] (Vixie, P., “Extension Mechanisms for DNS (EDNS0),” August 1999.). 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.
5. 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.
6. 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.

3.  Results

1. The total number of delegations from all 69 zones was 13,747,646.
2. The total number of unique nameserver names was 715,566.
3. 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.
4. 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.
5. 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.
6. 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.

4.  Summary

Assuming that the methodology described in this document has resulted in a representative sample, it may be concluded that:

1. 16.0% of authority-only servers are defective, and provide no useful response at all to a query which specifies EDNS0.
2. 94.4% of non-defective authority-only servers are EDNS0-capable.
3. 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.
4. 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.
5. 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.
6. 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.

5.  Opportunities for Further Study

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.

6. References

Appendix A.  Change History

This section to be removed prior to publication.

00

Initial draft, circulated as draft-kerr-dnsop-edns0-penetration-00.

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.