DNS Propagation Checker

What this DNS propagation checker shows

“DNS propagation” is the name people give to the wait before a DNS change shows up everywhere. Nothing is pushed out to the world during that wait. The servers that answer DNS questions for other people, called resolvers, remember each answer for a number of seconds that the record itself sets, its TTL (time to live). Your DNS provider’s own servers give the new answer as soon as the change has been published to all of them, but a resolver that already holds the old answer keeps handing it out until its copy runs out. Every resolver’s copy runs out at a different moment, so for a while some give the old answer and some give the new one.

This checker asks four public resolvers the same question at the same time (Google at 8.8.8.8, Cloudflare at 1.1.1.1, OpenDNS at 208.67.222.222, and Quad9 at 9.9.9.9), then lays the answers side by side with the time each may still keep its answer. It looks up the A record, the IPv4 address a name points to. Every question comes from HostChecker’s one server, so this is not a test from many places around the world. Each of these services runs servers in many locations behind a single address and answers from the location nearest the asker, which here is always the same one. What you see also depends on whether you enter a domain name or an IP address.

For a domain name

Enter a domain and the checker looks up its A record on each resolver. The first tile says how many of the four agree, and the table shows what each one answered. Here is an example of a name whose address was changed a few minutes ago, with what each part tells you:

Reading the table:

• Resolver. Which public resolver answered, with the address it was asked at under its name.
• Answer. The IPv4 addresses that resolver returned. Several addresses are normal for large sites, and their order can change from one answer to the next. Two resolvers count as agreeing when they return the same set of addresses (and, for an alias, the same chain of names), whatever the order or the TTL. A row that is not part of the majority is shaded; with an even split there is no majority, so none is. When there is no address, the cell says why in words (see the next section). If the name is an alias (a CNAME), the cell shows the name it points to, then an arrow, then the addresses at the end of the chain, because every resolver follows the alias for you.
• TTL (the small line under each answer). How many seconds that resolver may keep serving this answer before it looks it up again. A resolver that has just fetched the record shows the record’s full TTL, and the number counts down from there. In the example, OpenDNS still has the old address and has 74 seconds left on it, so it can keep serving it for 74 more seconds at most. The number can jump up and down between two checks, because many separate caches sit behind each resolver address and your question can land on a different one each time.

Under “Show complete raw command output” is dig’s own reply from each resolver. Here is what one looks like for a name that is an alias:

The word after status: is the response code (NOERROR for a normal answer, NXDOMAIN when the name does not exist, SERVFAIL when the resolver failed). The numbers after ANSWER and AUTHORITY count the records in those sections. A line starting EDE, when a resolver adds one, is an extended error code that gives a reason, such as “DNSSEC Bogus”. In the answer section, the number after the name is that resolver’s remaining TTL. Here the alias has 1800 seconds left and the address 300, so the TTL line would show 300, the lowest in the answer.

For an IP address

An A record is what a name points to, so there is nothing to propagate for an IP address on its own. For an IP address the checker asks the same four resolvers for its reverse DNS (PTR) record instead, the name registered for the address, and compares those. The card looks the same, with the table titled “Reverse DNS (PTR) answers”. Here is an example:

The owner of the address block sets the reverse name, which is usually a hosting company or an internet provider, so a change to it is made with them and not at your domain registrar. Addresses on private networks, such as 10.x.x.x or 192.168.x.x, have no public reverse name: resolvers answer that none exists, and the card then says “No PTR record found”. IPv6 addresses are not accepted.

Either way, this check has limits that matter. It looks up only the A record (or the PTR for an IP address), so it does not show AAAA (IPv6), MX, TXT, NS, or other record types, and it cannot tell you that an email or verification change has spread (the FAQ shows how to check those with dig). It asks four public resolvers, not your internet provider’s resolver, your router, your computer, or your browser, each of which keeps its own cache and may still hold the old answer. It does not ask your domain’s own name servers, so it cannot tell you whether the change was saved correctly. It does not validate DNSSEC; it only sees the SERVFAIL that a resolver returns when validation fails. And each resolver is asked once, which is one sample from a service with many caches behind one address.

