On Nov 7, 2013, at 6:52 AM, Edward Lewis <[email protected]> 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
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
