skip to content

How does a DNSSEC-validating resolver build a chain of trust from the root trust anchor down to the A record of www.example.com?

level: middleimportance: must knowfreq 40%

answer

  1. alternate DNSKEY and DS
  2. the DS lives in the parent
  3. digest matches the child's key
  4. that key signs the child's DNSKEY RRset
  5. zone cuts, not every label

basics

~20 s

From the root anchor down, at every zone cut the parent's signed DS must match a digest of a child DNSKEY, and that key must sign the child's DNSKEY RRset. A key of the last zone then verifies the RRSIG over the A record.

solid answer

~40 s

The chain alternates `DNSKEY` and `DS` RRsets, which RFC 4033 writes as `DNSKEY->[DS->DNSKEY]*->RRset`. First, the configured root anchor must match a key in the root's `DNSKEY` RRset, and that key must sign the RRset. A trusted root key then verifies the signed `DS` RRset for `com`, which is stored in the root zone. A `DS` holds the key tag, algorithm and digest of one `com` `DNSKEY`. The resolver hashes the matching key, compares, and requires that key to sign `com`'s whole `DNSKEY` RRset. The same step repeats from `com` to `example.com`. Finally a key in `example.com`'s `DNSKEY` RRset verifies the `RRSIG` over the `www.example.com` `A` RRset. Links exist only at zone cuts: `www` is normally just a name inside `example.com`, not a delegation, so it adds no DS step.

go deeper

for a junior

Recall the three records and their direction: DNSKEY holds a zone's keys, RRSIG signs an RRset, and DS lives in the parent and points down at the child's key.

for a middle

Walk the six steps from the root to the A record aloud, saying at each one which RRset is authenticated and by which key. Name the three conditions RFC 4035 puts on the DS-to-DNSKEY link.

for a senior

Show where the chain really breaks: a DS whose digest matches no published key, a matching key that did not sign the DNSKEY RRset, or a delegated subzone someone forgot. Read the chain zone cut by zone cut, not label by label.

for a principal

Discuss what the parent-vouches-for-child design means for an estate: every registrar and parent operator sits in your chain, and DS updates become a cross-organisation dependency to plan and monitor.

