Domain Name System Security Extensions: Difference between revisions
No edit summary |
Applied 3749 patterns from rulesets/patterns/awb-patterns.yaml |
||
| (4 intermediate revisions by 4 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]]. | The '''Domain Name System Security Extensions (DNSSEC)''' 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 | 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 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). | 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). | ||
| Line 10: | Line 10: | ||
==Overview== | ==Overview== | ||
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> | 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]]. | ||
| Line 65: | Line 65: | ||
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 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> | ||
==DNSSEC Difficulties== | ==DNSSEC Difficulties== | ||
| Line 113: | Line 112: | ||
[[Category: Glossary]] | [[Category: Glossary]] | ||
[[Category:Cybersecurity]] | [[Category:Cybersecurity]] | ||