Search... ⌘ K
Get Started Contact Sales

The DNSSEC Chain of Trust

Last updated

The DNSSEC chain of trust is the series of signed links that runs from the DNS root zone, through a top-level domain like .com, down to your domain. A validating resolver starts from a root key it already trusts and checks each link in turn, so it can confirm that your DNS records are authentic and haven’t been tampered with.

What is the DNSSEC chain of trust?

The DNSSEC chain of trust is a cryptographic pathway that follows the hierarchical structure of the Internet’s DNS. It is a series of digital signatures that link each level of the DNS system, from the root zone down to Top-Level Domains (TLDs) and individual domains, through all the steps in between.

By linking each level of the domain name hierarchy with digital signatures, it provides a verifiable path from a universally trusted anchor all the way down to your individual domain’s records. This creates an unbroken chain of cryptographic verification essential for preventing DNS tampering, ensuring data integrity, and building trust in the internet’s naming system.

Why is a chain of trust needed?

The chain of trust is essential to your domain name security with DNSSEC. Without a chain of trust, a DNSSEC-validating resolver would not know where to begin trusting DNS data.

The chain ensures

  • Authenticity: Each zone in the delegation chain uses its private key to sign its DNS data to provide proof of origin.
  • Integrity: Data has not been altered in transit.
  • Verifiability: Resolvers can validate the data they receive by verifying it against its expected authoritative origin.

How the chain of trust works

The chain of trust operates through the interplay of two key DNSSEC record types, DNSKEY records and DS records, starting from a trust anchor.

  1. The trust anchor (the root of trust)

    The journey begins with a trust anchor, which is a public cryptographic key. A DNSSEC-validating resolver is pre-configured to implicitly trust this key.

    The most important trust anchor is the public Key Signing Key (KSK) for the DNS root zone ( . ). Most validating resolvers have this key built in. Every other validation extends from it.

  2. Signing at each level (DNSKEY and RRSIG)

    Each DNSSEC-enabled zone (such as the root, a TLD, or your domain) has its public keys stored in DNSKEY records. The corresponding private keys are used to generate RRSIG records, which are cryptographic signatures over the zone’s data (specifically, its RRSETs, or resource record sets).

  3. Delegating trust down the hierarchy (DS records)

    A parent zone does not sign the child zone’s data. Instead, to create a secure delegation, the parent zone publishes a cryptographic digest (a hash) of the child zone’s KSK. This digest is called a Delegation Signer (DS) record.

    • Child zone action: The operator of the child zone (for example, example.com) generates a KSK, then calculates a digest of it. At DNSimple, we generate your keys and DS record when you enable DNSSEC.
    • Parent zone action: The digest is provided to the parent zone (for example, .com), usually through the domain’s registrar. The parent zone publishes it as a DS record and signs that record like any other record in its zone. The DS record acts as a secure pointer to the child zone’s KSK.
    • Chain establishment: This repeats down the hierarchy. The root zone publishes DS records for TLDs like .com, and TLDs like .com publish DS records for second-level domains like example.com.

  4. Processing a DNSSEC-aware request (how a resolver verifies trust)

    When a DNSSEC-validating resolver receives a request for a domain, it uses this chain of trust to verify the authenticity of the DNS data:

    • Trusting the root: The resolver uses its built-in trust anchor to validate the root zone’s DNSKEY records.
    • Verifying the TLD: The resolver fetches the DS record for .com from the root zone and checks the root’s signature on it with the root’s keys. It then fetches the .com DNSKEY records and confirms that the .com KSK matches the DS record.
    • Verifying your domain: Now trusting the .com keys, the resolver fetches the DS record for example.com from the .com zone and checks the .com signature on it. It then fetches your domain’s DNSKEY records and confirms that your KSK matches that DS record.
    • Verifying data: Your example.com zone signs its regular DNS data (like A, MX, and CNAME records) with RRSIG records. The resolver uses your domain’s validated DNSKEY records to verify those RRSIGs, confirming the data is authentic and unchanged.

Why the chain must remain unbroken

If any link in this chain breaks (for example, if a DS record points to a DNSKEY that no longer exists, or if a signature is missing or invalid), DNSSEC-validating resolvers can’t verify the data. They treat it as untrustworthy and return an error (SERVFAIL) instead of an answer. People using those resolvers can’t reach your website or service until the chain is fixed. For help finding the broken link, see Troubleshoot DNSSEC.

Have more questions?

If you want to explore more DNSSEC terms, take a look at our DNSSEC Glossary. Ready to get started with DNSSEC? Read Enable DNSSEC. If you have further questions or need any assistance, contact our support team, and we will be happy to help. You can also read more about domain and DNS security at DNSimple.