How to read the result

• All match (green). All four resolvers returned the same set of addresses. That means these four agree right now. It does not mean every resolver in the world has caught up, and it does not mean the address is the one you meant to set, so compare it with the address you expect. To see whether that address actually serves your site, run Host Check.
• 3 of 4, Split 2 / 2, or All differ (amber). The resolvers disagree: either most of them agree and the tile counts them, or they split evenly, or each one gave a different answer. Look at the TTL of the resolver that is out of step. If you just made a change, the TTL is the longest it can keep showing the old value, so it should switch when the countdown ends. If nothing changed and the name belongs to a large site or a CDN, a difference is usually normal (see the situations below). If the old answer is still there well after the old record’s TTL should have run out, the change was probably not saved, or it was made in a zone that is not the one the internet uses.
• No A record. The name exists but has no IPv4 address. It may have only an IPv6 address (AAAA), or only mail records, or be an alias whose target has no A record.
• Name does not exist (NXDOMAIN). That resolver was told, or remembers being told, that the name is not in DNS. If all four say it, check the spelling, then use WHOIS to see whether the domain is registered and which name servers it uses. If only one or two say it, the others may have a different answer cached (see “A new record does not show yet” below), or the resolver blocks the name: Quad9’s standard address refuses known-malicious domains by answering NXDOMAIN, and its documentation says an NXDOMAIN with AUTHORITY: 0 in the raw output is a block.
• Failed (SERVFAIL). The resolver tried and could not get a usable answer. Typical causes are name servers that are down or do not know the domain, and DNSSEC signatures that do not validate. All four resolvers here validate DNSSEC, so a domain with broken DNSSEC fails on all of them alike. One resolver failing alone is often temporary: run the check again.
• Refused, Error response, or No reply. The resolver declined, returned some other error code, or did not answer in time (HostChecker waits about 3 seconds, twice). Any of these counts as a difference, because that resolver did not give the answer the others did. Run the check again before reading much into it.

“All match” in amber is not a pass. It means every resolver gave the same outcome, and here that outcome is “nothing found”. The tile is green only when all four agree and found an address.

How long does DNS propagation take?

When you change a record: up to the old TTL

A resolver may keep an answer for as long as the TTL says (RFC 1035 defines it as the time the record may be cached before the source should be asked again). A resolver that fetched the old record a moment before you made the change can therefore keep it for the record’s whole TTL. With a TTL of 300 that is five minutes, and with 86400 it is a day. Resolvers that fetch afterward get the new value at once. The TTL is a ceiling and not a promise, since a resolver may drop an answer sooner, and some resolvers can be set to cap very long TTLs or to raise very short ones. So the dependable rule is that nearly everything has the new value after the old TTL has passed, and the TTL line shows you the countdown for each of the four.

When a record did not exist before: the negative TTL

Resolvers also remember that a name or record does not exist (RFC 2308 calls this negative caching). If someone looked the name up before you created it, that “no” is kept for a time taken from the zone’s SOA record, the lower of the SOA’s own TTL and its minimum field. RFC 2308 says values from one to three hours work well and values over a day are problematic, and the choice is up to the zone’s owner. DNS Lookup shows a domain’s SOA record: its own TTL is in the raw output, and its last number is the minimum field.

When you change name servers: until the delegation expires

Moving a domain to a different DNS provider is two changes. The registrar tells the domain’s registry which name servers to list, and the registry publishes that list in its own zone (a generic TLD’s registry must show a change on its servers within an hour in at least 95% of ICANN’s checks; country-code registries set their own rules). After that, resolvers keep using the name servers they already know until the cached list expires, and the registry decides its TTL. For .com it is measured in days, and you can see the figure by running dig +norec example.com NS @a.gtld-servers.net and reading the number beside each name server. That is why a name server change can take a day or two to settle for everyone while a record change takes minutes. This checker does not look at name servers, but the A record it shows is served by whichever provider each resolver currently uses, so a name server move shows up as resolvers disagreeing for a while.

