<html><head></head><body><div><div><div class=""><div class=""><div class=""><div class=""><br></div></div><div><br></div><div class="sh-signature"><div class="gmail_signature"><br></div></div></div><div><br></div><div class="sh-quoted-content"><div class=""><div class="gmail_quote"><div>On Thu, Apr 21, 2022 at 2:57 PM, Dave Lawrence <span dir="ltr" class=""><<a href="mailto:tale@dd.org" target="_blank" class="">tale@dd.org</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote" style="null" id="null"><p class="">Edward Lewis writes:
<br></p><blockquote class=""><blockquote class=""><p class="">
Unrelated, or just less correlated than you might otherwise imagine?
<br></p></blockquote><p class="">
Unrelated.
<br></p><p class="">
I'd studied an event which made it apparent that resolvers vastly
ignored the long TTLs in play. At the time I learned that two
popular strains of resolver code had an "internal" limit on the TTL
they would accept [which is old news now], meaning any authoritative
server operator who was banking on long TTLs to lower traffic was
not going to realize any benefit.
<br></p></blockquote><p class="">
The "ignored the long TTLs" goes right to the heart of the question
though.
<br></p><p class="">
If you tell me something akin to "it looks like TTLs under six hours
impact query refresh rate but then starts a rapid decline to where
almost no TTLs are honored for longer than 24 hours" then I'd say that
does not indicate TTLs and traffic are unrelated, just related in a
smaller window than those favoring long TTLs would hope.<br></p></div></div></blockquote></div></div></div></div><div><div><br></div><div><br></div><div>Well, in addition to the "standard" 6 hour[0], 1 day [1], 1 week[2] and other[3]<br></div><div>MAX_TTL caps, it is also worth remembering that the TTL is the **maximum** time that a record should be cached[4], not the "you must cache for exactly this time". Records can be evicted from the cache (or otherwise not used) for all sorts of reasons before the TTL expires, including running low on memory, more specific ECS, delegation revalidation, restarts, etc. <br></div><div><br></div><div>I know that y'all already know this, but it's worth repeating because I quite frequently see people (especially in enterprise environments) doing something like:<br></div><div>$ dig <a href="http://www.example.com/">www.example.com</a> @<a href="http://192.0.2.1">192.0.2.1</a><br></div><div>seeing that the TTL is e.g 5h37m, and then assuming that their resolution will continue to work for at least five and a half hours…<br></div><div><br></div><div>A while back there was a good presentation (I think at an OARC) where someone set a long TTL and then timed how quickly it was evicted from a bunch of open public resolvers - I cannot easily find the presentation at the moment, but a surprising number of records disappeared before the TTL reached 0. </div><div><br></div><div>W</div><div><br></div><div><br></div><div>[0]: <a href="https://developers.google.com/speed/public-dns/faq#:~:text=generally%20limited%20to%20six%20hours">https://developers.google.com/speed/public-dns/faq#:~:text=generally%20limited%20to%20six%20hours</a><br></div><div>[1]: <a href="https://github.com/NLnetLabs/unbound/blob/a0feea393a3a7f0ab0f88b3e1aa7a92cee0e0bb8/util/config_file.c#L168">https://github.com/NLnetLabs/unbound/blob/a0feea393a3a7f0ab0f88b3e1aa7a92cee0e0bb8/util/config_file.c#L168</a><br></div><div>[2]: <a href="https://github.com/isc-projects/bind9/blob/09dccf29b4eb46e133c35acfc84acab37403866e/bin/named/config.c#L170">https://github.com/isc-projects/bind9/blob/09dccf29b4eb46e133c35acfc84acab37403866e/bin/named/config.c#L170</a><br></div><div>[3]: <a href="https://blog.cloudflare.com/refresh-stale-dns-records-on-1-1-1-1/#:~:text=1.1.1.1%20caches%20DNS%20entries%20for%20up%20to%203%20hours">https://blog.cloudflare.com/refresh-stale-dns-records-on-1-1-1-1/#:~:text=1.1.1.1%20caches%20DNS%20entries%20for%20up%20to%203%20hours</a> , although, according to 'dig' at least, it is actually at least 1day?<br></div><div>[4]: Modulo if the data cannot be authoritatively refreshed when the TTL expires (see serve-stale)<br></div><div><br></div><div><br></div></div><div class=""><div class="sh-quoted-content"><div class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote" style="null" id="null"><p class="">
<br></p><p class="">
Conditional correlation != unrelated.
<br></p><p class="">
--
<br></p><p class="">
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: <a target="_blank" rel="noopener noreferrer" href="https://mailman.ripe.net/" class="">https:/<wbr>/<wbr>lists.<wbr>ripe.<wbr>net/<wbr>mailman/<wbr>listinfo/<wbr>dns-wg</a><br></p></div></div></blockquote></div></div></div></div><div><br></div></div><div></div></div></body></html>