[Concept] And I thought I knew DNS

Source: Dev.to

Introduction

We all know how DNS works – there are countless articles and blogs that explain it.
While digging deeper I discovered several pieces of information that were new to me, so I decided to write them down.

Note: There are many excellent resources on DNS, but I hope you’ll find something new here.

Why Was DNS Created?

Before DNS, name‑based communication relied on a HOSTS.TXT file that was copied from computer to computer.
Each site maintained its own file, mapping host names to network addresses in a simple, human‑readable format.

• Keeping multiple copies of the hosts file proved inefficient and error‑prone.
• RFC 623 and RFC 625 designated the Stanford Research Institute Network Information Center (NIC) as the official source of the master hosts file.

The Birth of DNS

Paul Mockapetris and his team were tasked with creating a more user‑friendly network, so users wouldn’t have to remember IP addresses.
They proposed that host names consist of:

A year later, the first generic Top‑Level Domains (gTLDs) were introduced:

• .com, .edu, .net, .org, .int, .gov, .mil

By the end of 1985, six new .com domains existed. The very first one ever registered – Symbolics.com – is still active today.

Trivia

DNS Interceptors

• Used for optimisation, censorship, captive portals, etc.
• Since DNS is the gateway to the Internet, controlling it allows control over queries and requests.

Privacy

• RFC 7816 – QNAME Minimisation improves privacy.
• Instead of sending the full query to the authoritative name server, a resolver can send only the minimal required information.

DNS in a Nutshell

DNS is a global, distributed identifier database that replaced the static /etc/hosts file.
To understand its distributed model, let’s trace a typical lookup.

The DNS Resolution Process

1. Browser Cache

When you request https://google.com, the browser first checks its local cache. If the answer is present, it’s returned immediately.

2. Stub Resolver

If the cache misses, the stub resolver (e.g., gethostbyname(), getaddrinfo()) in the operating system takes over and sends the query to a recursive resolver.

The stub resolver is a thin client that forwards queries to a recursive resolver on behalf of applications.

3. Recursive Resolver

The recursive resolver does the heavy lifting:

1. Cache Check – If it has a cached answer (still valid per TTL), it returns it.
2. Root Hint File – If not cached, it starts from the root hint file (a list of the 13 root server IPs).
3. Priming Query – It sends a priming query to a root server to obtain the list of root name servers.
4. Iterative Queries – It follows the DNS hierarchy: Root → TLD → Authoritative name server for the domain.
5. Caching – The answer is cached with its TTL (Time‑to‑Live) value.

TTL Details

• TTL is a suggestion for how long a record may be cached.
• Some resolvers enforce a maximum TTL; values above that are ignored.
• To honour TTL, a resolver subtracts the time already spent resolving before caching the result for downstream clients.

4. Forwarders & Proxies (Optional)

Between the stub and recursive resolver, you might encounter forwarders or proxy servers that forward queries to a recursive resolver. This is often done for:

• Security (hiding internal network details)
• Centralised caching

5. Types of Resolvers

Most ISPs operate their own recursive resolvers, each maintaining its own cache.

The Root Zone

• ICANN, Verisign, and the Root Server Operators manage the root zone.
• A query to the root domain (.) returns the 13 root name servers.

Glue Records

• Glue records are hard‑coded A (or AAAA) records that eliminate circular dependencies.
• A circular reference occurs when an authoritative name server’s name lives inside the zone it serves (e.g., ns.example.com inside example.com). Without glue, the resolver could never reach the server because it doesn’t yet know its IP.
• Glue records are added at the domain registrar when delegating a zone, and each name server on the Internet has its own glue record created by the domain’s owner.

Summary

• DNS replaced the static hosts file with a distributed, hierarchical database.
• The resolution flow moves from browser cache → stub resolver → recursive resolver → root → TLD → authoritative server.
• Caching and TTL control how long records are stored at each level.
• Root servers, glue records, and forwarders keep the system efficient and reliable.
• Modern concerns such as privacy (QNAME minimisation) and interception (censorship, optimisation) are addressed through extensions and best practices.

Feel free to explore each component further – DNS is a deep and fascinating topic!

The Name Servers

Now the Recursive Resolver, which is responsible for most of the work, finds the Authoritative Name Server, gets the answer for the query (including the remaining TTL), hands it over to the Stub Resolver, and that’s how we resolve a domain name to an IP address.

A Quick Pseudo‑code Summary

var cache = map[string]string{}

func stubResolver(domain string) string {
    var (
        ipAddress string
        cacheHit  bool
    )
    ipAddress, cacheHit = cache[domain]
    if !cacheHit {
        ipAddress = recursiveResolver(domain)
    }
    return ipAddress
}

func recursiveResolver(domain string) string {
    // … recursively keep trying to identify the
    // **Authoritative Name Server** by getting the
    // **Name Servers** of each element.
    // It may even go all the way to the root zone (".").
    return ipAddress
}

Note: The real process is far more involved; the code above is only a high‑level illustration.

What Is a DNS Query?

A DNS query is a tuple (called a Query Tuple) consisting of:

The requester asks for the entire tuple—it can’t request just a single piece in isolation. On the wire (RFC 1035) the query is a mix of ASCII‑like labels and binary data, using the historic label‑compression scheme.

Trivia Details

Closing Thoughts

Hope this “blog‑style” note gave you a clearer picture of DNS internals and some interesting trivia.

Happy Learning!