DNSSEC : once correct, always correct ?
Michael Graff
mgraff at isc.org
Wed Aug 17 15:02:11 UTC 2011
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.lampo at 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.lampo at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
More information about the bind-users
mailing list