DNSSEC

Introduction: authenticating DNS data

The Domain Name System (DNS) is a hierarchical, distributed naming system that maps human-readable domain names to IP addresses used by devices. The original DNS protocol was designed in the 1980s with an assumption that received answers could be trusted. When a computer asks a DNS resolver for the IP address of www.example.com, standard DNS provides no mechanism to check that the answer came from the appropriate zone and was not modified. DNSSEC addresses data authentication in DNS by adding signatures and validation.

Without authentication, an attacker can substitute a forged answer. One example is DNS cache poisoning or DNS spoofing. The forged response can point a browser to a malicious IP address instead of the address of the intended server. A user who believes they opened a banking or email site could then submit credentials to the attacker.

In response, the Internet Engineering Task Force (IETF) developed a set of extensions known as DNSSEC, or Domain Name System Security Extensions. These extensions add cryptographic validation mechanisms to DNS data.

What is DNSSEC? Authenticity and integrity of DNS data

DNSSEC does not replace DNS. It is a set of extensions that operates on existing DNS infrastructure. It does not provide confidentiality because it does not encrypt DNS queries or responses. Validation covers record sets and links a zone key to a chain of trust. RRSIG records cover the signed sets, while NSEC and NSEC3 provide authenticated denial of existence. DNSSEC provides two basic mechanisms:

1. Data origin authentication: DNSSEC allows a resolver to check cryptographically that data came from the signed zone for the requested domain and can be linked to a trust anchor.
2. Data integrity: DNSSEC allows the resolver to check that DNS data, including records, were not modified while being transferred between the authoritative server and the resolver. Changing one bit causes signature verification to fail.

These mechanisms help detect redirection to a malicious address. If DNSSEC validation is enabled and a response fails the cryptographic check, the resolver normally discards it and returns an error to the client.

How DNSSEC works: digital signatures

DNSSEC uses public-key cryptography and digital signatures for DNS data. To enable DNSSEC for a domain, the zone operator signs the zone and generates one or more cryptographic key pairs. In practice, operators may separate the Key Signing Key (KSK) and Zone Signing Key (ZSK) roles, with rotation details depending on the operator:

• A private key, which is kept secret by the zone operator and stored offline when practical.
• A corresponding public key, which is published publicly in the DNS for anyone to access.

These keys create and verify digital signatures for the domain's DNS record sets. The process introduces several new DNS record types that a resolver retrieves with the data needed for validation.

DNSSEC record types

To publish digital signatures and authenticated denial, DNSSEC adds new resource record types to DNS.

RRSIG (Resource Record Signature)

For each record set in a zone, such as all A records for a name, the authoritative server uses its private key to create a digital signature. The signature is published as an RRSIG record. It includes details such as the algorithm, key identifier, and signature validity period. When a resolver requests A data, the server returns the A record set and the corresponding RRSIG record.

DNSKEY (DNS Public Key)

To verify an RRSIG signature, the resolver needs the zone's public key. This key is published in a DNSKEY record. A zone can publish several DNSKEY records with different roles and identifiers. The resolver fetches DNSKEY data and uses the key to check the RRSIG signature. Successful verification shows that the data matches the signature associated with that zone.

DS (Delegation Signer)

A DSrecord contains a digest of a DNSKEY record in the child zone. Operators often use it to identify the Key Signing Key, while the record also carries the key tag and digest algorithm. The DS record is stored in the parent zone rather than in the delegated zone. For example, a DS record for 'example.com' is published in the '.com' zone. The digest links the child DNSKEY to a signed delegation in the parent zone and allows validation to continue.

NSEC/NSEC3 (Next Secure)

DNSSEC must also provide "authenticated denial of existence", proving that a name or record type is absent from a zone. The NSEC record orders names and record types in the zone. It can also show that an existing name has no requested record type. For a query for a name such as 'nonexistent.example.com', the server can return NSEC data showing the gap between two existing names. A later version, NSEC3, keeps this mechanism but uses name hashes to make "zone walking" harder, where an attacker follows the NSEC chain to enumerate names. NSEC3 makes enumeration harder but does not eliminate it entirely.

The validation chain: step-by-step checking

The following steps show how a DNSSEC-validating resolver checks a response for 'www.example.com'.

1. Starting with a Known Trust Anchor:The validating resolver starts with a pre-configured trust anchor associated with the public key of the DNS root zone (".").
2. Querying the Root:The resolver asks a root server for the delegation to '.com'. The response contains NS records, a DS record, and RRSIG signatures for the relevant sets. The resolver uses the trust anchor and the root zone DNSKEY to check this data, then can validate the '.com' zone key.
3. Querying the TLD:The resolver asks a '.com' server for the delegation to 'example.com'. The '.com' server returns the DS record and an RRSIG record signing it. The resolver fetches the DNSKEY of the '.com' zone and uses the validated delegation from the root zone to check this signature. Successful validation links the TLD key to the next DS record.
4. Querying the Authoritative Server:The resolver queries the 'example.com' authoritative server for the A record of 'www.example.com'. The server returns the A record set and its corresponding RRSIG signature.
5. Validating the Final Response:
   • The resolver asks the 'example.com' server for the zone public key in the DNSKEY record.
   • It calculates the digest of the relevant DNSKEY and compares it with the validated DS record received from the '.com' zone. A match allows the resolver to use the 'example.com' zone key for further validation.
   • Finally, it uses that key to verify the RRSIG signature attached to the A record set. A valid signature confirms that the data matches the signed zone.

This process moves down the DNS hierarchy from the trust anchor and creates a chain of links that can be validated cryptographically. A broken signed link produces a validation result indicating a problem with the response.

The role of DNSSEC

DNSSEC protects data used by the core Internet infrastructure. Deployment has three parts that must work together:

• Zone signing: Zone operators sign their zones by generating keys and creating the necessary DNSSEC records (RRSIG, DNSKEY, DS).
• Resolver validation: DNS resolvers, including those at ISPs or public services such as Google's $8.8.8.8$, must be configured to validate DNSSEC. Signing a zone provides protection only when a resolver checks the signatures.
• Application Handling:An application may receive the resolver's validation status through the local DNS interface; validation normally occurs in the recursive resolver.

The DNS root zone, TLD zones, and many domains use DNSSEC signatures, and many public resolvers validate them. If a zone has no DS chain, a resolver may treat it as unsigned according to its local configuration. A validating resolver begins with a configured trust anchor and follows DS and DNSKEY links. It also checks the signature validity period and supported algorithm. DNSSEC authenticates data and confirms its integrity. DoH (DNS over HTTPS) and DoT (DNS over TLS) protect transport confidentiality by encrypting queries, so they serve a different function.