DNS: From Concept to Implementation

General Overview

The Domain Name System (DNS) is the system that translates human‑readable domain names (e.g., example.com) into numeric IP addresses that machines can understand (e.g., 93.184.216.34). Without this abstraction layer, every user would have to memorize strings of numbers to reach a website or any other network service, which would be impractical at scale.

In practice, DNS works like a distributed, hierarchical, and resilient directory capable of answering billions of queries each day worldwide.

History: Creation Date and Creator

These documents laid the foundations of the hierarchical architecture, the iterative resolution model, and the various record types.

Why DNS?

1. Readability – Humans remember words far better than numbers.
2. Scalability – A single centralized directory would be a single point of failure; DNS spreads the load across thousands of servers.
3. Flexibility – DNS records allow multiple services (web, mail, cloud, etc.) to point to different IP addresses, and they can be changed without touching client configurations.
4. Redundancy & Fault Tolerance – Hierarchy and replication keep the system running even if a server or link goes down.

Core Principles

Hierarchical Architecture

root (.) → root name servers
      └─ TLD (com, org, net, fr, …) → TLD name servers
            └─ Second‑level domain (example.com) → authoritative name servers
                  └─ Sub‑domains (www.example.com, mail.example.com)

• Root servers – 13 logical sets (a–m) distributed globally, each using Anycast to provide many physical instances.
• TLD servers – Manage top‑level domains such as .com, .fr.
• Authoritative servers – Hold the definitive records for a domain (e.g., example.com).

Query Resolution

1. Client (recursive resolver) contacts its local resolver (usually supplied by the ISP or a public DNS provider).
2. If the resolver has no cached answer, it starts an iterative resolution:
   • Query a root server → receives the addresses of the relevant TLD servers.
   • Query the appropriate TLD server → receives the authoritative servers for the domain.
   • Query the authoritative server → receives the requested record.
3. The resolver returns the answer to the client and caches it for the duration indicated by the TTL.

IPv4 and IPv6 in DNS

DNS was designed from the start to support both address families. Today most zones publish both A and AAAA records so that IPv4 and IPv6 clients can resolve the same name.

DNS Record Types (Packets)

These records are defined in RFC 1035 and later extensions (e.g., RFC 7208 for SPF, RFC 8659 for CAA).

Role of Root Servers

• Why this design?
  • Robustness – Limiting the number of entry points (13 logical sets) reduces synchronization risk while providing massive geographic redundancy via Anycast.
  • Performance – Root servers sit in high‑capacity data centers, ensuring minimal latency for the first resolution step.
  • Centralised management – The Root Server Management System (operated by ICANN) keeps the list of TLD server addresses consistent and up‑to‑date.
• Current composition (2025) – 13 identifiers (A‑M), each potentially representing dozens of physical machines, totaling well over a thousand servers worldwide.
• Major operators – Verisign, University of Maryland, NASA, RIPE NCC, JPRS, among others.

Registrars and Registries

Process – The owner purchases a domain from a registrar, which forwards the request to the registry of the chosen TLD. The registry updates the TLD zone, adding NS records that point to the domain’s authoritative name servers.

Key Standards and RFCs

These documents form the normative backbone of the protocol and are periodically updated by the IETF.

Full Flow Synopsis (Example)

1. User types www.example.com into a browser.
2. Local resolver checks its cache. No entry → it initiates a recursive resolution.
3. Query the root server (.) → receives the addresses of the .com TLD servers.
4. Query a .com TLD server → receives the authoritative servers for example.com.
5. Query the authoritative server → obtains the A (or AAAA) record for www.example.com.
6. Resolver returns the IP address to the client and caches it for the TTL indicated in the SOA.
7. Browser opens a TCP/HTTPS connection to the received IP address.

References

1. Mockapetris, P. V. (1983). Domain Names – Concepts and Facilities, RFC 882.
2. Mockapetris, P. V. (1983). Domain Names – Implementation and Specification, RFC 883.
3. Mockapetris, P. V. (1987). Domain Names – Concepts and Facilities, RFC 1034.
4. Mockapetris, P. V. (1987). Domain Names – Implementation and Specification, RFC 1035.
5. Internet Engineering Task Force (IETF). (1995). DNS Security Extensions, RFC 1912.
6. IETF. (2005). DNS Extensions to Support IPv6, RFC 2671.
7. IETF. (2016). DNS over HTTPS (DoH), RFC 8484.
8. IETF. (2020). DNS over TLS (DoT), RFC 7858.
9. ICANN. Root Server System Overview. Available at https://www.icann.org/resources/pages/root-servers-2012-02-25-en.
10. AFNIC. Gestion des domaines .fr. Available at https://www.afnic.fr.