What helps

• Lower the TTL ahead of a planned change. Set it to a few minutes at least as far ahead as the old TTL, so that caches holding the old long value have expired by the time you switch. Raise it again once things are stable.
• Keep the old server working. Leave the old address serving the site, and the old DNS provider serving the same records, until the change has settled everywhere. Visitors on a stale cache then still get a working site.
• Check the source. Ask your DNS provider’s own name server directly with dig @ns1.your-provider.com example.com A (use a name server from the NS records). If that does not show the new value, the problem is the change itself and no amount of waiting will fix it.
• Flush what you can. Google and Cloudflare each publish a page that clears a name from their public resolver’s cache, which is faster than waiting. They cover only their own resolver, and Google cannot flush names that use client-subnet geolocation. Your own computer’s cache is separate: on Windows, ipconfig /flushdns clears it, including remembered “does not exist” answers.

Common DNS propagation situations

I just changed an A record

Expect a mix of old and new answers until the old TTL has run out. Run the check now and again a few minutes later: the resolvers still on the old address should drop out one by one as their countdowns end. When all four match the new address, check the site with Host Check. If one resolver is still on the old address long after its TTL has expired, check the record at your DNS provider and make sure the domain really uses that provider (compare the Name servers in WHOIS with it).

I changed my name servers

Resolvers can keep asking the old name servers until the cached list expires, so keep the old provider answering with the same records until the change has settled. Compare the Name servers in WHOIS, which come from the registry, with the provider you meant to move to. If the domain uses DNSSEC, deal with the DS record at the registrar as part of the move: a DS record that describes the old provider’s keys makes validating resolvers return SERVFAIL for the whole domain. Your DNS provider’s documentation covers the order of steps.

I changed an MX, TXT, or other record

This checker only reads A records, so it cannot show those. Ask the same resolvers yourself with dig, for example dig @8.8.8.8 example.com MX, dig @1.1.1.1 example.com TXT, dig @9.9.9.9 example.com NS, or on Windows nslookup -type=MX example.com 8.8.8.8. The answer shows its remaining TTL. DNS Lookup shows eight record types at once, but through one resolver only.

The resolvers disagree and I changed nothing

That is often normal. Large sites and CDNs give different answers to different askers, and a name can have several addresses that resolvers hand out in rotation. Google’s resolver passes part of the asker’s network address to the name servers so they can answer by location (EDNS Client Subnet), while Cloudflare’s 1.1.1.1 does not send it, and neither does Quad9’s standard address. Four resolvers can therefore legitimately get different addresses even when asked from one place at the same moment. For a site on a single fixed address, they should all match.

A new record does not show yet

If anyone looked up the name before the record existed, resolvers remember “does not exist” for the negative TTL described above. A resolver that never saw the name asks fresh and finds the record at once, so a mix of NXDOMAIN, “No A record”, and addresses is expected for a little while. Flushing your own computer’s cache also clears its remembered “no”.

All four match but my site still shows the old one

The four public resolvers are not the only caches. Your browser, your computer, your router, and your internet provider’s resolver can all still hold the old answer, and so can a CDN or proxy in front of the site. A hosts file entry on your computer overrides DNS completely. Try another network or device, restart the browser, and flush the local DNS cache. Host Check shows which address HostChecker’s server reaches and what the site answers there.

SERVFAIL on every resolver

The resolvers could not get a usable answer from the domain’s name servers. Check that the registrar lists name servers that really hold a zone for the domain, that those servers are up, and, if DNSSEC is on, that the DS record at the registrar matches the keys your DNS provider signs with. The raw output often carries a line starting EDE that names the reason.

Frequently asked questions