DNS in System Design

When a user opens a website such as www.example.com, the browser needs to find the server that should receive the request.

This is where DNS comes in.

DNS stands for Domain Name System. It translates human-readable domain names into IP addresses.

1. Why Do We Need DNS?

Computers communicate using IP addresses, but remembering IP addresses for every application would be difficult.

Instead of accessing:

142.250.195.36

users can access:

www.example.com

DNS maps the domain name to the appropriate IP address.

flowchart LR
User --> DNS
DNS --> IPAddress
IPAddress --> Server

2. What Happens When You Open a Website?

Suppose the user enters:

https://api.example.com/orders

A simplified flow is:

sequenceDiagram
Browser->>DNS: Find api.example.com
DNS->>Browser: Return IP
Browser->>Server: HTTPS request
Server->>Browser: Response

The browser first needs to resolve the domain name before it can communicate with the destination.

3. DNS Resolution

DNS resolution involves multiple components.

A simplified hierarchy is:

flowchart TD
Browser --> Resolver
Resolver --> Root
Root --> TLD
TLD --> Authoritative
Authoritative --> Resolver
Resolver --> Browser

The main components are:

• DNS Resolver
• Root DNS servers
• TLD DNS servers
• Authoritative DNS servers

4. DNS Resolver

The DNS resolver is responsible for finding the IP address on behalf of the client.

For example:

api.example.com → 203.0.113.10

The resolver may already have the answer cached. If it does, it can return the result without performing the complete DNS lookup again.

5. DNS Cache

DNS caching is extremely important for performance.

DNS information can be cached at different locations:

• Browser
• Operating system
• Local network
• DNS resolver

If the IP address is already cached and the cache entry is still valid, the lookup can be much faster.

6. TTL

TTL stands for Time To Live.

A DNS record contains a TTL that determines how long the record can generally remain cached.

For example:

api.example.com
IP: 203.0.113.10
TTL: 300 seconds

A shorter TTL allows DNS changes to become visible sooner, while a longer TTL can reduce repeated DNS lookups.

7. Important DNS Record Types

Record	Purpose
A	Maps a domain to an IPv4 address
AAAA	Maps a domain to an IPv6 address
CNAME	Creates an alias to another domain name
MX	Specifies mail servers
TXT	Stores text-based information
NS	Identifies authoritative name servers

8. A Record

An A record maps a domain name to an IPv4 address.

api.example.com → 203.0.113.10

This is one of the most common DNS records used for web applications.

9. CNAME Record

A CNAME record creates an alias for another domain name.

For example:

www.example.com → app.example.net

The client can use www.example.com while DNS points it toward another hostname.

10. DNS and Load Balancers

DNS is frequently used together with load balancers.

Consider a large web application:

flowchart LR
User --> DNS
DNS --> LoadBalancer
LoadBalancer --> API1
LoadBalancer --> API2
LoadBalancer --> API3

DNS can point the application domain toward a load balancer, which then distributes traffic across backend servers.

11. DNS and Multiple Regions

Large systems may run infrastructure in multiple geographical regions.

flowchart TD
User --> DNS
DNS --> Region1
DNS --> Region2
Region1 --> API1
Region2 --> API2

Depending on the DNS service and configuration, traffic can be directed using mechanisms such as:

• Latency-based routing
• Geographic routing
• Weighted routing
• Failover routing

This can help distribute traffic and support disaster recovery architectures.

12. DNS Failover

Suppose an application has two regions:

Region 1 → Primary
Region 2 → Secondary

If the primary endpoint becomes unavailable, a DNS-based failover configuration can direct new traffic toward the secondary endpoint.

flowchart LR
User --> DNS
DNS --> Primary
Primary --> HealthCheck
DNS --> Secondary

The exact failover behavior depends on the DNS provider and health-check configuration.

13. DNS Does Not Replace a Load Balancer

This is an important system design distinction.

DNS can help decide where traffic should go.

A load balancer can decide which healthy server should handle the request.

flowchart LR
User --> DNS
DNS --> LoadBalancer
LoadBalancer --> Server1
LoadBalancer --> Server2

They solve different problems and are often used together.

14. DNS in an ASP.NET Core Application

Your ASP.NET Core application normally does not need to implement DNS logic itself.

For example, an application may call another service using:

var response = await httpClient.GetAsync(
    "https://payment.example.com/api/payments/1001");

The operating system and networking stack resolve payment.example.com before the connection is established.

15. DNS and Microservices

DNS can also be used for service discovery in distributed systems.

For example:

flowchart LR
OrderService --> PaymentService
PaymentService --> PaymentDNS
PaymentDNS --> PaymentServer

In cloud and container environments, service discovery mechanisms can provide DNS names for services.

This allows applications to communicate using service names instead of hard-coded IP addresses.

16. DNS Security

DNS is part of the infrastructure of almost every internet application, so DNS security matters.

Important concepts include:

• DNSSEC
• Secure DNS configuration
• Protection against DNS spoofing
• Access control for DNS management
• Monitoring DNS changes

17. DNS and HTTPS

DNS and HTTPS solve different problems.

DNS answers:

Where is api.example.com?

HTTPS provides secure communication with the destination.

flowchart LR
Browser --> DNS
DNS --> IP
Browser --> HTTPS
HTTPS --> Server

So DNS resolution and HTTPS communication are separate steps in the overall request flow.

18. What Happens If DNS Is Slow?

DNS resolution adds latency before the actual application request can begin.

For example:

DNS lookup
+
TCP connection
+
TLS handshake
+
HTTP request
+
Server processing

Therefore, system designers consider DNS caching and appropriate TTL values when designing high-traffic applications.

19. DNS Interview Scenario

Interviewer: Your application is deployed in India, Europe, and the US. How can DNS help?

Answer: DNS can be configured with routing policies that direct users toward appropriate regional endpoints. Depending on the requirement, latency-based, geographic, weighted, or failover routing can be used. The selected endpoint can then route the request to the regional infrastructure.

20. Important Interview Questions

• What is DNS?
• Why do we need DNS?
• How does DNS resolution work?
• What is a DNS resolver?
• What is an authoritative DNS server?
• What is an A record?
• What is a CNAME?
• What is TTL?
• How does DNS caching work?
• How can DNS support multi-region applications?
• What is DNS failover?
• What is the difference between DNS and a load balancer?
• How can DNS be used for service discovery?

Key Takeaways

• DNS converts domain names into IP addresses.
• DNS resolution may involve a resolver, root servers, TLD servers, and authoritative servers.
• DNS caching improves lookup performance.
• TTL controls how long DNS information can generally be cached.
• A records map names to IPv4 addresses.
• CNAME records create aliases to other domain names.
• DNS can help route users across regions.
• DNS and load balancers solve different problems.
• DNS is an important building block of scalable distributed systems.

Conclusion

DNS looks simple from the outside because users only see a domain name. Behind that name is a distributed system that helps clients discover where an application is hosted.

In system design, DNS becomes especially important when discussing load balancing, multi-region deployments, failover, caching, service discovery, and disaster recovery.

The next important networking concept is CDN, where we will see how static and frequently requested content can be served closer to users instead of making every request travel to the application servers.