Re: TTL on DS records
Andrew Sullivan <[email protected]> Sat, 21 Feb 2015 15:50:34 -0500
| Newsgroups | gmane.ietf.dnsext |
|---|---|
| Message-ID | <[email protected]> |
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. > 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. > 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. A -- Andrew Sullivan [email protected] _______________________________________________ dnsext mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsext