DNSSEC : once correct, always correct ?

[Michael Graff]

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