Introduction

Applications usually refer to services through names such as api.example.com rather than directly embedding IP addresses. The Domain Name System, commonly abbreviated as DNS, provides the distributed naming infrastructure used to resolve these names and retrieve related information.

DNS can provide information such as:

• IPv4 and IPv6 addresses associated with a name
• Authoritative name servers for a zone
• Mail servers responsible for a domain
• Aliases between names
• Service-location information
• Reverse mappings from addresses to names
• Text-based verification and policy data
• Zone metadata and delegation information

DNS is hierarchical and distributed. Responsibility for different portions of the namespace can be delegated to different organizations and authoritative name servers.

In your System Design curriculum, DNS is Topic 3.2 under Networking and Web Request Lifecycle. It follows TCP/IP and UDP and precedes routing, TLS and HTTP. The module's practical exercise traces DNS, TLS and HTTP activity using tools such as dig, curl and Wireshark.

Prerequisites

What Is DNS?

DNS is a distributed, hierarchical naming system. It stores information in resource records associated with names in the DNS namespace.

DNS is often described as translating names into addresses, but DNS supports several record types and performs broader naming, delegation and service-discovery functions.

DNS Namespace

The DNS namespace is organized as a hierarchical tree. The root is at the top, followed by top-level domains, registered domains and subdomains.

                         Root
                           .
                           |
               +-----------+-----------+
               |           |           |
              com         org         net
               |
            example
               |
       +-------+--------+
       |       |        |
      www     api      mail

The fully qualified domain name api.example.com. can be read from the most specific label on the left toward the root on the right.

Name Components

Domains and Zones

A domain is a subtree of the DNS namespace. A zone is the portion of that namespace administered as one authoritative unit.

example.com zone
|
+-- example.com
+-- www.example.com
+-- api.example.com
|
+-- shop.example.com delegated elsewhere
        |
        +-- checkout.shop.example.com

When authority for shop.example.com is delegated, the parent zone contains information directing resolvers to the name servers responsible for the child zone.

DNS Participants

Recursive vs Authoritative Resolver

DNS Resolution Flow

When the recursive resolver does not have a usable cached answer, it can follow referrals from the root toward the authoritative server.

Application
    |
    | Resolve api.example.com
    v
Stub Resolver
    |
    v
Recursive Resolver
    |
    | Ask root for api.example.com
    v
Root Name Server
    |
    | Referral to .com servers
    v
Recursive Resolver
    |
    | Ask .com server
    v
.com TLD Server
    |
    | Referral to example.com servers
    v
Recursive Resolver
    |
    | Ask authoritative server
    v
Authoritative Server
    |
    | Return resource record
    v
Recursive Resolver
    |
    | Cache eligible answer
    v
Stub Resolver
    |
    v
Application

Resolution Steps

1. The application requests resolution of a name and record type.
2. The host's resolver logic checks applicable local sources and caches.
3. The stub resolver sends a query to the configured recursive resolver.
4. The recursive resolver checks whether it has a usable cached answer.
5. On a cache miss, the resolver follows DNS delegations.
6. The root provides information for the applicable top-level domain.
7. The top-level-domain server provides the delegated authoritative servers.
8. An authoritative server returns the requested answer or a defined negative response.
9. The recursive resolver caches eligible information according to DNS rules.
10. The recursive resolver returns the result to the requesting client.

Recursive and Iterative Queries

A stub resolver commonly requests recursive service from its configured resolver. The recursive resolver follows iterative referrals through the DNS hierarchy when required.

Resource Records

DNS data is represented through resource records. A resource record contains fields such as:

• Owner name
• Record type
• Class
• Time to live
• Type-specific resource data

Owner Name        TTL       Class     Type      Record Data
api.example.com.  300       IN        A         192.0.2.20

Common DNS Record Types

A and AAAA Records

api.example.com.  300  IN  A     192.0.2.20
api.example.com.  300  IN  AAAA  2001:db8::20

An application can request one or both address families. Receiving several addresses does not by itself define which one the application must use. Address selection, connection attempts and fallback are separate client behaviours.

CNAME Records

A CNAME record makes one owner name an alias of another name.

www.example.com.  300  IN  CNAME  web.example.net.
web.example.net.  300  IN  A      192.0.2.50

