[dns-operations] Opinions sought .... have I come to the right place?

[Olafur Gudmundsson]

On Nov 7, 2013, at 6:52 AM, Edward Lewis <Ed.Lewis at neustar.biz> wrote:

> I've been studying TTL settings off and on for a few weeks, trying to decide what are appropriate numbers.
> 
> In the past we taught the trade-off as - longer TTLs will reduce queries while shorter TTLs will enable agility.
> 
> In looking at a set of data with a long TTL - 6 days - over a period of time I noticed that 0.005% of all queriers respected the TTL setting I had.  I don't want to fork over details, so you can even say "0.005% +/- 5%" and in any case, it's small.  I'll admit by number here might be a little bit of an undercount, still, it's little.
> 
> In experimenting with some recursive servers (and by no means an exhaustive set), some code bases did adhere to the "rules" and some code bases seem to ignore the "rules."  I say this to the extent that the collective set of deployed tools out there pretty much are eating into the "longer TTLs will reduce queries" part of the above trade-off.
> 
> I see that in the IETF there are drafts to pre-fetch expiring data sets - which one can't argue with - but it makes, for an authoritative server operator - even more uncertainty in planning TTLs.
> 
> And I'll throw in another factoid from history.  During DNSSEC workshops eons ago, we found that is the TTLs got too low, DNSSEC had problems.  (Presumably because it took longer to fetch the chain than the TTL of the queried data.)  Has anyone found a TTL to be too low for DNSSEC?
> 
> So, I'm turning to this list...what is a good range for TTLs?

I want to point out that some resolver implementation have a MAX_TTL value i.e. will not cache anything for more than certain value. 
One of the questions is what is a good value for MAX_TTL?

Unbound for example has set this to 1 day, no comment if that is a good choice but it is not a bad one. 

	Olafur