DNS (Domain Name System) Explained: How It Works, Record Types, Security, and Cloud

DNS — the Domain Name System — is the distributed directory that translates human-readable domain names like google.com into machine-readable IP addresses like 142.250.185.14. Every time a user opens a browser, sends an email, or an API makes an HTTP call, DNS runs first. Without DNS, the internet as we know it would not function: every device would need a manually maintained list of every server's IP address on the planet. DNS solves this by distributing that responsibility across a global hierarchy of millions of servers, resolving billions of queries per day in under 100 milliseconds.

For backend engineers, DNS is not just a networking detail — it directly affects availability, latency, failover speed, and security of the systems you build. A misconfigured TTL can make a zero-downtime deployment take six hours instead of five minutes. A missing DNSSEC configuration can expose your users to cache poisoning attacks. Understanding DNS at depth is essential for production system design.

The Problem DNS Solves

Servers on the internet are identified by IP addresses: 142.250.185.14 for IPv4 or 2607:f8b0:4004:c08::8b for IPv6. Humans cannot remember these. We remember names — google.com, api.stripe.com, s3.amazonaws.com.

DNS sits between the human-readable name and the machine-readable address. But it is far more than a simple lookup table.

The core design challenges DNS had to solve:

• Scale: There are over 350 million registered domain names. No single database can serve all queries.
• Speed: DNS resolution must be faster than the requests it enables — ideally under 10ms for cached lookups.
• Fault tolerance: A single point of failure for DNS would take down the entire internet. The system must survive server failures, DDoS attacks, and network partitions.
• Consistency with delay tolerance: When a record changes, the old answer remains valid in caches for a controlled period. Strong consistency is traded for availability and speed.

The solution is a distributed, hierarchical, cached system — and understanding that hierarchy is the foundation of everything else.

How a DNS Lookup Works (Step by Step)

When you type example.com in your browser, the following sequence occurs. Each step only happens if the previous one fails to return a cached answer.

Step 1: Browser and OS Cache

Your browser checks its own DNS cache first. Chrome and Firefox maintain separate caches from the OS. If the record is there and the TTL hasn't expired, the lookup completes in microseconds — no network traffic at all.

If the browser has no record, it asks the operating system. The OS checks its own cache (and /etc/hosts on Linux/macOS, C:\Windows\System32\drivers\etc\hosts on Windows).

# View OS DNS cache on macOS
sudo dscacheutil -cachedump -entries Host
 
# Flush OS DNS cache on macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
 
# Flush DNS cache on Linux (systemd-resolved)
sudo systemd-resolve --flush-caches

Step 2: Recursive Resolver

If neither cache has the answer, the OS sends a UDP query to the recursive resolver — also called a full-service resolver. This is configured automatically by your network (DHCP) and is typically:

• Your ISP's resolver
• A public resolver: Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9
• A corporate internal resolver (common in private networks)

The recursive resolver does the heavy lifting on your behalf. It has its own large cache shared across all its clients. Most popular domains are already cached here, so the resolver returns the answer immediately without contacting any upstream servers.

Step 3: Root Name Servers

If the recursive resolver has no cached answer, it queries one of the 13 root name server clusters (labeled A through M: a.root-servers.net through m.root-servers.net). These are not 13 physical servers — they use anycast routing and collectively comprise hundreds of physical machines worldwide.

The root servers do not know the IP address of example.com. They know who is responsible for .com — they return the addresses of the .com TLD name servers.

Step 4: TLD Name Servers

The recursive resolver now queries the .com TLD name servers (operated by Verisign). These servers know which authoritative name servers are responsible for example.com — this information is set when you register a domain.

The TLD servers return NS records pointing to ns1.example.com and ns2.example.com.

Step 5: Authoritative Name Server

The authoritative name server is the final authority. It has the actual DNS records for example.com — the A record, MX records, TXT records, everything. It returns the answer:

example.com.  3600  IN  A  93.184.216.34

Step 6: Response, Cache, and Connect

The recursive resolver returns the IP address to the OS, which passes it to the browser. Both the resolver and the OS cache the result for the duration of the TTL. Your browser then opens a TCP connection to 93.184.216.34 on port 443.