## The idea: each parent vouches for its child's key DNSSEC signs DNS data, but a signature only proves something if the verifying key is trusted. The **chain of trust** (RFC 4033 calls it the *authentication chain*) is how a validating resolver gets from the one key it trusts by configuration - the root **trust anchor** - to the key that signed the answer it is holding. RFC 4033 describes it as "an alternating sequence of DNS public key (DNSKEY) RRsets and Delegation Signer (DS) RRsets", with each link vouching for the next, and gives the typical shape as `DNSKEY->[DS->DNSKEY]*->RRset`. Three record types do the work: - **`DNSKEY`** - a zone's public keys, published as one RRset at the zone apex. - **`RRSIG`** - a signature over one RRset, made with a zone's private key. - **`DS`** (Delegation Signer) - a hash of one of the child zone's `DNSKEY` records, stored in the **parent** zone at the delegation point and signed by the parent. ## The walk for www.example.com Assume the root, `com` and `example.com` are all signed, and `www.example.com` is an ordinary name inside the `example.com` zone. | Step | RRset the resolver authenticates | Where it lives | What makes it trusted | |---|---|---|---| | 1 | root `DNSKEY` RRset | root zone apex | it contains the anchored key, and an `RRSIG` made by that key covers it | | 2 | `DS` RRset for `com` | root zone | an `RRSIG` made by a key in the trusted root `DNSKEY` RRset | | 3 | `com` `DNSKEY` RRset | `com` apex | one key matches the `com` DS, and that key signed the RRset | | 4 | `DS` RRset for `example.com` | `com` zone | an `RRSIG` made by a key in the trusted `com` `DNSKEY` RRset | | 5 | `example.com` `DNSKEY` RRset | `example.com` apex | one key matches the `example.com` DS, and that key signed the RRset | | 6 | `A` RRset for `www.example.com` | `example.com` zone | an `RRSIG` made by a key in the trusted `example.com` `DNSKEY` RRset | Steps 3 and 5 are the heart of the chain. RFC 4035 Section 5.2 says a child's apex `DNSKEY` RRset is authenticated when all of these hold: 1. The `DS` record has itself been authenticated with a key from the parent's `DNSKEY` RRset. 2. The `DS` record's algorithm and key tag match a `DNSKEY` in the child's apex RRset, and hashing that key's owner name and RDATA with the DS digest type gives the DS digest. 3. That matching `DNSKEY` has the Zone Key flag set, and its private key signed the child's apex `DNSKEY` RRset. Once the whole `DNSKEY` RRset is trusted, *every* key in it is trusted. That is how a key that never appears in any `DS` can still sign the zone's ordinary data. ## Why the DS sits in the parent RFC 4034 Section 5 is explicit: the `DS` for `example.com` is stored in the `com` zone, not in `example.com`. RFC 4035 adds that DS RRsets "MUST NOT appear at a zone's apex". The placement is the point. The child cannot vouch for its own key, because a forger could vouch for a forged key just as easily. The parent's signature over a digest of the child's key is the only thing that carries trust across the zone cut. It also explains why the resolver asks the **parent's** servers when it needs a `DS`. ## Key roles are convention, not protocol Usually the key matched by the `DS` is a **key-signing key** (`DNSKEY` flags 257, with the SEP bit set) that signs only the `DNSKEY` RRset. A separate **zone-signing key** (flags 256) signs everything else. That split is operational practice from RFC 6781; RFC 4033 says validation "does not distinguish between key signing keys and other DNSSEC authentication keys". RFC 4034 says validators MUST NOT change their behaviour based on the SEP bit. One combined key that both matches the `DS` and signs the data is legal. ## Labels versus zone cuts "Walking label by label" is a fair picture of where the resolver *looks*, but links exist only where there is a **zone cut**. A label is just one dot-separated piece of a name. `www.example.com` has three labels but, in this example, sits in the third zone of the chain, so there are only two DS links below the root. If `www.example.com` were delegated to its own servers, the walk would gain one more DS-to-DNSKEY pair. When a cut has **no** `DS`, signed proof of that absence ends the chain with an *insecure* rather than a failed result. ## What the resolver does not repeat A resolver does not redo all six steps for every query. Validated `DNSKEY` and `DS` RRsets are cached for their TTLs. A later lookup for `mail.example.com` reuses the trusted `example.com` keys and needs only step 6.

  • Why does a child zone's self-signature over its own DNSKEY RRset not establish trust on its own?
    Anyone can generate a key and sign a key set with it, so a self-signature proves only that the signer holds that key. Trust comes from the parent: its signed `DS` record commits to a digest of one specific child key. Only when that digest matches and the matching key signed the `DNSKEY` RRset does the resolver trust the child's keys.
  • What happens if com holds two DS records for example.com and only one of them matches a key in example.com's DNSKEY RRset?
    One authenticated `DS` whose algorithm, key tag and digest match a zone key that signed the child's `DNSKEY` RRset is enough to authenticate it. RFC 4035 Section 2.4 allows a DS RRset to hold several records and accepts temporary mismatches, since parent and child are only loosely consistent. That is what lets a key change pre-publish a new DS beside the old one.
  • In the walk to www.example.com, which key signs the DS record that the com zone publishes for example.com?
    A key from `com`'s own `DNSKEY` RRset, because the `DS` is authoritative data in the `com` zone and is signed like any other `com` RRset. In the usual split that is `com`'s zone-signing key. Neither `example.com`'s keys nor the root's sign it: the root's job ended when it vouched for `com`'s key set.

Think of a chain of introductions where you trust only one person, met in advance. That person hands you a signed card bearing a fingerprint of the next person's ID; you check the ID against the fingerprint before believing anything that person signs. A stranger's own signed card about themselves proves nothing.

saying these in an interview costs you the question

  • Each label of www.example.com has its own DS record.
  • The child zone publishes its DS record at its own apex.
  • The resolver trusts a key because its DNSKEY flags are 257.
  • The DS record for example.com is signed by example.com's key-signing key.
  • Each zone's whole DNSKEY RRset is signed directly by the parent's key.