Reading a DNSSEC RRSIG line field by field, how do its labels, original TTL, inception and expiration, key tag and signer's name let a validator check it?

seniorshould knowfreq 15%

answer

nine fields, one RRset
labels reveal a wildcard
TTL before caches touched it
UTC seconds, serial arithmetic
tag narrows, does not identify

basics

~20 s

An RRSIG names the type it covers, the algorithm, the owner's label count (smaller means wildcard expansion), the RRset's original TTL, a UTC validity window, and the key tag and signer's name that locate the verifying DNSKEY at the zone apex.

solid answer

~40 s

In www.example.net. RRSIG A 13 3 3600 20100909100439 20100812100439 55648 example.net. ... the fields read: type covered A; algorithm 13; labels 3, equal to the owner's label count, so no wildcard was expanded — a smaller value would mean the answer was synthesised from a wildcard and the validator must rebuild *. plus the rightmost labels to verify. Original TTL 3600 restores the TTL that was signed, since caches decrement it. Expiration and inception are UTC, 32-bit seconds compared with serial number arithmetic; outside the window the RRSIG MUST NOT be used. Key tag 55648, algorithm and signer's name example.net. select candidate DNSKEYs at that zone's apex — the tag is not unique, so every match is tried. The validator also caps the cached TTL at the time left before expiration.

In `www.example.net. RRSIG A 13 3 3600 20100909100439 20100812100439 55648 example.net. ...` the fields read: type covered `A`; algorithm `13`; **labels** `3`, equal to the owner's label count, so no wildcard was expanded — a smaller value would mean the answer was synthesised from a wildcard and the validator must rebuild `*.` plus the rightmost labels to verify. **Original TTL** `3600` restores the TTL that was signed, since caches decrement it. **Expiration** and **inception** are UTC, 32-bit seconds compared with serial number arithmetic; outside the window the RRSIG MUST NOT be used. **Key tag** `55648`, algorithm and **signer's name** `example.net.` select candidate DNSKEYs at that zone's apex — the tag is not unique, so every match is tried. The validator also caps the cached TTL at the time left before expiration.

code

dns · 13 lines

dns

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

example.net. 3600 IN DS 55648 13 2 (
        b4c8c1fe2e7477127b27115656ad6256f424625bf5c1
        e2770ce6d6e37df61d17 )

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 that an RRSIG names the record type it covers, the key that signed it and a start and end time.

for a middle

Explain each field's job, especially why the original TTL and the signer's name are needed to verify.

for a senior

Read a real RRSIG under pressure: spot wildcard expansion from Labels, convert the window to UTC, and explain clock-skew and cache-capping effects.

for a principal

Connect field semantics to policy: how inception offsets and window lengths trade clock tolerance and replay exposure across many zones.

The record, field by field

RFC 4034 §3.1 defines the RRSIG RDATA in this order. The example below is RFC 6605's published ECDSA example (see the code sample):

www.example.net. 3600 IN RRSIG A 13 3 3600 20100909100439 20100812100439 55648 example.net. qx6w...

Field	Value	What a validator does with it
Type Covered	`A`	Must equal the RRset's type
Algorithm	`13` (ECDSAP256SHA256)	Must match the DNSKEY's algorithm
Labels	`3`	Detects wildcard expansion
Original TTL	`3600`	Reconstructs the signed TTL
Signature Expiration	`20100909100439`	Current time must not be later
Signature Inception	`20100812100439`	Current time must not be earlier
Key Tag	`55648`	Narrows the candidate DNSKEYs
Signer's Name	`example.net.`	Zone whose apex DNSKEY RRset holds the key
Signature	Base64	Verified over the RRSIG RDATA plus the RRset

Labels: the wildcard tell

The Labels field counts the labels of the original owner name, excluding the root label and any leading * (RFC 4034 §3.1.3): www.example.net. is 3, *.example.net. is 2. RFC 4035 §5.3.1 requires the answer's owner name to have at least that many labels.