The entire process — steps 2 through 5 — typically takes 20–120ms on first lookup. Subsequent lookups for the same domain are served from cache in under 1ms.

Browser → OS cache → Recursive resolver → Root servers
                                        → .com TLD servers
                                        → Authoritative NS
                                        ← IP address returned
Browser ← OS ← Resolver (caches result)

DNS Record Types You'll Actually Use

DNS stores structured records, each with a type, a value, and a TTL. Here are the types backend engineers encounter most:

Record examples in zone file format

; A record — point domain to server
api.example.com.      300   IN  A     10.0.1.5
 
; AAAA record — IPv6
api.example.com.      300   IN  AAAA  2001:db8::1
 
; CNAME — www to apex (note: CNAME at apex is invalid — see common mistakes)
www.example.com.      3600  IN  CNAME example.com.
 
; MX — mail routing with priority
example.com.          3600  IN  MX    10 aspmx.l.google.com.
example.com.          3600  IN  MX    20 alt1.aspmx.l.google.com.
 
; TXT — SPF record for email authentication
example.com.          3600  IN  TXT   "v=spf1 include:_spf.google.com ~all"
 
; CAA — only Let's Encrypt can issue certs for this domain
example.com.          3600  IN  CAA   0 issue "letsencrypt.org"

CNAME limitations

A CNAME record cannot coexist with other records for the same name. This is why CNAME at the zone apex (example.com) is invalid — the apex must have NS and SOA records. Many DNS providers work around this with proprietary record types: Cloudflare's CNAME flattening, AWS Route 53's ALIAS record, and Dyn's ANAME.

TTL: How Long Records Are Cached

Every DNS record carries a TTL (Time To Live) in seconds. When a resolver caches the record, it will serve that cached answer until the TTL expires — it will not re-query the authoritative server before then.

example.com.  300  IN  A  93.184.216.34
              ↑
        TTL = 300 seconds = 5 minutes

TTL is the primary lever you have over DNS propagation speed and query load.

TTL strategy by use case

Migration pattern: At least 24 hours before a server move, lower TTL to 60 seconds. Execute the migration. Wait 60 seconds for old cached records to expire. Raise TTL back to 3600 seconds once stable.

# Check current TTL on a record
dig example.com A +noall +answer
# example.com.  287  IN  A  93.184.216.34
#               ↑
#         287 seconds remaining in cache

DNS in System Design

DNS is a first-class tool in distributed systems design — not just a deployment detail.

DNS-Based Load Balancing

Return multiple A records for the same name. Resolvers and clients will round-robin across them, distributing traffic:

api.example.com.  60  IN  A  10.0.0.1
api.example.com.  60  IN  A  10.0.0.2
api.example.com.  60  IN  A  10.0.0.3

Limitation: DNS load balancing is not health-aware. If 10.0.0.1 goes down, DNS still returns it. Use health checks at the DNS provider level (Route 53 health checks, Cloudflare Load Balancing) to remove unhealthy records automatically.

Geographic Routing

Return different IP addresses based on the geographic origin of the DNS query. Users in Europe get EU servers; users in Asia get APAC servers. This is the foundation of how CDNs work.

AWS Route 53 Geolocation routing and Cloudflare's Argo Smart Routing both operate at the DNS layer. When a resolver in Frankfurt queries for api.example.com, the authoritative server returns the Frankfurt endpoint IP.

Active Failover

Monitor your primary server with health checks. When it goes down, your DNS provider updates the record to point to a standby server. With a TTL of 60 seconds, failover is complete within 60–120 seconds.

Route 53 health check failover example:

Primary:  api.example.com → 10.0.1.5  (health check: HTTPS /health)
Failover: api.example.com → 10.0.2.5  (activates if primary fails)

Service Discovery in Microservices

In Kubernetes, CoreDNS provides internal DNS so services find each other by name:

# Service "payments" in namespace "prod" is reachable at:
payments.prod.svc.cluster.local
 
# From another pod in the same namespace:
curl http://payments/charge
# Kubernetes DNS resolves "payments" → ClusterIP automatically

This decouples services from hardcoded IP addresses. When a pod restarts and gets a new IP, the DNS record updates and all other services continue working without reconfiguration.

DNS Security: DNSSEC, DNS over HTTPS (DoH), DNS over TLS (DoT)

