Every time you type a URL into a browser, paste a link into Slack, or click a bookmark, your device performs a DNS lookup before anything else happens. Before the TLS handshake, before the first byte of HTML, before the favicon loads, your operating system needs to turn a human-readable hostname like `blog.example.com` into a numeric IP address like `93.184.216.34`. That translation is what a DNS lookup does. It happens in roughly 10 to 100 milliseconds on a typical connection, and most people never notice it unless something goes wrong.
The simplicity of the result (a name goes in, an address comes out) hides a surprisingly layered process. A single lookup can involve your browser's internal cache, your operating system's resolver, a recursive nameserver run by your ISP or a public provider, the DNS root servers, a TLD registry server, and the authoritative nameserver that actually holds the answer. Each layer has its own cache, its own TTL rules, and its own failure modes. Understanding how these layers interact is the difference between staring at a timeout and knowing exactly where to look.
This guide walks through the full DNS resolution chain, the record types you will encounter, how caching and TTL shape what you see, practical commands for running lookups yourself, common error codes and what they mean, and the security signals that DNS lookups can reveal. If you want to follow along with live data, DomScan's DNS Lookup Tool lets you query any domain interactively.
The Full Resolution Chain
To make the resolution chain concrete, let us trace what happens when you navigate to `blog.example.com` for the first time on a fresh machine. No caches are warm. No shortcuts apply. Every layer has to do real work.
Step 1: Browser Cache Check
The browser checks its own internal DNS cache first. Chrome, Firefox, and Safari all maintain a short-lived cache (typically 60 seconds) of recent DNS answers. If you visited `blog.example.com` a few seconds ago, the browser already has the IP address and skips every subsequent step. This is the fastest possible path: zero network traffic, sub-millisecond resolution.
Step 2: OS Resolver Cache
When the browser cache misses, the request drops to the operating system. On macOS, the `mDNSResponder` daemon maintains a system-wide DNS cache. On Windows, the DNS Client service does the same. On Linux, `systemd-resolved` or `nscd` handles caching depending on the distribution. The OS cache respects the TTL of the original DNS response, so entries can live for minutes or hours. If another application on the same machine recently resolved `blog.example.com`, the OS cache returns the answer without hitting the network.
Step 3: Stub Resolver to Recursive Resolver
If neither local cache has the answer, the OS stub resolver sends a query to the recursive resolver configured in the system's network settings. This is typically an IP address provided by DHCP from your ISP, or a manually configured resolver like Google Public DNS (`8.8.8.8`), Cloudflare (`1.1.1.1`), or Quad9 (`9.9.9.9`). The stub resolver is deliberately simple: it sends the question and waits for a complete answer. All the hard work happens on the recursive resolver's side.
Step 4: Recursive Resolver Cache Check
The recursive resolver checks its own cache before doing anything else. Recursive resolvers serve thousands or millions of clients, so popular domains are almost always cached. If someone else using the same resolver looked up `blog.example.com` within the TTL window, the recursive resolver returns the cached answer immediately. This is why public resolvers like `8.8.8.8` are fast for popular domains: the cache hit rate for the top 10,000 domains is extremely high.
Step 5: Root Server Referral
On a genuine cache miss, the recursive resolver starts the iterative resolution process. It sends a query to one of the 13 root server clusters (labeled `a.root-servers.net` through `m.root-servers.net`). The root server does not know the IP address for `blog.example.com`. What it does know is which servers are authoritative for the `.com` TLD. It returns a referral: a list of nameservers for `.com`, like `a.gtld-servers.net` through `m.gtld-servers.net`. The root servers are distributed globally via anycast, so this query goes to the nearest instance, typically completing in under 10 milliseconds.
Step 6: TLD Server Referral
The recursive resolver follows the referral and queries a `.com` TLD server: "Where is `example.com`?" The TLD server does not have the final IP address either. It returns another referral: the authoritative nameservers for `example.com`, such as `ns1.example.com` and `ns2.example.com` (or whatever the domain owner configured). This is the layer where the domain registration matters. If the domain does not exist in the TLD zone, this is where the process stops with an NXDOMAIN response.
Step 7: Authoritative Nameserver Answer
The recursive resolver sends the final query to the authoritative nameserver for `example.com`: "What is the A record for `blog.example.com`?" The authoritative server checks its zone file and returns the answer: `blog.example.com. 3600 IN A 93.184.216.34`. This answer includes a TTL value (3600 seconds in this example), which tells every cache in the chain how long to store the result. The recursive resolver caches the answer, sends it back to the stub resolver, the OS caches it, the browser caches it, and the connection to the web server begins.
The entire chain, from root referral through TLD referral to authoritative answer, adds up to roughly 50-150 milliseconds for an uncached lookup. Subsequent lookups for the same name hit the recursive resolver cache and return in 1-5 milliseconds. This is why the first page load on a new domain feels slightly slower than subsequent visits.
DNS Record Types You Will See in a Lookup
When you run a DNS lookup, the response contains one or more records of a specific type. Each type answers a different question about the domain. Here is a brief overview of the types you will encounter most often. For a deeper treatment of each type, including interaction rules and common mistakes, see DNS Record Types Explained.
- A returns an IPv4 address. This is the most common lookup type and is what browsers need to open a TCP connection.
- AAAA returns an IPv6 address. Functionally identical to A records but for IPv6 connectivity. Modern clients query both A and AAAA in parallel.
- CNAME returns an alias to another hostname. If `blog.example.com` has a CNAME pointing to `example.cdn-provider.com`, the resolver follows the chain and resolves the target name to get the final IP address.
- MX returns mail exchange servers with priority values. These tell sending mail servers where to deliver email for the domain.
- TXT returns arbitrary text strings. Used heavily for SPF, DKIM, DMARC, domain verification tokens, and other policy declarations.
- NS returns the authoritative nameservers for a domain or zone. These are the servers queried in step 7 of the resolution chain above.
- SOA returns the Start of Authority record: the primary nameserver, the responsible party's email, the zone serial number, and timing values for zone transfers and negative caching.
Most DNS lookup tools let you specify which record type to query. If you do not specify one, the default is usually an A record lookup. The DomScan DNS Lookup API supports all common record types and returns structured JSON, which makes it straightforward to integrate into scripts and monitoring workflows.
TTL and Caching: Why Results Differ Between Lookups
TTL (Time to Live) is a value in seconds attached to every DNS response. It tells each cache in the resolution chain how long to store the answer before discarding it and querying again. TTL is the single most important factor in understanding why two people looking up the same domain at the same time can get different answers.
Common TTL values and what they signal in practice:
- 300 seconds (5 minutes) is common for records that change frequently, such as domains behind load balancers, failover systems, or CDNs that rotate IP addresses. Low TTLs give operators agility at the cost of more DNS traffic.
- 3600 seconds (1 hour) is the most common default for general-purpose records. It balances cache efficiency with reasonable update speed. Most hosting providers set this as the default TTL.
- 86400 seconds (24 hours) is typical for stable records that rarely change: NS records, MX records for established mail infrastructure, or TXT records for long-term domain verification. High TTLs reduce DNS query volume but make changes slow to propagate.
Caching happens independently at every layer. The browser has its own cache with its own (often shorter) TTL floor. The OS cache respects the record's TTL. The recursive resolver caches according to the TTL but may also impose minimum or maximum TTL policies. Some ISP resolvers are known to cache beyond the stated TTL, which is technically a protocol violation but happens in practice.
This layered caching is what people mean when they talk about DNS propagation. There is no propagation mechanism in DNS. There is no push system that distributes updates. What actually happens is that old cached entries expire at different times on different resolvers around the world. A resolver that cached your old A record with a 3600-second TTL will keep serving the old IP for up to an hour after you change the record. A different resolver that had a cache miss five minutes after your change will already have the new IP. The term "propagation" describes the gradual, uncoordinated process of caches expiring and refilling with fresh data.
If you need to make a DNS change with minimal disruption, the standard practice is to lower the TTL to 300 seconds (or less) well before the change, wait for the old higher TTL to expire, make the change, verify it is serving correctly, and then raise the TTL back to its normal value. DomScan's DNS History tool lets you track these TTL changes over time to verify that the preparation window was actually respected.
How to Run a DNS Lookup
Three practical approaches, from command line to API.
Using dig
The `dig` command (Domain Information Groper) is the standard DNS lookup tool on Unix-like systems. It is installed by default on macOS and most Linux distributions.
$ dig example.com A
; <<>> DiG 9.18.18 <<>> example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41523
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 3600 IN A 93.184.216.34
;; Query time: 23 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Wed Apr 23 09:15:22 UTC 2026
;; MSG SIZE rcvd: 56Key fields in the output: the status line shows `NOERROR` meaning the query succeeded. The ANSWER SECTION contains the actual record: `example.com` has an A record with a TTL of 3600 seconds pointing to `93.184.216.34`. The Query time of 23 msec tells you how long the recursive resolver took to respond. The SERVER line shows which resolver handled the query.
To query a specific resolver, append `@` followed by the resolver IP. To query a different record type, replace `A` with the type you need:
$ dig @8.8.8.8 example.com MX
;; ANSWER SECTION:
example.com. 3600 IN MX 10 mail.example.com.
;; Query time: 18 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)Using nslookup
The `nslookup` command is available on Windows, macOS, and Linux. It provides less detail than `dig` but is often the first tool people reach for, especially on Windows systems where `dig` is not installed by default.
$ nslookup example.com
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: example.com
Address: 93.184.216.34The "Non-authoritative answer" label means the response came from a resolver cache rather than directly from the authoritative nameserver. This is normal. Most lookups you run will be non-authoritative because they are served from the recursive resolver's cache.
Using DomScan
For a visual interface that structures results and lets you compare record types side by side, DomScan's DNS Lookup tool queries live DNS records and displays them in a readable format. The DNS Lookup API returns the same data as structured JSON, which is useful for scripting, monitoring, or integrating DNS checks into CI/CD pipelines. Both approaches query authoritative data rather than relying on a single resolver's cache.
Common DNS Lookup Problems and What They Mean
DNS lookups fail in predictable ways. The response code (RCODE) in the DNS header tells you what category of failure occurred. Here are the four you will see most often and what each one means in practice.
NXDOMAIN (Non-Existent Domain)
The authoritative nameserver has confirmed that the queried name does not exist in its zone. This is a definitive negative answer, not a timeout or a guess. Common causes: the domain has expired and been removed from the TLD zone, the subdomain was never created, or there is a typo in the hostname. NXDOMAIN is the response you see when you query a domain that genuinely does not exist. It is also the response that triggers NXDOMAIN hijacking by some ISPs, which redirect non-existent domains to advertising pages instead of returning the honest error.
SERVFAIL (Server Failure)
The recursive resolver tried to resolve the name but encountered an error it could not recover from. This is the catch-all error code for nameserver problems. Common causes: the authoritative nameserver is down or unreachable, DNSSEC validation failed (the signatures on the DNS response did not verify), or the zone file on the authoritative server is misconfigured and contains syntax errors. SERVFAIL is the most frustrating response code because it tells you something broke but not exactly what. Querying different recursive resolvers and comparing results usually helps narrow down whether the problem is on the resolver side or the authoritative side.
REFUSED
The nameserver understood the query but actively declined to answer it. This is a policy decision by the server operator, not a failure. Common causes: you queried a nameserver that is not configured to serve the zone you asked about, the server has access control lists that block your source IP, or the server only accepts queries from authorized clients. REFUSED is common when you accidentally query the wrong nameserver or when a corporate resolver blocks external lookups.
Timeouts
A timeout means no response was received at all within the configured wait period. Unlike the other codes, a timeout is the absence of a response rather than an explicit error. Common causes: the nameserver is offline, a firewall is blocking UDP port 53 (or TCP port 53 for larger responses), the network path between the resolver and the authoritative server is broken, or the server is overloaded and dropping queries. Timeouts are the hardest failures to diagnose remotely because they provide no information beyond silence. Running lookups from multiple locations (or using DomScan's Domain Health tool) helps distinguish between a server that is down globally versus a network path that is broken from your specific location.
When DNS Lookups Reveal Security Issues
DNS lookups are not just operational diagnostics. The records returned in a lookup can surface security issues that are not visible from other vantage points. Here are the patterns that should trigger further investigation.
Unexpected CNAME Chains
A CNAME record points one hostname to another. When the target of that CNAME is a service you no longer control, an attacker can register the target resource and serve their own content under your domain name. This is subdomain takeover, and it is one of the most common DNS-related vulnerabilities. If a lookup for `status.yourcompany.com` returns a CNAME to `yourcompany.statuspage.io` and you cancelled that StatusPage account, anyone who claims that subdomain on StatusPage now controls what `status.yourcompany.com` serves. Look for CNAME targets that resolve to default hosting pages, error pages, or domains registered by third parties.
Dangling DNS Records
Dangling records are DNS entries that point to infrastructure that no longer exists. An A record pointing to an IP address you released back to your cloud provider. An MX record pointing to a mail server you decommissioned. These records are not technically errors (they are valid DNS), but they create risk because someone else may acquire the infrastructure they point to. Regular DNS lookups compared against your known infrastructure inventory are the simplest way to catch these. DomScan's DNS History makes this comparison easier by showing when records were added and whether the target infrastructure has changed.
Mismatched Nameservers
The NS records returned in a DNS lookup should match the nameservers configured at the registrar. When they diverge, it usually means a migration was started but not completed, or the zone was transferred without updating the delegation. In rare cases, mismatched nameservers can indicate unauthorized changes. If the registrar says the nameservers are `ns1.provider-a.com` but a lookup returns NS records pointing to `ns1.provider-b.com`, someone changed the zone-level NS records without updating the registrar delegation, or the other way around. Either way, it needs investigation.
Unauthorized Zone Transfers
A zone transfer (AXFR query) asks a nameserver to dump its entire zone contents. This is a legitimate mechanism for synchronizing secondary nameservers, but it should never be open to the public internet. If you can run `dig @ns1.example.com example.com AXFR` and receive a full zone listing, the nameserver is misconfigured. An open zone transfer reveals every subdomain, every internal hostname, every IP mapping, which gives an attacker a complete map of the domain's DNS infrastructure. Checking for open zone transfers should be part of any DNS security review.
DNS Lookup in Broader Domain Intelligence
A DNS lookup is a point-in-time observation. It tells you what a domain resolves to right now, from the perspective of one resolver, at this moment. That observation becomes much more useful when combined with context: what the domain resolved to last week, who registered it, what certificates have been issued for it, whether its nameservers match its registrar configuration, and how its DNS posture compares to related domains.
This is where individual lookups connect to broader domain intelligence. A single A record answer is a data point. That same A record compared against historical DNS data, cross-referenced with WHOIS ownership records, and checked against the domain's overall health posture becomes actionable evidence for decisions about trust, security, migration readiness, or incident response.
DNS lookup is the starting point, not the conclusion. The value is in what you do with the result. Whether you are debugging a failed deployment, investigating a suspicious domain, preparing for a migration, or auditing your own infrastructure, understanding how DNS resolution works gives you the foundation to interpret everything that follows.
Independent references: Review RFC 1035 for the protocol specification and Google Public DNS documentation for resolver-side behavior and troubleshooting.