What is DNS? How the Domain Name System Translates Names to IP Addresses

DNS (Domain Name System) is a hierarchical, distributed naming system that translates human-readable domain names such as www.example.com into IP addresses such as 93.184.216.34 that computers use to route network traffic. DNS resolution typically completes in 20–120 ms.

Without DNS, every Internet request would require the user to know the numeric IP address of the destination server. This guide covers the DNS hierarchy, resolution process, caching, record types, security extensions, and how to flush the DNS cache.

What Is DNS?

DNS is the distributed database that maps domain names to IP addresses across the global Internet. The system is hierarchical — no single server holds all DNS records.

Instead, authority is delegated from the root downward to Top-Level Domain (TLD) servers and then to authoritative nameservers operated by domain registrars and hosting providers. DNS is defined in RFC 1034 and RFC 1035, published in 1987.

DNS uses port 53 for both UDP (standard queries) and TCP (zone transfers and responses larger than 512 bytes or larger than 4,096 bytes with EDNS). The average DNS response is under 512 bytes and fits in a single UDP packet.

DNS Hierarchy

DNS is organized as an inverted tree with 3 main levels below the root.

• Root servers: The top of the DNS hierarchy. There are 13 root server clusters (labeled A through M), operated by 12 organizations. As of 2024, over 1,700 root server instances exist globally via anycast routing. Root servers store the addresses of all TLD nameservers but do not hold individual domain records.
• TLD nameservers: Manage Top-Level Domains such as .com, .org, .net, .uk, and country-code TLDs. Verisign operates the .com and .net TLD servers. Over 1,500 TLDs exist as of 2024.
• Authoritative nameservers: Hold the actual DNS records for specific domains. When a domain is registered, the registrar points to the authoritative nameservers (typically hosted by the web host, CDN, or a DNS provider like Cloudflare or AWS Route 53). Authoritative servers provide the definitive answer — no further lookup is needed once reached.
• Recursive resolvers: The first step in DNS resolution for end users. Recursive resolvers (also called full-service resolvers) are operated by ISPs, Google (8.8.8.8), Cloudflare (1.1.1.1), and others. They query the DNS hierarchy on behalf of the client and cache responses to reduce latency on repeated lookups.

DNS Resolution Process Step by Step

A complete uncached DNS resolution follows these 7 steps, typically completing in 50–100 ms for the first query.

1. The browser checks its own DNS cache. If the record is found and not expired, the resolution ends here (sub-millisecond).
2. The operating system checks the local DNS cache (and the hosts file at /etc/hosts on Linux/macOS or C:\Windows\System32\drivers\etc\hosts on Windows).
3. The OS sends the query to the configured recursive resolver (e.g., 1.1.1.1 or the ISP resolver). If the resolver has the answer cached, it returns it immediately.
4. The recursive resolver queries a root server: “Who handles .com?” The root server returns the addresses of the .com TLD nameservers.
5. The recursive resolver queries the .com TLD server: “Who handles example.com?” The TLD server returns the authoritative nameserver addresses for example.com.
6. The recursive resolver queries the authoritative nameserver for example.com and receives the A record (IP address) for www.example.com.
7. The recursive resolver returns the IP address to the client’s OS, which passes it to the browser. The resolver caches the response for the duration specified by the record’s TTL.

DNS Caching and TTL

DNS caching stores query results at the recursive resolver, OS, and browser level to avoid repeating the full resolution process. TTL (Time to Live) is a value in seconds set by the domain owner in each DNS record that defines how long resolvers may cache the record before discarding it and re-querying.

Common TTL values include 3,600 seconds (1 hour) for most records, 300 seconds (5 minutes) for records expected to change soon, and 86,400 seconds (24 hours) for stable records. Low TTLs increase DNS server load and query latency.

High TTLs delay propagation when DNS records are updated. DNS changes do not propagate instantly — propagation can take from minutes (for low TTL records) to 48 hours (for records with 24-hour TTLs that are cached across many resolvers globally).

DNS Record Types

DNS supports dozens of record types. The following are the 6 most commonly encountered in web hosting and email configuration.

DNS over HTTPS and DNS over TLS

Standard DNS queries are transmitted in plaintext over UDP port 53, allowing ISPs, network administrators, and attackers on the same network to observe which domains a device queries. DoH and DoT encrypt DNS queries to prevent this.

• DoH (DNS over HTTPS): Sends DNS queries inside encrypted HTTPS traffic on port 443. DoH queries are indistinguishable from regular HTTPS traffic, making them difficult to block or monitor at the network level. Supported by Firefox, Chrome, and Edge.
• DoT (DNS over TLS): Encrypts DNS queries using TLS on port 853. Dedicated DNS port makes DoT easier for network administrators to identify and control compared to DoH. Supported by Android 9+ (Private DNS feature) and many enterprise firewalls.

DNS Cache Poisoning

DNS cache poisoning (also called DNS spoofing) is an attack in which false DNS records are injected into a recursive resolver’s cache, redirecting users who query that resolver to attacker-controlled IP addresses. The attack exploits the fact that DNS uses UDP, which does not verify the source of responses.

DNSSEC (DNS Security Extensions) mitigates cache poisoning by cryptographically signing DNS records. Resolvers verify signatures against the zone’s public key before accepting records.

DNSSEC does not encrypt queries (that is DoH/DoT’s role) — it authenticates responses to prevent tampering. As of 2024, approximately 35% of domain names support DNSSEC globally according to ICANN data.

How to Flush the DNS Cache

Flushing the DNS cache clears all locally stored DNS records, forcing the system to perform fresh lookups. This is required when DNS records for a domain have changed and the cached old values are causing connection errors.

• Windows: Open Command Prompt as Administrator and run ipconfig /flushdns. The output confirms: “Successfully flushed the DNS Resolver Cache.”
• macOS (Ventura / Sonoma): Run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder in Terminal.
• Linux (systemd-resolved): Run sudo systemd-resolve --flush-caches in Terminal.
• Google Chrome browser cache: Navigate to chrome://net-internals/#dns and click “Clear host cache.”

Key Takeaways

• DNS translates domain names to IP addresses. Resolution traverses recursive resolver → root server → TLD server → authoritative nameserver, typically in 50–100 ms.
• There are 13 root server clusters with over 1,700 anycast instances globally as of 2024.
• TTL controls how long DNS records are cached. Common values are 3,600 seconds (1 hour) to 86,400 seconds (24 hours).
• A records map to IPv4; AAAA records map to IPv6; MX records specify mail servers; TXT records carry SPF/DKIM/DMARC and verification strings.
• DoH encrypts DNS queries within HTTPS on port 443. DoT encrypts on dedicated port 853. Both prevent plaintext DNS surveillance.
• On Windows, ipconfig /flushdns clears the local DNS cache when stale records cause connection issues.

Last Thoughts on DNS

DNS is the directory service of the Internet. Every web request, email, and API call begins with a DNS lookup. The system’s hierarchical design — root servers, TLD servers, authoritative nameservers, recursive resolvers — distributes billions of daily queries without a central point of failure.

TTL controls propagation speed; DNSSEC authenticates records; DoH and DoT encrypt queries. Understanding DNS resolution, record types, and cache flushing is foundational to web hosting, email deliverability, network troubleshooting, and security configuration.