A DNSSEC-signed zone nobody has edited for weeks starts failing validation; how do signature validity windows differ from TTLs, and how should re-signing be scheduled?
answer
- absolute time versus relative time
- signatures expire even when data does not
- refresh period, re-sign period, jitter
- the slack left to fix a stalled signer
basics
~20 sA DNSSEC signature is valid only between the absolute inception and expiration times in its RRSIG, while a TTL only limits caching. An unedited zone still needs re-signing well before expiry, leaving days of slack for a stalled signer.
solid answer
~50 sA TTL is relative: it tells a cache how long to keep an RRset. An `RRSIG`'s inception and expiration are absolute times, and outside them the signature cannot validate - a TTL cannot extend that, and a resolver may cap its cache lifetime at the time left (RFC 4033 §8.1). So a signed zone has a temporal dependency plain DNS lacks: with no edits at all, it goes bogus when its signatures expire, and validating resolvers answer SERVFAIL. RFC 6781 §4.4 schedules re-signing with a **validity period** several times the maximum zone TTL, a **Refresh Period** (renew any signature that close to expiry, at least a TTL and preferably a few days), a shorter **Re-Sign Period** for how often the signer runs, and **jitter** so signatures do not expire together. Refresh minus Re-Sign minus maximum jitter is the time you have to fix a broken signer.
go deeper
Remember that every DNSSEC signature has an expiry date, so a signed zone must be re-signed regularly even when nothing in it changes.
Explain how absolute inception and expiration differ from a relative TTL, and why a TTL can never keep an expired signature usable.
Size validity, Refresh, Re-Sign and jitter so a stalled signer leaves days of slack, and alert on the earliest served expiration, secondaries included.
Weigh replay exposure against recovery time and re-signing load; on a large estate, decide who watches expiry and how quickly someone must act.
## Two clocks: TTL and the validity window Plain DNS has only relative time. A **TTL** says how many seconds a cache may keep an RRset; the SOA's refresh, retry and expire values say how long a secondary server may go without reaching its primary. DNSSEC adds **absolute** time. Each `RRSIG` carries a **signature inception** and a **signature expiration**; RFC 6781 §1.2 calls the span between them the **signature validity period**. RFC 4033 §8.1 keeps the two apart: - A cache still purges an RRset when its TTL runs out, security-aware or not. - A signature can validate only inside its validity period. "TTL values cannot extend the validity period of signed RRsets in a resolver's cache", and a resolver may use the time left before expiration as an upper bound on the cache lifetime. ## Why an unedited zone breaks RFC 4033 §8.2 calls this a "new temporal dependency": a signed zone "requires regular maintenance to ensure that each RRset in the zone has a current valid RRSIG RR". If the signer stops - a failed job, an expired credential for the key store, a full disk - nothing visibly changes until the oldest signatures pass their expiration. Then validating resolvers find no usable signature, classify the data as bogus and return SERVFAIL; Extended DNS Error code 7, Signature Expired (RFC 8914), may say why. Resolvers that do not validate keep answering, which is why the outage looks partial. Re-signing is not free either. Changing any `RRSIG` changes the zone, so the SOA serial must increase and the `SOA` RRset be re-signed, which can trigger NOTIFY messages and zone transfers (RFC 4033 §8.2). ## The scheduling parameters RFC 6781 §4.4.2 names the knobs. None has a protocol-mandated value; each is local policy. | Parameter | Meaning | RFC 6781 guidance | |---|---|---| | Validity period | Inception to expiration of one signature | Several times the maximum zone TTL; a minimum of a few days | | Refresh Period | Signatures this close to expiry are replaced | At least one maximum zone TTL, preferably a few days | | Re-Sign Period | How often the signer visits the zone | Must be smaller than the Refresh Period | | Jitter | Random variation in the validity period | Small, so signatures do not all expire together | | Inception offset | Inception set slightly before signing time | Covers validators with clock skew | The reasoning behind each: 1. **Validity well above the TTL.** If the two were similar, every cached RRset would expire at signature expiration together, and query load on the authoritative servers would peak (RFC 6781 §4.4.1). 2. **Refresh early.** Re-signing just before expiry gives one maximum TTL at best to recover; refreshing a few days ahead survives "a (long) weekend". 3. **Know your slack.** In the worst case the next signatures to expire are Refresh minus Re-Sign away from expiry; subtract the maximum jitter and you have the time in which "operational havoc can be resolved" (RFC 6781 §4.4.2.2). 4. **Do not stretch it without limit.** A signed RRset can be replayed until its signature expires, so a long validity period lets an attacker keep serving old data - an address you have since changed, say (RFC 6781 §4.4.2.1). ## A worked policy Take an example policy, chosen for illustration rather than drawn from any RFC: maximum zone TTL 1 day, validity period 21 days, Refresh Period 7 days, Re-Sign Period 1 day, jitter up to 1 day, inception offset 1 hour. - Validity is 21 times the maximum TTL, so caches do not expire in step with signatures. - The Refresh Period of 7 days exceeds one maximum TTL. - Slack for a stalled signer: 7 - 1 - 1 = **5 days**. ## Secondaries and the SOA expire timer A secondary that cannot reach its primary keeps serving the zone until the SOA expire timer runs out, and "there exists no coupling between the signature expiration of RRSIGs in the zone and the expire parameter in the SOA" (RFC 6781 §4.4.1). A secondary can therefore serve expired signatures. RFC 6781 suggests an SOA expire of roughly a third to a quarter of the validity period, ideally no longer than the Refresh Period; in the example, 5 days is about a quarter of 21 and fits inside the 7-day Refresh Period. It also suggests secondary operators monitor upcoming signature expirations. The practical rule: alert on the earliest RRSIG expiration served by every authoritative server, not on whether the signer process is running.
- Why set an RRSIG's inception time slightly before the moment of signing?Because validators' clocks are not perfect. RFC 6781 §4.4.2.2 calls the back-dating the inception offset: a validator whose clock runs a little behind would otherwise see a freshly published signature as not yet valid and treat the data as bogus. Choose it large enough to make such false failures rare.
- Why not use a one-year validity period and stop worrying about re-signing?Because a signed RRset can be replayed until its signature expires. If you change a record, an attacker holding the old signed copy can keep serving it as valid for the rest of that window (RFC 6781 §4.4.2.1). Long windows also let the re-signing routine fall out of practice. The validity period trades replay exposure against time to recover.
- How can a DNSSEC zone go bogus on one secondary while the primary looks healthy?The secondary may have lost contact with the primary and kept serving its last copy, because the SOA expire timer is relative to the last successful refresh while signatures expire at absolute times. RFC 6781 §4.4.1 notes there is no coupling between the two and suggests an SOA expire around a quarter to a third of the validity period, plus monitoring of signature expiry.
saying these in an interview costs you the question
- A long TTL keeps a signed answer valid after its RRSIG expires.
- A zone that nobody edits never needs re-signing.
- Signatures are best refreshed at the last moment before they expire.
- The SOA expire timer stops secondaries serving expired signatures.
- The DNSSEC protocol fixes the signature validity period at 30 days.
- Longer validity periods are always safer because outages become rarer.