Domain Name System Security Extensions: Difference between revisions

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.

The main goal of DNSSEC is to protect against [[Data Spoofing|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 [[RFC]]s which provide supporting information. <ref>[http://www.dnssec.net DNSSEC Official Website/]</ref>

The DNS was initially developed without any security extensions, thus increasing the chances to get out of synch and allow the spoofing of [[IP Address|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.<ref>[http://www.educause.edu/Resources/7ThingsYouShouldKnowAboutDNSSE/195431 7 things about DNSSEC]</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]].

On December 23, 2020, ICANN announced that all [[gTLD]]s had deployed DNSSEC.<ref>[https://www.icann.org/news/announcement-2020-12-23-en ICANN - Domain Name System Security Extensions Now Deployed in all Generic Top-Level Domains]</ref>

[[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:

# [[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

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 [[TCR|Trusted Community Representatives]] (TCRs), who undertake the detailed procedures with 14 [[ICANN]] employees. [[TCR]]s 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.<ref>[http://www.icann.org/en/announcements/announcement-2-07jun10-en.htm ICANN's DNSSEC Key Ceremony Announcement]</ref>

 

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

On December 23, 2020, ICANN announced that all 1,195 [[gTLD]]s had deployed Domain Name System Security Extensions (DNSSEC) and that the focus of the DNSSEC rollout would turn to [[ccTLD]]s.<ref>[https://www.icann.org/news/announcement-2020-12-23-en ICANN announces total gTLD DNSSEC deployment]</ref>

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.<ref>[http://www.darkreading.com/authentication/167901072/security/application-security/232500483/dnssec-error-caused-nasa-website-to-be-blocked.html DNSSEC Error Caused NASA Website To Be Blocked]</ref>  

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 [https://vimeo.com/91504543 Vimeo]".<ref name="vimeo">[https://vimeo.com/91504543 What is DNSSEC?], Vimeo.com. Retrieved 2015 July 29.</ref><ref name="centr">[https://centr.org/member/estonian-internet-foundation Estonian Internet Foundation], CENTR.org. Updated 2015 July 29.</ref>

* [http://dnssec-tools.org/ DNSSEC-TOOLS.org] - a site which encourages users to send reports on [[DNSSEC]] quality and capability of their current connection.