Yes. It is correct behavior. There is no revoke method for a publisher. I don't think adding one would be wise.
--Michael (from an iPhone) On Aug 17, 2011, at 7:18, "Marc Lampo" <marc.la...@eurid.eu> wrote: > Hello, > > Experimenting with key roll-over timing conditions, > with a Bind 9.7.3 setup, I noticed, today, that this > version does not re-validate DNSSEC data, once > something makes it into its cache. > > I wonder though, if that is correct ? > > What I noticed : > - some data (with "long" TTL) is queried for a first time > --> answer is with AD bit set (I know : for info only) > and with corresponding RRSIG (generated with old ZSK) > - then I replaced the ZSK : > old ZSK --> new ZSK (a "quick" ZSK roll-over) > and resigned the zone > --> new RRSIG (generated with new ZSK) > - when the DNSKEY RRset timed-out from the caching name server, > I queried for the same data again > (to my surprise) > --> the answer is again with AD bit set, > and again with the (old) RRSIG > (querylog from the auth NS does not show any query > for DNSKEY information) > - indeed, when queried for DNSKEY RRset, with "+norecurse", > --> no DNSKEY's in the cache, 0 returned > - when queried for DNSKEY RRset, *without* "+norecurse", > --> *new* DNSKEY RRset is in the cache > (in the cache are now both the *old* RRSIG and the *new* ZSK) > - again : querying for the initial data (with "long" TTL) > still yields the old RRSIG > (that cannot be decrypted with the new DNSKEY) > > > It looks like once DNSSEC'd data validates correctly, > that version of Bind will keep reusing that data (until TTL expires). > > > While it may make sense, to save on CPU cycles, > I am unsure if that behaviour is correct : > suppose a validating *forwarding* name server > (or validating resolvers in clients, once we they become available) > addresses this caching name server in that "condition". > It would : > 1) receive, from the cache, the data + (old) RRSIG > 2) when queried for it, because the forwarding name server wants to > validate, it will deliver the (new) DNSKEY's > --> validation should now fail !!! > > Very confusing for debugging : > One validating name server yields AD-'d data; > the other, using the first one, yields SERVFAIL ... > > If I overlooked something obvious, > sorry for the interrupt (but thanks for sending clarifying references). > > Thanks and kind regards, > > > Marc Lampo > Security Officer > > EURid > Woluwelaan 150 > 1831 Diegem - Belgium > marc.la...@eurid.eu > http://www.eurid.eu > > > > Want a .eu web address in your own language? Find out how so you don’t > miss out! > > > _______________________________________________ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
