Understanding DNS: How Domain Names Become IP Addresses
#web#dns#registrar#registry
daud99

daud99 @daud99

About: Geek by day, an overthinker by night

Location:
Madrid, Spain
Joined:
Nov 13, 2019

Understanding DNS: How Domain Names Become IP Addresses

Publish Date: May 18
0 0

Understanding DNS: How Domain Names Become IP Addresses

In our previous blog post, we covered domains and their various aspects. Now, let's dive deeper into DNS (Domain Name System) - the backbone of internet navigation.

What is DNS?

DNS, or Domain Name System, is essentially a translator for the internet. Its primary function is simple yet crucial: it converts human-friendly domain names (like example.com) into machine-readable IP addresses that computers use to identify each other. Without DNS, you'd need to memorize numeric IP addresses instead of easy-to-remember domain names.

Key Players in the Domain World: Registries vs. Registrars

Before we explore how DNS works, let's clarify two important roles that make the domain system possible:

Registry: The Domain Database Managers

  • A registry is an organization that manages a specific top-level domain (TLD)
  • For example, Verisign manages the .com and .net TLDs, while Public Interest Registry manages .org
  • Registries maintain the authoritative database for their TLDs
  • They operate the TLD nameservers that direct traffic to the correct domain
  • Registries don't sell domains directly to users

The Domain Hierarchy: Who Controls What

Think of the domain system as a tree:

