Domain Name System Security Extensions: Difference between revisions
Bill Jouris (talk | contribs) mNo edit summary |
|||
| (21 intermediate revisions by 9 users not shown) | |||
| Line 1: | Line 1: | ||
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 | 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. | |||
==Overview== | ==Overview== | ||
The main goal of DNSSEC is to protect against [[Data Spoofing|data spoofing]] and corruption. Initially, | 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> | ||
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]]. | 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=== | ===How it Works=== | ||
The DNS was initially developed without any security extensions, thus increasing the chances to get out of synch and | The DNS was initially developed without any security extensions, thus increasing the chances to get out of synch and allowing 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 toward the correct server. | ||
The DNS ensures the correlation between the web address with [[IP Address]] and route traffic, but DNSSEC ensures the 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 backward-compatible system, the transaction will follow respective DNS protocols.<ref>[http://www.educause.edu/Resources/7ThingsYouShouldKnowAboutDNSSE/195431 7 things about DNSSEC]</ref> | |||
====KSK==== | |||
The Root DNSSEC Key-signing Key ([[KSK]]) Ceremony is a strict procedure during which the [[DNS]] root zone’s public keying information is signed for three months. The KSK is the key used to sign the set of Zone-signing Keys (ZSK), which form the [[trust]] anchor of the Domain Name System. Since 2016, [[ICANN]] has overseen the DNS root zone via IANA, which is the organization that keeps the private portion of the Key-Signing Key locked away. However, [[Verisign]] oversees the DNS root zone maintenance. It is in charge of generating the Root Zone-signing Key that is signed during the ceremony.<ref>[https://www.stackscale.com/blog/root-dnssec-ksk-ceremony/ Root DNSSEC KSK Ceremony, Stackscale]</ref> | |||
In 2010, ICANN started making KSK ceremonies public. The first public DNSSEC KSK ceremony was held in a high-security data center 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. | |||
The | 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> | ||
During the event, ICANN staff retrieve the root zone KSK. The ceremony produces months of [[cryptography|cryptographic]] signatures to protect global DNS operations. The ceremony is designed to involve a diverse group of experts from the [[ICANN Community]] (the TCRs) to access the KSK. These community members are distributed globally to help minimize risk, and they only convene in the same place when a ceremony is held. As of August 2022, 46 KSK ceremonies had taken place.<ref>[http://www.ag-ip-news.com/news.aspx?id=69284&lang=en ICANN Announces Face-to-Face 46th Key Ceremony, AG-IP News]</ref> | |||
===Objectives=== | ===Objectives=== | ||
| Line 25: | Line 35: | ||
* Authenticated denial of existence <ref>[http://ripe.net/training/dnssec/material/dnssec.pdf DNSSEC Objectives]</ref> | * 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 | 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 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 and ICANN== | ==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 | [[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> | |||
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.<ref>[http://www.circleid.com/posts/20100127_icann_begins_public_dnssec_test_plan_for_the_root_zone/ Circle ID]</ref> Details of the root signature can be found | 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.<ref>[http://www.circleid.com/posts/20100127_icann_begins_public_dnssec_test_plan_for_the_root_zone/ Circle ID]</ref> Details of the root signature can be found on the [http://www.root-dnssec.org/ Root DNSSEC's website]. | ||
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> | |||
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 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 | |||
==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 | 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 | # 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 | # 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 | 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 that 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, 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> | 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'''] | 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== | ||
| Line 87: | Line 97: | ||
* 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 its deployment of it in January 2014. The video's publication was supported by the European Union Structural Funds program, ''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- | * [http://dnssec-tools.org/ DNSSEC-TOOLS.org] - a site that encourages users to send reports on [[DNSSEC]] quality and capability of their current connection. | ||
==References== | ==References== | ||
| Line 97: | Line 111: | ||
[[Category: Glossary]] | [[Category: Glossary]] | ||
[[Category:Cybersecurity]] | |||
__NOTOC__ | __NOTOC__ | ||
Latest revision as of 09:35, 14 November 2024
The Domain Name System Security Extensions are a set of 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.
Overview[edit | edit source]
The main goal of DNSSEC is to protect against data spoofing and corruption. Initially, the DNS did not include security extensions. The main DNSSEC are specified by RFC4033, RFC4034, and RFC4035. There are RFCs that 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 | edit source]
The DNS was initially developed without any security extensions, thus increasing the chances to get out of synch and allowing 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 toward the correct server.
The DNS ensures the correlation between the web address with IP Address and route traffic, but DNSSEC ensures the 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 backward-compatible system, the transaction will follow respective DNS protocols.[2]
KSK[edit | edit source]
The Root DNSSEC Key-signing Key (KSK) Ceremony is a strict procedure during which the DNS root zone’s public keying information is signed for three months. The KSK is the key used to sign the set of Zone-signing Keys (ZSK), which form the trust anchor of the Domain Name System. Since 2016, ICANN has overseen the DNS root zone via IANA, which is the organization that keeps the private portion of the Key-Signing Key locked away. However, Verisign oversees the DNS root zone maintenance. It is in charge of generating the Root Zone-signing Key that is signed during the ceremony.[3]
In 2010, ICANN started making KSK ceremonies public. The first public DNSSEC KSK ceremony was held in a high-security data center 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.[4]
During the event, ICANN staff retrieve the root zone KSK. The ceremony produces months of cryptographic signatures to protect global DNS operations. The ceremony is designed to involve a diverse group of experts from the ICANN Community (the TCRs) to access the KSK. These community members are distributed globally to help minimize risk, and they only convene in the same place when a ceremony is held. As of August 2022, 46 KSK ceremonies had taken place.[5]
Objectives[edit | edit source]
The core objectives of DNSSEC are:
- Origin authority
- Data integrity
- Authenticated denial of existence [6]
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[edit | edit source]
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.[7]
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.[8]
DNSSEC and ICANN[edit | edit source]
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:
- 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:
- 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 [9]
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.[10] Details of the root signature can be found on the Root DNSSEC's website.
At the ICANN meeting in Brussels in 2010, there was an overwhelming response from companies who had implemented or were supporting the new protocol.[11]
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. [12]
DNSSEC Difficulties[edit | edit source]
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 | edit source]
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 that several .gov domain names experienced the same problem.[13]
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.[14]
A detailed report of the NASA DNSSEC signing error is available here.
DNSSEC Standards[edit | edit source]
- 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 [15]
Education[edit | edit source]
The Estonian Internet Foundation created a tutorial video for DNSSEC after its deployment of it in January 2014. The video's publication was supported by the European Union Structural Funds program, Raising Public Awareness about the Information Society. It is entitled "What is DNSSEC?" and can be seen on Vimeo".[16][17]
External Links[edit | edit source]
- DNSSEC-TOOLS.org - a site that encourages users to send reports on DNSSEC quality and capability of their current connection.
References[edit | edit source]
- ↑ DNSSEC Official Website/
- ↑ 7 things about DNSSEC
- ↑ Root DNSSEC KSK Ceremony, Stackscale
- ↑ ICANN's DNSSEC Key Ceremony Announcement
- ↑ ICANN Announces Face-to-Face 46th Key Ceremony, AG-IP News
- ↑ DNSSEC Objectives
- ↑ TLD DNSSEC Report (2012-05-03)
- ↑ ICANN announces total gTLD DNSSEC deployment
- ↑ ICANN explains DNSSEC
- ↑ Circle ID
- ↑ Security Week
- ↑ Slowly Cracking the DNSSEC Code at ICANN 43
- ↑ DNSSEC Error Caused NASA Website To Be Blocked
- ↑ Comcast Completes DNSSEC Deployment
- ↑ DNSSEC Standards
- ↑ What is DNSSEC?, Vimeo.com. Retrieved 2015 July 29.
- ↑ Estonian Internet Foundation, CENTR.org. Updated 2015 July 29.