DNS was designed in 1983 without security in mind. The three main threats are:

1. Cache poisoning — attacker injects a forged DNS response into a resolver's cache, redirecting users to malicious IPs
2. DNS hijacking — attacker modifies DNS responses in transit (man-in-the-middle on port 53)
3. DNS surveillance — third parties (ISPs, governments, attackers) read unencrypted DNS queries to track user behavior

Three technologies address these threats:

DNSSEC (DNS Security Extensions)

DNSSEC adds cryptographic signatures to DNS records. The authoritative server signs each record set with a private key. Resolvers validate signatures against public keys published in the DNS hierarchy itself — the chain of trust runs from the root zone down to the individual domain.

Root Zone (.) → .com zone → example.com zone
Each level signs the next level's keys (DS records)

What DNSSEC protects against: cache poisoning, record tampering. What it does NOT protect: query privacy (DNS traffic is still plaintext on the wire).

Check if a domain has DNSSEC:

dig example.com +dnssec
# Look for RRSIG records in the answer — confirms DNSSEC is active
 
dig . DNSKEY
# Root zone public keys
 
# Validate full DNSSEC chain
dig example.com DS @8.8.8.8

DNSSEC adoption: ~35% of domains have it configured as of 2024. For any domain handling financial transactions, authentication, or sensitive data, enabling DNSSEC is a security baseline.

DNS over HTTPS (DoH)

DoH encrypts DNS queries inside standard HTTPS traffic (port 443). This prevents ISPs and network observers from seeing which domains you query.

Traditional DNS:  Client → [plaintext UDP port 53] → Resolver
DoH:              Client → [HTTPS TLS encrypted] → DoH resolver endpoint

DoH resolvers:

• Cloudflare: https://cloudflare-dns.com/dns-query
• Google: https://dns.google/dns-query
• NextDNS: https://dns.nextdns.io/<id>

DoH is supported natively in Firefox, Chrome, macOS 11+, Windows 11, and iOS 14+. Many corporate networks block or intercept DoH — it can interfere with split-horizon DNS setups where internal and external DNS need to return different results.

DNS over TLS (DoT)

DoT encrypts DNS queries using TLS on a dedicated port (853), rather than wrapping them in HTTPS. It provides the same privacy benefits as DoH but is more visible to network administrators because it uses a non-standard port.

Traditional DNS:  UDP/TCP port 53 (plaintext)
DoT:              TCP port 853 (TLS encrypted)
DoH:              TCP port 443 (HTTPS, looks like web traffic)

DoT is preferred in enterprise and network infrastructure contexts — it's transparent to network monitoring tools. DoH is preferred for browser-level privacy since it blends with HTTPS traffic.

# Test DoT with kdig (from knot-dnsutils)
kdig -d @1.1.1.1 +tls-ca example.com A
 
# Test DoH with curl
curl -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

Which Should You Use?

DNS in Cloud Infrastructure

AWS Route 53

Route 53 is Amazon's authoritative DNS service with global anycast infrastructure. Key capabilities:

Routing policies:

• Simple — single record, no health checks
• Weighted — split traffic by percentage (useful for canary deployments: 5% to new version)
• Latency-based — return the region with lowest measured latency to the querying client
• Geolocation — route by continent/country/US state
• Failover — active/passive with health checks
• Multivalue answer — return up to 8 healthy records (pseudo load balancing with health checks)

ALIAS records: Route 53's proprietary extension that lets you CNAME-like-point the zone apex to AWS resources (ALB, CloudFront, S3 bucket website) — something standard CNAME cannot do.

# Route 53 ALIAS at apex — valid
example.com  ALIAS  → my-alb-1234.us-east-1.elb.amazonaws.com
 
# Standard CNAME at apex — INVALID per DNS spec
example.com  CNAME  → my-alb-1234.us-east-1.elb.amazonaws.com  ← ERROR

Health checks: Route 53 health checkers probe endpoints from 15+ global locations every 10–30 seconds. When an endpoint fails, Route 53 removes it from DNS responses (if failover routing is configured) within one TTL cycle.

Cloudflare DNS

Cloudflare operates one of the largest authoritative DNS networks, with propagation times under 5 seconds globally (compared to minutes for traditional DNS providers). Key features:

