<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">Hi Vahid -<br>
Thanks for the tool; always good to see more people building things for measurement. I'm with Quad9. A few notes/questions/clarifications:</p>
<ol>
<li>
<p dir="auto">Quad9's "primary" should probably be 9.9.9.9 & 149.112.112.112 & 2620:fe::fe - you have us as 149.112.112.13, which is not even listed in our production set of resolvers. See <a href="https://quad9.net/service/service-addresses-and-features/" style="color: #3983C4;">https://quad9.net/service/service-addresses-and-features/</a> for details.</p>
</li>
<li>
<p dir="auto">Are you using IPv6 to connect to resolvers in your tests? That would probably give faster results in some cases.</p>
</li>
<li>
<p dir="auto">Given the latency figures at the bottom of the page, I'm guessing you're testing public resolvers from within a very specific testpoint. If you're only testing to public resolvers from one test point, the data is going to be very skewed and may give people quite non-intuitive (false) impressions. For instance: I'm fairly confident that Quad9 and Cloudflare are not >21ms for the vast majority of the world's population, which is over my repeated tests what seems to be shown.</p>
</li>
<li>
<p dir="auto">The question mark icon beside each testing point does not work. What was it supposed to show?</p>
</li>
<li>
<p dir="auto">Are you performing DNSSEC validation on results? If DNSSEC fails, is there a special error type shown? Hopefully "yes".</p>
</li>
<li>
<p dir="auto">Your test seems to be focusing on recursive resolvers, but that is only half the problem set when you are trying to determine why a zone is not sync'ed. The first half of the problem is un-described by your tool, and that is "does the authoritative anycast array have the correct answers to give?" If you're just measuring what the recursive resolver says, you can't actually identify where the problem is. The only way to identify the actual problem (or at least a closer view, which will still be imperfect) is to have both the recursive resolver AND a direct query to the authoritative servers from the same location. A significant problem with zone synchronization is propagation between anycast instances on the authoritative side of the equation. This will be more visible to you with more testing across zones that have anycast authoritative servers.</p>
</li>
<li>
<p dir="auto">I would expect that clicking on a city name would bring up the list for ALL recursive resolvers, and their answers from that perspective. Quad9, Google, Cloudflare, OpenDNS, and many others have enough anycast nodes that you would need to perform a many-to-many test for all queries in order to determine if results are lagging. Right now, a single test in each geography is not very meaningful. The point of having servers in remote geographies is to test both the authoritative AND recursive behaviors of large arrays (though of course you should still test more local resolver caches as well.)</p>
</li>
<li>
<p dir="auto">I hope you have some math in your system that accounts for TTL when triggering warnings for "out of sync".</p>
</li>
<li>
<p dir="auto">(probably the most important question) How do you even validate correctness of answers? CDNs may have 1000 possible different answers on a specific query, and which one you get varies depending on geography/time/cost/phase of moon/routing/etc. You may only see an A record once across your entire fleet of queries. How do you know this particular IP address is correct for that query, at that time, from that geography? In other words: what is the baseline against which you are testing "correctness"? You can't compare resolvers to each other, and unless you know the ground truth state of the zone from the authoritative's perspective (which may be programmatically generated) then you can't derive that a particular answer is valid or not. So I'm not sure what the tool provides except in the most simplistic cases where there is a non-dynamic answer for a qname/qtype. This may still be enough for some people to find useful but I suspect the people most concerned with zone update latency may not be using static zone data.</p>
</li>
</ol>
<p dir="auto">To answer or clarify some background on your questions:</p>
<ol>
<li>
<p dir="auto">"serve-stale" is a behavior some recursive resolvers utilize (Quad9 does.) If authoritative servers are unreachable, the stale record may be served in lieu of failing. This behavior should be coupled with other indicators that something is wrong with the authoritative server, though those problems may not be visible from your testing vantage point. I don't know if that is the root cause of what you describe, but it exists.</p>
</li>
<li>
<p dir="auto">Can you provide some examples of this DS behavior?</p>
</li>
<li>
<p dir="auto">Again, some examples of CNAME flattening would be useful. Who does this? Do we? Is the answer correct in the A/AAAA result at the end, or is this "breaking" in some way that prevents expected client connection behavior?</p>
</li>
<li>
<p dir="auto">I'd say that expectations of "fully propagated" would be having records updated within ${now}-{$last-ttl-value+2s} in normal conditions. Each resolver may get a query that holds the record for the TTL just before you ask, so you have to assume that the TTL needs to expire before you can trust that an answer has been refreshed. I put the caveat of "in normal conditions" due to serve-stale behavior. You may not know "last-ttl-value" as well unless you're testing prior to change events and are certain that TTL is fixed and not generated per-query so that is another edge case that may catch you.</p>
</li>
</ol>
<p dir="auto">[note: I wrote this when I had a few unexpected minutes of time; replies will be very very slow if at all]</p>
<p dir="auto">JT</p>
<p dir="auto">On 2 Mar 2026, at 9:12, Vahid Shaik wrote:</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">Hello,</p>
<p dir="auto">I have been building and maintaining an open DNS propagation monitoring platform at DNS Robot (<a href="https://dnsrobot.net" style="color: #777777;">https://dnsrobot.net</a><a href="https://dnsrobot.net/" style="color: #777777;">https://dnsrobot.net/</a> ) that queries 30+ globally distributed DNS resolvers simultaneously to track record propagation in real time.</p>
<p dir="auto">During development and ongoing monitoring, I have observed some interesting inconsistencies in how different resolver implementations handle TTL expiry and cache refresh behavior. Specifically:</p>
<ol>
<li>
<p dir="auto">Some major public resolvers (particularly in Asia-Pacific regions) appear to serve stale records well beyond the configured TTL, sometimes by 2-3x the expected duration.</p>
</li>
<li>
<p dir="auto">DNSSEC-signed zones occasionally show inconsistent DS record propagation between parent and child zones during key rollovers, visible when checking multiple resolvers within a short window.</p>
</li>
<li>
<p dir="auto">CNAME flattening behavior varies significantly — some resolvers return the flattened A record while others return the CNAME chain, which can cause confusion when debugging propagation.</p>
</li>
</ol>
<p dir="auto">These observations come from real-time queries across resolvers in 20+ countries. I am curious whether others on this list have documented similar patterns, or if there are known resolver-specific behaviours that explain these discrepancies.</p>
<p dir="auto">I would also welcome any feedback on best practices for measuring propagation completeness — specifically, what threshold of global resolver agreement should be considered "fully propagated” for operational purposes.</p>
<p dir="auto">Best regards,</p>
<p dir="auto">Shaik Vahid</p>
<p dir="auto">DNS Robot — <a href="https://dnsrobot.net" style="color: #777777;">https://dnsrobot.net</a><a href="https://dnsrobot.net/" style="color: #777777;">https://dnsrobot.net/</a></p>
<p dir="auto">Free DNS Propagation Checker & Network Tools</p>
<hr style="border: 0; height: 1px; background: #333; background-image: linear-gradient(to right, #ccc, #333, #ccc);">
<p dir="auto">dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" style="color: #777777;">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" style="color: #777777;">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a></p>
</blockquote>
</div>
</div>
</body>
</html>