Skip to main content
Resources

DNSSEC

To easily identify resources on the Internet, the underlying numerical addresses for these resources are represented by human readable strings. The conversion of these strings to numbers is done by the distributed hierarchical Domain Name System (DNS). Increased sophistication in computing and networking since its design in 1983 have made this "phone book" vulnerable to attacks. Specifically, to the ability of attackers to falsify responses to queries to the DNS thus allowing attackers to redirect end users to Web sites under their own control (for account and password collection) without notice.

In response to these threats, the international standards organization, IETF, developed DNSSEC to cryptographically ensure DNS content cannot be modified from its source without being detected. Once fully deployed, DNSSEC will stop the attacker's ability to redirect users using the DNS. Of particular interest to ISPs and enterprises, DNSSEC will prevent en masse redirection at the DNS resolver (also known as cache poisoning).

DNSSEC works by digitally signing each DNS record so that any tampering of that record can be detected. The digital signatures, and keys used to create them, are distributed just like any other records in the DNS making DNSSEC backward compatible. Keys in each layer in the DNS hierarchy are signed by keys from the preceding layer which effectively vouches for them just like domain names are delegated from one layer to the next. This "chain of trust" is used to validate the digital signatures accompanying DNSSEC protected records to detect changes.

With and Without DNSSEC

Starting with the discovery of improved DNS exploits in 2008 together with broad multi-stakeholder support, DNSSEC has been deployed at an accelerated pace on many top level domains, the "root", and products. For the public to benefit fully from DNSSEC via the chain of security it establishes from content source to end user, it must be supported by every entity along this chain, e.g., ISPs and domain name owners.

Moving Forward: With the healthy deployment of DNSSEC well on its way and serious efforts to make use of the resulting global PKI to expand the benefits of cryptographic security to the masses, DNSSEC has the potential of becoming a critical link for a wide range of industry applications.

Greater support of DNSSEC by Registrars, ISPs, Registrants, and enterprises will help achieve this potential by building on the international bottom-up, multi-stakeholder DNSSEC infrastructure deployment efforts that have brought us to where we are today. Specifically, to help reap the full benefits of DNSSEC we recommend the following:

  • Support DNSSEC validation on DNS resolution services.
  • Deploy DNSSEC on domain names.
  • Raise awareness of the security benefits of DNSSEC and its trustworthy deployment.

Future Applications: Although ancillary to its original purpose, DNSSEC is seen by many Internet veterans as a platform for innovation for a whole new range of Internet security solutions from digital certificates and email to yet to be discovered products. Therefore, gaining experience with DNSSEC may have broader value.

This web page is designed to track activities relating to DNSSEC. For more information on DNSSEC and interest in DNSSEC education and training please contact dnssec@icann.org.

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."