DNS

The Domain Name System (DNS) is the phonebook of the Internet. Humans access information online through memorable domain names, like nytimes.com or espn.com. Web browsers and network hardware interact through Internet Protocol (IP) addresses. DNS bridges this gap by translating human-readable domain names into machine-routable IP addresses so browsers can load Internet resources.

Why DNS Exists

Computers connect to servers using IP addresses, while people prefer readable, recognizable names such as google.com. DNS exists to connect these two forms seamlessly.

What DNS does

DNS maps a domain name to a server’s IP address:

google.com ──(DNS Translation)──> 142.250.190.46

When a user enters a domain name into a browser, DNS resolves the corresponding IP address so network packets can be addressed and routed to the correct server.

A phone-book analogy

DNS operates very similarly to a traditional phone book:

Just as you look up a person's name in a phone book to find their phone number, a computer queries DNS with a domain name to discover the server's numeric IP address.

Why this matters

Without DNS, users would need to memorize and type numeric server IP addresses (like 142.250.190.46 or IPv6 hex strings like 2607:f8b0:4005:805::200e) directly into browser address bars.

DNS abstracts these underlying network numbers behind friendly names, allowing servers to change IP addresses without breaking user-facing bookmarks and links.

The DNS Lookup Process

A DNS lookup translates a domain name into an IP address. The lookup travels through several layers of internet infrastructure: the client, the local resolver / Internet Service Provider (ISP), and hierarchical DNS servers.

The resolution flow

+--------+       1. Query google.com (Recursive)      +-------------------+
| Client | -----------------------------------------> | Recursive Resolver|
|        | <----------------------------------------- |    (ISP / 8.8.8.8)|
+--------+        8. Return 142.250.190.46            +---------+---------+
                                                                |
                            +-----------------------------------+-------------------------------+
                            | (2. Query .)                      | (4. Query .com)               | (6. Query google.com)
                            v (Iterative)                       v (Iterative)                   v (Iterative)
                  +-------------------+               +-------------------+           +-------------------+
                  |  Root Nameserver  |               |  TLD Nameserver   |           |   Authoritative   |
                  |       ( . )       |               |     ( .com )      |           |    Nameserver     |
                  +---------+---------+               +---------+---------+           +---------+---------+
                            | (3. Referral: .com TLD)           | (5. Referral: google NS)      | (7. A: 142.250.190.46)
                            +-----------------------------------+-------------------------------+

The step-by-step resolution path:

1. Client: The browser and operating system check their local caches. If missing, the operating system requests the IP address for the domain from the Recursive Resolver (typically hosted by the ISP or public resolvers like Cloudflare 1.1.1.1 or Google 8.8.8.8).
2. Root Nameserver (.): If the recursive resolver does not have the answer cached, it queries a Root server to find who handles the Top-Level Domain (e.g., .com).
3. TLD Nameserver (.com): The resolver queries the .com TLD server, which directs it to the authoritative nameserver for google.com.
4. Authoritative Nameserver: The authoritative server holds the official DNS records for google.com and returns the final IP address.
5. Client receives IP: The recursive resolver caches the record and returns the IP address to the client, allowing the client to initiate the TCP connection.

Observe a lookup with nslookup and dig

You can inspect DNS lookups directly from your terminal using standard network diagnostic tools:

nslookup google.com

Server:		192.168.1.1
Address:	192.168.1.1#53

Non-authoritative answer:
Name:	google.com
Address: 142.250.190.46

The output reveals the domain-to-IP translation reported by the DNS server.

DNS Ownership and Records

Who coordinates domain ownership?

Domain names are managed through a global hierarchical governance model:

• ICANN (Internet Corporation for Assigned Names and Numbers): Coordinates global domain ownership and IP address allocation, managing the top-level root zone.
• Registries: Organizations managing specific TLDs (e.g., Verisign manages .com and .net).
• Registrars: Accredited commercial companies (e.g., Namecheap, Cloudflare Registrar, GoDaddy) that resell domains to individuals and organizations, managing their registration records.

What are DNS records?

DNS records are configuration instructions stored in authoritative DNS servers. They map human-readable domain names to IP addresses and other services:

A records in practice