Equal: the RRset was signed under the name it is served under.
Smaller: the server synthesised the answer from a wildcard. An answer for host.example.net (3 labels) carrying an RRSIG with Labels 2 was signed as *.example.net; the validator rebuilds that owner name before verifying.
Larger: impossible for a correct zone, and the RRSIG fails the check.

Proving that no closer name existed, so the wildcard legitimately applied, needs a separate denial-of-existence record; the Labels field only reveals that expansion happened.

Original TTL: undoing the cache

Caching resolvers count TTLs down, but the signature was made over the zone's TTL. The Original TTL field gives the validator the value to put back into the canonical RRset before verifying (RFC 4034 §3.1.4). After validation, RFC 4035 §5.3.3 caps the TTL of the RRset and its RRSIG at the smallest of:

the RRset's TTL as received;
the RRSIG's TTL as received;
the Original TTL field;
the time left until Signature Expiration.

Item 4 is why a validated answer never outlives its signature in a cache.

Inception and expiration: a window in UTC

Both fields are 32-bit unsigned counts of seconds since 1 January 1970 UTC, presented either as that integer or as YYYYMMDDHHmmSS in UTC (RFC 4034 §3.1.5, §3.2). Because the counter wraps, comparisons MUST use serial number arithmetic (RFC 1982), so expiration can be numerically smaller than inception near the wrap and neither field can point more than 68 years away. In the example the window runs from 12 August to 9 September 2010 at 10:04:39 UTC, 28 days.

Two operational readings follow. A validator whose clock is behind the signer's can see a fresh signature as not yet valid, which is why RFC 6781 describes an inception offset, starting the window shortly before the signing time. And the window is per RRset: signatures in one zone can expire at different times (RFC 4033 §8.2).

Key tag, algorithm and signer's name: finding the key

The signer's name MUST be the name of the zone containing the RRset and is sent uncompressed (RFC 4034 §3.1.7). Together with the algorithm and key tag it must match a DNSKEY in that zone's apex DNSKEY RRset with the Zone Key bit set (RFC 4035 §5.3.1). The key tag is a checksum of the DNSKEY RDATA and is not unique; if several keys match, the validator tries each until one verifies or none are left.

A reading checklist

Type covered equals the RRset type; signer's name equals the zone.
Labels no greater than the owner's label count; smaller means wildcard.
Now is between inception and expiration, in UTC.
A DNSKEY with that name, algorithm and tag exists at the apex.

