Re: [dnsext] TTL on DS records

[Ralf Weber <[e-mail]>]

Moin!

On Sat, Feb 21, 2015 at 03:50:34PM -0500, Andrew Sullivan wrote:
> 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.
Don't most browser validators still use at least the system stub 
resolvers and thus your configured recursive resolver anyway? What 
you describe is correct, but the lookup only has to fill the DS
from the parent and nothing from the child (unless it expired of
course).

> > 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_? 
The DNS community within the IETF (and possible other venues).

> 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.
Yes there may be one round trip to the parent name server when
the DS expires, but you still control how often your server is
asked with the TTL of your records (unless there is an attack ;-).

> 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.
You have to as in the DITL run you might not see the effect of 
different DS TTL because the root might not be asked in the
cache refill scenario.

Just one side note of personal experience running or helping people
to run large resolver farms over the last 20 years. While the average
TTL, especially for often used records has gone down during that 
time frame, the cache hit rate has gone up. These days it is not
uncommon to see cache hit rates of 90% or more. So I don't think
lowering the TTL of the DS record will have an impact on the cache
hotness and thus performance of resolution.

So long
-Ralf