Domain Name System Security Extensions: Difference between revisions
| Line 25: | Line 25: | ||
* [[Verisign]], which is contracted by the U.S. government to edit the root zone with the information supplied and authenticated by [[ICANN]], which was subsequently authorized by the Department of Commerce, and also to distribute the root zone file containing information on where to find info on TLDs | * [[Verisign]], which is contracted by the U.S. government to edit the root zone with the information supplied and authenticated by [[ICANN]], which was 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]] then distributes root information from the root zone file across the Internet. Those groups are: | * An international group of [[Root Service Operators]] then distributes root information from the root zone file across the Internet. Those groups are: | ||
# VeriSign Global Registry Services | # [[VeriSign]] Global Registry Services | ||
# Information Sciences Institute at USC | # [[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> | |||
Revision as of 08:17, 4 February 2011
The Domain Name System Security Extensions is a set of 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.
Short Overview[edit | edit source]
DNSSEC is generally referred to as DNS Security Extensions. Its main goal is to protect against 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 RFCs which provide supporting information.
Apart from the new DNS server and client concepts, DNSSEC introduces to 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 allow the spoofing of IP Addresses with the purpose of redirecting traffic to undesired websites. This is how DNSSEC appeared: as a need for adding protection and security to 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 the 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 the DNS protocols.
Objectives[edit | edit source]
The core objectives of DNSSEC are:
- Origin authority
- Data integrity
- Authenticated denial of existence
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 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 top level domain (TLD) operators. These actions are perfomed in conjunction with:
- The National Telecommunications and Information Administration, which is a division of the U.S. Department of Commerce, and is responsible for authorizing changes to the roots.
- Verisign, which is contracted by the U.S. government to edit the root zone with the information supplied and authenticated by ICANN, which was 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 then 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[1]
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 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.[2]
Each TCR is a respected member of the technical Domain Name System (DNS) community in their home country. They are also unaffiliated to ICANN, VeriSign or the US Department of Commerce, and have been assigned a separate key management role within the ceremony.
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 are encountered:
- 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.
- International conflicts which 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
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
References[edit | edit source]
- ↑ ICANN explains DNSSEC
- ↑ [ http://www.icann.org/en/announcements/announcement-2-07jun10-en.htm ICANN's DNSSEC Key Ceremony Announcement.}