> > > 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: [email protected] >
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
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/bind-users
