DNS Lookup from
22 global locations.

Query DNS records for any domain from 22 servers across 15 countries. Verify propagation, check configuration, and troubleshoot resolution issues.

22 Monitoring nodes

15 Countries

< 2s Per lookup

$0 No account

Query DNS records from multiple resolvers across 22 global locations. Pick a record type and enter any domain — A, AAAA, MX, NS, TXT, SOA, CNAME, PTR and SRV are all supported.

Domain

Record type

Try:

Note: All checks are public. To keep your checks private, create a free account.

Global Network Diagnostics

Run a check to see your service from around the world.

Tested from 22 monitoring locations worldwide
Results in seconds, not minutes
Shareable result links for your team
No account or signup required

What is a DNS Lookup?

The Domain Name System (DNS) is the internet's phone book — it translates human-readable domain names like example.com into IP addresses that computers use to communicate. Every time you visit a website, send an email, or connect to any internet service, DNS resolution happens silently in the background.

When you perform a DNS lookup, you are querying a chain of servers to retrieve the records associated with a domain name. This resolution chain works as follows:

Browser cache — Your browser checks its own local cache for a recently resolved answer.
OS resolver — If no cache hit, the operating system checks its own resolver cache and the /etc/hosts file.
Recursive resolver — Your ISP or configured DNS server (e.g., 8.8.8.8, 1.1.1.1) takes over and performs the full lookup on your behalf.
Root nameservers — The recursive resolver contacts a root nameserver, which knows where to find the authoritative servers for each top-level domain (TLD).
TLD nameservers — The root refers the resolver to the TLD nameservers (e.g., the .com nameservers), which know the authoritative nameservers for the specific domain.
Authoritative nameservers — The final step: the domain's own nameservers respond with the actual DNS records requested.

DNS matters for everything from web browsing and email delivery to API connectivity, CDN routing, and service discovery. Because DNS records are cached at multiple levels, changes can take time to propagate globally — which is exactly why running a lookup from multiple locations simultaneously is valuable. Emercom queries from 22 locations to show you what resolvers around the world are currently seeing.

DNS is the internet's phone book — except every resolver carries its own copy, updated on its own schedule. Two browsers in two cities can get different answers for the same domain at the same moment, and both are technically correct.

DNS Record Types Explained

Each DNS record type serves a different purpose. Understanding what each one does helps you query the right record when diagnosing issues.

Type	Purpose	Example
A	Maps a domain to an IPv4 address. The most fundamental record type — used for web servers, APIs, and any service reachable by hostname.	93.184.216.34
AAAA	Maps a domain to an IPv6 address. The IPv6 equivalent of the A record, increasingly important as IPv4 address space is exhausted.	2606:2800:220:1:248:1893:25c8:1946
CNAME	Canonical Name — creates an alias for another domain. Commonly used to point subdomains (like `www`) to a root domain, or to map custom domains to CDN or SaaS endpoints.	www → example.com
MX	Mail Exchange — specifies the mail servers responsible for accepting email for a domain. Each record includes a priority value; lower numbers are preferred.	mail.example.com (priority 10)
NS	Name Server — lists the authoritative nameservers for a domain. These are the servers that hold the definitive DNS records for the domain.	ns1.example.com
TXT	Text records used to store arbitrary string data. Critical for email authentication (SPF, DKIM, DMARC), domain ownership verification, and service configuration tokens.	v=spf1 include:_spf.example.com ~all
SOA	Start of Authority — contains administrative information about a DNS zone, including the primary nameserver, the email of the zone administrator, the zone serial number, and timing parameters for zone transfers and caching.	ns1.example.com admin (2024010101)
PTR	Pointer record — performs reverse DNS lookups, mapping an IP address back to a hostname. Used by mail servers to verify sender identity and reduce spam.	34.216.184.93.in-addr.arpa → example.com
SRV	Service record — specifies the location and port of servers for specific protocols and services. Used by SIP (VoIP), XMPP (messaging), and various autodiscovery mechanisms.	_sip._tcp.example.com

Inside a DNS Response

When you run dig or nslookup against a domain, the resolver returns a structured response with several parts: the question that was asked, the answer (record values and their TTLs), and metadata about how long the query took and which server replied. Most lookup tools only surface the answer — but the full response carries everything you need to debug caching, propagation, and resolution speed.

