DNSSEC
From ICANNWiki
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.
Overview
The main goal of DNSSEC 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. [1]
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
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.[2]
Objectives
The core objectives of DNSSEC are:
- Origin authority
- Data integrity
- Authenticated denial of existence [3]
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
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:
- 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 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 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 [4]
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.[5] Details of the root signature can be found at Root DNSSEC's website.
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.[6]
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.[7]
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:
- 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
- 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 [8]
