When a DNSSEC-validating resolver receives a signed A record, what does it fetch and check before it treats the answer as secure?

middleshould knowfreq 24%

answer

the signature and the key behind it
owner, type, signer, labels
inception before now before expiration
key tag and algorithm pick the key
canonical form, then verify

basics

~20 s

It needs the RRSIG over the A RRset and the zone's authenticated DNSKEY RRset. It checks the RRSIG matches the RRset, its validity window and a zone key, then verifies the signature over the canonical RRset.

solid answer

~50 s

With DO set, the answer carries the RRSIG covering the A RRset; the resolver also needs the zone's apex DNSKEY RRset, which it fetches if it does not hold it and which must itself be authenticated, through the parent's DS or a trust anchor. RFC 4035 §5.3.1 then checks before any cryptography: same owner and class, Type Covered is A, Signer's Name is the zone holding the RRset, Labels is not more than the owner's label count, the current time lies between Inception and Expiration, and Signer's Name, Algorithm and Key Tag match a DNSKEY with the Zone Key flag. It rebuilds the signed data (RRSIG RDATA minus the signature, plus the RRset in canonical form and order, using the Original TTL) and verifies it, trying each matching key. One valid RRSIG makes the RRset secure (RFC 6840 §5.4); if none verifies, it is bogus.

