Check DNS propagation

Check propagation in DNSPeek

On the link's page, open the Switch DNS step of the migration checklist: the switch screen shows each resolver as it picks up the new server, the share that already has it and the highest TTL still cached. Click I've changed the record once you have changed it, then Check again (paid plans re-check every minute while the screen is open). The same check is also in the link settings: Check now in the DNS propagation section. DNSPeek asks 16 public resolvers for your domain and compares their answers with the link’s server IP (an A record for IPv4, AAAA for IPv6). You see each resolver’s answer and TTL, and the share that already returns the new IP.

One-off checks are available on every plan. Repeated clicks within a minute show the latest result.

Resolvers checked: Google, Cloudflare, Quad9, OpenDNS, AdGuard, Level3 / Lumen, UltraDNS Public, Yandex, CleanBrowsing, NextDNS, Control D, DNS4EU, CIRA Canadian Shield, HiNet, AliDNS, Hurricane Electric. They are asked from DNSPeek's server, so anycast resolvers answer from their location nearest to it.

When DNSPeek calls it propagated

• At least 90% of the resolvers that answered return the new IP.
• At least half of all resolvers answered. Resolvers that time out or refuse the query are left out of the percentage, so one unreachable resolver cannot hold you back.

The result also shows the highest TTL seen: caches that still have the old IP may keep it for up to that many seconds.

Sites on Cloudflare

Cloudflare answers DNS with the address of an edge server near each resolver, so resolvers in different regions return different Cloudflare IPs for the same site (for example 188.114.96.3, 104.21.66.63 and 172.67.201.135). DNSPeek handles both ways a migration can involve Cloudflare:

• The link's server IP is a Cloudflare address (you are moving the site onto Cloudflare): a resolver counts as matched when every address it returns belongs to Cloudflare's published ranges, whichever edge it is. Resolvers that still return the old host's IP count as not yet switched. Each resolver row is tagged Cloudflare next to the raw addresses.
• The link's server IP is your own server, but the domain is behind the Cloudflare proxy (orange cloud): public DNS only ever shows Cloudflare's addresses, never your server. When you change the origin IP inside Cloudflare, DNS does not change and Cloudflare applies it within seconds, so there is nothing to propagate. The DNS check says so instead of showing 0%. Open the preview link to check the new server directly.

Get an alert when it’s done

Pro+Available on the Pro, Agency and Provider plans Turn on Alert me when DNS has propagated in the link settings or on the switch screen; clicking I've changed the record there turns it on for you. DNSPeek then checks every 5 minutes and emails you once the domain has propagated.

• Webhook: optionally add an https:// URL and DNSPeek calls it as well. Requests are signed with an X-DNSPeek-Signature header. When a shared link is made private, its webhook is removed, since a teammate may have added it; tracking keeps running and the link’s creator gets a DNS webhook removed notification. Add the webhook again if it was yours.
• 72-hour limit: if propagation has not completed within 72 hours, tracking stops and you get an email, which usually means a record was not updated or still points elsewhere.
• Behind the Cloudflare proxy: when you turn the alert on, DNSPeek checks the domain once and warns you right away if every resolver returns Cloudflare's addresses instead of the link's server IP (why). If that is still true 2 hours after you turned it on, the alert stops and you get a DNS alert stopped notification that says so, instead of polling for 72 hours. The 2 hours leave time to turn the proxy off or repoint the record. If you are moving the domain away from Cloudflare by changing nameservers, which can take longer, turn the alert on again once some resolvers return the new IP.
• Automatic QA re-check: once propagation is done, DNSPeek re-runs your QA report on the live domain and compares it with the last report from before the switch (uses one QA report of the month).

Check it yourself from the command line

Query a few public resolvers directly. Each should print the new server IP:

# Ask specific public resolvers for the A record
dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short
dig @9.9.9.9 example.com A +short

# Include the remaining TTL of the cached answer
dig @1.1.1.1 example.com A +noall +answer

nslookup example.com 8.8.8.8
nslookup example.com 1.1.1.1

Resolve-DnsName -Name example.com -Type A -Server 8.8.8.8
Resolve-DnsName -Name example.com -Type A -Server 1.1.1.1

Still seeing the old site?

Your own computer and browser cache DNS too. Flush the local cache and restart the browser:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder