DNS Explained for Developers: How Domain Resolution Actually Works

What Is DNS?

The Domain Name System (DNS) is often called the "phonebook of the internet." It translates domain names like securebin.ai into IP addresses like 104.21.32.1 that computers use to route traffic. Without DNS, you would need to memorize IP addresses for every website you visit.

DNS is a distributed, hierarchical database. No single server holds all the records. Instead, responsibility is delegated across thousands of servers worldwide, organized in a tree structure.

The DNS Hierarchy

DNS is organized into a strict hierarchy with three main levels:

Root Servers

At the top of the hierarchy are the root name servers. There are 13 root server addresses (labeled A through M), operated by organizations like ICANN, Verisign, NASA, and the U.S. Army Research Lab. These servers do not hold domain records themselves — they hold pointers to the TLD servers. When a DNS resolver has no cached information at all, the root servers are the starting point.

TLD (Top-Level Domain) Servers

TLD servers are responsible for top-level domains like .com, .org, .ai, .io, and country codes like .uk and .de. When you query for securebin.ai, the root server directs the resolver to the .ai TLD server. The TLD server then directs to the authoritative name server for securebin.ai.

Authoritative Name Servers

The authoritative name server is the final authority for a domain. It holds the actual DNS records (A, AAAA, CNAME, MX, etc.) for the domain. When you configure DNS at your registrar or a service like Cloudflare, you are setting records on the authoritative name server.

How DNS Resolution Works

When your browser needs to resolve securebin.ai, here is the full chain of events:

1. Browser cache: The browser checks its own DNS cache first. If the domain was resolved recently and the TTL has not expired, the cached IP is used immediately.
2. OS cache: If not in the browser cache, the operating system's DNS resolver cache is checked (/etc/hosts is also consulted on Linux/macOS).
3. Recursive resolver: If the OS has no cached answer, the query goes to a recursive DNS resolver — typically operated by your ISP, or a public resolver like Cloudflare (1.1.1.1), Google (8.8.8.8), or Quad9 (9.9.9.9).
4. Root server: If the recursive resolver does not have the answer cached, it asks a root server: "Where is the .ai TLD server?"
5. TLD server: The resolver asks the .ai TLD server: "Where is the authoritative name server for securebin.ai?"
6. Authoritative server: The resolver asks the authoritative server: "What is the A record for securebin.ai?" The answer (the IP address) is returned.
7. Caching: Every server in the chain caches the result according to the TTL value, so subsequent queries are faster.

This entire process typically completes in under 100 milliseconds. Cached lookups resolve in under 1ms.

In practice, most queries never reach the root servers. Recursive resolvers cache heavily, and popular domains are almost always served from cache.

DNS Record Types

Here are the record types every developer should know:

A Record

Maps a domain to an IPv4 address. This is the most fundamental record type.

securebin.ai.    300    IN    A    104.21.32.1

AAAA Record

Maps a domain to an IPv6 address. The name comes from the fact that IPv6 addresses are four times the length of IPv4.

securebin.ai.    300    IN    AAAA    2606:4700:3030::6815:2001

CNAME Record

Creates an alias that points one domain to another. The resolver follows the chain to find the final A/AAAA record. You cannot have a CNAME at the zone apex (the root domain) alongside other records.

www.securebin.ai.    300    IN    CNAME    securebin.ai.

MX Record

Specifies the mail servers for a domain, with a priority value. Lower numbers = higher priority.

securebin.ai.    300    IN    MX    10    mail1.example.com.
securebin.ai.    300    IN    MX    20    mail2.example.com.

NS Record

Specifies the authoritative name servers for a domain. These are set at the registrar level.

securebin.ai.    86400    IN    NS    ns1.cloudflare.com.
securebin.ai.    86400    IN    NS    ns2.cloudflare.com.

TXT Record