With `DO` set, the answer carries the `RRSIG` covering the `A` RRset; the resolver also needs the zone's apex `DNSKEY` RRset, which it fetches if it does not hold it and which must itself be authenticated, through the parent's `DS` or a trust anchor. RFC 4035 §5.3.1 then checks before any cryptography: same owner and class, `Type Covered` is `A`, `Signer's Name` is the zone holding the RRset, `Labels` is not more than the owner's label count, the current time lies between `Inception` and `Expiration`, and `Signer's Name`, `Algorithm` and `Key Tag` match a `DNSKEY` with the Zone Key flag. It rebuilds the signed data (RRSIG RDATA minus the signature, plus the RRset in canonical form and order, using the `Original TTL`) and verifies it, trying each matching key. One valid RRSIG makes the RRset secure (RFC 6840 §5.4); if none verifies, it is bogus.

code

dns · 9 lines

dns

example.net. 3600 IN DNSKEY 257 3 13 (
        GojIhhXUN/u4v54ZQqGSnyhWJwaubCvTmeexv7bR6edb
        krSqQpF64cYbcB7wNcP+e+MAnLr+Wi9xMWyQLc8NAA== )

www.example.net. 3600 IN A 192.0.2.1
www.example.net. 3600 IN RRSIG A 13 3 3600 (
        20100909100439 20100812100439 55648 example.net.
        qx6wLYqmh+l9oCKTN6qIc+bw6ya+KJ8oMz0YP107epXA
        yGmt+3SNruPFKG7tZoLBLlUzGGus7ZwmwWep666VCw== )

go deeper

for a junior

Recall the pieces: the answer comes with an RRSIG, the key lives in the zone's DNSKEY RRset, and the resolver checks the signature with that key before trusting the answer.

for a middle

Walk through RFC 4035's checks in order: owner, type, signer, labels, validity window, key tag and algorithm, Zone Key flag, then canonical reconstruction with the Original TTL and the cryptographic verify.

for a senior

Connect each check to a failure you would see: a window that has closed, a key tag with no matching DNSKEY, a signature rejected because the validator's clock is wrong, and why one valid RRSIG out of several is enough.

for a principal

Discuss the cost side: every verification is CPU spent on a resolver serving many clients, which is why caching validated results, capping TTLs at expiry and keeping a BAD cache for persistent failures matter at scale.

What arrives and what is missing

A DNSSEC signature is an RRSIG record covering one RRset: all records with the same owner name, class and type, such as every A record for www.example.net. When a resolver sends its query with the DO bit set, a signed zone's servers return the A RRset together with its RRSIG. That is not enough to check anything: the resolver also needs the public key, which lives in the zone's apex DNSKEY RRset. RFC 4035 §4.2 lets a resolver query for missing security records, so it fetches example.net DNSKEY if it is not already cached.

The key itself must be trustworthy before it proves anything. RFC 4035 §5.3.1 says a matching DNSKEY counts as authentic only if the apex DNSKEY RRset is authentic, or if the DNSKEY matches an authenticated DS from the parent or a configured trust anchor. Building that link up to the root is the chain of trust, a separate subject; this answer is the check at one zone.

The checks before any cryptography

RFC 4035 §5.3.1 lists conditions the RRSIG must meet before it is used. All of them must hold:

the RRSIG and the RRset have the same owner name and class;
the Signer's Name is the name of the zone that contains the RRset (not the record's own name);
the Type Covered field equals the RRset's type, here A;
the owner name's label count is at least the Labels field; a smaller Labels value means the answer came from a wildcard, which needs an extra denial-of-existence proof that no closer name matched;
the validator's current time is no later than Expiration and no earlier than Inception, compared with serial-number arithmetic (RFC 4034 §3.1.5);
the Signer's Name, Algorithm and Key Tag match some DNSKEY in the apex DNSKEY RRset, and that key has the Zone Key flag (bit 7) set.

A key tag is a 16-bit value that does not uniquely identify a key (RFC 4034 Appendix B), so several DNSKEY records may match. The validator must try each one until a signature verifies or it runs out of keys.

Rebuilding exactly what was signed

The signer computed the signature over bytes the resolver never receives as such. RFC 4035 §5.3.2 says to reconstruct them:

Take the RRSIG RDATA without the Signature field, with the Signer's Name in canonical form.
Append each record of the RRset in canonical form: lower-cased names, no compression, and the Original TTL from the RRSIG in place of the received TTL, because every cache on the way decremented it.
Sort the records into canonical order, since the signer sorted them and the wire order may differ.
Verify the Signature field over that data with the public key from the matching DNSKEY, using the algorithm the Algorithm field names, such as 13 for ECDSAP256SHA256.

Verdicts

Outcome	What happened	What the resolver does
Secure	at least one `RRSIG` verified with an authenticated key	returns the data and may set `AD`
Bogus	the zone should be signed, but no `RRSIG` verified or a needed record is missing	returns SERVFAIL (RFC 4035 §5.5) unless the query set `CD`
Insecure	the resolver knows no chain of trust reaches this RRset	returns the data without `AD`

RFC 6840 §5.4 settles the multiple-signature case: a resolver should accept any valid RRSIG and call the RRset bogus only if all fail, because a stricter rule would break during a double-signature key rollover. RFC 6840 §5.12 adds that signatures from keys absent from the DNSKEY RRset are disregarded rather than treated as failures.

An accepted RRset also gets a capped TTL. RFC 4035 §5.3.3 sets it to no more than the smallest of the RRset's received TTL, the RRSIG's received TTL, the Original TTL field, and the time left until Expiration, so a cached answer never outlives its signature.

Reading a real example

RFC 6605 §6.1 shows www.example.net's A record signed with an algorithm 13 key whose key tag is 55648. Here a single key with flags 257 does both jobs, which is legal; the split into separate key-signing and zone-signing keys is operational practice. For a validator, the Labels value of 3 equals the label count of www.example.net, so no wildcard is involved; the Signer's Name is the zone example.net; and the window runs from 2010-08-12 10:04:39 to 2010-09-09 10:04:39 UTC. A validator checking it on 2010-09-15 rejects it at the time check without doing any cryptography.

## What arrives and what is missing A DNSSEC signature is an `RRSIG` record covering one **RRset**: all records with the same owner name, class and type, such as every `A` record for `www.example.net`. When a resolver sends its query with the `DO` bit set, a signed zone's servers return the `A` RRset together with its `RRSIG`. That is not enough to check anything: the resolver also needs the public key, which lives in the zone's **apex `DNSKEY` RRset**. RFC 4035 §4.2 lets a resolver query for missing security records, so it fetches `example.net DNSKEY` if it is not already cached. The key itself must be trustworthy before it proves anything. RFC 4035 §5.3.1 says a matching `DNSKEY` counts as authentic only if the apex `DNSKEY` RRset is authentic, or if the `DNSKEY` matches an authenticated `DS` from the parent or a configured trust anchor. Building that link up to the root is the chain of trust, a separate subject; this answer is the check at one zone. ## The checks before any cryptography RFC 4035 §5.3.1 lists conditions the `RRSIG` must meet before it is used. All of them must hold: - the `RRSIG` and the RRset have the **same owner name and class**; - the **`Signer's Name`** is the name of the zone that contains the RRset (not the record's own name); - the **`Type Covered`** field equals the RRset's type, here `A`; - the owner name's label count is **at least the `Labels` field**; a smaller `Labels` value means the answer came from a wildcard, which needs an extra denial-of-existence proof that no closer name matched; - the validator's current time is **no later than `Expiration`** and **no earlier than `Inception`**, compared with serial-number arithmetic (RFC 4034 §3.1.5); - the `Signer's Name`, **`Algorithm`** and **`Key Tag`** match some `DNSKEY` in the apex `DNSKEY` RRset, and that key has the **Zone Key flag** (bit 7) set. A key tag is a 16-bit value that does not uniquely identify a key (RFC 4034 Appendix B), so several `DNSKEY` records may match. The validator must try each one until a signature verifies or it runs out of keys. ## Rebuilding exactly what was signed The signer computed the signature over bytes the resolver never receives as such. RFC 4035 §5.3.2 says to reconstruct them: 1. Take the `RRSIG` RDATA without the `Signature` field, with the `Signer's Name` in canonical form. 2. Append each record of the RRset in canonical form: lower-cased names, no compression, and the **`Original TTL`** from the `RRSIG` in place of the received TTL, because every cache on the way decremented it. 3. Sort the records into canonical order, since the signer sorted them and the wire order may differ. 4. Verify the `Signature` field over that data with the public key from the matching `DNSKEY`, using the algorithm the `Algorithm` field names, such as 13 for ECDSAP256SHA256. ## Verdicts | Outcome | What happened | What the resolver does | |---|---|---| | Secure | at least one `RRSIG` verified with an authenticated key | returns the data and may set `AD` | | Bogus | the zone should be signed, but no `RRSIG` verified or a needed record is missing | returns SERVFAIL (RFC 4035 §5.5) unless the query set `CD` | | Insecure | the resolver knows no chain of trust reaches this RRset | returns the data without `AD` | RFC 6840 §5.4 settles the multiple-signature case: a resolver **should accept any valid `RRSIG`** and call the RRset bogus only if all fail, because a stricter rule would break during a double-signature key rollover. RFC 6840 §5.12 adds that signatures from keys absent from the `DNSKEY` RRset are disregarded rather than treated as failures. An accepted RRset also gets a capped TTL. RFC 4035 §5.3.3 sets it to no more than the smallest of the RRset's received TTL, the `RRSIG`'s received TTL, the `Original TTL` field, and the time left until `Expiration`, so a cached answer never outlives its signature. ## Reading a real example RFC 6605 §6.1 shows `www.example.net`'s `A` record signed with an algorithm 13 key whose key tag is 55648. Here a single key with flags 257 does both jobs, which is legal; the split into separate key-signing and zone-signing keys is operational practice. For a validator, the `Labels` value of 3 equals the label count of `www.example.net`, so no wildcard is involved; the `Signer's Name` is the zone `example.net`; and the window runs from 2010-08-12 10:04:39 to 2010-09-09 10:04:39 UTC. A validator checking it on 2010-09-15 rejects it at the time check without doing any cryptography.