Root (.)
  |
  ├── .com (managed by Verisign)
  |     |
  |     ├── amazon.com (managed by Amazon's nameservers)
  |     |
  |     └── google.com (managed by Google's nameservers)
  |
  └── .org (managed by Public Interest Registry)
        |
        └── wikipedia.org (managed by Wikimedia's nameservers)
Enter fullscreen mode Exit fullscreen mode

Each registry only manages its specific level in this tree:

  1. Verisign operates nameservers authoritative for .com itself

    • These TLD nameservers know which nameservers are responsible for each individual .com domain
    • But they don't store the actual IP addresses for websites

  2. Domain owners (like Amazon) operate nameservers authoritative for their specific domains

    • Amazon runs ns1.amazon.com, ns2.amazon.com, etc.
    • These servers contain all the DNS records (IP addresses, mail servers, etc.) for amazon.com

The registry simply maintains a database that says: "For information about amazon.com, ask Amazon's nameservers."

Why TLDs Don't Store IP Addresses: The Power of Delegation

You might wonder: "If the .com TLD servers already have a list of all .com domains, why don't they just store the IP addresses directly? Wouldn't that be faster by removing a step?"

This delegation approach is actually a brilliant design decision for several reasons:

  1. Scalability: There are hundreds of millions of .com domains, each with multiple DNS records. By delegating to authoritative nameservers, TLD servers remain manageable and efficient.

  2. Distributed Control: Domain owners can update their DNS records (change IPs, add subdomains, configure email) without involving the registry. You control your domain through your nameservers.

  3. Flexible Updates: Websites change servers, companies add new services, and IP addresses get updated frequently. If all these changes had to go through the TLD servers, it would create a massive bottleneck.

  4. Separation of Responsibilities: Verisign (the .com registry) focuses on maintaining the integrity of the TLD, while you focus on managing your specific domain's records.

  5. System Resilience: Distributing DNS across thousands of nameservers creates redundancy. If all .com records were in one place, it would be a single point of failure.

This delegation model is like a phone company maintaining a list of office building addresses, but letting each building manage its own internal directory of employee extensions. It's more efficient for everyone!

Flexible Nameserver Arrangements: Breaking the Hierarchy

While the domain system is hierarchical, nameservers don't have to follow this hierarchy. This creates flexibility in how domains are managed:

Nameserver Flexibility

A single nameserver can handle domains across different levels and TLDs:

  • Your hosting provider's nameserver (like ns1.hostgator.com) might handle:
    • yourbusiness.com
    • yourfriend.org
    • blog.someoneelse.net

This is like having one receptionist who knows about multiple unrelated businesses!

Examples of flexible nameserver arrangements:

  1. Hosting providers manage millions of unrelated domains on the same nameservers
  2. Large companies might use their nameservers for multiple brands (Google's nameservers handle google.com, youtube.com, gmail.com)
  3. Specialized services might take over part of your domain (blog.yoursite.com might use your blogging platform's nameservers)

What matters is not who owns the nameserver, but which nameserver is registered as authoritative for each domain. You can mix and match however works best for your needs.

Registrar: Your Domain Service Provider

  • A registrar (like GoDaddy, Namecheap, or Google Domains) is accredited by ICANN to sell domains
  • They act as the middlemen between you and the registry
  • Registrars handle domain registration, renewals, transfers, and DNS management
  • When you buy a domain, your registrar communicates with the appropriate registry to record your ownership

How Domain Registration Works

When you register a domain like "yourblog.com":

  1. You visit a registrar's website and check if the domain is available
  2. The registrar queries the .com registry (Verisign) to verify availability
  3. You purchase the domain through the registrar
  4. The registrar sends your information to the registry
  5. The registry adds your domain to its database
  6. The registry updates its nameservers with information about your domain's authoritative nameservers
  7. These updates propagate through the DNS system (which can take 24-48 hours)

This centralized registry system ensures that no matter which registrar you use, there's only one authoritative source of truth for each TLD.

The DNS Resolution Process: A Step-by-Step Journey

When you type a URL into your browser, a fascinating sequence of lookups begins. Let's walk through this journey:

1. Browser and OS Cache Check

Your system first checks if it already knows the answer:

  • Browser DNS Cache: Your browser keeps a temporary record of recent DNS lookups. You can view this in some browsers (in Edge, type "edge://net-internals/#dns" in the address bar).

  • Operating System Cache: If not found in the browser, your OS checks its own cache. This local resolver is called a stub resolver.

2. The Recursive Resolver: Your DNS Detective

If the domain isn't found locally, the query leaves your computer with a recursive flag set to true, heading to a DNS recursor server.

Think of the DNS recursor as a detective - it takes your case and investigates until it finds an answer. This server is typically provided by your Internet Service Provider (ISP) or public DNS services like Google's 8.8.8.8 or Cloudflare's 1.1.1.1.

The recursor first checks its own cache. If the information isn't there, it begins a journey through the DNS hierarchy.

3. The DNS Hierarchy: A Tree of Servers

The DNS system is structured as a hierarchical tree:

  • Root Servers: The recursor first contacts one of the 13 root server networks (labeled A through M). Despite being only 13 logical entities, these represent hundreds of physical servers distributed globally, operated by 12 independent organizations.

  • Top-Level Domain (TLD) Servers: The root server points the recursor to the appropriate TLD server (like .com, .org, or .net).

  • Authoritative Nameservers: The TLD server directs the recursor to the authoritative nameservers for the specific domain. These servers hold the actual DNS records (including IP addresses) for the domain you're looking for.

4. Finding the Final Answer

The recursor contacts the authoritative nameserver, which responds with the IP address for the requested domain. This information then flows back through the chain to your browser, which can finally connect to the website.

Intelligent Shortcuts: How DNS Optimizes Lookups

DNS resolvers are smart - they don't just cache complete domain resolutions. They remember:

  • Addresses of root servers
  • Addresses of TLD servers (like .com)
  • Addresses of authoritative nameservers

This strategic caching means that:

  1. If a resolver has seen a .com domain before, it can skip the root server step and go directly to the .com TLD server
  2. If it recognizes the authoritative nameservers for a domain, it can bypass both root and TLD servers

These shortcuts significantly speed up DNS resolution for frequently accessed domains.

Solving the Chicken-and-Egg Problem: Glue Records

Here's an interesting puzzle: If nameservers often have domain names themselves (like ns1.example.com), how do we resolve their domains without creating an infinite loop?

The solution is glue records. When a domain is registered, the registrar provides not just the nameserver's domain name but also its direct IP address to the TLD server. This breaks the circular dependency, allowing resolvers to find the nameserver's IP without having to resolve another domain name.

Types of DNS Queries

The DNS resolution process involves three distinct query types:

  1. Recursive Queries: Like asking a librarian to find a book for you. You expect a complete answer (the book) or a definitive "we don't have it."

  2. Iterative Queries: Like asking a librarian which section to look in, then going there yourself. The server gives you directions to the next stop, but you continue the journey yourself.

  3. Non-recursive Queries: Like asking for a book the librarian is already holding. These are quick responses for information the DNS server already has in its cache or is directly responsible for.

Reverse DNS: Looking Up Names from IP Addresses

While standard DNS answers "What IP address does example.com have?", Reverse DNS answers "What domain name is using IP address 93.184.216.34?"

This process uses the special .in-addr.arpa TLD (for IPv4) or .ip6.arpa (for IPv6). Reverse DNS is commonly used for:

  • Email server verification (reducing spam)
  • Server logging (showing domain names instead of IP addresses)
  • Network troubleshooting
  • Security monitoring

Conclusion

The Domain Name System is a marvel of internet engineering. Its distributed, hierarchical design allows billions of DNS queries to be resolved daily with remarkable efficiency.

Understanding DNS involves recognizing the roles of different entities:

  • Registries maintain the authoritative databases for TLDs
  • Registrars provide the interface between users and registries
  • DNS Servers (from root servers to your ISP's resolvers) work together to translate domains to IP addresses

This knowledge helps you:

  • Troubleshoot website connection issues
  • Make smarter decisions about hosting and domain management
  • Better understand who controls different aspects of your online presence
  • Appreciate how the internet maintains its user-friendly face

References

  1. How DNS Works - DNS Explained in Comic Form
  2. Cloudflare - What is DNS?

Comments 0 total

    Add comment