Jump to content

Domain Name System Security Extensions

The Domain Name System Security Extensions (DNSSEC) are a set of Domain Name System (DNS) extensions enabling authentication and integrity verification of DNS data. DNSSEC is used for securing 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 secure transport: it doesn't encrypt or hide DNS data (but like any DNS traffic, an encrypted channel like DoH or DoQ can be used for transport). It was designed with backward compatibility in mind, and does not modify the way the DNS works, beyond adding the optional information needed to perform validation.

The new resource record types are RRSIG (for digital signature), DNSKEY (the public key), DS (Delegation Signer), and NSEC/NSEC3 (pointer to the next secure record). The new message header bits are AD (for authenticated data, set after validation) and CD (checking disabled, for debugging). 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 sign DNS record sets — 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 check the RRSIG. In order to obtain assurance that domain's DNSKEY hasn't been modified in transit, it is compared to a DS record stored in the parent zone, next to the delegation NS records of the domain's delegation. The DS record contains a hash (fingerprint) of the child domain's DNSKEY, and is endorsed via a signature from the parent domain. While progressing through the DNS hierarchy to resolve a query, a validating resolver collects DS records (and their RRSIG signatures) along the delegation chain in order to in turn validate the DNSKEY for each new subzone. This is called the "DNSSEC chain of trust", where each layer authenticates the next. The last key retrieved in this way is then used to validate the signature of the final query response (such as an A record for www.example.com).

The validating resolver is configured with a trust anchor — this is the starting point that refers to a signed zone (normally the root). The trust anchor is a DNSKEY or DS record and should be securely retrieved from a trusted source (not using DNS).

When signing a zone, additional records are added "between" subdomains, which record any gaps (such as: "the next subdomain after 'mail' is 'www'). The corresponding record type is NSEC, or NSEC3 (which uses a hashed representation for subdomain ranges, to prevent full inspection of a zone's names). This allows resolvers to validate that an answer to a given query does not exist ("negative response"). NSEC/NSEC3 records contain additional metadata to also confirm which record types (such as A or MX) are present and each defined subdomain, and which do not. They are further used in case of wildcard records, to confirm that no more specific record exists that would take precedence over the wildcard.

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:

  1. 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.
  2. 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
  3. An international group of Root Service Operators that distributes root information from the root zone file across the Internet. Those groups are:

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:

  1. Developing backward-compatible system and standards
  2. 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.
  3. International conflicts that arise from the implementation of DNSSEC, renewing the debates related to "control over the Internet".
  4. Conflicts among implementers related to ownership issues of the root encryption keys

DNSSEC Standards[edit | edit source]

An overview of other DNSSEC-related RFC standards is given in RFC 9364.

Education[edit | edit source]

References[edit | edit source]

Related Articles[edit | edit source]

Key Signing Key. DNSSEC key used to sign a DNS zone's zone signing key, including in root zone key-management contexts.

Country code top-level domain. Determined by "ISO 3166-1: Codes for the representation of names of countries and their subdivisions — Part 1: Country codes".

Request For Comments. Archival series dedicated to documenting Internet technical specifications, including general contributions from the Internet research and engineering community as well as standards documents (RFC Editor Model, Version 3).

Retrieved from "https://icannwiki.org/index.php?title=Domain_Name_System_Security_Extensions&oldid=1410046"
Semantic properties for "Domain Name System Security Extensions"
RDF feed