DNS propagation inconsistencies across European resolvers — observations and data
Hi team, I've been investigating DNS propagation behavior across European resolvers and wanted to share some observations that might be useful to the group. When testing DNS record changes (particularly A, AAAA, and MX records) across resolvers in different RIPE member regions, I've noticed significant inconsistencies in how quickly changes propagate — even when TTLs are identical. Some examples: * Records with TTL 300 updated within 5 minutes on Cloudflare (1.1.1.1) and Google (8.8.8.8), but took 15-25 minutes on several ISP resolvers in DE, NL, and FR. * CNAME chains with 3+ levels caused noticeably slower propagation compared to direct A records, particularly on resolvers that don't support aggressive NSEC caching (RFC 8198). * Some ISP resolvers appear to enforce a minimum TTL floor (often 300-600s), overriding the authoritative server's lower TTL values. For anyone investigating similar behaviour, I've found it helpful to query the same record from multiple global locations simultaneously to identify which resolvers are lagging. We built a tool called DNS lookup<https://dnsrobot.net/dns-lookup> that does this at it queries from 20+ server locations in parallel and shows per-location results with response times. Has anyone else on the list observed ISP resolvers in the RIPE region enforcing minimum TTL values? RFC 8767 (Serving Stale Data) seems related, but I'm curious whether this is intentional policy or just aggressive caching implementations. Regards, Vahid
Can you give us concrete examples of your investigation? Because right now, this looks like nice wrapped SEO spam. Ondrej -- Ondřej Surý (He/Him) A gentle nudge is always appreciated if I take a little longer to reply.
On 9. 3. 2026, at 2:31, Vahid Shaik <vahid@> wrote: When testing DNS record changes (particularly A, AAAA, and MX records) across resolvers in different RIPE member regions, I've noticed significant inconsistencies in how quickly changes propagate — even when TTLs are identical. Some examples:
Well, If anyone of you had any doubts before - I got this AI slop answer in my private email: Fair point — here are specific examples from tests I ran this week: Domain: example-test.de (a domain I manage) Record changed: A record, TTL 300 Time: 2026-03-07 14:00 UTC Results after TTL expiry: - 1.1.1.1 (Cloudflare): updated in 5m 12s - 8.8.8.8 (Google): updated in 5m 48s - 9.9.9.9 (Quad9): updated in 6m 03s - Deutsche Telekom (194.25.0.60): updated in 22m 15s - Vodafone DE (139.7.30.126): updated in 18m 41s - Orange FR (80.10.246.2): updated in 15m 33s The ISP resolvers consistently took 3-4x longer than the public resolvers, despite the same 300s TTL. I repeated this across 5 different domains with similar results. The minimum TTL floor observation came from testing with TTL 60 — the public resolvers respected it, but the ISP resolvers returned stale results for 300+ seconds, suggesting they enforce a floor. Ondrej -- Ondřej Surý (He/Him) A gentle nudge is always appreciated if I take a little longer to reply.
On 9. 3. 2026, at 6:45, Ondřej Surý <ondrej@sury.org> wrote:
Can you give us concrete examples of your investigation?
Because right now, this looks like nice wrapped SEO spam.
Ondrej -- Ondřej Surý (He/Him)
A gentle nudge is always appreciated if I take a little longer to reply.
On 9. 3. 2026, at 2:31, Vahid Shaik <vahid@> wrote: When testing DNS record changes (particularly A, AAAA, and MX records) across resolvers in different RIPE member regions, I've noticed significant inconsistencies in how quickly changes propagate — even when TTLs are identical. Some examples:
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/dns-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
$ whois example-test.de Domain: example-test.de Status: free Heh. Tell them to try with example.com next, maybe they also registered that domain. :-) -- Marc van der Wal
:-) Yeah, that’s why I said AI slop. These people don’t even bother to read, they just copy&paste. Well, I already did my part of identifying the SEO spammer. Now it is up to the chairs whether they take any action or not. Ondrej -- Ondřej Surý (He/Him) A gentle nudge is always appreciated if I take a little longer to reply.
On 9. 3. 2026, at 8:15, Marc van der Wal via dns-wg <dns-wg@ripe.net> wrote:
Heh. Tell them to try with example.com next, maybe they also registered that domain. :-)
Vahid Shaik writes:
Has anyone else on the list observed ISP resolvers in the RIPE region enforcing minimum TTL values? RFC 8767 (Serving Stale Data) seems related, but I'm curious whether this is intentional policy or just aggressive caching implementations.
Highly unlikely to be 8767-related. Serve Stale is intended for exceptional circumstances, when a resolver has tried to refresh expired data but failed to. Cache Minimum TTLs are a different matter.
participants (4)
-
Dave Lawrence -
Marc van der Wal -
Ondřej Surý -
Vahid Shaik