DNS Monitoring
A DNS lookup shows where a domain actually points right now - and, queried from many locations at once, whether a change you just made has genuinely reached the rest of the internet, or is still stuck in resolver caches.
Free instant check · 300+ worldwide locations · no login required
How a lookup reads the domain, resolver by resolver
Domain administrators, developers, and support teams run a DNS lookup whenever a domain isn't resolving the way it should - or right after making a DNS change and needing to confirm it actually took effect.
After pointing a domain's A record at a new server, the natural question is whether the change has reached every resolver on the internet, or whether some visitors are still routed to the old server by an unexpired cache. Querying from many independent locations at once - not refreshing one browser - is the only reliable way to answer that.
Because resolution differs by resolver, region, and cache state, a problem that looks like a server issue is very often DNS instead - an incorrect record, a typo in a recently edited zone, or a change that hasn't propagated. Querying MX records directly confirms exactly where a domain's mail is routed before blaming the mail server.
Security-conscious teams use DNS lookups to audit their own domains periodically - confirming records still point where they're supposed to, catching a stale CNAME left behind by a decommissioned service, or spotting an unexpected change that could indicate a compromised registrar or DNS provider account.
Trusted by teams at
Websites, servers, APIs, certificates. One check type per page, the same locations, alerts and reports behind all of them.
Every chapter opens in place, so the page stays short.
Seeing different IP addresses for the same domain from different locations is often correct behavior, not a bug.
If a lookup returns no results at all, the usual causes are a typo in the domain, a record type that simply doesn't exist for it, or nameservers that aren't correctly delegated.
Once DNS itself checks out, the port checker verifies that a mail or web server's ports are actually open where the records point, and the WHOIS lookup surfaces the domain's registration and nameserver details directly.
The free DNS lookup tool answers one question - where does this domain point right now - in a single query from 300+ locations, no login. For the standing answer, a HostTracker monitor can pin the IP addresses a host is expected to resolve to and fail - and alert - as soon as it resolves to anything else, re-checked from 300+ locations as often as once a minute.
This is usually intentional, not an error. Many sites run behind a content delivery network or use GeoDNS specifically to route each visitor to the server nearest them, so a domain legitimately resolves to different IP addresses depending on where the query originates. It can also happen temporarily right after a DNS change: locations whose resolvers already cached the old answer keep returning it until that cached answer's TTL expires, while locations querying fresh already show the new value.
TTL (time to live) is a number, in seconds, attached to every DNS record that tells resolvers how long they're allowed to reuse a cached answer before checking the authoritative nameserver again. A high TTL (say, 24 hours) reduces load on your nameservers and speeds up repeat lookups, but means a change you make can take up to that long to be visible everywhere. A low TTL makes changes propagate faster but means more frequent queries hit your nameservers. It's common practice to lower a record's TTL a day or two before a planned migration, then raise it again afterward.
An A record maps a domain name directly to an IPv4 address (an AAAA record does the same for IPv6) - it's the most direct kind of DNS record. A CNAME record instead maps a name to another domain name, which is then resolved in turn; it's typically used for subdomains that should always point wherever a root domain or a third-party service (like a CDN) currently points, without needing to update an IP address by hand every time that target changes. A domain's root (apex) usually can't use a CNAME record, only A/AAAA.
DNS propagation isn't a single global event - it's every individual resolver around the world independently deciding when to re-check the authoritative nameserver, which they only do once their cached answer's TTL expires. Until that happens, a resolver keeps confidently serving the old, cached answer. That's why a change can appear instantly from one location and take hours to show up from another: it depends entirely on when each resolver last cached the record and how long its TTL was, not on how far away it is.
An MX (Mail Exchange) record tells the internet which mail server is responsible for accepting email on behalf of a domain, and in what priority order if there's more than one. Querying a domain's MX records directly shows you exactly where its mail is being routed right now - useful for confirming a mail provider migration actually took effect, or for ruling out DNS as the cause when email delivery problems come up, before assuming the mail server itself is misconfigured.
The three most common causes are: a typo in the domain name itself; querying a record type that simply doesn't exist for that domain (many domains have no TXT, MX, or AAAA record at all, which is normal); or the domain's nameservers not being correctly delegated at the registrar, so no server actually holds an authoritative answer to return. Checking a record type you know should exist, like A, is a quick way to tell whether the domain resolves at all before assuming a specific record is missing.
Start a free trial and let HostTracker watch your domains' resolution and availability around the clock.
