Skip to main content
HostTracker
HostTracker
website monitoring service
Status pages Instant check Price
Login Register

DNS propagation checker and DNS lookup

Look up A, AAAA, CNAME, MX and TXT records for any domain and check DNS propagation in one run: HostTracker checkpoints around the world each ask public DNS resolvers near them and show every answer by location, so you can see where a change has arrived and where the old record is still cached.

Examples: 300+ locations worldwide · results in about 10 seconds

You've used today's free checks

Create a free account to keep checking. It takes less than a minute, and new free checks are available again tomorrow.

Start 30-day free trial Already have an account? Log in
{{error.message}}

Unlock the full report

30-day free trial · cancel anytime

Loading plans…
See all plans & pricing
Recommended
{{ plan.name }}
{{ money(priceMo(plan)) }}/mo
  • {{ plan.maxTaskCount == null ? 'Unlimited' : plan.maxTaskCount }} monitored sites
  • All check locations in the report
  • TLS, headers & timing details
  • Scheduled reports
  • REST API access
Start the 30-day trial
Billed only after your trial · Compare all plans

Checking DNS servers

Find out how different users around the world see your site. We perform DNS queries from various servers and provide you with detailed information.

Find out more

Global DNS monitoring

Get detailed information about your domain's DNS settings. We perform DNS queries from globally distributed servers and report on response times, IP addresses and other parameters.

Find out more

Optimize DNS settings

Improve the availability and loading speed of your website. Our feature allows you to deeply analyze your DNS configuration and identify potential problems.

Find out more

More about DNS lookups - records, TTL, propagation, and common questions.

Need this checked around the clock, not just once? Set up DNS blacklist monitoring

Key takeaways

  • This tool queries public DNS (Domain Name System) resolvers from many locations at once and shows the A, AAAA, CNAME, MX and TXT records each one returns for a domain.
  • Differing answers usually mean either a content delivery network answering per region, or a record change that has not yet expired out of every resolver's cache.
  • The lookups run from more than 300 HostTracker locations, which is what makes a propagation gap visible at all.
  • It is free, needs no login and no credit card.
  • For continuous checks, see the DNS monitoring page: expected IP addresses ride on an Http, Ping or Port monitor.

Frequently asked questions.

A tool that asks many DNS resolvers in different places for the same record and shows each answer, so you can see whether a recent change has reached them. This one queries five public resolvers per HostTracker checkpoint and lists every answer with its location.
Note the value you expect and the value it replaced. Enter the exact name the record belongs to (www.example.com and example.com are separate names with separate records), pick the record type and run the check. Rows with the new value come from resolvers that have already refreshed; rows with the old value are still serving a cached copy. Wait at least as long as the old record's TTL and run it again. When every row shows the new value, the change has reached every resolver the run could see. For the background, read how to check DNS propagation.
Up to one old TTL after you save the change, because that is how long a resolver may keep serving the old answer: 5 minutes for a 300-second TTL, 1 hour for 3,600 seconds, 4 hours for 14,400 and 24 hours for 86,400. A nameserver change at the registrar can take up to 48 hours, because the delegation records in the parent zone (.com, for example) carry their own two-day TTL. A few resolvers apply their own minimum cache time, which can stretch this.
The resolvers that answered cached the record before your change and keep it until the TTL runs out. HostTracker checkpoints cache answers too, for the TTL the resolver reports but never less than 3 minutes or more than 60, so for up to 3 minutes after a resolver has refreshed, a run can still show its old value. Wait for the old TTL to pass and run the check again. If the old value persists everywhere, ask your own nameservers with dig.
Usually for one of these reasons:
  • A change in progress: some resolvers still serve the old value until its TTL runs out.
  • A CDN or geographic DNS: many sites return a different IP address per region on purpose, so every value can be correct.
  • Several records for one name: resolvers may return all of them or only some.
  • Resolver policy: some resolvers filter or rewrite answers for domains covered by local rules or their own blocklists.
  • Negative caching: resolvers remember "no such record" for a time set in the zone's SOA record (RFC 2308), so a new record can lag behind an edited one.
Not after the change - nobody can flush other people's resolver caches. Before the next change, lower the record's TTL to 300 seconds and wait one old TTL; the change itself then reaches most resolvers within minutes. Once your own nameservers return the new value and the old TTL has passed, any stragglers are caches outside your control, such as a laptop or an office network that has not refreshed yet.
If every row shows the old value long after the old TTL, the edit probably went into the wrong zone or DNS provider, or the domain's nameservers point elsewhere. Find the nameservers the domain really uses with dig example.com NS +short and make the change there. If there are no rows at all for the record type you picked, the record was never created, or it sits on a different name (www versus the bare domain); create it on the exact name you queried.
Unexpected IP addresses usually come from a leftover record of an old host, a CDN in front of the site, or one resolver rewriting answers. Compare with the zone at your DNS provider; if only one operator differs, it is that resolver's policy. Two TXT rows where you expected one usually mean a new verification string was added next to the old one instead of replacing it, so delete the TXT record you no longer need. To be alerted when a hostname starts resolving to an address you did not expect, set up DNS monitoring with expected IPs.
A red row, such as a timeout, means that public resolver was slow, unreachable from the checkpoint or answered with a server failure. That is usually not your DNS. If errors show up across many resolvers and many countries, test your own nameservers directly with dig, and check the other rows for the answers that did arrive.
This tool shows record values, not the TTL left on them. On macOS or Linux, dig example.com A +noall +answer @8.8.8.8 asks a public resolver, and the number in the second column is the TTL left on its cached copy. dig example.com NS +short lists the domain's nameservers; put one after the @ in the first command to ask it directly, which is the source of truth. On Windows, use nslookup -type=A example.com 8.8.8.8. If your own nameservers return the old value, fix the zone first: no amount of waiting will help.
A and AAAA (together, as "IP, IPv6"), CNAME, MX and TXT. NS, SOA and PTR records are not supported; use dig for those. To follow a nameserver move, add a temporary TXT record at the new DNS provider only and watch which locations return it. For one record type at a time, the CNAME lookup and the TXT record lookup group the answers by value.
Yes, with no signup and no credit card. Without an account the table shows a sample of six rows; a free account shows every row from every location. Each row is one answer from one resolver, so a record with several values produces several rows.

Part of HostTracker's website monitoring software.