What Is DNS and How It Works

Imagine trying to call a friend, but instead of dialing a phone number, you had to remember the exact GPS coordinates of their house and somehow “dial” that instead. That’s essentially what using the internet without DNS would feel like — every website, every server, every email system is really just a numeric IP address underneath, like 142.250.premises. Nobody wants to memorize 142.250.190.14 to visit Google. Instead, we type google.com.

The Domain Name System (DNS) is the piece of internet infrastructure that makes this possible. It is, without exaggeration, one of the most important systems ever built — a massive, distributed, constantly-updating global directory that translates human-friendly names into machine-friendly numbers, billions of times a day.

This article explains DNS completely from first principles — what it is, how it works step-by-step, its structure, the different types of DNS records, and how all the pieces fit together — in plain language for beginners, while including enough depth for working professionals too.

The Core Problem DNS Solves

Computers communicate using IP addresses — numeric identifiers like 93.184.216.34 (IPv4) or 2606:2800:220:1:248:1893:25c8:1946 (IPv6). These are perfect for computers but terrible for humans to remember.

DNS solves this by providing a name-to-address translation service — similar to how a phone book translates a person’s name into their phone number.

The DNS Namespace: A Hierarchy, Not a List

DNS is not one giant list somewhere — it’s a distributed, hierarchical, tree-like structure. Understanding this tree is the key to understanding all of DNS.

flowchart TD
    Root["Root ( . )"] --> COM["TLD: .com"]
    Root --> ORG["TLD: .org"]
    Root --> NET["TLD: .net"]
    COM --> Example["example.com"]
    Example --> WWW["www.example.com"]
    Example --> MAIL["mail.example.com"]

At the very top sits the root zone, represented by a single dot (.) — often invisible in everyday use (www.example.com. technically has a trailing dot). Below the root are Top-Level Domains (TLDs) like .com, .org, .net, or country codes like .uk and .pk. Below TLDs are second-level domains (the actual company/organization name, like example), and below that are subdomains like www or mail.

Each level in this tree can be delegated to a different organization — which is exactly why DNS scales to billions of records without any single entity controlling everything.

The Key Players in DNS

Step-by-Step: How a DNS Lookup Actually Works

Let’s trace exactly what happens when you type www.example.com into your browser for the very first time (nothing cached anywhere).

sequenceDiagram
    participant You as Your Computer
    participant Resolver as Recursive Resolver
    participant Root as Root Server
    participant TLD as .com TLD Server
    participant Auth as example.com Authoritative Server

    You->>Resolver: Where is www.example.com?
    Resolver->>Root: Where is www.example.com?
    Root-->>Resolver: Ask the .com TLD servers
    Resolver->>TLD: Where is www.example.com?
    TLD-->>Resolver: Ask example.com's name servers
    Resolver->>Auth: Where is www.example.com?
    Auth-->>Resolver: It's at 93.184.216.34
    Resolver-->>You: 93.184.216.34

Step-by-Step Explanation

1. You type the address. Your browser asks the operating system’s stub resolver to find the IP for www.example.com.
2. The stub resolver asks a recursive resolver — typically configured by your ISP, your company, or a public one like 1.1.1.1 or 8.8.8.8.
3. The recursive resolver checks its cache first. If it doesn’t have a fresh answer, it starts the full “recursive” walk.
4. It asks a root server, “Who handles .com?” The root server doesn’t know the final answer, but it knows who to ask next.
5. It asks the .com TLD server, “Who handles example.com?” The TLD server replies with the authoritative name servers for example.com.
6. It asks the authoritative server directly for www.example.com, and finally gets the real answer: an IP address.
7. The recursive resolver caches the answer (for future speed) and returns it to your computer.
8. Your browser connects to that IP address over HTTP/HTTPS to load the actual website.

All of this typically happens in well under 100 milliseconds — often much faster thanks to caching at multiple layers.

Common DNS Record Types

DNS doesn’t just store IP addresses — it stores many different types of records for different purposes.

Understanding TTL (Time To Live)

Every DNS record has a TTL — the number of seconds a resolver is allowed to cache that record before checking again.

A common real-world practice: temporarily lower a record’s TTL before a planned change (like migrating a website to a new server), wait for the old TTL to expire everywhere, make the change, then raise the TTL back once things are stable.

Recursive vs. Iterative Queries

Clients (like your laptop) almost always make recursive queries — they want a final answer, not a chain of referrals. Resolvers, in turn, use iterative queries when talking to root/TLD/authoritative servers.

Real-World Example: Moving a Website to a New Host

Suppose a company is migrating www.example.com from an old hosting provider (IP 198.51.100.10) to a new one (IP 203.0.113.20).