On the wire — what dig dashboard.emercom.io prints

; <<>> DiG 9.18.30 <<>> dashboard.emercom.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63019
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;dashboard.emercom.io.          IN      A

;; ANSWER SECTION:
dashboard.emercom.io.        21600   IN      CNAME   hcl-active.infra.emercom.io.
hcl-active.infra.emercom.io. 21600   IN      A       167.88.50.156
hcl-active.infra.emercom.io. 21600   IN      A       5.78.158.0

;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Tue May 20 12:34:56 UTC 2026
;; MSG SIZE  rcvd: 112

TTL — seconds the answer is cacheable Record type — what was queried / returned Answer value — what this lookup actually reads

The apex name is a CNAME pointing at hcl-active.infra.emercom.io, which in turn resolves to two A records — two nodes of Emercom's hyperconverged cluster, both valid simultaneously so the resolver can hand back either one and clients fail over between them. 21600 is the TTL: resolvers along the path may cache this answer for up to 21600 seconds (6 hours) before re-querying the authoritative servers. SERVER: 8.8.8.8#53 is the resolver that actually answered (Google Public DNS, on the standard DNS port). Query time: 24 msec includes any recursive resolution this resolver had to do; a warm cache would be closer to 1–5 ms.

The flags: qr rd ra line tells you a lot in three tokens: qr means this is a response (not a query), rd means the client requested recursion, and ra means the resolver was willing to recurse. Lookups against authoritative-only servers will show rd but not ra — a fast way to distinguish recursive resolvers from authoritative ones.

Why Check DNS From Multiple Locations?

DNS is not instantaneous or globally synchronized. Records are cached at every layer of the resolution chain — in your browser, your OS, your ISP's resolver, and intermediate recursive resolvers worldwide. This is by design: caching reduces load on authoritative nameservers and speeds up responses. The downside is that after a DNS change, the old record lives on in those caches until the Time to Live (TTL) expires.

There are several important reasons why the same domain may return different answers from different locations:

DNS propagation. TTL expiry happens at different times across resolvers around the world. Some resolvers may be serving your new record while others are still returning the old one, causing inconsistent behavior for users in different regions.
GeoDNS. Many services intentionally return different IP addresses based on the location of the querying resolver. A CDN might return a Frankfurt edge node IP to European resolvers and a New York IP to North American ones. Multi-location DNS lookup lets you verify that GeoDNS is routing correctly for each region.
Split-horizon DNS. Some organizations serve different DNS records for internal and external queries. Testing from multiple external locations confirms what the public internet sees versus what internal resolvers return.
CDN steering differences. Performance-based DNS (where the fastest edge is returned) may serve different IPs to different locations even without explicit GeoDNS configuration. Seeing all the returned values helps you understand your CDN's global distribution.
Misconfigured or incomplete propagation. After migrating to a new DNS provider or changing nameservers, some secondary resolvers may be slow to update. A multi-location lookup immediately shows which regions are still resolving to old records.

Emercom runs all 22 DNS queries in parallel from geographically distributed nodes, giving you a complete propagation snapshot in seconds.

Common Uses for DNS Lookup

DNS lookup is a daily tool for anyone running a domain — but the workflows around it differ depending on what you're verifying. Four of the most common reasons to reach for a multi-location DNS check:

Propagation Verification

After a record change, confirm the new value has reached resolvers worldwide before declaring it rolled out. Multi-location lookup shows you exactly which regions are still serving the old answer — and how many minutes (or hours) the TTL still has to drain.

Email Deliverability

Verify SPF, DKIM and DMARC TXT records are correctly published, and that MX points to the right mail server with the right priority. Email-auth misconfiguration is silent — your messages just start landing in spam — so the lookup catches what the inbox would only tell you in retrospect.

Site Migration Planning

Pre-lower the TTL 24–48 hours before a planned switchover so the cut-over is fast and rollback is realistic. During and after the migration, multi-location lookup shows you whether the old or new IP is winning in each region — turning what would otherwise be a guessing game into a checklist.

GeoDNS & CDN Routing

Confirm that region-specific DNS routing actually returns the closest edge server in each region. North-American resolvers should hit US edges; European ones should hit European edges. A single misconfigured GeoDNS rule can quietly send half the world's traffic across an extra ocean.

