DNSSEC and DNS Records: Locating the Public Key

By /

DNSSEC and DNS Records: Locating the Public Key

DNSSEC (Domain Name System Security Extensions) is a suite of IETF specifications designed to secure information provided by the Domain Name System (DNS). It’s crucial for establishing trust on the internet, preventing attacks like DNS spoofing (cache poisoning) and man-in-the-middle attacks that can redirect users to malicious websites. Instead of encrypting DNS data, DNSSEC digitally signs it. This ensures data integrity and authenticity, guaranteeing that the DNS information received is genuine and hasn’t been tampered with.

This article dives into the mechanics of DNSSEC and, specifically, how the crucial public key used for signature verification is located within the DNS hierarchy.

1. The Core Concept: Digital Signatures

DNSSEC works by using cryptographic digital signatures. Here’s the basic flow:

  • Signing: The authoritative DNS server for a zone (e.g., example.com) uses its private key to generate a digital signature for each set of DNS records (RRsets). This signature proves that the records originated from the authoritative server and haven’t been altered.
  • Verification: A DNSSEC-aware resolver (often your ISP’s resolver or a public resolver like Google DNS or Cloudflare DNS) uses the zone’s corresponding public key to verify the signature. If the signature is valid, the resolver can trust the DNS data. If the signature is invalid, the resolver knows the data has been tampered with or is not authentic.
  • Chain of Trust: The magic of DNSSEC lies in the chain of trust. Signatures are not just applied to individual resource record sets. Instead, the public key used to verify those signatures is itself signed by a key higher up in the DNS hierarchy. This chain continues all the way up to the root zone, whose key-signing key (KSK) is considered the trust anchor.

2. Key DNSSEC Record Types

To understand how the public key is located, we need to understand the key DNSSEC record types involved:

  • DNSKEY: This record contains the public keys used in DNSSEC. There are two main types of DNSKEY records:
    • Zone Signing Key (ZSK): Used to sign the RRsets within a zone (e.g., the A records, MX records, etc., for example.com). ZSKs are typically rotated more frequently than KSKs for better security practices.
    • Key Signing Key (KSK): Used to sign the DNSKEY RRset itself. This includes both the ZSK and the KSK. The KSK forms the link in the chain of trust to the parent zone.
  • RRSIG (Resource Record Signature): This record contains the digital signature for a specific RRset. It includes:
    • Type Covered: The type of record the signature covers (e.g., A, MX, NS).
    • Algorithm: The cryptographic algorithm used for the signature.
    • Labels: The number of labels in the original domain name.
    • Original TTL: The original Time-To-Live of the signed RRset.
    • Signature Expiration: The date and time when the signature expires.
    • Signature Inception: The date and time when the signature was created.
    • Key Tag: A short numeric value calculated from the DNSKEY record used to create the signature, helping quickly identify the correct DNSKEY.
    • Signer’s Name: The domain name of the zone that holds the DNSKEY record used to create the signature.
    • Signature: The actual digital signature.
  • DS (Delegation Signer): This record resides in the parent zone and contains a cryptographic hash of the KSK’s public key from the child zone. It’s the crucial link in the chain of trust. For example, the DS record for example.com would reside in the .com zone. The DS record allows the parent zone to vouch for the authenticity of the child zone’s KSK.
  • NSEC (Next Secure) / NSEC3 (Next Secure version 3): These records are used for authenticated denial of existence. They prove that a requested record (or domain name) doesn’t exist. Without these, an attacker could forge responses claiming a name doesn’t exist, potentially disrupting service. NSEC3 adds hashing to obscure the zone’s contents, preventing zone enumeration (where an attacker lists all the names in a zone).
    • NSEC: Lists the next domain name in the zone (alphabetically) and the record types that exist for the current name. This reveals the structure of the zone.
    • NSEC3: Uses a hash of the next domain name and includes a hash of the original name, along with the record types. This prevents zone enumeration while still proving non-existence.
  • NSEC3PARAM: Defines the parameters used for NSEC3 hashing.

3. Locating the Public Key: The Step-by-Step Process

Now, let’s walk through the process of locating the public key and verifying a signature. Imagine we’re trying to resolve www.example.com and want to verify its A record.

  1. Initial Query: The resolver queries for www.example.com‘s A record, indicating that it supports DNSSEC (by setting the DO bit in the DNS query).

  2. Response with RRSIG: The authoritative nameserver for example.com responds with:

    • The A record for www.example.com.
    • The RRSIG record for the A record, signed by example.com‘s ZSK. The Signer's Name field in the RRSIG will be example.com.

  3. Retrieving the ZSK: The resolver needs the ZSK to verify the RRSIG. It queries for the DNSKEY record for example.com.

  4. DNSKEY Response: The nameserver responds with the DNSKEY RRset for example.com, which contains:

    • The ZSK (identified by a flag in the DNSKEY record).
    • The KSK (also identified by a flag).
    • An RRSIG record for the DNSKEY RRset itself, signed by example.com‘s KSK. The Signer's Name field in this RRSIG will also be example.com.

  5. Verifying the ZSK: The resolver now has the ZSK. It uses the ZSK’s public key (from the DNSKEY record) to verify the RRSIG of the A record received in step 2. If this verification succeeds, the resolver knows the A record is authentic.

  6. Verifying the KSK (and the DNSKEY RRset): The resolver now needs to verify that the KSK (and therefore the ZSK) is legitimate. It uses the KSK’s public key to verify the RRSIG of the DNSKEY RRset received in step 4. If this succeeds, the resolver knows the DNSKEY RRset (including both ZSK and KSK) is authentic.

  7. Locating the DS Record: To complete the chain of trust, the resolver needs to verify the KSK against the parent zone. It knows to look in the parent zone because the Signer's Name in the RRSIG for the DNSKEY record (step 4) was example.com. The resolver queries the .com zone for the DS record for example.com.

  8. DS Record Response: The .com nameservers respond with the DS record for example.com. This DS record contains a hash of example.com‘s KSK’s public key.

  9. Verifying the DS Record: The resolver hashes the KSK public key it received in step 4 and compares the result to the hash in the DS record received in step 8. If they match, it means the .com zone vouches for the authenticity of example.com‘s KSK.

  10. Chain of Trust Continues: The .com zone’s DNSKEY records are themselves signed, and its KSK has a corresponding DS record in the root zone (.). The resolver repeats steps 7-9, querying for the DS record of .com in the root zone, verifying it against the .com KSK.

  11. Root Zone Trust Anchor: The chain of trust ultimately ends at the root zone. The root zone’s KSK is the trust anchor. Its public key is widely distributed and pre-configured in DNSSEC-aware resolvers. There is no DS record for the root zone in a higher level (because there is no higher level). Instead, the root KSK’s authenticity is established out-of-band (through trusted distribution channels).

In Summary:

DNSSEC relies on a hierarchical chain of trust, where each zone’s public key is signed by its parent zone, all the way up to the root zone. The DS record is the key element that links a child zone’s KSK to its parent zone, enabling this chain of trust. By following this chain and verifying signatures at each step, a resolver can be confident that the DNS data it receives is genuine and hasn’t been tampered with, preventing many common DNS-based attacks. The location of the public key is thus not a single, fixed place, but rather a path through the DNS hierarchy, guided by the DS records and the Signer's Name field within the RRSIG records.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top