Domain Name System Security Extensions

This article is neutral, but is sponsored by Dyn, Inc., a leading provider of DNS & DNSSEC services and solutions. Lean more about their services here.
link={{{link}}}
ICANNWiki Silver Sponsor

The Domain Name System Security Extensions is a set of Domain Name System (DNS) extensions which enables communication authentication between hosts and DNS data, while ensuring data integrity. DNSSEC is used for securing specific information provided by DNS.

Overview edit

The main goal of DNSSEC is to protect against data spoofing and corruption. Initially, it was called only DNS (Domain Name System) and did not include security extensions. The main DNSSEC extensions are specified by RFC4033, RFC4034, and RFC4035. There are also some additional RFCs which provide supporting information. ^[1]

Apart from the new DNS server and client concepts, DNSSEC introduced to the DNS the following 4 new resource records: DNSKEY, RRSIG, NSEC and DS.

How it Works edit

The DNS was initially developed without any security extensions, thus increasing the chances to get out of synch and allow the spoofing of IP Addresses with the purpose of redirecting traffic to undesired websites. DNSSEC was created as a means of adding protection and security to the DNS so that the redirected traffic could be checked and directed towards the correct server.

The DNS ensures the correlation between the web address with IP Address and route traffic, but DNSSEC ensures accuracy of the lookup date by adding a digital signature. In this way, the computer is connected to legitimate servers. If the DNSSEC authentication does not work (such as when the encryption keys do not match), due to the backwards-compatible system, the transaction will follow respective DNS protocols.^[2]

Objectives edit

The core objectives of DNSSEC are:

Origin authority
Data integrity
Authenticated denial of existence ^[3]

The DNSSEC mechanism of authentication of communication between hosts is fulfilled by means of TSIG. More specifically, the TSIG is used to securely authenticate the transactions between the name servers and the resolver. The DNSSEC mechanism of establishing authenticity and data integrity is achieved by means of: new RRs, signing a single zone, building a trust chain and by means of key rollers or key exchange.

DNSSEC and ICANN edit

ICANN is one of four entities that is a part of the DNSSEC process, it is responsible for receiving and inspecting the information from the TLD operators. These actions are perfomed in conjunction with:

The National Telecommunications and Information Administration (NTIA), which is a division of the U.S. Department of Commerce, and is responsible for authorizing changes to the root zone.
Verisign, which is contracted by the U.S. government to edit the root zone with the information supplied and authenticated by ICANN, which is subsequently authorized by the Department of Commerce, and also to distribute the root zone file containing information on where to find info on TLDs
An international group of Root Service Operators that distributes root information from the root zone file across the Internet. Those groups are:

On January 27th, 2007 deployment of DNSSEC for the root zone officially started; it was undertaken by ICANN and Verisign, with support from the U.S. Department of Commerce.^[5] Details of the root signature can be found on the Root DNSSEC's website.

In June, 2010, ICANN hosted the first production DNSSEC key ceremony in a high security data centre outside of Washington, D.C.. The key ceremony involved the creation of the first cryptographic digital key used to secure the Internet root zone, which was securely stored after its generation. Each key ceremony is designed to allow the private key material for the root zone to be managed in a transparent yet secure manner. The goal is for the whole Internet community to be able to trust that the procedures involved were executed correctly, and that the private key materials are stored securely. There is an emphasis on the transparency of the process through the use Trusted Community Representatives (TCRs), who undertake the detailed procedures with 14 ICANN employees. TCRs are members of the international DNS community, and are unaffiliated with ICANN, Verisign, or the US Department of Commerce. These ceremonies will take place 4 times a year in two different American locations.^[6]

At the ICANN meeting in Brussels later that month there was an overwhelming response from companies who had implemented, or were supporting the new protocol.^[7]

