Domain Name System Security Extensions

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. DNSSEC (Domain Name System Security Extensions) adds resource records and message header bits which can be used to verify that the requested data matches what the zone administrator put in the zone and has not been altered in transit. DNSSEC doesn’t provide a secure tunnel; it doesn’t encrypt or hide DNS data. It was designed with backwards compatibility in mind. The original standard DNS protocol continues to work the same.

The new resource record types are: RRSIG (for digital signature), DNSKEY (the public key), DS (Delegation Signer), and NSEC (pointer to next secure record). The new message header bits are: AD (for authenticated data) and CD (checking disabled). A DNSSEC validating resolver uses these records and public key (asymmetric) cryptography to prove the integrity of the DNS data. A private key (specific to a zone) is used to encrypt a hash of a set of resource records — this is the digital signature stored in a RRSIG record.

The corresponding public key is stored in the DNSKEY resource record. The validating resolver uses that DNSKEY to decrypt the RRSIG and then compares the result with the hash of the corresponding resource record set to verify it is not changed. A hash of the public DNSKEY is stored in a DS record. This is stored in the parent zone. The validating resolver retrieves from the parent the DS record and its corresponding signature (RRSIG) and public key (DNSKEY); a hash of that public key is available from its parent. This becomes a chain of trust — also called an authentication chain. The validating resolver is configured with a trust anchor — this is the starting point which refers to a signed zone. The trust anchor is a DNSKEY or DS record and should be securely retrieved from a trusted source (not using DNS).

Also all the names in the zone have corresponding NSEC records listed in order creating a chain of all the signed record sets. (Corresponding RRSIG records are also created to verify the NSEC data.) Because there is no gap, NSEC records are used to provide proof of non-existence of an resource record or to authenticate negative replies.

Overview

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.

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

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.

Objectives

The core objectives of DNSSEC are:

• Origin authority
• Data integrity
• Authenticated denial of existence

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 Deployment Statistics

In 2012, ICANN's TLD DNSSEC Report stated that 1391 TLDs out of the 1534 TLDs in the DNS root zone were already signed with the DNSSEC protocol while 1383 TLDs had trust anchors published in the root zone, which meant they were DNSSEC compatible.

On December 23, 2020, ICANN announced that all gTLDs had deployed DNSSEC.

DNSSEC and ICANN

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:

1. 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.
2. 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
3. An international group of Root Service Operators that distributes root information from the root zone file across the Internet. Those groups are:

• Verisign Global Registry Services
• Information Sciences Institute at USC
• Cogent Communications
• University of Maryland
• NASA Ames Research Center
• Internet Systems Consortium Inc.
• U.S. DOD Network Information Center
• U.S. Army Research Lab
• Autonomica/NORDUnet, Sweden
• RIPE NCC, Netherlands
• ICANN
• WIDE Project, Japan

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

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.

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

On December 23, 2020, ICANN announced that all 1,195 gTLDs had deployed Domain Name System Security Extensions (DNSSEC) and that the focus of the DNSSEC rollout would turn to ccTLDs.

DNSSEC Difficulties

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:

1. Developing backward-compatible system and standards
2. 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.
3. International conflicts that arise from the implementation of DNSSEC, renewing the debates related to "control over the Internet".
4. Conflicts among implementers related to ownership issues of the root encryption keys

NASA DNSSEC Error

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.

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.

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

DNSSEC Standards

• 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

Education

The Estonian Internet Foundation created a tutorial video for DNSSEC after their deployment of it in January 2014. The video's publication was supported by the European Union Structural Funds programme, Raising Public Awareness about the Information Society. It is entitled "What is DNSSEC?" and can be seen on Vimeo".

External Links

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

Related Articles

• DNS Value and Vulnerability