1. A week before the migration, they lower the A record’s TTL to 300 seconds (5 minutes), so any change propagates quickly.
2. On migration day, they update the A record to point to 203.0.113.20.
3. Within about 5–10 minutes (accounting for caches that hadn’t refreshed yet), essentially all visitors worldwide are now reaching the new server.
4. A few days later, once everything is confirmed stable, they raise the TTL back to a longer value like 3600 or 86400 seconds to reduce ongoing DNS query load.

Without understanding TTL and DNS propagation, this kind of migration could cause confusing intermittent outages for users still hitting stale cached records.

Linux Example: Observing the Whole Process

# See the full step-by-step hierarchy walk yourself
dig +trace www.example.com

# See just the final answer and its TTL
dig www.example.com

# See the authoritative name servers for a domain
dig example.com NS

# See the full step-by-step hierarchy walk yourself
dig +trace www.example.com

# See just the final answer and its TTL
dig www.example.com

# See the authoritative name servers for a domain
dig example.com NS

Cisco Example: DNS at the Network Layer

Network engineers configuring Cisco devices interact with DNS constantly — for example, enabling DNS-based hostname resolution on a router:

ip domain lookup
ip name-server 8.8.8.8
ip domain name example.com

ip domain lookup
ip name-server 8.8.8.8
ip domain name example.com

Once configured, commands like ping server1 automatically resolve server1.example.com using the configured DNS servers — the exact same recursive lookup process described above, just triggered from network hardware instead of a laptop.

Python Example: Performing a Manual DNS Walk

To really cement the concept, here’s a simplified Python script that performs its own iterative walk instead of relying on a recursive resolver — essentially reimplementing what dig +trace shows:

import dns.resolver
import dns.query
import dns.message

def manual_trace(domain):
    # Start at a root server
    root_server = '198.41.0.4'  # a.root-servers.net
    current_server = root_server

    for _ in range(10):
        query = dns.message.make_query(domain, 'A')
        response = dns.query.udp(query, current_server, timeout=3)

        if response.answer:
            for rrset in response.answer:
                print(f"Answer found: {rrset}")
            return

        if response.additional:
            # Pick the next server to ask from the "glue" records
            for rr in response.additional:
                if rr.rdtype == 1:  # A record
                    current_server = rr[0].address
                    print(f"Following referral to: {current_server}")
                    break
        else:
            print("No further referral found")
            break

manual_trace("www.example.com")

import dns.resolver
import dns.query
import dns.message

def manual_trace(domain):
    # Start at a root server
    root_server = '198.41.0.4'  # a.root-servers.net
    current_server = root_server

    for _ in range(10):
        query = dns.message.make_query(domain, 'A')
        response = dns.query.udp(query, current_server, timeout=3)

        if response.answer:
            for rrset in response.answer:
                print(f"Answer found: {rrset}")
            return

        if response.additional:
            # Pick the next server to ask from the "glue" records
            for rr in response.additional:
                if rr.rdtype == 1:  # A record
                    current_server = rr[0].address
                    print(f"Following referral to: {current_server}")
                    break
        else:
            print("No further referral found")
            break

manual_trace("www.example.com")

This illustrates, in code, the exact referral-following process that recursive resolvers perform automatically on your behalf.

Comparison Table: DNS vs. Other Naming Systems

Best Practices

• Keep TTLs reasonable — balance propagation speed against DNS query load.
• Always have at least two authoritative name servers for redundancy, ideally in different networks/locations.
• Use meaningful, consistent naming conventions for subdomains (api.example.com, mail.example.com) rather than confusing ad-hoc names.
• Monitor domain expiration dates — an expired domain registration is one of the most common (and entirely preventable) causes of total DNS failure.
• Use DNSSEC where possible to cryptographically protect against tampering.
• Document your DNS records — zone files can get complex quickly in larger organizations.

Troubleshooting Common DNS Issues

Summary

DNS is the invisible backbone that makes the human-friendly internet possible. It works through a distributed, hierarchical system of root servers, TLD servers, and authoritative servers, with recursive resolvers doing the legwork on behalf of everyday users. Understanding this system — from record types, to TTLs, to the actual lookup sequence — isn’t just academic; it’s foundational knowledge for anyone who manages websites, servers, email, or networks of any kind.

Further Reading

• RFC 1034 – Domain Names: Concepts and Facilities
• RFC 1035 – Domain Names: Implementation and Specification
• IANA Root Servers
• Cloudflare: What Is DNS?
• ICANN: Beginner’s Guide to DNS
• DNSSEC Overview – ICANN
• dnspython Documentation