During the ICANN 43 meeting in Costa Rica, a half-day was devoted to DNSSEC discussion. Ram Mohan, Executive Vice President of Business Operations and Chief Technology Officer at Afilias, wrote in his blog that "the industry is quickly moving into the end-user adoption phase of global DNSSEC deployment." His statement was based on his assessment during the DNSSEC session in Costa Rica. He cited the .se ccTLD as example wherein Staffan Hagnel, a pioneer ccTLd operator in Sweden, said that 172,000 domain names adopted DNSSEC overnight after his offering a 5% discount to registrars. He plans to increase the discount to 7.5% to reach 350,000 domain names by the end of 2012. During the discussion, the ICANN community also learned about the experiences of companies implementing the DNSSEC protocol. Comcast noted that consumers do not have enough knowledge about DNSSEC, while Bill Smith, a representative from PayPal, said that it took the company a lot of planning and preparation to deploy the DNSSEC across its 1,100 domain names. He perceived that the next challenge is to create an effective key rollover strategy. ^[8]

DNSSEC Difficulties edit

It is critically important to secure the DNS for ensuring overall Internet protection, but when it comes to the deployment of DNSSEC the following difficulties may be encountered:

Developing backward-compatible system and standards
Logistical problems as a result of the addition of encryption keys to all Internet lookups, which requires solutions for updating the encryption keys without damaging the name servers.
International conflicts that arise from the implementation of DNSSEC, renewing the debates related to "control over the Internet".
Conflicts among implementers related to ownership issues of the root encryption keys

NASA DNSSEC Error edit

On January 18, 2012, the U.S. National Aeronautics and Space Administration (NASA) erroneously signed the DNSSEC protocol on its domain name nasa.gov, which caused Comcast to automatically block users from accessing the site. Many thought that blocking the NASA website was a Comcast strategy to express its protest against the SOPA/PIPA legislation because the DNSSEC signing error coincided with the Blackout Protest. According to Jason Livingood, vice president of Internet Systems Engineering for Comcast Cable Communications, the problem was caused by a domain signing error. The Comcast DNS resolver detected that the security signatures used by the administrator of the nasa.gov domain were invalid. He also said the several .gov domain names experienced the same problem.^[9]

Comcast was one of the earliest ISP service providers in North America to fully integrate the new security protocol. The company completed its DNSSEC deployment on January 10, 2012. In a statement, Mr. Livingwood confirmed that the company's 17.8 million residential customers of Xfinity Internet Service are fully supported with DNSSEC-validating DNS servers.^[10]

A detailed report of the NASA DNSSEC signing error is available here.

DNSSEC Deployment Statistics edit

Based on ICANN's TLD DNSSEC Report, 95 TLDs out of the 313 TLDs in the DNS root zone were already signed with the DNSSEC protocol while 86 TLDs have trust anchors published in the root zone, which means they are DNSSEC compatible.^[11]

DNSSEC Standards edit

RFC 2181 Clarifications to the DNS Specification
RFC 2535 Domain Name System Security Extensions
RFC 2671 Extension Mechanisms for DNS
RFC 3833 A Threat Analysis of the Domain Name System
RFC 3757 Domain Name System KEY (DNSKEY) Resource Record (RR)
RFC 4033 DNS Security Introduction and Requirements (DNSSEC-bis)
RFC 4034 Resource Records for the DNS Security Extensions (DNSSEC-bis)
RFC 4035 Protocol Modifications for the DNS Security Extensions (DNSSEC-bis)
RFC 4398 Storing Certificates in the Domain Name System (DNS)
RFC 4470 Minimally Covering NSEC Records and DNSSEC On-line Signing
RFC 4641 DNSSEC Operational Practices
RFC 5155 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
RFC 4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
RFC 4641 DNSSEC Operational Practices
RFC 5155 DNSSEC Hashed Authenticated Denial of Existence ^[12]

External Links edit

DNSSEC-TOOS.org - a site which encourages users to send reports on DNSSEC quality and capability of their current connection.