The resolver follows the alias to obtain the requested final data:

www.example.com
       |
       | CNAME
       v
web.example.net
       |
       | A
       v
192.0.2.50

Long alias chains can add resolution work and introduce more dependency points.

MX Records

MX records identify servers responsible for receiving email for a domain. Each record contains a preference value and target name.

example.com.  3600  IN  MX  10 mail1.example.com.
example.com.  3600  IN  MX  20 mail2.example.com.

A lower preference value has greater preference. The target name must resolve to the applicable network address used by the mail client.

NS and Delegation

NS records identify name servers responsible for a zone or delegated namespace.

example.com.  86400  IN  NS  ns1.example.net.
example.com.  86400  IN  NS  ns2.example.net.

A parent zone publishes delegation information directing resolvers toward the child zone's authoritative servers.

Glue Records

When an authoritative name server's address is required to follow a delegation and that address would otherwise depend on the delegated namespace itself, the parent can provide supporting address information called glue.

Delegation:

example.com.  NS  ns1.example.com.

Problem:

To query example.com,
the resolver needs the address of ns1.example.com.

Supporting glue:

ns1.example.com.  A  192.0.2.53

SOA Record

The Start of Authority record contains zone-related administrative and synchronization fields.

SOA data includes:

• Primary authoritative server name
• Responsible-party mailbox representation
• Zone serial value
• Refresh interval
• Retry interval
• Expiry interval
• A final timer field whose modern interpretation includes negative caching

example.com. IN SOA ns1.example.net. hostmaster.example.com. (
    2026092201
    3600
    900
    1209600
    300
)

The values above are synthetic examples and should not be treated as a production recommendation.

Time to Live

A DNS record's time to live, or TTL, controls how long eligible cached data can remain usable before it must be refreshed.

Authoritative answer:

api.example.com.  300  IN  A  192.0.2.20
                  |
                  +--> TTL of 300 seconds

A recursive resolver can cache the answer and return it to later clients while the cached data remains valid.

TTL Trade-off

Positive Caching

Positive caching stores successful DNS answers.

First query:

Client -> Recursive Resolver -> Authoritative Server
                                  |
                                  v
                               Answer
                                  |
                                  v
                                Cache


Later query before TTL expiry:

Client -> Recursive Resolver Cache -> Answer

Caching reduces repeated hierarchy traversal and decreases authoritative server load.

Negative Caching

DNS can cache authoritative negative information, such as confirmation that a requested name does not exist.

Query:
new-api.example.com

Authoritative response:
Name does not exist

Recursive resolver:
Cache eligible negative result

Later query:
Return cached negative response

Negative caching means a newly created name can remain unresolved by some resolvers until the previously cached negative information expires.

Common DNS Responses

NXDOMAIN vs Missing Record Type

Case 1:

Name:
missing.example.com

Result:
NXDOMAIN

Meaning:
The queried name does not exist.


Case 2:

Name:
service.example.com

Requested type:
MX

Result:
NOERROR with no MX answer

Meaning:
The name can exist, but the requested
record type is not present.

Distinguishing these cases is important for troubleshooting and negative caching.

Reverse DNS

Reverse DNS performs a lookup based on an address-oriented DNS name and typically returns a PTR record.

IPv4 address:
192.0.2.20

Reverse lookup name:
20.2.0.192.in-addr.arpa.

PTR answer:
host.example.com.

IPv6 reverse lookups use the applicable reverse namespace and nibble-based representation.

A reverse mapping does not automatically prove identity, authorization or ownership. Security decisions require appropriate authentication and validation.

DNS Transport

DNS can use UDP and TCP. DNS transport behaviour has evolved through standards beyond the original DNS specifications.

A client must handle the possibility that a response does not fit the initially selected transport response or indicates truncation. Modern DNS implementations can retry through an applicable transport according to the protocol and resolver policy.

DNSSEC

DNS Security Extensions add mechanisms that allow validating resolvers to verify the authenticity and integrity of signed DNS data through a chain of trust.

DNSSEC can help detect:

• DNS data modified in transit
• Forged signed answers
• Invalid delegation or signature chains

DNSSEC does not by itself:

