DNS stands for:
Domain Name System
DNS is the distributed naming system that allows applications to use human-readable names such as:
www.example.cominstead of requiring users to remember an IP address.
At the simplest level:
Domain name
|
v
DNS
|
v
IP addressFor example:
www.example.com
|
v
203.0.113.10The browser can then use the destination address to establish network communication.
DNS is much more than a simple lookup table.
It is:
Understanding DNS is essential for System Design because DNS can participate in:
Imagine there were no DNS.
You would have to remember:
203.0.113.10instead of:
example.comThat creates several problems.
Names are easier to remember.
A service may move from:
203.0.113.10to:
203.0.113.50Users should not need to change the URL.
For example:
example.com
|
+----> Server A
|
+----> Server B
|
+----> Server CThis can support traffic distribution.
A global service can direct users toward different infrastructure based on location or other routing policies.
DNS therefore provides a flexible naming layer between users/applications and network destinations.
The most useful beginner mental model is:
Human-readable name
|
v
DNS
|
v
Network destinationFor example:
api.example.com
|
v
DNS lookup
|
v
203.0.113.25But the actual lookup can involve multiple components:
Application
|
v
Recursive Resolver
|
v
Root DNS
|
v
TLD DNS
|
v
Authoritative DNS
|
v
IP addressLet's understand each component.
DNS is hierarchical.
A domain such as:
www.example.comcan be viewed as:
www
|
example
|
com
|
.The final . represents the DNS root.
So conceptually:
.
└── com
└── example
└── wwwThe hierarchy allows DNS to be distributed.
No single server needs to store every domain on Earth.
At the top of the DNS hierarchy are the root servers.
The root does not normally provide the final IP address for:
www.example.comInstead, it can direct a resolver toward the appropriate top-level domain infrastructure.
Conceptually:
Resolver
|
| Where is .com?
v
Root
|
v
TLD informationThere are many instances of the root server system distributed globally.
The important idea is:
Root DNS helps the resolver navigate the DNS hierarchy.
TLD means:
Top-Level Domain
Examples:
.com
.org
.net
.in
.uk
.devFor:
www.example.comthe TLD is:
.comThe TLD infrastructure knows which authoritative name servers are responsible for domains under that TLD.
Conceptually:
Root
|
v
.com TLD
|
v
example.com authoritative DNSAn authoritative DNS server holds the DNS information for a domain or delegated zone.
For example:
example.commight have authoritative name servers that know records such as:
www.example.com → 203.0.113.10
api.example.com → 203.0.113.20The authoritative server is the source that can provide authoritative answers for the zone.
This distinction is extremely important:
Recursive resolver
→ Finds/caches answers
Authoritative server
→ Serves authoritative DNS data for its zoneMost end-user devices do not directly walk the complete DNS hierarchy for every lookup.
Instead, they commonly use a recursive resolver.
Conceptually:
Browser
|
v
Operating System
|
v
Recursive Resolver
|
+--> Root
|
+--> TLD
|
+--> AuthoritativeThe recursive resolver performs the work of finding the answer and can cache it.
Examples of recursive DNS services include:
The important role is:
A recursive resolver obtains DNS answers on behalf of clients.
This is a common interview question.
| Recursive Resolver | Authoritative Server |
|---|---|
| Finds answers for clients | Holds authoritative zone data |
| Can cache answers | Provides authoritative records |
| Queries other DNS servers | Serves its own zone |
| Acts on behalf of requester | Acts as authority for domain data |
Simplified:
Client
|
v
Recursive Resolver
|
v
Authoritative DNSSuppose the browser needs:
www.example.comA simplified resolution process is:
Browser
|
v
Local DNS cache
|
| miss
v
Recursive Resolver
|
| cached?
|
+---- YES → return answer
|
+---- NO
|
v
Root
|
v
.com TLD
|
v
Authoritative DNS
|
v
IP address
|
v
Recursive Resolver
|
v
BrowserThis is the core DNS flow.
Before querying a remote resolver, the operating system or browser may already have DNS information cached.
Conceptually:
Browser
|
v
Local cache
|
+---- HIT → IP
|
+---- MISS → ResolverCaching is critical because DNS lookups themselves take time and create network traffic.
DNS answers can be cached by multiple layers:
Browser
↓
Operating System
↓
Local / Network Resolver
↓
Authoritative DNSIf an answer is cached:
example.com
|
v
Cache
|
v
IP addressthe resolver does not necessarily need to ask the authoritative server again.
TTL stands for:
Time To Live
A DNS record can specify how long an answer may be cached.
Example:
TTL = 300 secondsThis means a cache can generally retain that DNS answer for the specified TTL before needing to obtain fresh information.
Mental model:
DNS Record
|
+---- TTL = 300After the TTL expires, a resolver may need to refresh the information.
Suppose:
api.example.com
|
v
Old ServerYou change it to:
api.example.com
|
v
New ServerIf caches still hold the old answer, clients may continue using the old destination until the cached record expires.
Therefore:
Lower TTL
→ faster changes
→ more DNS queries
Higher TTL
→ fewer DNS queries
→ changes can take longer to propagate through cachesThis is a classic trade-off.
People often say:
DNS propagation takes time.
A more precise explanation is that DNS information can remain cached according to TTLs and caching behavior.
Suppose:
Old IP = A
New IP = BDifferent recursive resolvers may have cached:
Resolver 1 → A
Resolver 2 → B
Resolver 3 → A
Resolver 4 → Bfor a period of time.
Therefore users may temporarily observe different answers.
DNS supports multiple record types.
The most important for System Design are:
Let's study them.
An A record maps a hostname to an IPv4 address.
Example:
example.com → 203.0.113.10Conceptually:
example.com
|
| A
v
203.0.113.10Use case:
api.example.com
↓
IPv4 destinationAn AAAA record maps a hostname to an IPv6 address.
Example:
example.com
|
| AAAA
v
2001:db8::10So:
A
→ IPv4
AAAA
→ IPv6A domain can have both.
CNAME means:
Canonical Name
It creates an alias from one hostname to another hostname.
Example:
www.example.com
|
| CNAME
v
example.cdn-provider.comThe resolver can then continue resolution for the target hostname.
CNAMEs are useful when an application wants a friendly domain name pointing to another hostname managed elsewhere.
Example:
api.example.com
↓
203.0.113.10api.example.com
↓
service.provider.com
↓
203.0.113.10The key difference:
A
→ hostname → IPv4 address
CNAME
→ hostname → another hostnameNS means:
Name Server
It identifies the authoritative name servers for a DNS zone.
Conceptually:
example.com
|
+---- NS → ns1.provider.com
|
+---- NS → ns2.provider.comThis delegation allows DNS responsibility to be distributed.
MX means:
Mail Exchange
It identifies mail servers responsible for receiving email for a domain.
Example:
example.com
|
| MX
v
mail.example.comMX records are primarily relevant to email systems rather than normal web traffic.
TXT records can store textual information associated with a domain.
They are commonly used for:
Example conceptually:
example.com
|
| TXT
v
"verification=..."SOA stands for:
Start of Authority
It contains important administrative information about a DNS zone.
It can include information such as:
You do not need to memorize every SOA field yet.
The important idea is:
SOA contains core administrative information for a DNS zone.
A DNS zone is an administrative portion of the DNS namespace managed under a particular authority.
For example:
example.commay be a DNS zone containing:
www.example.com
api.example.com
mail.example.comA zone can delegate responsibility for subdomains.
For example:
example.com
|
+---- dev.example.com
|
+---- delegated zoneZones are a key reason DNS can scale organizationally.
Suppose:
example.comis managed by one organization.
They can delegate:
internal.example.comto another authoritative DNS service.
Conceptually:
example.com
|
+---- NS → DNS provider A
|
+---- internal.example.com
|
+---- NS → DNS provider BThis allows different teams or organizations to manage different DNS portions.
Let's walk through:
api.example.comAssume there is no cached answer.
Client
|
| api.example.com?
v
ResolverResolver
|
v
RootRoot directs the resolver toward the .com TLD infrastructure.
.com#Resolver
|
v
.com TLDThe TLD infrastructure identifies the authoritative servers for:
example.comResolver
|
v
Authoritative DNSIt asks for:
api.example.comFor example:
api.example.com
A
203.0.113.20
TTL 300Resolver cache
api.example.com
→ 203.0.113.20
→ TTL 300Client
|
v
203.0.113.20The application can now establish the network connection.
These terms are often confusing.
The client asks the resolver:
Find the answer for me.
Client
|
| recursive query
v
ResolverThe resolver does the work.
The resolver can query DNS servers and receive referrals.
Conceptually:
Resolver → Root
Root → "Ask .com"
Resolver → .com
.com → "Ask example.com authoritative server"
Resolver → Authoritative
Authoritative → AnswerThe resolver iteratively follows the DNS hierarchy.
DNS can also tell a resolver that a name does not exist.
For example:
does-not-exist.example.commay return a negative response such as:
NXDOMAINNXDOMAIN means the queried domain name does not exist.
Negative answers can also be cached according to applicable DNS rules and zone configuration.
DNS can return multiple addresses.
Example:
api.example.com
A → 203.0.113.10
A → 203.0.113.11
A → 203.0.113.12A resolver/client may receive multiple addresses.
Conceptually:
api.example.com
|
+----> Server A
|
+----> Server B
|
+----> Server CThis can help distribute traffic.
However, DNS-based distribution has important limitations because:
DNS load balancing is therefore different from a traditional load balancer.
Consider:
DNS
|
+----> Server A
|
+----> Server Bversus:
DNS
|
v
Load Balancer
|
+----> Server A
|
+----> Server BWith a load balancer:
DNS operates earlier in the process:
Name resolution
↓
Destination selection
↓
Connection
↓
RequestTherefore DNS and load balancing solve related but different problems.
Suppose:
Primary
203.0.113.10fails.
A DNS-based system may change responses to:
Secondary
203.0.113.20Conceptually:
Before:
example.com
↓
Primary
After:
example.com
↓
SecondaryBut cached DNS answers mean clients may continue using the old address until caches expire.
Therefore DNS failover is not instantaneous in all cases.
DNS traffic-management systems can use health checks to determine whether destinations are healthy.
Example:
Health Check
|
+----> Server A ✓
|
+----> Server B ✗The DNS service can avoid returning unhealthy destinations depending on the provider and configuration.
This can be useful for:
A global application might have:
US users
↓
US infrastructure
India users
↓
India/Asia infrastructure
Europe users
↓
European infrastructureDNS-based traffic management can use geographic or latency-oriented policies to return different destinations.
Conceptually:
DNS
|
+---------+---------+
| | |
v v v
US Europe AsiaThe goal can be:
The exact routing capabilities depend on the DNS provider and architecture.
Anycast is a networking technique in which the same IP address is announced from multiple network locations.
Conceptually:
Same IP
|
+---------+---------+
| | |
v v v
Site A Site B Site CNetwork routing can direct users toward an appropriate nearby/available location according to routing policies.
Anycast is widely used in large-scale DNS and edge infrastructure.
Important distinction:
DNS
→ name resolution
Anycast
→ network routing techniqueThey can be used together but are not the same thing.
A common global architecture is:
User
|
v
DNS
|
v
CDN / Edge
|
v
OriginDNS may direct a hostname toward CDN infrastructure.
The CDN then decides which edge location serves the request.
This allows:
User in India
↓
Nearby edge
User in Europe
↓
European edgeThe actual routing architecture depends on the CDN provider.
Consider two TTL choices.
Advantages:
Disadvantages:
Advantages:
Disadvantages:
So:
Lower TTL
→ freshness
Higher TTL
→ caching efficiencyThe appropriate value depends on operational requirements.
DNS can also be used inside infrastructure.
Suppose:
payment-serviceneeds to find:
inventory-serviceA service-discovery system may provide a DNS name:
inventory-service.internalwhich resolves to an appropriate service endpoint.
Conceptually:
Payment Service
|
| DNS
v
inventory-service.internal
|
v
Service destinationCloud and container environments commonly provide DNS-based service discovery.
Kubernetes provides DNS-based service discovery inside clusters.
Conceptually:
Application Pod
|
| DNS lookup
v
service-name
|
v
Kubernetes Service
|
v
PodsThis means applications can communicate using service names rather than hard-coding pod IP addresses.
This will become especially useful when we later study Kubernetes system design.
DNS itself has security considerations.
Problems can include:
One important technology is:
DNSSEC — Domain Name System Security Extensions
DNSSEC adds cryptographic mechanisms that help validate the authenticity/integrity of DNS data.
DNSSEC does not encrypt normal DNS queries.
That distinction is important.
DoH means:
DNS over HTTPS
Instead of sending DNS queries using traditional DNS transport, the client can send DNS queries through HTTPS.
Conceptually:
Application
|
v
HTTPS
|
v
DNS resolverThis can provide encrypted transport between the client and the resolver.
DoT means:
DNS over TLS
It similarly protects DNS traffic using TLS.
Conceptually:
Client
|
| TLS
v
DNS ResolverDoH and DoT address transport privacy in different ways.
This distinction is important.
DNS generally helps answer:
Where is this service?It does not normally carry:
User's complete HTTP responseA simplified architecture:
DNS
↓
Find destination
HTTP
↓
Exchange application dataSuppose:
Browser
|
X
DNS ResolverThe browser cannot resolve:
api.example.comEven if the API servers are perfectly healthy, users may still be unable to access the service.
This demonstrates an important System Design principle:
A dependency can become a single point of failure even when the main application is healthy.
DNS infrastructure therefore needs:
Caching can actually provide resilience.
Suppose:
Authoritative DNS
X unavailableA recursive resolver may still have a valid cached answer:
Resolver cache
|
v
Existing DNS answerClients can potentially continue resolving the name while the cached record remains valid.
This is one reason caching is such a fundamental distributed-systems technique.
A useful advanced mental model:
DNS can act as a control mechanism for deciding where clients should connect.
For example:
example.com
|
v
DNS policy
|
+----> Region A
|
+----> Region BChanging DNS configuration can change the destinations clients receive.
But DNS is not a real-time request router because caching creates propagation and freshness constraints.
Imagine a service deployed in:
India
Europe
USAArchitecture:
Users
|
v
DNS
+-----------+-----------+
| | |
v v v
India Europe USA
| | |
v v v
Load Load Load
Balancer Balancer Balancer
| | |
App tier App tier App tierDNS may help direct users toward an appropriate region.
Inside each region:
Load Balancer
|
+---- App 1
+---- App 2
+---- App 3This gives us a layered architecture:
DNS
↓
Region
↓
Load Balancer
↓
ApplicationThe result might involve:
Different caches can expire at different times.
TTL and resolver behavior matter.
DNS can participate in traffic distribution, but it does not provide the same request-level control as a load balancer.
A CNAME points to another hostname.
CNAME
→ hostnameAn A record maps to IPv4.
A
→ IPv4DNSSEC provides authenticity/integrity mechanisms.
It is not the same thing as encrypted DNS transport.
Cached answers may continue to work until their relevant cache lifetime expires.
A distributed hierarchical naming system that maps names to information such as network destinations.
A recursive resolver obtains answers on behalf of clients and can cache them. An authoritative server provides authoritative records for its zone.
example.com?#At a simplified level:
Client
↓
Local cache
↓
Recursive resolver
↓
Root
↓
TLD
↓
Authoritative server
↓
IP/recordassuming the answer is not already cached.
The time associated with how long a DNS response may be cached before it should be refreshed according to DNS caching rules.
Hostname → IPv4 address.
Hostname → IPv6 address.
Hostname → another hostname.
It identifies name servers responsible for a DNS zone/delegation.
Yes, DNS can return multiple destinations or use traffic-management policies, but it has caching and control limitations compared with request-level load balancers.
It reduces lookup latency, network traffic and load on DNS infrastructure.
Explain this complete flow:
www.example.comfrom browser to IP address.
Include:
Explain the difference:
A
AAAA
CNAME
NS
MX
TXT
SOASuppose:
api.example.com
IP = A
TTL = 300 secondsAt 12
you change the IP to:BExplain why some users/resolvers may continue receiving A for a period of time.
Design:
Primary Region
Secondary Regionusing DNS-based failover.
Discuss:
Design a simple architecture for:
Users:
India
Europe
USA
Infrastructure:
India
Europe
USAExplain how DNS could participate in directing users toward regions.
Create a small conceptual program that models:
Client
↓
Cache
↓
Recursive Resolver
↓
Authoritative ServerSupport:
Example:
Lookup:
api.example.com
Cache:
MISS
Authoritative:
203.0.113.10
TTL:
60 seconds
Cache:
STOREThen repeat the lookup:
Lookup:
api.example.com
Cache:
HIT
Return:
203.0.113.10After TTL expiration:
Cache:
EXPIRED
Query authoritative DNS againThis exercise will make DNS caching behavior concrete.
DNS is not just an Internet utility.
It can become part of the architecture.
Consider:
User
|
v
DNS
|
+---------+---------+
| |
v v
Region A Region B
| |
v v
Load Balancer Load Balancer
| |
App Servers App ServersNow introduce failure:
Region A
X DOWNDNS traffic management may direct new clients toward Region B.
But remember:
DNS caching
↓
Not every client immediately receives the new destinationTherefore a production architecture may combine:
Think in layers:
DNS
|
v
Root (.)
|
v
TLD
(.com)
|
v
Authoritative DNS
(example.com)
|
v
Record
|
+--------+--------+
| | |
v v v
A AAAA CNAME
| | |
v v v
IPv4 IPv6 HostnameAnd think about caching:
Client
↓
Local Cache
↓
Recursive Resolver
↓
Authoritative DNSThe most important System Design principle is:
DNS provides a scalable naming and delegation layer, but caching means DNS-based routing is not the same as real-time request routing.
You should now understand:
Next we move from:
DNS
↓
Find the destinationto:
HTTP
↓
Actually communicate with the applicationWe will study:
Mark it as complete to track your mastery.