How DNS Lookup Works: Domain Names to IP Addresses

When you type example.com into your browser and press Enter, you get a web page back in under a second. Behind that instant response is a surprisingly structured chain of servers working together to translate a human-readable name into a machine-readable number. That system is the Domain Name System, or DNS. Understanding it makes you a better developer, a more effective sysadmin, and a more informed user whenever something breaks.

Last updated: July 2026

What DNS Actually Does

Every device on the internet has an IP address, a number like 93.184.216.34. Computers route traffic using those numbers, not names. DNS is the global, distributed phone book that maps names to numbers. Without it, you would need to memorize IP addresses for every site you visit, and every address change by a hosting provider would break your bookmarks instantly.

DNS is not a single server. It is a hierarchy of servers spread across every continent, designed to be fast, resilient, and decentralized. No single organization controls it all, and no single failure can take it down entirely.

The Four Types of DNS Servers

A full DNS resolution involves four distinct roles. Understanding them individually makes the whole process clear.

• Recursive resolver: This is the first stop your query makes. Your internet service provider, or a public service like Google (8.8.8.8) or Cloudflare (1.1.1.1), runs recursive resolvers. When you request a domain, your device asks the resolver to find the answer on its behalf.
• Root name server: There are 13 sets of root name servers (labeled A through M) distributed globally using anycast routing. They do not know the final IP address, but they know which top-level domain (TLD) server to ask next.
• TLD name server: These servers handle specific extensions such as .com, .org, or .dev. The TLD server for .com knows which authoritative name server is responsible for example.com.
• Authoritative name server: This is the final authority. It holds the actual DNS records for the domain, including the IP address, mail server details, and any other records the domain owner has configured. When the recursive resolver reaches this server, it gets the answer it needs.

The Step-by-Step Resolution Process

Here is what happens in order when you visit a domain for the first time, with no cached data anywhere in the chain.

1. Your browser checks its own local cache. Nothing found.
2. Your operating system checks its own DNS cache and the hosts file. Nothing found.
3. Your device sends a query to the configured recursive resolver (often your ISP's or a public resolver).
4. The recursive resolver checks its own cache. Nothing found.
5. The resolver asks a root name server: "Who handles .com?" The root server returns the address of the .com TLD name servers.
6. The resolver asks the .com TLD server: "Who handles example.com?" The TLD server returns the address of example.com's authoritative name servers.
7. The resolver asks the authoritative name server: "What is the IP for example.com?" The authoritative server returns the A record (IPv4) or AAAA record (IPv6).
8. The resolver caches the result and sends it back to your device.
9. Your device caches the result, and your browser opens a TCP connection to the IP address.

This entire chain typically completes in 20 to 120 milliseconds. Subsequent visits are faster because the answer is cached at multiple levels.

Key DNS Record Types

DNS is not just for mapping names to IP addresses. A domain's DNS zone can hold many different record types, each serving a specific purpose.

• A record: Maps a domain to an IPv4 address. The most common record type.
• AAAA record: Maps a domain to an IPv6 address.
• CNAME record: An alias that points one domain name to another. Useful for www.example.com pointing to example.com.
• MX record: Specifies which mail servers handle email for the domain.
• TXT record: Stores arbitrary text. Widely used for domain ownership verification, SPF records (email anti-spoofing), and DKIM keys.
• NS record: Lists the authoritative name servers for the domain. Changing these is how you transfer DNS hosting between providers.
• SOA record: The Start of Authority record, which contains administrative information about the zone, including the primary name server and a serial number used to trigger zone transfers.
• PTR record: The reverse of an A record. Maps an IP address back to a domain name. Used in reverse DNS lookups and email server reputation checks.

You can inspect all of these in real time using EveryFreeTool's DNS Lookup tool, which queries live authoritative servers and displays every record type for any domain you enter.

TTL: How Caching and Propagation Work

Every DNS record includes a Time to Live (TTL) value, measured in seconds. This tells resolvers and clients how long they may cache the record before they must query for a fresh copy. A TTL of 3600 means the record can be cached for one hour.

TTL has a direct effect on how quickly DNS changes propagate across the internet. If you update an A record and the old record had a TTL of 86400 (24 hours), some users may see the old IP address for up to a day while their resolver's cache expires. Lowering your TTL to 300 seconds before a planned migration gives you much faster propagation, at the cost of slightly higher query load on your authoritative servers.

The term "DNS propagation" is slightly misleading. DNS records do not actively push out to every server. Instead, each resolver simply waits until its cached copy expires, then fetches the new value. Propagation time is therefore equal to the TTL of the old record, not some fixed global window.

Why DNS Lookups Fail

DNS failures fall into a small number of categories. Knowing them speeds up diagnosis considerably.

• NXDOMAIN: The domain does not exist in DNS. This can mean a typo, a deleted domain, or a domain whose registration lapsed.
• SERVFAIL: The authoritative name server returned an error or was unreachable. Often caused by a misconfigured zone file or a nameserver that is down.
• Stale cache: You are seeing an outdated IP because a resolver's cache has not yet expired. Check the TTL and wait, or switch to a resolver that has already refreshed its cache.
• Wrong nameservers: After buying a domain, you must point it to the correct nameservers at your DNS host. If this step is skipped or done incorrectly, the domain resolves to nothing useful.
• DNSSEC validation failure: If DNSSEC is enabled and there is a key mismatch, security-aware resolvers will refuse to return the record rather than return a potentially forged answer.

For quick diagnosis, use EveryFreeTool's Domain Lookup tool to check nameserver assignments, and the IP Address Lookup tool to verify which server an IP actually belongs to once resolution succeeds.

DNS Security: DNSSEC and DNS over HTTPS

Standard DNS queries are sent in plain text, which makes them visible to anyone on the network path between your device and the resolver. Two technologies address this.

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records. A resolver that supports DNSSEC can verify that a record came from the legitimate authoritative server and has not been tampered with in transit. It does not encrypt the query itself, only authenticates the response.

DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the DNS query itself, so network observers cannot see which domains you are looking up. Modern browsers increasingly use DoH by default, routing queries through a trusted HTTPS endpoint rather than your ISP's plain-text resolver.

Practical Takeaways for Developers

If you manage any infrastructure or build web applications, a few habits around DNS will save you significant pain over time.

• Lower your TTL to 300 or less at least 24 hours before any planned DNS change.
• Always check both A and AAAA records when troubleshooting connectivity, since IPv4 and IPv6 may point to different servers.
• Use multiple authoritative name servers in different geographic regions to avoid a single point of failure.
• Verify TXT records after setting up email authentication (SPF, DKIM, DMARC) before switching mail flow.
• Treat NS record changes as high-risk operations. A wrong NS record can take an entire domain offline and require up to 48 hours to recover, depending on the TLD registry's TTL.

For subnet-level network planning alongside DNS work, the Subnet Calculator on EveryFreeTool handles CIDR block math without requiring any installed software.

Summary

DNS is one of the most critical and least visible pieces of infrastructure on the internet. A query that feels instantaneous is actually a coordinated conversation between your device, a recursive resolver, root servers, TLD servers, and finally the authoritative server that holds the real answer. Knowing how each step works, what each record type does, and how TTL controls caching gives you the foundation to deploy, debug, and secure any domain-dependent system with confidence.