• Encrypt DNS names or answers
• Hide queries from network observers
• Provide application-level authorization
• Replace TLS for web application traffic
• Guarantee that the destination application is safe

Encrypted DNS

Selected DNS clients and resolvers can communicate using encrypted transport mechanisms. Encryption protects the DNS exchange on that particular client-to-resolver path.

Encrypted transport and DNSSEC solve different problems:

DNS Security Risks

DNS-related risks include:

• Unauthorized zone changes
• Cache poisoning attempts
• Domain hijacking
• DNS amplification attacks
• Resolver abuse
• Subdomain takeover caused by dangling dependencies
• DNS tunnelling or unusual query patterns
• Misconfigured delegation
• Expired or incorrect DNSSEC data

Defensive Controls

• Restrict administrative access
• Use strong authentication for DNS management
• Separate administrative and runtime permissions
• Monitor unauthorized record changes
• Use resilient authoritative infrastructure
• Limit open recursive resolver exposure
• Apply response-rate and abuse controls where appropriate
• Review dangling aliases and delegated subdomains
• Validate DNSSEC configuration when DNSSEC is used
• Maintain an auditable change process

DNS in System Design

DNS participates in several architecture patterns:

• Mapping service names to addresses
• Directing users toward regional endpoints
• Supporting content-delivery endpoints
• Publishing mail-routing information
• Supporting service discovery
• Moving traffic during migration or failover
• Providing several endpoint addresses

DNS should not be treated as instantaneous, synchronized configuration distribution. Cached answers can remain active until their applicable lifetimes expire.

Multiple Address Records

api.example.com.  A  192.0.2.10
api.example.com.  A  192.0.2.20
api.example.com.  A  192.0.2.30

Publishing several addresses gives clients or resolvers several returned endpoints. It does not by itself guarantee equal traffic distribution, health-aware selection or immediate removal of a failed endpoint from caches.

Supporting design must define:

• How records are selected or ordered
• How endpoint health is determined
• How unhealthy destinations are removed
• How cached old answers are handled
• How clients retry another address
• How connection and request deadlines are applied

DNS-based Failover

Normal:

service.example.com
        |
        v
Primary endpoint


Failure detected:

DNS record is changed
        |
        v
New queries can receive backup endpoint


Existing caches:

Can continue returning the previous answer
until applicable cache data expires.

DNS-based failover is therefore influenced by TTLs, cache state, client behaviour, failure detection and endpoint retry policies.

DNS and Request Latency

Name resolution contributes to request latency when an answer is not already available from an applicable local or recursive cache.

A simplified web-request relationship is:

\[ T_{request} = T_{DNS} + T_{connection} + T_{TLS} + T_{HTTP} + T_{application} \]

DNS latency can be affected by:

• Local cache availability
• Recursive resolver proximity and load
• Authoritative server response time
• Alias-chain length
• Packet loss and retries
• DNSSEC validation
• Transport setup
• Network routing

DNS Availability

A service can be healthy but unreachable by name when required DNS resolution fails.

Availability considerations include:

• Several authoritative name servers
• Independent failure characteristics
• Geographic and network diversity
• Recursive resolver availability
• Valid delegation
• Zone consistency
• Monitoring from external networks
• Safe change and rollback procedures
• Cache behaviour during an authoritative outage

dig: Query DNS Records

The dig command displays DNS query and response information.

Query an IPv4 Address

dig example.com A

Query an IPv6 Address

dig example.com AAAA

Query Mail Servers

dig example.com MX

Query Authoritative Servers

dig example.com NS

Query Zone Metadata

dig example.com SOA

Query Text Records

dig example.com TXT

Reverse Lookup

dig -x 192.0.2.20

Show a Concise Answer

dig example.com A +noall +answer

Query a Specific Resolver

dig @RESOLVER_ADDRESS example.com A

Trace the Delegation Path

dig +trace example.com A

Request TCP Transport

dig +tcp example.com A

Replace example names and resolver addresses with approved targets.

Reading dig Output

Important sections and fields include:

Common DNS Flags

Host Resolver Commands

getent

getent ahosts example.com

getent uses the host's configured name-service mechanisms and can therefore reflect resolution sources beyond a direct DNS query.

Resolver Configuration

cat /etc/resolv.conf