• CNAME flattening at apex — resolves CNAME records server-side and returns A records to clients
• Cloudflare Load Balancing — Layer 7 health-aware DNS load balancing with geographic steering
• Argo Smart Routing — routes queries over Cloudflare's private backbone for lower latency
• Zero Trust DNS filtering — block malicious domains at the resolver level

Split-Horizon DNS (Split-Brain DNS)

Split-horizon DNS returns different DNS responses based on where the query originates. Internal clients (employees, servers) get internal IP addresses. External clients get public IP addresses.

External query for api.example.com → returns 203.0.113.10 (public load balancer)
Internal query for api.example.com → returns 10.0.1.5 (internal VPC IP, avoids hairpin)

Implementation options:

• Route 53 Private Hosted Zones: associate a zone with a VPC; queries from that VPC get internal records
• Unbound / CoreDNS: self-hosted resolver with view configuration
• Cloudflare for Teams: DNS filtering + split routing for corporate networks

AWS Route 53 private hosted zone example:

Public zone:  api.example.com  →  203.0.113.10
Private zone: api.example.com  →  10.0.1.5
              (associated with VPC vpc-abc123 — only visible to resources in that VPC)

Private DNS in Kubernetes

CoreDNS handles internal service discovery in Kubernetes clusters:

# View CoreDNS config
kubectl -n kube-system get configmap coredns -o yaml
 
# DNS name format for a service
<service>.<namespace>.svc.<cluster-domain>
# e.g.: payments.production.svc.cluster.local
 
# Headless service — returns individual pod IPs, not a single ClusterIP
# Useful for statefulsets where clients need to connect to specific pods

Troubleshooting DNS Issues

The Core Toolkit

# Basic lookup — what IP does this domain resolve to?
dig example.com A
 
# Query a specific resolver (bypass local cache)
dig @8.8.8.8 example.com A      # Google
dig @1.1.1.1 example.com A      # Cloudflare
dig @9.9.9.9 example.com A      # Quad9
 
# Show full answer section without extra noise
dig example.com A +noall +answer
 
# Check remaining TTL — how long until cache expires?
dig example.com A +noall +answer
# example.com.  247  IN  A  93.184.216.34
# ↑ 247 seconds left in cache
 
# Trace the full resolution chain from root to answer
dig +trace example.com A
 
# Check all record types
dig example.com ANY
 
# Reverse lookup — IP to domain
dig -x 93.184.216.34
 
# MX records (mail routing)
dig example.com MX
 
# NS records (which servers are authoritative)
dig example.com NS
 
# SOA record (zone serial number — useful to confirm propagation)
dig example.com SOA
 
# Check DNSSEC signatures
dig example.com A +dnssec

Diagnosing Propagation Issues

When you update a DNS record and it seems to not be taking effect:

# Compare what different resolvers see
dig @8.8.8.8 example.com A +short   # Google sees?
dig @1.1.1.1 example.com A +short   # Cloudflare sees?
dig @9.9.9.9 example.com A +short   # Quad9 sees?
 
# Query the authoritative server directly (bypasses all caches)
# First, find the authoritative NS
dig example.com NS +short
# Returns: ns1.example.com.
 
# Then query it directly
dig @ns1.example.com example.com A
 
# If authoritative returns new IP but public resolvers return old IP:
# The change is live — wait for TTL on public resolvers to expire

Python DNS Lookup

import socket
import dns.resolver  # pip install dnspython
 
# Simple lookup using socket (uses OS resolver)
ip = socket.gethostbyname("example.com")
print(f"example.com → {ip}")
 
# Advanced lookup with dnspython
resolver = dns.resolver.Resolver()
resolver.nameservers = ["8.8.8.8"]  # Use specific resolver
 
# A records
answers = resolver.resolve("example.com", "A")
for rdata in answers:
    print(f"A: {rdata.address}, TTL: {answers.ttl}")
 
# MX records
mx_records = resolver.resolve("example.com", "MX")
for rdata in sorted(mx_records, key=lambda x: x.preference):
    print(f"MX priority={rdata.preference}: {rdata.exchange}")
 
# TXT records (SPF, DKIM verification)
txt_records = resolver.resolve("example.com", "TXT")
for rdata in txt_records:
    for string in rdata.strings:
        print(f"TXT: {string.decode()}")
 
