14,927
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: − {{Glossary| − |note = This article is neutral, but is [[Sponsorship|sponsored]] by [[Dyn|Dyn, Inc.]],<br> a leading provider of [[DNS]] & DNSSEC services and solutions.<br> Lean more about their services [http://dyn.com/ here]. − |logo = DynLogo.png − |silversponsor = ICANNWiki [[Sponsorship|Silver Sponsor]] − }} + + + + + + + + Line 25:
Line 28: + + + + + Line 50:
Line 58: − + + + − + − + − + − + − − 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, Livingwood confirmed that the company's 17.8 million residential customers of Xfinity Internet Service are fully supported with DNSSEC-validating DNS servers.<ref>[http://blog.comcast.com/2012/01/comcast-completes-dnssec-deployment.html Comcast Completes DNSSEC Deployment]</ref> − A detailed report of the NASA DNSSEC signing error is available [http://www.dnssec.comcast.net/DNSSEC_Validation_Failure_NASAGOV_20120118_FINAL.pdf '''here''']+ − ==DNSSEC Deployment Statistics==+ − 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.<ref>[http://stats.research.icann.org/dns/tld_report/ TLD DNSSEC Report (2012-05-03)]</ref> Line 86:
Line 93: + + + + − +
Domain Name System Security Extensions (view source)
Revision as of 15:58, 31 December 2020
, 3 years ago→DNSSEC and ICANN
The '''Domain Name System Security Extensions''' is a set of [[DNS|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]].
The '''Domain Name System Security Extensions''' is a set of [[DNS|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==
==Overview==
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 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 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]].
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 [[TLD|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.<ref>[http://stats.research.icann.org/dns/tld_report/ TLD DNSSEC Report (2012-05-03)]</ref>
On December 23, 2020, ICANN announced that all [[gTLDs]] 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>
==DNSSEC and ICANN==
==DNSSEC and ICANN==
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>
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 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. <ref>[http://www.circleid.com/posts/20120405_slowly_cracking_the_dnssec_code_at_icann_43/ Slowly Cracking the DNSSEC Code at ICANN 43]</ref>
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. <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>
==DNSSEC Difficulties==
==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 are encountered:
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
# Developing backward-compatible system and standards
# Logistical problems as a result of the addition of encryption keys to all Internet lookups: requires solution for updating the encryption keys without damaging the name servers.
# 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 which arise from the implementation of DNSSEC, renewing the debates related to "control over the Internet".
# 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
# Conflicts among implementers related to ownership issues of the root encryption keys
===NASA DNSSEC Error===
===NASA DNSSEC Error===
On January 18, 2012, the 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 was coincidental 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>
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>
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.<ref>[http://blog.comcast.com/2012/01/comcast-completes-dnssec-deployment.html Comcast Completes DNSSEC Deployment]</ref>
A detailed report of the NASA DNSSEC signing error is available [http://www.dnssec.comcast.net/DNSSEC_Validation_Failure_NASAGOV_20120118_FINAL.pdf '''here'''].
==DNSSEC Standards==
==DNSSEC Standards==
* RFC 4641 DNSSEC Operational Practices
* RFC 4641 DNSSEC Operational Practices
* RFC 5155 DNSSEC Hashed Authenticated Denial of Existence <ref>[http://www.dnssec.net/ DNSSEC Standards]</ref>
* RFC 5155 DNSSEC Hashed Authenticated Denial of Existence <ref>[http://www.dnssec.net/ DNSSEC Standards]</ref>
==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 [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>
==External Links==
==External Links==
* [http://dnssec-tools.org/ DNSSEC-TOOS.org] - a site which encourages users to send reports on [[DNSSEC]] quality and capability of their current connection.
* [http://dnssec-tools.org/ DNSSEC-TOOLS.org] - a site which encourages users to send reports on [[DNSSEC]] quality and capability of their current connection.
==References==
==References==