## The record, field by field RFC 4034 §3.1 defines the RRSIG RDATA in this order. The example below is RFC 6605's published ECDSA example (see the code sample): `www.example.net. 3600 IN RRSIG A 13 3 3600 20100909100439 20100812100439 55648 example.net. qx6w...` | Field | Value | What a validator does with it | |---|---|---| | Type Covered | `A` | Must equal the RRset's type | | Algorithm | `13` (ECDSAP256SHA256) | Must match the DNSKEY's algorithm | | Labels | `3` | Detects wildcard expansion | | Original TTL | `3600` | Reconstructs the signed TTL | | Signature Expiration | `20100909100439` | Current time must not be later | | Signature Inception | `20100812100439` | Current time must not be earlier | | Key Tag | `55648` | Narrows the candidate DNSKEYs | | Signer's Name | `example.net.` | Zone whose apex DNSKEY RRset holds the key | | Signature | Base64 | Verified over the RRSIG RDATA plus the RRset | ## Labels: the wildcard tell The Labels field counts the labels of the **original** owner name, excluding the root label and any leading `*` (RFC 4034 §3.1.3): `www.example.net.` is 3, `*.example.net.` is 2. RFC 4035 §5.3.1 requires the answer's owner name to have **at least** that many labels. - Equal: the RRset was signed under the name it is served under. - Smaller: the server synthesised the answer from a wildcard. An answer for `host.example.net` (3 labels) carrying an RRSIG with Labels `2` was signed as `*.example.net`; the validator rebuilds that owner name before verifying. - Larger: impossible for a correct zone, and the RRSIG fails the check. Proving that no closer name existed, so the wildcard legitimately applied, needs a separate denial-of-existence record; the Labels field only reveals that expansion happened. ## Original TTL: undoing the cache Caching resolvers count TTLs down, but the signature was made over the zone's TTL. The Original TTL field gives the validator the value to put back into the canonical RRset before verifying (RFC 4034 §3.1.4). After validation, RFC 4035 §5.3.3 caps the TTL of the RRset and its RRSIG at the smallest of: 1. the RRset's TTL as received; 2. the RRSIG's TTL as received; 3. the Original TTL field; 4. the time left until Signature Expiration. Item 4 is why a validated answer never outlives its signature in a cache. ## Inception and expiration: a window in UTC Both fields are 32-bit unsigned counts of seconds since 1 January 1970 UTC, presented either as that integer or as `YYYYMMDDHHmmSS` in UTC (RFC 4034 §3.1.5, §3.2). Because the counter wraps, comparisons MUST use **serial number arithmetic** (RFC 1982), so expiration can be numerically smaller than inception near the wrap and neither field can point more than 68 years away. In the example the window runs from 12 August to 9 September 2010 at 10:04:39 UTC, 28 days. Two operational readings follow. A validator whose clock is behind the signer's can see a fresh signature as **not yet valid**, which is why RFC 6781 describes an *inception offset*, starting the window shortly before the signing time. And the window is per RRset: signatures in one zone can expire at different times (RFC 4033 §8.2). ## Key tag, algorithm and signer's name: finding the key The signer's name MUST be the name of the zone containing the RRset and is sent uncompressed (RFC 4034 §3.1.7). Together with the algorithm and key tag it must match a DNSKEY in that zone's apex DNSKEY RRset with the Zone Key bit set (RFC 4035 §5.3.1). The key tag is a checksum of the DNSKEY RDATA and is **not unique**; if several keys match, the validator tries each until one verifies or none are left. ## A reading checklist - Type covered equals the RRset type; signer's name equals the zone. - Labels no greater than the owner's label count; smaller means wildcard. - Now is between inception and expiration, in UTC. - A DNSKEY with that name, algorithm and tag exists at the apex.

Why may a DNSSEC RRSIG's Labels value be smaller than the owner name's label count but never larger?
Smaller means the answer was expanded from a wildcard: the signed owner was `*.` plus the rightmost labels, and the wildcard label is not counted. Larger cannot arise from any legitimate signing, since the original name cannot have more labels than the name it was expanded into; RFC 4035 §5.3.1 requires the owner to have at least as many labels as the field states.
Why does an RRSIG carry an Original TTL when the RRSIG record already has its own TTL?
The RRSIG's own TTL is decremented in caches just like the data's, so it no longer shows what was signed. The signature covers the RRset with the zone's TTL, and the validator needs that exact value to rebuild the canonical form. The field also caps how long the validated data may be cached.
A validator reports a freshly signed RRset as not yet valid; what in the RRSIG explains it?
The Signature Inception time is later than the validator's notion of now, usually because the validator's clock lags the signer's or the signer set inception to the exact signing moment. RFC 6781 describes an inception offset — starting the window a little before signing — to absorb clock skew between signers and validators.

saying these in an interview costs you the question

Signature inception and expiration are in the signer's local time zone.
An RRSIG Labels value below the owner's label count means it is corrupt.
The key tag alone pins down exactly one DNSKEY in the zone.
The signature covers whatever TTL the resolver currently holds.
A cache may keep validated data for its full TTL even past signature expiration.
Expiration must always be numerically greater than inception.

Reading a DNSSEC RRSIG line field by field, how do its labels, original TTL, inception and expiration, key tag and signer's name let a validator check it?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

The record, field by field

Labels: the wildcard tell

Original TTL: undoing the cache

Inception and expiration: a window in UTC

Key tag, algorithm and signer's name: finding the key

A reading checklist

▾common follow-ups3 questions

▾red flags6 flags

The record, field by field

Labels: the wildcard tell

Original TTL: undoing the cache

Inception and expiration: a window in UTC

Key tag, algorithm and signer's name: finding the key

A reading checklist

answer

go deeper