Holds arbitrary text data. Commonly used for SPF (email authentication), DKIM, DMARC, domain verification (Google, Let's Encrypt), and other metadata.

securebin.ai.    300    IN    TXT    "v=spf1 include:_spf.google.com ~all"

SOA Record

The Start of Authority record defines the primary name server for the zone, the administrator's email, and zone transfer parameters (serial number, refresh interval, retry interval, expiry, minimum TTL).

TTL (Time to Live)

TTL is specified in seconds and tells DNS caches how long to store a record before re-querying the authoritative server. Common values:

• 300 (5 minutes): Good for records that may change frequently. Cloudflare uses this as default.
• 3600 (1 hour): A good balance for most static records.
• 86400 (24 hours): Used for records that rarely change, like NS records.

Before making DNS changes, lower the TTL first (e.g., to 300 seconds), wait for the old TTL to expire, then make the change. This ensures the change propagates quickly. After the change is verified, you can raise the TTL back up.

Caching Layers

DNS answers are cached at multiple levels:

1. Browser: Chrome, Firefox, and other browsers maintain their own DNS cache (typically 60 seconds, independent of TTL)
2. Operating system: The OS resolver caches records for the TTL duration (systemd-resolved on Linux, dscacheutil on macOS)
3. Recursive resolver: Your ISP or public resolver (1.1.1.1, 8.8.8.8) caches records for the TTL duration
4. CDN / proxy: Services like Cloudflare may cache records at their edge

This is why DNS changes are not "instant." Even with a short TTL, records may be cached at each layer. Full propagation typically takes 5 minutes to 48 hours depending on the original TTL.

DNS over HTTPS (DoH)

Traditional DNS queries are sent in plaintext over UDP port 53. Anyone on the network path (your ISP, a coffee shop Wi-Fi operator, a government) can see which domains you are resolving. DNS over HTTPS (DoH) encrypts DNS queries inside HTTPS requests, providing privacy and integrity.

Major browsers now support DoH. Firefox uses Cloudflare by default. Chrome uses the system resolver's DoH endpoint if available. You can also configure it system-wide:

• Cloudflare: https://cloudflare-dns.com/dns-query (1.1.1.1)
• Google: https://dns.google/dns-query (8.8.8.8)
• Quad9: https://dns.quad9.net/dns-query (9.9.9.9)

Debugging DNS with dig and nslookup

dig and nslookup are the essential command-line tools for DNS troubleshooting.

dig (Domain Information Groper)

# Basic A record lookup
dig securebin.ai

# Query a specific record type
dig securebin.ai MX
dig securebin.ai TXT
dig securebin.ai NS

# Query a specific DNS server
dig @1.1.1.1 securebin.ai

# Short output (just the answer)
dig +short securebin.ai

# Trace the full resolution path
dig +trace securebin.ai

# Show all record types
dig securebin.ai ANY

# Reverse DNS lookup
dig -x 104.21.32.1

nslookup

# Basic lookup
nslookup securebin.ai

# Query specific server
nslookup securebin.ai 1.1.1.1

# Query specific record type
nslookup -type=MX securebin.ai
nslookup -type=TXT securebin.ai

Flushing DNS Cache

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd)
sudo systemd-resolve --flush-caches

# Windows
ipconfig /flushdns

# Chrome browser
chrome://net-internals/#dns

Cloudflare DNS

Cloudflare is both a public DNS resolver (1.1.1.1) and a DNS hosting/proxy service. When you use Cloudflare as your authoritative DNS provider, you get several features beyond basic DNS:

• Proxied records: Cloudflare acts as a reverse proxy, hiding your origin IP and providing DDoS protection, WAF, and caching
• DNS-only records: Traffic goes directly to your origin server without Cloudflare proxying (grey cloud icon)
• DNSSEC: Cryptographic authentication of DNS responses, preventing DNS spoofing
• Fast propagation: Cloudflare propagates DNS changes globally in under 5 seconds for proxied records
• Flattening: Cloudflare supports CNAME-like behavior at the zone apex through CNAME flattening, working around the limitation that standard CNAME records cannot coexist with other records at the root

Common DNS Pitfalls

• Forgetting to lower TTL before changes: If your record has a 24-hour TTL, changes will take up to 24 hours to propagate. Lower TTL first, wait, then change.
• CNAME at zone apex: You cannot have a CNAME record at the root domain (e.g., example.com) alongside other records like MX or TXT. Use an ALIAS or ANAME record (provider-specific) or Cloudflare's CNAME flattening.
• Trailing dots: In DNS zone files, domain names end with a dot (example.com.). Omitting it can cause the domain to be treated as a subdomain.
• Testing against cached resolvers: When verifying DNS changes, query the authoritative server directly (dig @ns1.cloudflare.com example.com) rather than a caching resolver that may have stale data.
• Ignoring negative caching: Failed DNS lookups (NXDOMAIN) are also cached. If you queried a record before it existed, the negative answer may be cached for the SOA minimum TTL.

The Bottom Line

DNS is infrastructure you interact with daily, whether you realize it or not. Understanding the hierarchy, record types, TTL, and caching behavior makes you a better developer and a faster debugger. When something is "not working," the answer is often DNS.

For more developer tools, check out our JSON Formatter, JWT Decoder, Base64 Encoder, and Hash Generator — all free, all running in your browser. And when you need to share sensitive data, create an encrypted paste on SecureBin with zero-knowledge encryption.