The file can contain configured resolver addresses and resolver options, although its management depends on the Linux environment.

systemd-resolved Environments

resolvectl status

resolvectl query example.com

Command availability and resolver architecture vary by Linux distribution and system configuration.

curl and DNS Timing

curl -o /dev/null -sS \
  -w 'dns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://example.com/

This helps separate observed name-resolution time from connection, TLS and complete request time.

Packet Capture

Capture DNS Traffic

sudo tcpdump -i any -nn port 53

Capture DNS for One Host

sudo tcpdump -i any -nn host DNS_SERVER_ADDRESS and port 53

Wireshark Display Filter

dns

Packet captures can contain queried names, addresses and other sensitive metadata. Capture only in approved environments and retain data according to authorized policy.

DNS Troubleshooting Workflow

1. Confirm the exact queried name and record type.
2. Record the observed response status.
3. Identify the resolver used by the affected client.
4. Compare host resolution with a direct DNS query.
5. Inspect answer records, aliases and remaining TTLs.
6. Compare responses from selected recursive resolvers where authorized.
7. Trace the delegation path.
8. Query the authoritative servers directly.
9. Verify that every authoritative server provides consistent data.
10. Inspect network reachability and transport behaviour.
11. Check DNSSEC validation where applicable.
12. Correlate DNS results with the application's connection behaviour.

Scenario: Name Does Not Resolve

getent ahosts service.example.com
dig service.example.com A
dig service.example.com AAAA
dig service.example.com CNAME
dig +trace service.example.com
dig example.com NS
dig example.com SOA

Investigate:

• Whether the exact name exists
• Whether the requested record type exists
• Whether the delegation is valid
• Whether authoritative servers respond consistently
• Whether negative information is cached
• Whether DNSSEC validation fails
• Whether the client uses a different resolution source

Scenario: Old Address Is Returned

dig service.example.com A +noall +answer
dig @RECURSIVE_RESOLVER service.example.com A +noall +answer
dig @AUTHORITATIVE_SERVER service.example.com A +noall +answer

Investigate:

• The answer from the authoritative server
• The answer and remaining TTL from the recursive resolver
• Local application and operating-system caches
• Alias records with independent TTLs
• Whether every authoritative server contains the new zone version
• Whether the client uses private or split DNS

Scenario: DNS Is Slow

dig service.example.com A
dig @RECURSIVE_RESOLVER service.example.com A
dig +trace service.example.com A

curl -o /dev/null -sS \
  -w 'dns=%{time_namelookup}\ntotal=%{time_total}\n' \
  https://service.example.com/

Investigate:

• Recursive resolver latency
• Cache hit versus full resolution
• Packet loss and retries
• Slow or unreachable authoritative servers
• Long alias chains
• DNSSEC validation problems
• Search-domain or resolver configuration
• Difference between DNS time and complete application time

Common DNS Mistakes

Recommended Test Cases

DNS Best Practices

Practice Exercise

Trace the DNS resolution path for an approved test domain and connect the answer to the complete web request flow.

Tasks

1. Identify the host's configured resolver.
2. Query the domain's A and AAAA records.
3. Record the response status and TTL values.
4. Query NS and SOA records.
5. Trace the delegation from the root.
6. Query each authoritative server directly.
7. Identify aliases in the resolution path.
8. Compare recursive and authoritative answers.
9. Measure DNS lookup time through curl.
10. Capture the DNS exchange in an approved environment.
11. Continue the trace through connection establishment and TLS.
12. Document one failure scenario and the expected observable result.

Result Template

Queried name:
<Fully qualified domain name>

Record types:
<A, AAAA, CNAME, NS, SOA or others>

Client resolver:
<Configured recursive resolver>

Response status:
<NOERROR, NXDOMAIN, SERVFAIL or other>

Answer:
<Returned resource records>

Observed TTL:
<Remaining cache lifetime shown by the response>

Delegation path:
Root -> TLD -> Authoritative servers

Authoritative servers:
<Server names and consistency result>

Alias chain:
<Aliases followed during resolution>

DNS query time:
<Measured value>

Application result:
<Connection, TLS and HTTP outcome>

Failure tested:
<Missing name, timeout, stale answer or other>

Conclusion:
<Evidence-based explanation>

Frequently Asked Questions