Single-key rollover

[Alexander Gurvitz]

>
>
> That paragraph from 4.1.4 is just plain wrong and following it will
> lead to cached data that can't be validated once retrieved.
>
> Lets say that all data in the zone has a TTL of 3600.
>
> At T - 3500 you have retrieved the DNSKEY while validating a MX RRset.
> At T - 100 you lookup a A record and validate it with the previously
> validated
> DNSKEY RRset.
> At T you update the zone's contents as per above.
> At T + 100 the DNSKEY RRset expires from the cache.
> At T + 200 a validating stub resolver looks up the A record and gets
> RRSIG(KEY1).  It then does a DNSKEY retrieval and only gets KEY2.
>
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
>

At T+200 resolver will get RRSIG(KEY2). But your idea stands, the last
sentence should read something like this:
"One replaces the DNSKEY_S_1 signatures with signatures
 made with DNSKEY_S_2 AND, AFTER OLD RRSIG EXPIRE FROM CACHES,
 REMOVES DNSKEY_S_1."

The scenario wil be:
1. DNSKEY#1 + RRSIGS#1 + DS#1 (initial state)
2. DNSKEY#1, DNSKEY#2 +  RRSIGS(DNKSEY)#1,#2 + RRSIGS(ZONE)#2 + DS#1 (add
new DNSKEY, sign DNSKEYs with both DNSKEYs, sign zone with new DNSKEY only
(remove old RRSIGs))
3. (wait DNSKEY propagation delay)
4. DNSKEY#1, DNSKEY#2 +  RRSIGS(DNKSEY)#1,#2 + RRSIGS(ZONE)#2 + DS#2
(change DS#1 to DS#2)
5. (wait DS propagation delay + RRSIG propagation delay since step 2)
6. DNSKEY#2 +  RRSIGS#2 + DS#2 (remove DNSKEY#1, and the corresponding
DNSKEY signatures)

Anyhow, my question was if that would be possible to achieve with BIND.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120619/bd4c96af/attachment.html>