Domain Name System Security Extensions: Difference between revisions

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

DNSSEC 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 backward 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 the 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 an 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 that 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).

All the names in the zone have corresponding NSEC records listed in order to create 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 the non-existence of a resource record or to authenticate negative replies.

The main goal of DNSSEC is to protect against [[Data Spoofing|data spoofing]] and corruption. Initially, the [[DNS]] did not include security extensions. The main DNSSEC are specified by RFC4033, RFC4034, and RFC4035. There are [[RFC]]s that provide supporting information.<ref>[http://www.dnssec.net DNSSEC Official Website/]</ref>

 

 

 

 

 

 

 

===Objectives===

* Authenticated denial of existence <ref>[http://ripe.net/training/dnssec/material/dnssec.pdf DNSSEC Objectives]</ref>

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

 

 

[[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 performed in conjunction with:

# [[NTIA|The National Telecommunications and Information Administration]] (NTIA), which is a division of the U.S. [[DOC|Department of Commerce]], and is responsible for authorizing changes to the [[Root Zone|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 [[TLD]]s

# 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 <ref>[http://www.icann.org/en/announcements/dnssec-qaa-09oct08-en.htm ICANN explains DNSSEC]</ref>

At the [[ICANN Meetings|ICANN meeting]] in Brussels in 2010, there was an overwhelming response from companies who had implemented or were supporting the new protocol.<ref>[http://www.securityweek.com/dnssec-becomes-reality-today-icann-brussels Security Week]</ref>

During the [[ICANN 43]] meeting in Costa Rica, a half-day was devoted to the 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. <ref>[http://www.circleid.com/posts/20120405_slowly_cracking_the_dnssec_code_at_icann_43/ Slowly Cracking the DNSSEC Code at ICANN 43]</ref>

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:

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

* RFC 5155 DNSSEC Hashed Authenticated Denial of Existence <ref>[http://www.dnssec.net/ DNSSEC Standards]</ref>