# Check if a domain exists (NXDOMAIN detection)
try:
    resolver.resolve("nonexistent.example.com", "A")
except dns.resolver.NXDOMAIN:
    print("Domain does not exist")
except dns.resolver.NoAnswer:
    print("Domain exists but no A record")
except dns.resolver.Timeout:
    print("DNS query timed out")

Reading dig Output

$ dig api.example.com A
 
; <<>> DiG 9.18 <<>> api.example.com A
;; QUESTION SECTION:
;api.example.com.    IN  A       ← what was asked
 
;; ANSWER SECTION:
api.example.com. 300 IN A 10.0.1.5   ← the answer, TTL=300
 
;; AUTHORITY SECTION:
example.com. 3600 IN NS ns1.cloudflare.com.  ← authoritative servers
 
;; Query time: 12 msec     ← resolver latency
;; SERVER: 1.1.1.1#53      ← which resolver answered
;; WHEN: ...
;; MSG SIZE rcvd: 68

Key fields:

• ANSWER SECTION: the record returned. If empty, the record doesn't exist.
• AUTHORITY SECTION: which servers are authoritative — useful to confirm delegation is correct.
• NXDOMAIN: domain does not exist at all.
• NOERROR + empty ANSWER: domain exists, but no record of the requested type.
• Query time: latency to the resolver. Sudden spikes indicate resolver or network issues.

nslookup Alternative

# nslookup (available on Windows/macOS/Linux without extra install)
nslookup example.com           # basic lookup
nslookup example.com 8.8.8.8   # use specific resolver
nslookup -type=MX example.com  # MX records
nslookup -type=NS example.com  # NS records
 
# Interactive mode
nslookup
> server 1.1.1.1
> set type=A
> example.com

Common DNS Mistakes Engineers Make

1. Wrong TTL Before a Migration

Setting TTL too late — or not at all — before a server migration. If your TTL is 86400 (24 hours) and you change your A record, the old IP will be served by cached resolvers for up to 24 hours.

Fix: Lower TTL to 60–300 seconds at least 24 hours before any planned migration. After the migration is stable, raise it back.

2. CNAME at Zone Apex

Attempting to set a CNAME record on the root domain (example.com with no subdomain). DNS specification forbids CNAME records on the apex because the apex must carry NS and SOA records, and CNAME cannot coexist with other record types.

# WRONG — will be rejected or behave unexpectedly
example.com  CNAME  myloadbalancer.elb.amazonaws.com  ← INVALID
 
# CORRECT — use ALIAS (Route 53), ANAME (DNS Made Easy), or CNAME flattening (Cloudflare)
example.com  ALIAS  myloadbalancer.elb.amazonaws.com  ← Route 53 proprietary, works

3. Forgetting to Remove Old Records

When migrating from one email provider to another or switching CDNs, engineers add the new records but forget to remove the old conflicting ones. Multiple MX records with the same priority, or multiple A records pointing to decommissioned IPs, cause non-deterministic routing.

# Audit all records for your domain
dig example.com ANY +noall +answer
 
# Check specifically for duplicate A records
dig example.com A +noall +answer | wc -l

4. Hardcoding IP Addresses Instead of DNS Names

In application configs, database connection strings, or infrastructure code, using raw IP addresses instead of DNS hostnames. When the server moves or restarts with a new IP, everything breaks and requires a full redeployment.

# WRONG
DB_HOST = "10.0.1.5"
 
# CORRECT — use DNS name, resolves dynamically
DB_HOST = "db.internal.example.com"

5. Not Accounting for DNS Caching in Health Checks

Using DNS names in load balancer health checks without understanding that the health checker may cache the resolved IP. If you update DNS to point to a new backend, the health checker may still be probing the old IP for up to one TTL period.

6. Missing Wildcard Records for Subdomains

Deploying an app that dynamically generates subdomains (tenant1.app.com, tenant2.app.com) without a wildcard DNS record. Each new tenant gets a DNS error until you manually add a record.

# Wildcard — matches any subdomain not explicitly defined
*.app.example.com.  300  IN  A  10.0.1.5

7. Ignoring Negative Caching (NXDOMAIN TTL)

