How DNS Records Route Internet Traffic
Ever wondered, when you type a URL (Uniform Resource Locator, or simply the address of a website) like www.example.com into your browser:
“Where on earth should this request go?”
The system that solves this mystery is DNS (Domain Name System) — often called the phonebook of the internet.
Computers understand numbers (IP addresses), while humans prefer names (domain names). DNS acts as the bridge between the two by translating human-friendly domain names into machine-understandable instructions.
Instead of hard-coding IP addresses everywhere, DNS uses records — small configuration entries that describe how different kinds of requests for a domain should be handled. Different record types exist for different jobs: some point to web servers, some route emails, and some declare who is actually in charge of the domain’s DNS.
In this blog, we’ll break down the most important DNS record types, understand why they exist, and see how they work together in real production systems — in a way that’s easy to follow and useful for interviews.
What Are DNS Records and Why Do They Exist?
A DNS record is a single row in the DNS “database” that says:
For this name, here is how to handle a specific kind of request.
Each record answers a specific question about a domain, such as:
Where is the website hosted?
Where should email be delivered?
Who is responsible for managing the domain?
Instead of providing one generic answer, DNS uses different record types, each with a focused responsibility.
Think of DNS as a traffic control system:
Web traffic goes this way
Email traffic goes that way
Management and authority are handled separately
Each DNS record has at least:
Name (e.g.,
example.com,api.example.com)Type (A, AAAA, CNAME, MX, NS, TXT, etc.)
Value (IP address, another domain, mail host, or name server)
TTL (Time To Live) — how long DNS resolvers can cache the answer
In short, DNS records allow humans to use names instead of IP addresses, while ownership and configuration are cleanly delegated behind the scenes.
A Record: Mapping Domain Names to IPv4 Addresses
What Problem Does It Solve?
Computers do not understand domain names — they understand IP addresses.
An A (Address) record maps a domain name to an IPv4 address.
It answers the question:
“Which server IP should handle this request?”
Example
example.com → 93.184.216.34
When you type example.com, your browser first talks to a DNS resolver (also called a recursive DNS server). The resolver does the heavy lifting — querying the root name servers, the TLD server (.com), and finally the authoritative name server to obtain the A record.
This resolution happens before the TCP handshake. Without the A record, the browser has no IP address to send the initial SYN packet to.
Real-World Usage
Websites hosted on AWS, Azure, or GCP
Backend APIs
Load balancers pointing to multiple servers
AAAA Record: Mapping Domains to IPv6 Addresses
What Problem Does It Solve?
The internet is gradually moving from IPv4 to IPv6 due to address exhaustion.
An AAAA (Quad-A) record maps a domain name to an IPv6 address.
Functionally, it is the same as an A record — except it works with IPv6.
Question it answers:
“Which IPv6 server should handle this request?”
example.com → 2606:2800:220:1:248:1893:25c8:1946
Real-World Usage
Modern cloud infrastructure
Mobile networks
IPv6-enabled ISPs
Dual-stack deployments (IPv4 + IPv6)
CNAME Record: Domain Aliases and Indirection
What Problem Does It Solve?
Sometimes, the DNS resolver reaches the authoritative name server and receives another domain name instead of an IP address.
This is where the CNAME (Canonical Name) record comes in.
The CNAME answers:
“This domain is an alias — where is the real one?”
Example
www.example.com → example.com
The authoritative server is effectively saying:
“I don’t have an IP for
www.example.com, but I can tell you it’s an alias forexample.com.”
The resolver then resolves example.com (often using cached root and TLD data) to obtain the final A or AAAA record.
Real-World Usage
Cloud services (CloudFront, Azure App Service, GitHub Pages)
Avoiding IP changes when infrastructure changes
Cleaner DNS management
Key Points
You cannot have a CNAME and other record types (A, MX, TXT) for the same hostname.
CNAMEs are usually avoided at the zone apex (
example.com); instead, A/AAAA records are used.If the IP behind
example.comchanges, the CNAME does not need updating — only the final A/AAAA record does.
Common Confusion: A vs CNAME
| A Record | CNAME Record |
| Points to an IP | Points to another domain |
| Final destination | Indirection |
| Simple & direct | Flexible & scalable |
NS Record: Who Controls the Domain?
What Problem Does It Solve?
An NS (Name Server) record specifies which DNS servers are authoritative for a domain.
It answers:
“Which servers have the final, official DNS records for this domain?”
When the resolver queries the TLD server (.com), the TLD responds with NS records saying:
“I don’t know the IP, but these servers own the DNS for
example.com. Go ask them.”
Where the NS Record Lives (Delegation)
NS records exist in two places:
Parent zone (e.g.,
.com): tells resolvers where authority is delegatedChild zone (authoritative server): confirms it owns the zone
The “Chicken and Egg” Problem: Glue Records
If a nameserver is inside the same domain it serves (e.g., ns1.example.com), the resolver needs its IP before it can query it.
To solve this circular dependency, the TLD server provides a Glue Record — an A record containing the IP of the nameserver.
Key takeaway:
NS records say who to ask. Glue records say how to reach them.
Summary Table for the "End-to-End" Flow.
Step | Who is talking? | What record is exchanged? | Purpose |
1 | Resolver → Root | NS Record (for .com) | Find the TLD server. |
2 | Resolver → TLD | NS Record (for example.com) | Find the Authoritative server. |
3 | Resolver → Authoritative | A / CNAME / MX | Get the final answer (IP or alias). |
Common Confusion: NS vs MX
NS Record | MX Record |
Controls DNS authority | Controls email routing |
Used by DNS resolvers | Used by mail servers |
Set at registrar level | Email specific |
TXT Record: Storing Text-Based Instructions and Proof
What Problem Does It Solve?
Sometimes DNS needs to store information, not routing data.
A TXT record stores arbitrary text used by external systems for verification and security.
Question it answers:
“Can this domain prove or publish something?”
Example
example.com → "v=spf1 include:_spf.google.com ~all"
This SPF record tells mail servers which systems are allowed to send email for the domain.
Real-World Usage
SPF, DKIM, and DMARC
Domain ownership verification
SSL certificate validation
Third-party service integrations
Key Point:
TXT records do not control traffic. They provide proof and configuration data.
Final Thoughts: DNS Is Simple — Until It Isn’t
DNS looks simple on the surface, but it quietly powers almost everything on the internet. Websites load, emails get delivered, and cloud systems scale — all because DNS answers one fundamental question correctly:
“Where should this request go?”
Each DNS record exists to answer a specific version of that question:
A / AAAA → Where is the server?
CNAME → Is this an alias?
MX → Where should email be delivered?
TXT → Can this domain prove something?
NS → Who controls the domain?
In real production systems, these records work together, not in isolation. A single DNS change can enable global scale — or cause a global outage.
DNS isn’t about memorizing record types.
It’s about understanding traffic, ownership, and trust on the internet.
DNS Records: Interview Questions & Answers
Q1. What are DNS records and why do they exist?
Answer:
DNS records are instructions stored in DNS servers that tell the internet how to route requests for a domain. They exist to translate human-readable domain names into actionable information such as IP addresses, mail servers, or verification data.
Without DNS records, systems would not know:
Where a website is hosted
Where emails should be delivered
Who controls a domain
Q2. What is the difference between an A record and a CNAME record?
Answer:
An A record maps a domain directly to an IPv4 address.
A CNAME record maps a domain to another domain name.
Key rule:
A domain with a CNAME record cannot have other records like MX or TXT.
Example:
example.com → A → 93.184.216.34
www.example.com → CNAME → example.com
Q3. When should you use AAAA records?
Answer:
AAAA records are used to map a domain to an IPv6 address.
They are increasingly important as IPv6 adoption grows.
In modern production systems, it’s common to configure both A and AAAA records so clients can connect using either IPv4 or IPv6.
Q4. How does email routing work using MX records?
Answer:
MX records specify which mail servers are responsible for receiving emails for a domain.
They include a priority value, where lower numbers are tried first.
Example:
example.com → MX 10 mail1.example.com
example.com → MX 20 mail2.example.com
If the first server fails, the second is used automatically.
Q5. What is a TXT record and why is it important?
Answer:
TXT records store arbitrary text and are commonly used for:
Domain ownership verification
Email security (SPF, DKIM, DMARC)
Service integrations (Google, Microsoft, GitHub)
TXT records play a critical role in security and trust on the internet.
Q6. What does an NS record do?
Answer:
NS records define which name servers are authoritative for a domain.
They establish control and delegation, not traffic routing.
Without correct NS records:
DNS changes won’t propagate
Domains may stop resolving entirely
Q7. Can a single domain have multiple DNS records?
Answer:
Yes. A domain typically has multiple DNS records working together.
Example:
A / AAAA → Website access
MX → Email delivery
TXT → Security and verification
NS → DNS authority
Each record answers a different routing question.
Q8. Common DNS Interview Trick Question
Question:
Why can’t you use both CNAME and MX on the same domain?
Answer:
Because a CNAME replaces the domain name entirely with another name.
Allowing MX or TXT alongside it would create ambiguity during DNS resolution.
Q9. How does DNS relate to real production systems?
Answer:
In production:
Load balancers rely on DNS
Failover is often DNS-based
Cloud services depend heavily on DNS TTLs
Misconfigured DNS can cause global outages
DNS is a critical infrastructure layer, not just a configuration detail.
