Skip to main content

Anchors Aweigh!

We are pleased today to announce a new service that is a small step toward helping the community toward deploying DNSSEC and consequently securing the domain name system. Called the Interim Trust Anchor Repository, this service is admittedly for the more technically minded, but for those experimenting with early DNSSEC deployments it will provide great utility.

As has been discussed a lot lately, the DNS does not have much in the way in inherent security mechanisms. DNSSEC is a newer technology designed to remedy that by adding a layer of cryptographic verification to the DNS. By using DNSSEC, DNS data can be checked and verified to make sure it has not been tampered with in transit over the unprotected Internet.

Key to deploying DNSSEC is deploying it at the root zone level. The root zone is the upper most level in the DNS hierarchy, and is managed under a complex arrangement involving not only ourselves, but also VeriSign and the US Government. Right now, consultations are being made on how best to secure the root zone using DNSSEC, and that discussion is expected to carry on for some time. It is a somewhat political debate, as well as a technical discussion on how to maintain the robustness of a service that is the cornerstone of Internet stability.

The community has recognised that discussion will undoubtedly carry on for some time, but that there is an immediate need to support nascent DNSSEC deployment efforts. To do this a trust anchor repository was proposed, with ICANN requested to operate the service. A trust anchor repository would be a place to hold the security information that would be in the root zone if it were signed. For example, the Swedish country code top-level domain .SE has already implemented DNSSEC, and their trust anchors can be found in the repository. This allows for early adopters who have suitably configured DNSSEC software to obtain that security information independent of the DNS, without waiting for the root zone to have DNSSEC implemented.

Today we have released the first public version of the trust anchor repository after some initial experimentation with some of the core DNSSEC engineering community. We have prepended the word “interim” to its name, just to emphasise that this isn’t permanent, and is only designed to be a stepping stone to the ultimate goal of a DNSSEC-signed root zone.

We do not recommend it for use other than by expert administrators. It is experimental and requires some understanding of DNSSEC to be helpful. We think it will be useful in giving everyone involved better operational experience with DNSSEC, as well as being a helpful nudge on the way toward more universal DNSSEC deployment on the Internet. As a temporary solution, it has its caveats, and we recommend not treating it as an ultimate solution. But with that in mind, we look forward to those who are feeling adventurous to give it a try and provide us with feedback on how we can improve the service.


    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"""" is not an IDN."