Re: [dnsext] TTL on DS records

[Olafur Gudmundsson <[e-mail]>]

> On Feb 21, 2015, at 3:50 PM, Andrew Sullivan <[e-mail]> wrote:
> 
> On Sat, Feb 21, 2015 at 08:19:34PM +0100, Ralf Weber wrote:
>> I don't see how this will increase latency of page loading. Most
>> recursive resolvers these day do pre fetching for often used records
>> and if the record isn't in the cache the difference in latency comes 
>> from validation anyway.
> 
> Well, this could be, but if you're validating, reducing the TTL on the
> DS automatically entails a lookup as frequently as the DS.  Now of
> course, if browsers are doing this validation themselves (and not
> relying on the system validator), they might pin anyway.

No Andrew it effectively is the MAX( DS TTL, DNSKEY TTL) 
and with prefetching you can compare existing records to the new ones thus avoid validation. 
In most cases there is plenty of headroom for calculations so I think we should be thinking about
what is good for the internet. 
Long TTL’s are good for unstable networks, Short TTL meet customers expectations. 


> 
>> I think we need to move away from TTLs in the days or even week range
>> to TTLs that are in the hours range.
> 
> What do you mean _we_?  Your zone, your rules.  That's part of why I'm
> objecting to parents having very short DS TTLs: it affects what the
> child's cache behaviour is like, and we have historically supposed
> that zone administrators have pretty good control over that for their
> own zones.  If the parent side TTL gets short, then setting the TTL on
> the child side isn't the only thing one can do to affect caching.
> That seems like a pretty big change to the operational environment.

Not putting words in Ralph’s mouth, but I agree with him. 
Long TTL are artifacts of decisions taken long time ago
and they need to be reexamined. 

> 
>> I think one hour is a good TTL for DNSSEC stuff. If your domain
>> isn't asked once an hour in a big providers network chances are it
>> would have fallen out of the cache becuse of LRU anyway during that
>> time frame.
> 
> That could be.  It seems to me that without actually studying this, we
> could all make up numbers.  I gather that OARC is going to run another
> DITL this year.  Maybe that'd be something worth getting large
> recursive operators involved in so that we have something to study.

Yep we need to study and experiment. 
A simple study is to compare how much more traffic a resolver with MAXCACHE = 1H 
asks than one with MAXCACHE = 6H or 12H 

	Olafur