DNSSEC Explained: Signing, Not Secrecy

DNSSEC works by adding cryptographic signatures to DNS records, verifying their authenticity and integrity.

Let’s see it in action. Imagine you want to visit www.example.com. Your computer asks a DNS resolver for its IP address. Without DNSSEC, an attacker could intercept this request and send back a fake IP address, directing you to a malicious site. With DNSSEC, the resolver asks the authoritative DNS server for example.com not just for the IP address, but also for a cryptographic signature proving that the record came from the legitimate example.com server and hasn’t been tampered with.

Here’s the breakdown:

1. Zone Signing: The owner of a DNS zone (like example.com) signs its DNS records. This involves generating a private key and using it to create digital signatures for each record. These signatures are published alongside the original records as RRSIG (Resource Record Signature) records.

   • Example: A RRSIG record for the A record www.example.com A 192.0.2.1 would contain the signature.

2. Key Distribution: The public keys used to verify these signatures are also published in DNS, specifically as DNSKEY records. There are two types of keys: the Zone Signing Key (ZSK) used to sign the records, and the Key Signing Key (KSK) used to sign the DNSKEY set itself, including the ZSK.

   • Example: A DNSKEY record for example.com might look like this: example.com. IN DNSKEY 257 3 8 AwEAAc3... (This represents the public KSK or ZSK).

3. Chain of Trust: To prevent a single point of failure and allow for secure key rollovers, DNSSEC establishes a chain of trust. The KSK of a child zone (e.g., sub.example.com) is cryptographically linked to its parent zone (e.g., example.com) via a DS (Delegation Signer) record. The parent zone signs the DS record, which contains a hash of the child’s KSK. This DS record is then published in the parent zone.

   • Example: example.com. might have a DS record for sub.example.com: sub.example.com. IN DS 12345 8 2 0A1B2C3D... (This DS record is signed by example.com’s KSK).

4. Validation: When a DNSSEC-aware resolver receives a DNS response, it performs validation. It starts by fetching the RRSIG record for the requested record and the DNSKEY record for the zone. It then uses the public key from the DNSKEY record to verify the RRSIG signature. To establish trust, it walks up the delegation chain: it asks the parent zone for the DS record of the child zone and verifies that DS record using the parent’s DNSKEY. This continues all the way up to the root zone, which is pre-configured with trusted root DNSKEYs.

   • Example Validation Step: The resolver fetches www.example.com’s A record and its RRSIG. It then fetches example.com’s DNSKEY record. It uses the public key from DNSKEY to verify the RRSIG for the A record.

   • Example Chain Verification Step: The resolver then fetches example.com’s DS record from the root zone’s DNS server. It verifies that DS record using the root zone’s trusted DNSKEY. Then, it fetches example.com’s DNSKEY and verifies that the DS record it got from the root matches the hash of the example.com KSK.

The most surprising thing is how the trust originates: it doesn’t magically appear; it’s explicitly established by the root zone, which has its KSK public keys hardcoded into resolvers. This "root trust anchor" is the foundation upon which the entire DNSSEC chain of trust is built. Every other zone’s security ultimately relies on the integrity of the root zone’s keys.

The actual data you’re looking for (like the IP address) is in the A record (or AAAA for IPv6, MX for mail servers, etc.). The RRSIG record provides the signature for that specific record type. If you request a record and its corresponding RRSIG record, and the validation chain holds up, you know the record is authentic. If any signature fails verification, or if a required record (like a DS record or a DNSKEY) is missing, the resolver will reject the response and typically return an SERVFAIL error to the client, preventing you from being misdirected.

The next problem you’ll run into is managing key rollovers, especially for the KSK. This involves securely exchanging the new KSK with the parent zone and ensuring a smooth transition without breaking the chain of trust.