Thank you Anand and team! Out of curiosity, do you notice an increase in load at your servers? — Moritz

On 20 Apr 2022, at 10:23, Anand Buddhdev <anandb@ripe.net> wrote:

Dear colleagues,

This work has been completed, and all zones are now being published with lower TTLs.

Regards, Anand Buddhdev RIPE NCC

On 11/04/2022 14:44, Anand Buddhdev wrote:

...

Dear colleagues, In 2021, we announced a plan to change the time-to-live (TTL) values in the reverse DNS zones that we maintain. You may view the announcement here: https://www.ripe.net/ripe/mail/archives/dns-wg/2021-November/003928.html Many members of the community expressed support for our proposal. Therefore, we are going to make these changes next week on Wednesday 20 April. We will lower the TTL of NS records to 86400 (1 day) and that of DS records to 3600 (1 hour). Note that the TTL of records imported from other Regional Internet Registries (RIRs) will not be affected. Those records will be imported with the TTLs as published by the origin RIR. Regards, Anand Buddhdev RIPE NCC

--

To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg

On 4/21/22, 4:23 AM, "dns-wg on behalf of Anand Buddhdev" <dns-wg-bounces@ripe.net on behalf of anandb@ripe.net> wrote:

In the past 24 hours, we have not seen *any* increase in the query rate.

I'm not shocked - but if this holds up, it'll seriously challenge the commonly held belief that TTL and query rate are inversely proportional. I once did some work [that could not be made public] where I began to suspect that the two were unrelated.

On 4/21/22, 1:46 PM, "Dave Lawrence" <tale@dd.org> wrote:

Edward Lewis writes:

...

I once did some work [that could not be made public] where I began to suspect that the two were unrelated.

Unrelated, or just less correlated than you might otherwise imagine?

Unrelated. 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. And, in the case of the event, it meant that the event had a far greater impact that it should have. Adhering to the TTL, most resolvers would have "stepped over" the problem (in time) and not noticed. But because many came back pre-TTL-maturely, they stepped into the event. Ever since then I've questioned the conventional wisdom that TTL and query rate were inversely related - as advertised. It seems that time-to-re query is determined more by the resolver's design than the authoritative server's setting of the TTL.

On Thu, Apr 21, 2022 at 2:57 PM, Dave Lawrence <tale@dd.org> wrote:

Edward Lewis writes:

Unrelated, or just less correlated than you might otherwise imagine?

Unrelated.

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.

The "ignored the long TTLs" goes right to the heart of the question though.

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.

Well, in addition to the "standard" 6 hour[0], 1 day [1], 1 week[2] and other[3] 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. 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: $ dig www.example.com @192.0.2.1 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… 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. W [0]: https://developers.google.com/speed/public-dns/faq#:~:text=generally%20limit... [1]: https://github.com/NLnetLabs/unbound/blob/a0feea393a3a7f0ab0f88b3e1aa7a92cee... [2]: https://github.com/isc-projects/bind9/blob/09dccf29b4eb46e133c35acfc84acab37... [3]: https://blog.cloudflare.com/refresh-stale-dns-records-on-1-1-1-1/#:~:text=1.... , although, according to 'dig' at least, it is actually at least 1day? [4]: Modulo if the data cannot be authoritatively refreshed when the TTL expires (see serve-stale)

Conditional correlation != unrelated.

--

To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/ listinfo/dns-wg