DNS Myths That Won't Die

DNS is mostly invisible, which means most people's mental models of it are wrong in roughly the same six ways. Internalising what is actually happening is the difference between five-minute fixes and multi-hour incidents.

"DNS changes are instant."

Reality: Every resolver in the chain caches answers until the TTL expires. If your old TTL was 86 400 seconds (24 hours), some users will still hit the old record up to a day after you publish the change. Lower the TTL to 300 seconds at least 24 hours before any planned switchover.

"Lower TTL is always better."

Reality: Low TTL hurts cache hit rate, multiplies query volume against your authoritative servers, and adds a DNS round-trip to every cold-cache page load. Use low TTL temporarily — around migrations — then raise it back to the 300–3600 s range. Steady-state should be efficient, not "agile."

"DNS over HTTPS hides me from my ISP."

Reality: DoH and DoT encrypt the DNS query itself, so the resolver can't read your ISP's queries. But the TCP connection to the destination still carries the TLS SNI hostname (encrypted in TLS 1.3 only if ECH is in use, which most sites still don't support), and the destination IP is right there in the packet header. Your ISP still sees most of what you visit.

"Anycast DNS gives me a different IP."

Reality: The IP doesn't change. Anycast advertises the same IP from many physical locations; BGP routing sends each packet to the topologically closest instance. 1.1.1.1 is the same address in Frankfurt and Tokyo — just answered by different boxes. That's why Anycast DNS is fast and resilient without any GeoDNS magic.

"My ISP's resolver is fast and clean."

Reality: ISP resolvers are often slow, frequently cache aggressively (meaning stale answers), sometimes inject ads or redirect NXDOMAIN to a landing page, and occasionally log everything for marketing. Free public resolvers — 1.1.1.1, 8.8.8.8, 9.9.9.9 — are usually faster, don't editorialise, and publish clearer privacy policies.

"DNS lookup time = website load time."

Reality: DNS is one step out of many. A typical cold-cache lookup is 5–50 ms; warm cache is 1–5 ms. After that comes TCP handshake (1 RTT), TLS handshake (1–2 RTT), HTTP request, response, render. On a 200 ms-RTT link, TLS alone dwarfs the DNS step. Optimising DNS rarely moves the page-load needle unless the lookup is genuinely failing.

Frequently Asked Questions

Quick answers to the most common questions about DNS and the lookup tool.

What is DNS, in one sentence?

DNS is the system that translates human-readable domain names like emercom.io into machine-routable IP addresses, so your browser knows where to connect when you type a URL. Without it, you would have to memorize four octets for every site you visit.

How long does DNS propagation actually take?

Up to the TTL of the old record. If your previous TTL was 86,400 seconds (24 hours), some resolvers will keep serving stale answers for up to a day after the change. Lower the TTL to 300 seconds at least 24 hours before any planned switchover so the new record propagates in minutes instead of hours.

Why do I get different IPs from different locations?

Several possibilities: GeoDNS is intentionally returning regional IPs, propagation has not completed and some resolvers still cache the old record, split-horizon DNS is serving different records internally vs externally, or load balancing returns a rotating set of IPs. Multi-location lookup is the fastest way to tell which one is in play.

What is the difference between A and CNAME?

An A record maps a domain directly to an IPv4 address. A CNAME maps a domain to another domain name, which the resolver then has to resolve in a second lookup. CNAME is useful for aliases (subdomains pointing to vendor endpoints) but adds a round-trip and cannot coexist with other record types on the same name.

How do I check if my DNS change has propagated?

Query the record from many resolvers in different regions simultaneously. If all 22 Emercom nodes return your new value, propagation is effectively complete. Pre-lower the TTL before the change for faster propagation, and budget for the full old TTL as the worst case.

Can I use a faster DNS resolver than my ISP's?

Yes. Free public resolvers like Cloudflare's 1.1.1.1, Google's 8.8.8.8, and Quad9's 9.9.9.9 are usually faster, cleaner, and more privacy-respecting than typical ISP resolvers. Configure them in your OS network settings or directly in your router so all devices on the network benefit.

Related Tools

More free network diagnostics, all running from the same 22-location footprint.