DNS Lookup

A recursive resolver such as Google Public DNS (8.8.8.8) answers from its cache, so it may return a record that has since changed. An authoritative nameserver holds the zone itself and answers with the record as it exists right now. Comparing the two is the quickest way to confirm whether a DNS change has taken effect or is still cached somewhere.

Our DNS lookup tool queries records from multiple public DNS resolvers simultaneously, including Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9), and OpenDNS (208.67.222.222). You can also query the domain's authoritative nameservers directly for the most up-to-date records. The tool supports eleven record types: A, AAAA, MX, TXT, CNAME, NS, SOA, PTR, SRV, NAPTR and CAA. For MX and NAPTR it also follows the chain to the resolved IP addresses and shows the geolocation and ASN of each one.

DNS results can vary between resolvers due to caching with different TTL values, geographic DNS routing (GeoDNS), and filtering by some resolvers. Each resolver caches records independently and only discards a record when its TTL expires, so one resolver can still be serving the previous value after another has picked up the change. Some domains use GeoDNS and answer differently depending on where the query comes from. Filtering resolvers such as Quad9 withhold answers for domains they classify as malicious.

Querying the authoritative nameserver takes caching out of the picture. It holds the zone itself, and its answer is the one every other resolver will pick up once their cached copies expire. Comparing results across Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9) and the authoritative nameservers helps identify propagation issues after making DNS changes.

DNS propagation is the time it takes for a DNS change to be seen by every resolver, and it is really just cache expiry. Authoritative nameservers are updated the moment the zone is published. What takes time is the recursive resolvers that already hold the old record, and each of them keeps its cached copy for the TTL that was in force when it fetched the record.

A record with a 300-second TTL is fully replaced within five minutes. A record with an 86,400-second TTL can take up to 24 hours. Since the wait is governed by the old TTL, lowering a TTL speeds up the next change and not the current one. Lower it at least one full TTL period before a cutover, make the change, and raise it again once the new record is everywhere.

To check propagation, compare the answer from several resolvers. The Compare All option on this page does that for Google, Cloudflare, Quad9, OpenDNS and the authoritative nameservers, and our DNS propagation checker is built for that one job. A resolver that still returns the old value has not expired its cache yet, and there is nothing to do but wait for its TTL to run out.

Yes. Every lookup on this site is a GET URL on api.dnsx.dev, with the record type and then the domain in the path, and it returns JSON whatever client requests it. Add format=raw to get dig-style plain text instead, one record per line, which is handy in shell scripts. There is no signup and no API key. The limit is 200 requests a day per IP address, and the response headers tell you how many you have left. The full reference, with every endpoint and response shape, is at docs.dnsx.dev.

curl https://api.dnsx.dev/dns/mx/gmail.com
curl "https://api.dnsx.dev/dns/txt/example.com?format=raw"

With a local resolver, dig does the same job as the API. It ships with macOS and with the bind-utils or dnsutils package on Linux, and it can query every record type on this page.

1. Query a record type with dig. Run dig example.com MX +short to list the MX records for a domain. Replace MX with A, AAAA, TXT, CNAME, NS, SOA, SRV, NAPTR or CAA to query another type.
2. Pick a resolver. Add the resolver address after an @ sign, as in dig @8.8.8.8 example.com MX +short, to ask Google Public DNS instead of your system resolver. Use @1.1.1.1 for Cloudflare or @9.9.9.9 for Quad9.
3. Query the authoritative nameserver. Run dig example.com NS +short to find the nameservers for the domain, then dig @ns1.example.com example.com MX to read the record straight from the zone, with no cache in between.

dig example.com MX +short
dig @8.8.8.8 example.com MX +short
dig example.com NS +short
dig @ns1.example.com example.com MX

Windows ships with nslookup, and PowerShell adds Resolve-DnsName. Both can query A, AAAA, MX, TXT, CNAME, NS, SOA, SRV and PTR records, and both accept a resolver address so you can compare answers from Google or Cloudflare with your local resolver. Neither can query NAPTR records, so for those use WSL or the DNSX API.

nslookup -type=MX example.com
nslookup -type=TXT example.com 8.8.8.8
Resolve-DnsName example.com -Type MX
Resolve-DnsName example.com -Type TXT -Server 1.1.1.1
ipconfig /flushdns

macOS ships with dig, so you can query any record type from Terminal without installing anything. The system resolver keeps its own cache, so a change that dig already shows can still be invisible to Safari for a while. Flushing that cache takes two commands.

dig example.com TXT +short
dig @1.1.1.1 example.com A +short
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

On Linux, dig comes from the bind-utils package on Fedora and RHEL and the dnsutils package on Debian and Ubuntu. The host command from the same package gives a shorter answer. Systems that run systemd-resolved can also query through resolvectl, which shows which upstream resolver answered and lets you flush the local cache.

dig example.com A +short
host -t MX example.com
resolvectl query example.com
resolvectl flush-caches