Skip to main content

Report on the Assessment of Security and Stability Implications of the Use of DNAME Resource Records in the Root Zone of the DNS

ICANN commissioned a technical study into the security and stability implications of using the Domain Name System (DNS) DNAME Resource Record [RFC2672] in the root zone of the DNS. Testing was specified to be carried out in a captive lab environment which provided a functional replica of certain components of the public DNS. The results of that testing are presented in this report for the information of the wider DNS technical community.

This report found no failure in resolution nor in the ability to perform DNSSEC validation when DNAME was used in the root zone to provide isomorphism between two top-level domains (TLD), i.e. when one TLD was provisioned as a DNAME, compared to being provisioned as a distinct delegation. A variety of DNS software was tested as part of this study.

The use of DNAME in provisioning isomorphic domains is a candidate mechanism for the deployment of variant TLDs. However, the purpose of this report was not to investigate or make recommendations about whether DNAME provides a useful partial or complete solution to any problem related to variant TLDs, but rather to consider the narrower technical implications of using DNAME in the root zone. The more general requirements for variant TLD provisioning are being studied independently of this work within ICANN.

Since this study was performed using a captive replica of the public DNS, it should not be interpreted as an exhaustive answer to the question of whether DNAME can be usefully deployed in the public root zone. However, the conclusions of this report support future work which might (for example) propose the limited deployment of DNAME in the root zone for the purposes of real-world testing.

Report on the Assessment of Security and Stability Implications of the Use of DNAME Resource Records in the Root Zone of the DNS [PDF, 268 KB]

 

 


More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."