DNSSEC Trust Anchor History Service NLnet Labs Science Park 1401098 XGAmsterdamThe Netherlands+31-20-888-4551 wouter@nlnetlabs.nl
Internet Area
DNS Extensions Working Group DNSDNSSECDNSKEYhistoryrollovertrust anchor When DNS validators have trusted keys, but have been
offline for a longer period, key rollover will fail and they are stuck
with stale trust anchors. History service allows validators to query for
older DNSKEY RRsets and pick up the rollover trail where they left off.
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119. DNSSEC validators that have been offline
of have missed an (emergency) rollover can use trust history service
to get back on track. The trust history location is assumed available
from the validator configuration. The validator then fetches old DNSKEY
RRsets and checks they form a chain to the latest key. Providers of trust history can fetch the DNSKEY data as published by
the zone they track, and copy-and-paste it. They need not sign nor hold
private keys safe. The algorithms for this are explained below. The algorithm is in steps. Step 1. The validator performs a DNSKEY lookup to the target zone,
which looks like any other initial DNSKEY lookup for a trust anchor.
If the keyset verifies with the trust anchor currently held, the keyset
already works. Otherwise, store this result, the further algorithm either
ends with this result or fails. Step 2. Fetch the trust history list end points. Query type PTR to
the location configured for trust history. Step 3. Go backwards through the trust history list. Verify that the
keyset validly signs the next keyset. This is
validation, but the RRSIG expiration date is ignored. Replace the owner
domain name of the DNSKEY with the target zone name for verification.
Query type PTR to get previous and next locations. Step 4. When the trust anchor currently held by the validator verifies
the keyset, the algorithm is done. The initial DNSKEY from Step 1 is the
result. Use it as the new trust anchor (if using , put it in state VALID). The validator SHOULD store the new trust
anchor on stable storage. The tracker polls the target zone DNSKEY RRset from cron. Ignore
date changes in the RRSIG. If the tracker knows that the zone performs
responsible prepublish KSK rollovers then also
ZSK changes can be ignored. Copy the newly polled DNSKEY RRset and RRSIGs, change the owner
name to "h%d.example" or similar. With %d a new number, and .example the
history location. Publish the new RRset. Publish PTR records that link
list elements. Update PTR records for the list start and end. The list is a double linked list, because this empowers low memory
hosts to perform consistency checks. Thus if there is x.example PTR
y.example then there MUST be y.example PTR x.example. Except at start
and end of list. To find the start of the list, it MUST be a name before the end of the
list in canonical comparison ordering (). With
exactly one list element, one PTR record points to both start and end. In this example tuhi.example.com provides trust history for
example.net. The DNSKEY rdata and RRSIG rdata is omitted for brevity,
it is a literal copy and paste of the data from example.net. The trust history tracker only provides a cached copy of old data.
The history data can be altered or withheld; the lookup algorithm then
fails. Ultimately the security depends on the key that the validator is
holding, and the keys in the chain up to the present. If the old key
held by the validator is too old, the validator MAY not accept this risk,
and then SHOULD perform out of band key priming. The algorithm looks up the initial DNSKEY like other validators do,
and then walks the history in reverse. This avoids exposing the validator
on the network as a host with an older key and the key id. Validators can (OPTIONAL) examine RRSIG dates. To account for clock
skew padding by the target zone, the middle of the inception and expiration
date SHOULD be used, if consistency checks are done. The algorithm can be abused to provide a secure method to get (close
to) the current month or year. Validators without clock then know the
date that validates signatures currently in use by the zone. -