The A record is the most common record type, directly translating names into IPv4 addresses:

example.com.     300  IN  A   203.0.113.10
www.example.com. 300  IN  A   203.0.113.10
api.example.com. 300  IN  A   203.0.113.25

In this setup, root queries and www queries point to the primary web server, while api directs to a dedicated backend server.

DNS Caching and Time-to-Live (TTL)

Resolving a domain from authoritative servers for every single network request would overload DNS infrastructure and add hundreds of milliseconds of latency. DNS caching eliminates this overhead.

What DNS caching does

DNS caching stores resolved IP addresses temporarily at multiple layers so future requests can reuse the result instantly:

1. Client requests domain
         │
         ▼
[Is IP in Local Cache?] ──── YES ───> Use cached IP immediately (0ms network delay)
         │ NO
         ▼
[Query Recursive Resolver] ─ YES ───> Return cached resolver copy
         │ NO
         ▼
[Full DNS Hierarchy Lookup] ────────> Cache IP with TTL & return to client

Time-to-Live (TTL)

Every DNS record specifies a TTL (Time-to-Live) value in seconds:

• A high TTL (e.g., 86400 seconds / 24 hours) reduces DNS query traffic and speeds up lookups, ideal for stable, static infrastructure.
• A low TTL (e.g., 60 or 300 seconds) allows rapid updates and fast failovers when migrating servers or updating IP addresses.

Static vs. dynamic server addresses

• Static IP addresses: The server’s IP address remains fixed. Caching works best with static IPs because the cached result remains valid throughout the TTL window.
• Dynamic IP addresses: Some servers (e.g., residential home servers or ephemeral cloud instances) receive changing IPs.

When an IP changes before a cache expires, clients with stale caches may fail to connect. Dynamic DNS (DDNS) solves this by running an agent on the server that automatically updates the DNS record whenever its public IP changes.

Public Servers and URL Structure

A public server is accessed across the internet through a Uniform Resource Locator (URL). DNS connects the domain portion of that URL to the physical server IP. Understanding URL anatomy clarifies how DNS fits into the broader web architecture.

The anatomy of a URL

A standard web URL consists of structured components:

https:// api.service.example.com :443 /v1/users ?sort=desc&limit=10 #section-2
└──┬──┘  └──────┬──────┘ └───┬───┘ └─┬─┘ └───┬──┘ └───────┬───────┘ └────┬────┘
   │            │            │       │       │             │              │
Protocol    Subdomain     Primary    Port   Path     Query String      Anchor/
 (Scheme)                  Domain   (Opt.)             Parameters     Fragment
                          and TLD
         └─────────────┬─────────────────┘
                 Handled by DNS

Component breakdown

Reading a URL systematically

When examining a URL, parse its sections in order:

1. Protocol (https://): Determines how data is framed and encrypted.
2. Domain & Subdomain (api.example.com): Extracted and resolved by DNS into the server's IP address.
3. Port (:443): Defines the TCP port to open the connection with.
4. Path (/v1/users): Sent in the HTTP request line to target the specific route.
5. Query Parameters (?sort=desc): Passed to the application logic to filter or modify data.

Key Takeaways

• The Internet's Phonebook: DNS translates human-memorable domain names (like google.com) into machine-routable IP addresses (like 142.250.190.46).
• Hierarchical Lookup: When a cache misses, lookups flow through Recursive Resolvers → Root Nameservers (.) → TLD Nameservers (.com) → Authoritative Nameservers.
• Record Types: A records map to IPv4, AAAA to IPv6, CNAME creates domain aliases, MX routes email, and TXT holds verification metadata.
• Domain Governance: ICANN oversees root policy, registries operate top-level domains, and registrars sell domains to registrants.
• Caching & TTL: DNS records are cached across browsers, operating systems, and resolvers for the duration of their TTL to minimize latency and server load.
• Security & Privacy: DNSSEC uses cryptographic signatures to prevent cache poisoning, while DoH and DoT encrypt the client-to-resolver channel against eavesdropping.
• URL Connection: DNS resolves only the host/domain portion of a URL; the protocol, path, port, and query parameters are processed directly by client and server during the HTTP transaction.