Custom DNS Propagation Checker: How to Build One

A custom DNS propagation checker is a script or tool you build yourself to query multiple DNS servers around the world and report which ones have your updated records and which still show the old ones. You enter a domain name and record type, and the checker returns a list of locations with the answer each DNS server gives, plus how long ago that server last updated. This is useful when you change hosting, move email, or update SSL verification records, because DNS changes do not go live everywhere at once.

Why DNS Propagation Is Not Instant

When you change a DNS record, the authoritative server for your domain updates immediately. But every other DNS server on the internet caches the old answer for a period called the TTL (time to live), which is set in seconds on the record itself. A typical TTL is 300 seconds (5 minutes) or 3600 seconds (1 hour). During that window, a resolver that already cached the old record will keep serving it until the TTL expires. After expiry, the resolver re-queries the authoritative server and gets the new value. That is why propagation is not a single switch but a gradual process across thousands of resolvers.

A common misconception is that “propagation” is a global event that takes 24–48 hours. In reality, most public resolvers refresh within a few hours, but some ISPs and corporate resolvers ignore TTLs or have longer caching policies. That is why a custom checker is valuable: it shows you exactly which resolvers still have the old record, so you can decide whether to wait or contact the network administrator.

How to Build a Custom Checker

You can build a simple checker in any language that has a DNS library. Python with dnspython is the most common choice. Here are the steps:

• Choose your resolver list – Use public DNS servers like Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9), and OpenDNS (208.67.222.222). For broader coverage, add regional resolvers from different countries.
• Write the query loop – For each resolver, send a DNS query for the domain and record type. In Python, you can use dns.resolver.Resolver() and set resolver.nameservers = [ip].
• Compare answers – Convert the returned IP addresses or text records to a string and compare with the expected value you hardcode or read from a config file.
• Handle timeouts – Set a socket timeout (e.g., 5 seconds) and catch exceptions so one slow server does not hang the whole script.
• Display results – Print a table with the resolver name, IP, returned value, and status (new, old, timeout). Then show the percentage.

A minimal Python script looks like this (pseudocode):

import dns.resolver
resolvers = ['8.8.8.8', '1.1.1.1', '9.9.9.9']
expected = '93.184.216.34'
for r in resolvers:
    res = dns.resolver.Resolver()
    res.nameservers = [r]
    res.timeout = 5
    try:
        answers = res.resolve('example.com', 'A')
        ips = [str(a) for a in answers]
        status = 'NEW' if expected in ips else 'OLD'
    except Exception:
        status = 'TIMEOUT'
    print(r, status)

For a web-based checker, you would need a backend that can make DNS queries, because browsers cannot directly query DNS. You can use a server-side script (PHP, Node.js, Python) or a serverless function that runs the query and returns JSON.

Choosing the Right Resolvers

The accuracy of your checker depends on which resolvers you query. If you only query Google and Cloudflare, you get a false sense of full propagation because those two update quickly. To get a realistic picture, include:

• Major public resolvers – Google, Cloudflare, Quad9, OpenDNS, and Comodo.
• Regional ISPs – Many countries have popular resolvers like Deutsche Telekom in Germany, KDDI in Japan, or Comcast in the US.
• Geographically diverse servers – At least one per continent to see if there are regional delays.
• Servers with different software – BIND, Unbound, and PowerDNS behave differently.

You can find lists of public DNS servers from sources like the Public DNS Server List, but be aware that some are unreliable or may rate-limit your queries. Start with 10–15 well-known servers and expand if needed.

Common Problems and How to Avoid Them

When building or using a custom checker, you may run into these issues:

• Rate limiting – Public resolvers may block you if you send too many queries in a short time. Add a delay (e.g., 0.2 seconds) between queries.
• False timeouts – Some resolvers block traffic from cloud IPs or require EDNS. Use a longer timeout (10 seconds) and retry once.
• CNAME vs A records – If your domain has a CNAME, the resolver returns the target domain, not an IP. Make sure your comparison handles that.
• IPv6 vs IPv4 – A record queries return IPv4, AAAA return IPv6. If you expect both, query both types separately.
• DNSSEC validation – Some resolvers return SERVFAIL if the DNSSEC chain is broken. That is not a propagation issue; it is a configuration issue.

Another common mistake is checking propagation before the TTL of the old record has expired. If you just changed the TTL from 86400 (24 hours) to 300, the old TTL still applies to cached records. Wait at least the old TTL before expecting full propagation.

When to Use a Custom Checker vs a Free Online Tool

Free online DNS propagation checkers (like whatsmydns.net or dnschecker.org) are convenient because they have a large network of servers already set up. However, they have limitations:

• Limited resolver selection – You cannot choose specific ISPs or regions.
• No automation – You cannot run them from a script or monitor changes continuously.
• Privacy – You are sending your domain queries to a third party.

A custom checker is better if you need to check many domains, integrate with a deployment pipeline, or monitor propagation over time. It also lets you add your own logic, like alerting when a certain percentage is reached. The trade-off is maintenance: you have to keep the resolver list updated and handle edge cases yourself.

Safety and Accuracy Considerations

When using any DNS checker, remember that DNS is not a security tool. A propagation checker cannot tell you if your records have been hijacked or if a resolver is lying. For security-critical checks, use DNSSEC validation and query the authoritative server directly. Also, be careful with the timeout value: a very short timeout (1 second) may produce false timeouts, while a very long one (30 seconds) makes the check slow. A 5-second timeout is a good balance for most public resolvers.

Finally, note that your custom checker only reflects what those specific resolvers see. It does not measure the entire internet. Even if 100% of your chosen resolvers show the new record, some remote ISP may still have the old one. For practical purposes, if all major public resolvers and your target audience’s ISPs show the new record, you can consider propagation complete.

Frequently Asked Questions

How long does DNS propagation really take?

With a typical TTL of 300 seconds, most public resolvers update within 5–15 minutes. However, some ISPs cache for hours or even days. In practice, 95% of resolvers update within 24 hours, but you may see stragglers for up to 72 hours. Your custom checker will show you the exact status.

Can I force DNS propagation to be faster?

No, you cannot force other servers to update faster. You can only lower the TTL before making the change, so that cached records expire sooner. If you already changed the record with a long TTL, you can temporarily set a short TTL and then change the record again after the old TTL expires.

Why does my checker show a different result than an online tool?

Different tools use different resolver lists. An online tool may query 50 servers while your custom checker queries 10. Also, they may use different timeout settings or handle CNAMEs differently. That is why it is important to compare the same resolvers when diagnosing an issue.

What is the best TTL for my DNS records?

For records that change rarely (like MX or TXT), a TTL of 3600 seconds (1 hour) is fine. For records that change often (like A records in a failover setup), use 300 seconds or even 60 seconds. Lower TTL means faster propagation but more queries to your authoritative server.

Does DNS propagation affect email delivery?

Yes. If you change MX records, email servers may still try to deliver to the old server for up to the TTL period. That can cause delays or bounces. Use your checker to monitor MX propagation after changing email hosting.

Can I use a custom checker for all record types?

Yes, you can query A, AAAA, CNAME, MX, TXT, NS, and others. Just be aware that some record types (like CNAME) require special handling because the answer is a domain name, not an IP. Also, some resolvers may not support DNSSEC-related record types like DNSKEY.

Related

• How to Uninstall Zoom on Any Platform
• Track Electronics Prices on Vijay Sales with Daily Screenshots
• Stop Dropbox Photo Imports: Full Guide