Hello,
Remarks below are valid and applicable to both
draft-ietf-dnsop-dnssec-key-timing
and
draft-mekking-dnsop-dnssec-key-timing-bis
>From the first I quote, pg 11, Event 8:
(It is possible that a validating resolver could
have an unexpired RRSIG record and an expired DNSKEY RRset in the
cache when it is asked to provide both to a client. In this case the
DNSKEY RRset would need to be looked up again.)
>From the second I quote, pg 10, 2.5 Delay Timings :
TTL Delay (Dttl): The time it takes to expire the previous
information from the validator caches. This delay depends on what
RRsets need to expire from the caches. If not explicitly
mentioned otherwise, Dttl is considered the maximum TTL of the
information that needs to expire from caches.
Both documents assume that, when a validating caching name server
is being asked a second (or third, or
) time for the same data,
it must/should/will ? also revalidate (data still in cache).
This seems to be, however, an assumption (only ?) :
I fail to find a reference that obliges validating caching name servers
to effectively re-verify the whole chain of trust for each response.
Or is there ?
It might be an implementation issue of the validating caching name server.
It might maintain two caches :
- one for unsigned (or not-validatable - eg: no DS in parent) data;
- one for validatable data
In the latter cache, it can store only if data validates correctly.
When queried later, for something in that second cache, it can deliver
without new validation (saves CPU cycles).
As a matter of fact, as I am experimenting with a Bind 9.7.3 setup,
I do notice that I keep getting authenticated data (I know the AD bit
is "for info" only), even if the ZSK that signed the record has long
been replaced.
The assumption that validating caching name servers must/should
reask for DNSSEC data (if it timed out of the cache) does not seem
to be followed in every implementation.
However I am unsure if that behaviour is correct :
suppose a validating *forwarding* name server 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
My feeling is that TTL should indeed be taken into account;
however, applicable RFC's should also state explicitly that
DNSKEY information *must* be refetched (and if refetched :
Validation must be redone).
If that case, the validating caching name server will reply
SERVFAIL. Which will make debugging more straightforward.
Because in the present implementation :
One validating name server yields AD-'d data;
the other, using the first one, yields SERVFAIL.
--> confusing at least !
If I overlooked any statement that already makes that refetching
a requirement, sorry to have interrupted you
(but please send me the reference)
Thanks and kind regards,
Marc Lampo
Security Officer
EURid
Woluwelaan 150
1831 Diegem - Belgium
[email protected]
http://www.eurid.eu
Want a .eu web address in your own language? Find out how so you dont
miss out!
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
