TOC |
|
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.
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.
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
TOC |
[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.
TOC |
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.
Figure 1 |
TOC |
TOC |
Assuming that the methodology described in this document has resulted in a representative sample, it may be concluded that:
TOC |
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.
TOC |
[RFC2671] | Vixie, P., “Extension Mechanisms for DNS (EDNS0),” RFC 2671, August 1999 (TXT). |
TOC |
This section to be removed prior to publication.
- 00
- Initial draft, circulated as draft-kerr-dnsop-edns0-penetration-00.
TOC |
Shane Kerr | |
Afilias Canada Corp. | |
Suite 204, 4141 Yonge Street | |
Toronto, ON M2P 2A8 | |
Canada | |
Phone: | +1 416 673 8371 |
Email: | shane@ca.afilias.info |
Joe Abley | |
Afilias Canada Corp. | |
Suite 204, 4141 Yonge Street | |
Toronto, ON M2P 2A8 | |
Canada | |
Phone: | +1 416 673 4176 |
Email: | jabley@ca.afilias.info |
TOC |
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.
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.