Why must the DNSKEY be authenticated before it can verify the A record's RRSIG?
Anyone able to forge the `A` record could forge a `DNSKEY` and a matching signature in the same reply. RFC 4035 §5.3.1 notes the check is only meaningful if the key is authenticated first: the apex `DNSKEY` RRset must be authentic, which means a key in it matches an authenticated `DS` from the parent or a configured trust anchor and signs that RRset.
Several DNSKEY records match an RRSIG's key tag and algorithm; what does the validator do?
Key tags are 16-bit values and RFC 4034 says implementations must not assume they identify a single key. RFC 4035 §5.3.1 and §5.3.3 therefore require the validator to try each matching `DNSKEY` until the signature verifies or it runs out of candidates; only then does that `RRSIG` count as failed.
An RRset arrives with TTL 3600, its RRSIG with TTL 3600 and Original TTL 3600, and the signature expires in 1200 seconds; what TTL does the validator allow?
1200 seconds. RFC 4035 §5.3.3 caps an accepted RRset's TTL at the smallest of the received RRset TTL, the received `RRSIG` TTL, the `Original TTL` field and the time remaining until `Expiration`. Here three values are 3600 and the remaining validity is 1200, so the cached answer cannot outlive the signature.

saying these in an interview costs you the question

The validator trusts the DNSKEY that arrived in the same response.
The RRSIG's Signer's Name must equal the record's own owner name.
An expired RRSIG still validates as long as the key verifies it.
Every RRSIG over an RRset must verify, or the RRset is bogus.
The signature covers the TTL exactly as the resolver received it.

When a DNSSEC-validating resolver receives a signed A record, what does it fetch and check before it treats the answer as secure?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What arrives and what is missing

The checks before any cryptography

Rebuilding exactly what was signed

Verdicts

Reading a real example

▾common follow-ups3 questions

▾red flags5 flags

What arrives and what is missing

The checks before any cryptography

Rebuilding exactly what was signed

Verdicts

Reading a real example

answer

go deeper