NXDOMAIN responses (domain does not exist) are also cached, controlled by the SOA record's minimum TTL field. If you make a typo in a domain name, look it up (getting NXDOMAIN), then fix the typo, resolvers may still return NXDOMAIN for the SOA's negative cache period.

# Check the SOA negative cache TTL
dig example.com SOA +noall +answer
# The last number is the negative caching TTL

FAQ

What is DNS and why does it matter for backend engineers?

DNS (Domain Name System) is the distributed system that translates domain names into IP addresses. For backend engineers, it matters because DNS sits at the entry point of every request your system handles. DNS configuration controls how traffic is routed to your servers, how fast failover happens when a server goes down, whether your users can be directed to geographically close infrastructure, and whether your system is protected against cache poisoning attacks. A misconfigured DNS record can make a service unreachable; a well-tuned DNS setup can reduce latency and enable zero-downtime deployments.

How long does DNS propagation take?

Propagation time equals the TTL (Time To Live) of the record being changed. If your A record has a TTL of 3600 seconds (1 hour), resolvers worldwide will serve the old record for up to 1 hour after you change it. With a TTL of 60 seconds, propagation completes in about 60–120 seconds. The common claim that "DNS propagation takes 24-48 hours" is only true if your TTL is set to 86400 seconds (24 hours) — which is the default on many registrars. Always lower your TTL before planned changes.

What is the difference between authoritative and recursive DNS servers?

An authoritative DNS server holds the actual DNS records for a domain. It is the final source of truth. When you configure DNS records for example.com through your DNS provider (Cloudflare, Route 53, etc.), those records live on authoritative servers.

A recursive resolver (also called a full-service resolver) does the lookup work on behalf of clients. It has no DNS records of its own — it queries the hierarchy (root → TLD → authoritative) to find answers and caches them. Your ISP's DNS server and public resolvers like 8.8.8.8 and 1.1.1.1 are recursive resolvers.

What is DNS TTL and what value should I use?

TTL (Time To Live) is the number of seconds a DNS record can be cached by resolvers before they must re-query the authoritative server. Higher TTL = less query load and faster responses (from cache). Lower TTL = changes propagate faster but generate more queries.

General guidelines: use 3600–86400 for stable records (A, MX), 300–600 for CDN or load-balanced endpoints where health routing matters, and 60 seconds during active migrations for fast rollback capability. Never leave the default TTL (often 86400) on records you might need to change quickly in an incident.

How does DNS load balancing work?

DNS load balancing works by returning multiple A records for the same domain. When a resolver receives multiple A records, it typically returns all of them to the client. The client (or application) picks one — often by rotating through the list (round-robin). This distributes connections across multiple servers without requiring a dedicated load balancer.

Limitation: DNS load balancing is not health-aware by default. Dead servers stay in rotation until the DNS record is manually removed. Cloud DNS providers (Route 53, Cloudflare) offer health-checked load balancing that automatically removes unhealthy endpoints from DNS responses.

What is DNSSEC and when should I use it?

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, allowing resolvers to verify that a response came from the legitimate authoritative server and was not tampered with in transit. It prevents cache poisoning attacks where an attacker injects forged DNS responses.

Use DNSSEC for: any domain handling authentication, financial transactions, or sensitive user data. It is also recommended as a security baseline for any public-facing service. Check with your DNS provider — most major providers (Route 53, Cloudflare, Google Cloud DNS) support DNSSEC with one-click enablement. Verify with dig example.com +dnssec and look for RRSIG records in the response.

How do I debug DNS issues in production?

Start with dig @8.8.8.8 yourdomain.com A +noall +answer to see what a major public resolver returns, bypassing local caches. Compare against dig @1.1.1.1 yourdomain.com A +short (Cloudflare) — if they differ, propagation is still in progress.

Query the authoritative server directly with dig @ns1.yourdomain.com yourdomain.com A — if the authoritative returns the correct record but public resolvers return old data, the change is live and you need to wait for TTL expiry. Use dig +trace yourdomain.com to trace the full delegation chain and identify where resolution breaks. For NXDOMAIN errors on a record you just added, check the SOA negative cache TTL — it controls how long "domain not found" responses are cached.

Related reading: OSI Model Explained · Network Protocols: TCP, UDP, HTTP