DNS Records & Concepts
What is DNS lookup?
A DNS lookup is the process of querying the DNS system to translate a human-readable domain name into the information stored in DNS records: most commonly an IP address that a browser or application can use to establish a network connection. Every time a browser navigates to a website, an application connects to an API, an email server delivers a message, or any networked service needs to resolve a hostname, a DNS lookup is performed behind the scenes.
The lookup is the fundamental operation of the domain name system, the translation service that makes domain names functional. Without DNS lookups every network connection would require knowing the numeric IP address of the destination, an impossibility for everyday users navigating a web of billions of addresses. DNS lookups make domain names work by bridging the gap between the human-readable names people type and the numeric addresses computers use to communicate.
A DNS lookup appears instantaneous from the user’s perspective, typing a URL and pressing enter results in a page loading within seconds. But behind that apparent instantaneity lies a sophisticated query process involving multiple servers, caching layers, and network round trips, all completed in milliseconds through the efficiency of the DNS infrastructure.
How a DNS lookup works
A DNS lookup follows a specific sequence, from the browser’s initial need for an IP address through to receiving the answer. The sequence involves checking multiple caches before making any network requests and querying a hierarchy of servers when cached information is not available.
Step 1, browser cache check: before making any external query the browser checks its own DNS cache. If the domain was recently resolved and the cached result has not expired the browser uses the cached IP address immediately. No network query is needed. This is the fastest possible outcome, a cache hit at the browser level.
Step 2, operating system cache check: if the browser cache misses the browser asks the operating system to resolve the domain. The OS checks its own DNS cache, a system-level cache shared across all applications. If a recent result is available the OS returns it to the browser. Still no network query needed for the DNS lookup itself.
Step 3, hosts file check: before querying the network the OS checks the local hosts file, a plain text file that maps hostnames to IP addresses locally. Any entry in the hosts file overrides DNS entirely for that hostname. The hosts file is consulted before any DNS query is made.
Step 4, recursive resolver query: if no cached result is found locally the OS sends a DNS query to the configured recursive resolver: typically the ISP’s resolver or a public resolver like 8.8.8.8. The query asks the resolver to find the IP address for the domain. If the resolver has a cached result from a previous lookup for the same domain it returns it immediately, another cache hit, this time at the resolver level.
Step 5, root nameserver query: if the resolver has no cached result it begins an iterative resolution process. It queries one of the 13 root nameserver clusters asking for information about the domain. Root nameservers do not have the specific record but they know which nameservers are authoritative for the TLD: .com, .net, .org, or any other extension. The root nameserver returns a referral to the TLD nameservers.
Step 6, TLD nameserver query: the resolver queries the TLD nameserver, for example the .com nameserver for a .com domain. The TLD nameserver holds the delegation records, NS records: for every domain registered in that TLD. It returns the NS records for the queried domain specifying which nameservers are authoritative for it.
Step 7, authoritative nameserver query: the resolver queries one of the authoritative nameservers returned in step 6. The authoritative nameserver holds the actual DNS records for the domain, the zone data configured by the domain owner or DNS provider. It returns the requested record, typically an A record or CNAME record: with the IP address and TTL value.
Step 8, response caching and return: the resolver caches the response for the duration of the record’s TTL and returns the IP address to the OS. The OS caches it and returns it to the browser. The browser caches it and uses it to establish a TCP connection to the web server. The DNS lookup is complete.
The full resolution process, steps 4 through 8, typically takes 20 to 100 milliseconds for a cold lookup with no cached results. Subsequent lookups served from resolver caches take microseconds.
Types of DNS lookups
DNS lookups are categorised by the type of query being made and the record type being requested.
Forward lookup: the standard DNS lookup that translates a domain name to an IP address. A forward lookup for example.com returns its A record, 93.184.216.34. This is what browsers perform when navigating to a website. Forward lookups are what the term DNS lookup refers to in most contexts.
Reverse lookup: translates an IP address back to a domain name using PTR records. A reverse lookup for 93.184.216.34 returns example.com. Reverse lookups are used by email servers for spam verification, by network administrators for log readability, and by security tools for IP address identification.
MX lookup: specifically queries for MX records to find the mail servers for a domain. Performed by sending mail servers when delivering email. The lookup returns the mail server hostnames and priorities rather than IP addresses, the sending server then performs additional forward lookups for the mail server hostnames.
NS lookup: queries for NS records to identify the authoritative nameservers for a domain. Performed during the DNS resolution process itself, when resolvers follow the delegation chain from root to TLD to authoritative nameserver.
TXT lookup: queries for TXT records to retrieve text-based information, SPF records for email authentication, domain verification tokens, DMARC policies. Applications and services that need to verify domain ownership or check email policies perform TXT lookups.
CNAME lookup: queries for CNAME records that alias one domain name to another. Resolvers follow CNAME chains automatically during forward lookup resolution, a CNAME response triggers an additional lookup for the canonical name.
DNS lookup performance
DNS lookup performance directly affects the overall page load time experienced by visitors. Understanding the performance characteristics of DNS lookups explains why they matter for website optimisation and why redirect management must account for DNS efficiency.
Lookup latency: each DNS lookup involves network round trips between the browser, resolver, and authoritative nameservers. Round trip times depend on geographic distance between the client and resolver, resolver and nameserver response times, and network conditions. A single cold DNS lookup, with no cached results anywhere in the chain, typically adds 20 to 120 milliseconds of latency before the browser can even begin establishing a connection to the web server.
Multiple lookups per page: modern web pages load resources from multiple domains, the main domain, CDN domains for assets, third-party script providers, analytics services, advertisement networks. Each unique domain requires its own DNS lookup. A page loading resources from ten different domains may perform ten DNS lookups before all resources begin loading. Browser connection limits and DNS lookup parallelism affect how these multiple lookups are handled.
DNS lookup caching: caching dramatically reduces the average cost of DNS lookups. A domain visited recently has its IP address cached in the browser or OS, the lookup takes microseconds from cache rather than milliseconds from the network. The effectiveness of caching depends on DNS TTL values, higher TTLs mean longer cache lifetimes and higher cache hit rates.
DNS prefetching: browsers support DNS prefetching, pre-resolving domain names for links on the current page before the user clicks them. This eliminates DNS lookup latency when the user does navigate to a prefetched domain. The dns-prefetch link hint in HTML instructs the browser to begin DNS resolution for specified domains in advance.
Resolver proximity: the closer a resolver is to the client the lower the round trip time for DNS queries. Public resolvers with global anycast infrastructure, like 1.1.1.1 and 8.8.8.8: serve queries from nearby locations with low latency. ISP resolvers are typically within the ISP’s network, close to customers geographically but variable in performance.
DNS lookups and redirects
The relationship between DNS lookups and URL redirects is important for understanding the full latency chain that visitors experience.
DNS lookup precedes redirect: a server-side redirect begins with a DNS lookup. Before the browser can receive a 301 redirect response it must first resolve the domain name to an IP address, the DNS lookup, then establish a TCP connection, then send the HTTP request, and then receive the redirect response. DNS lookup latency is the first cost in the redirect sequence.
Redirect adds another DNS lookup: after receiving a redirect response pointing to a different domain the browser must perform another DNS lookup for the destination domain before it can load the destination page. A redirect from olddomain.com to newdomain.com requires two DNS lookups, one for olddomain.com to receive the redirect and one for newdomain.com to load the destination. Both lookups add to the total load time.
Redirect chains multiply DNS lookups: a three-hop redirect chain, URL A to URL B to URL C, potentially requires three DNS lookups if each URL is on a different domain. Each hop adds both a DNS lookup and an HTTP round trip. This is one of the performance costs of redirect chains that makes minimising hops important.
Caching reduces redirect DNS cost: if newdomain.com has been visited recently its IP address is cached and the DNS lookup for the redirect destination costs microseconds rather than milliseconds. For returning visitors DNS lookup costs are largely eliminated by caching. For first-time visitors DNS lookup costs are paid in full.
Performing DNS lookups manually
DNS lookups can be performed manually using command-line tools and web-based interfaces, useful for diagnosing DNS issues, verifying record values, checking propagation, and understanding what resolvers are serving for a domain.
dig command: the most versatile DNS lookup tool on Linux and macOS. Performs lookups with detailed output showing the full DNS response including record values TTLs query times and the nameserver that answered.
Basic A record lookup:
Lookup with short output showing only the record value:
Lookup querying a specific resolver:
Lookup querying the authoritative nameserver directly, bypassing resolver caches:
Lookup following the full resolution chain showing each step:
The +trace option is particularly valuable for understanding the delegation chain, showing the root nameserver referral the TLD nameserver referral and the authoritative nameserver response in sequence.
nslookup: available on Windows macOS and Linux. Simpler than dig with less detailed output.
Basic lookup:
Lookup for a specific record type:
Lookup using a specific resolver:
host command: a simpler command-line tool available on Linux and macOS.
Basic lookup:
Lookup for a specific record type:
Online DNS lookup tools: web-based tools perform DNS lookups without requiring command-line access and show results from multiple geographic locations simultaneously. Useful for checking DNS propagation: seeing which locations have received an updated record value and which are still serving the old cached value.
DNS lookups and HTTPS
HTTPS connections involve DNS lookups as the first step but also introduce additional complexity through the TLS handshake that follows.
After a DNS lookup returns the server IP address the browser establishes a TCP connection and then performs a TLS handshake to establish the secure connection. The TLS handshake involves multiple round trips, certificate exchange verification and session key establishment, adding 50 to 150 milliseconds of latency before the first HTTP request can be sent.
DNS over HTTPS, DoH, changes how DNS lookups are transported. Instead of sending DNS queries over UDP port 53 in plaintext DNS queries are sent over HTTPS, encrypted and indistinguishable from regular HTTPS traffic. DoH prevents eavesdropping on DNS queries and makes it harder for network-level actors to intercept and manipulate DNS lookups. Major browsers support DoH natively and major resolvers including Cloudflare and Google provide DoH endpoints.
TLS session resumption and HTTP/2 connection coalescing reduce the overhead of subsequent connections to the same server, but DNS lookups for each new domain still occur for each unique hostname encountered in a page load.
DNS lookup failures
A DNS lookup failure, receiving no valid response from any resolver, prevents the browser from establishing any connection to the target server. The browser displays an error, typically DNS_PROBE_FINISHED_NXDOMAIN in Chrome or a similar message in other browsers, indicating the domain could not be resolved.
Common causes of DNS lookup failures include:
Non-existent domain: the domain name does not exist in DNS, it was never registered or the registration has expired. The authoritative nameserver returns NXDOMAIN.
Misconfigured DNS records: DNS records exist but are incorrectly configured, a CNAME pointing to a non-existent target an A record with an invalid IP address or NS records pointing to unreachable nameservers.
DNS resolution timeout: the resolver or authoritative nameserver did not respond within the timeout period. May indicate network connectivity issues server downtime or DDoS attacks against nameserver infrastructure.
NXDOMAIN after recent creation: a newly created DNS record that has not yet propagated, resolvers that cached a negative response before the record was created continue serving NXDOMAIN until their negative cache expires.