On 2012-03-27, at 20:29, Don Stokes wrote:
Craig Whitmore wrote:
If an ISP (or anyone) is breaking/changing TTL's (and maybe other stuff in DNS) on purpose I would think IMHO this is bad. Think would make DNSSEC signed zones fail + other stuff you have said as the ISP is playing around with it. Um, no, messing with the TTL doesn't break DNSSEC (the TTL isn't signed), although potentially a vastly extended TTL could push caching of a DNSSEC records beyond the expiry of their keys.
Keys in DNSSEC do not have inception or expiry times. Keys don't expire. Signatures expire. The TTL on a DNSKEY is only really relevant in this discussion when it comes to key rollover, but recommended practice for rollovers involves significant delays before keys are withdrawn, long after the last signatures with those keys have been withdrawn. Any TTL mangling of that magnitude is likely to have noticeable impact on customers in general, never mind the (likely tiny) population that validate. And if a cache is broken that badly, either the operator of the cache cares and will fix it, or they don't care and their customers will go somewhere else. Either way, problem solved.
(If a < 24 hour expiry did this, whoever is maintaining the DNSSEC keys is Doing It Wrong.) But in general, every recursive name server updates the TTL of its cached records every time it issues a cached answer to a query.
The required behaviour in the case where RRSIGs expire before their TTL is well-specified in the DNSSEC protocol. I have heard no credible suggestion that common/widespread implementations get this wrong. Modifying TTLs in caches should have zero practical impact on DNSSEC operation. I have limited sympathy for complaints about how caches are operated. If you don't get good results from the cache you're using, use a different one or run your own. Joe