DNS Explained: How the Domain Name System Works 2026

DNS Explained: How the Domain Name System Works — A Complete Technical Guide

The Domain Name System (DNS) is one of the most important services behind modern networks and the Internet. Every time you open a website, connect to an API, send an email, access a cloud application, or use a service identified by a hostname, DNS may be involved before the actual application connection begins.

At its simplest, DNS translates a human-readable domain name such as example.com into network information that computers can use, such as an IPv4 or IPv6 address. However, describing DNS only as a “domain-to-IP converter” misses much of what the system actually does.

DNS is a distributed, hierarchical naming system. It can identify web servers, mail servers, authoritative nameservers, service endpoints, aliases, certificate-authority policies, email-security information, and other resources. DNS also includes caching, delegation, recursive resolution, authoritative zones, security extensions, and multiple transport mechanisms.

If you are learning DNS as part of networking, it helps to understand the broader communication model first. Our Computer Networking Explained guide introduces the foundations, while TCP/IP Explained explains how IP addressing, TCP, UDP, ports, and network layers fit together.

The fundamental DNS architecture is documented in RFC 1034 and RFC 1035, which define core concepts of the domain namespace, resolvers, nameservers, zones, queries, and resource records.

In this guide, we will examine DNS from the ground up: how DNS resolution works, what recursive and authoritative servers do, how DNS records are structured, why caching and TTL matter, how DNSSEC protects DNS data, and how to troubleshoot DNS failures systematically.

1. What Is DNS?

DNS stands for Domain Name System.

Its best-known function is associating human-readable domain names with IP addresses.

For example:

example.com → 203.0.113.10

Instead of requiring users to remember an IP address, applications can use a stable and recognizable hostname.

But DNS does much more than this.

DNS can provide information about:

• IPv4 addresses
• IPv6 addresses
• Mail servers
• Authoritative nameservers
• Domain aliases
• Service locations
• Reverse DNS mappings
• Certificate-authority policies
• Email authentication
• Domain ownership verification
• Other service-specific information

This makes DNS a fundamental part of Internet infrastructure rather than simply a convenience for web browsing.

A website may change servers, IP addresses, hosting companies, cloud regions, or network architecture while retaining the same public domain name. DNS creates an abstraction between the service name users recognize and the underlying infrastructure delivering that service.

2. Why Does DNS Exist?

Imagine an Internet without DNS.

Instead of visiting:

example.com

you might have to remember:

203.0.113.10

for one service and a different address for another.

That would be inconvenient, but human convenience is only part of the reason DNS matters.

Consider a website moving from one server to another:

Old server

203.0.113.10

New server

198.51.100.25

With DNS, the public name can remain:

example.com

while the DNS administrator changes the address associated with it.

The relationship becomes:

User → example.com → DNS → current server address

This separation allows infrastructure to evolve while service names remain relatively stable.

DNS is therefore both a naming system and an abstraction layer between applications and the network infrastructure behind them.

3. DNS Is a Distributed Database

A common misconception is that one central server stores the DNS information for every domain on the Internet.

That is not how DNS works.

DNS is a distributed database organized hierarchically.

A simplified DNS namespace looks like this:

.
└── com
    └── example.com
        ├── www
        ├── mail
        └── api

The dot at the top represents the DNS root.

Below the root are Top-Level Domains such as:

• .com
• .org
• .net
• .uk
• .fr
• .de
• .ma

Below a TLD can be a registered domain such as:

example.com

The domain can then contain additional names such as:

www.example.com

mail.example.com

api.example.com

This architecture allows responsibility to be delegated.

The root does not need to know the final IP address of every website. Instead, it knows how to direct resolvers toward the infrastructure responsible for different parts of the DNS namespace.

Information about the root zone and TLD infrastructure is coordinated through IANA’s Domain Name Services.

4. Understanding the DNS Hierarchy

The DNS hierarchy can be simplified as:

Root
  ↓
Top-Level Domain
  ↓
Domain
  ↓
Subdomain / Hostname

Consider:

www.example.com

Reading from right to left:

• . represents the root.
• com is the Top-Level Domain.
• example is the registered domain.
• www is a hostname or subdomain label within that namespace.

When a recursive resolver needs information about www.example.com, it can follow the hierarchy:

Root DNS
   ↓
.com TLD
   ↓
example.com authoritative DNS
   ↓
www.example.com record

This hierarchy is fundamental to DNS scalability.

5. The DNS Stub Resolver

Most end-user systems do not independently walk the DNS hierarchy every time they need to resolve a hostname.

Instead, the operating system typically contains or interacts with a stub resolver.

An application may request:

What is the address for example.com?

The request can follow a path similar to:

Application
    ↓
Operating System
    ↓
Stub Resolver
    ↓
Recursive DNS Resolver

The stub resolver forwards the request to a configured recursive resolver.

That resolver may be supplied by:

• An ISP
• A corporate network
• A home router
• A VPN
• A public DNS provider
• An enterprise DNS infrastructure

This distinction becomes useful during troubleshooting because the problem can exist at the local host, configured resolver, authoritative DNS, or another layer.

6. Recursive DNS Resolvers

A recursive DNS resolver performs DNS resolution on behalf of clients.

Suppose the client asks for:

www.example.com

If the answer is not already available in cache, the resolver may need to query other DNS infrastructure.

Conceptually:

Client
   ↓
Recursive Resolver
   ↓
Root
   ↓
TLD
   ↓
Authoritative DNS
   ↓
Answer

The resolver then returns the result to the client.

Recursive resolvers also perform another extremely important function: caching.

If thousands of users request the same domain, the resolver does not necessarily repeat the complete hierarchy lookup thousands of times. A valid cached response can be reused until its applicable caching lifetime expires.

This reduces latency, bandwidth consumption, and load on authoritative DNS infrastructure.

7. Root DNS Servers

The DNS root is represented by:

.

Root DNS infrastructure sits at the top of the public DNS hierarchy.

When a recursive resolver does not know where to find information about a domain such as example.com, it can query the root infrastructure.

The root does not normally return the final IP address for example.com.

Instead, it provides information that directs the resolver toward the appropriate Top-Level Domain infrastructure.

Conceptually:

Resolver
   ↓
Root
   ↓
.com TLD servers

A frequently repeated statement says that the Internet has “13 root servers.”

More precisely, there are 13 named root server identities. The infrastructure behind those identities is distributed across many physical instances and geographic locations, commonly using technologies such as Anycast.

8. Top-Level Domain Servers

A Top-Level Domain, or TLD, is the part of a DNS name immediately below the root.

Examples include:

.com

.org

.net

.uk

.de

.fr

.ma

If the resolver is looking for:

www.example.com

the root can refer it to the infrastructure responsible for .com.

The TLD infrastructure can then provide delegation information identifying the authoritative nameservers responsible for example.com.

The process becomes:

Resolver
   ↓
Root
   ↓
.com
   ↓
Authoritative servers for example.com

The TLD server generally does not need to know the final address for www.example.com; its important role is helping the resolver find the authoritative source.

9. Authoritative DNS Servers

An authoritative DNS server serves authoritative data for one or more DNS zones.

If the authoritative zone for example.com contains:

www.example.com. IN A 203.0.113.10

the authoritative server can return that information when queried appropriately.

Authoritative servers may contain records such as:

• A
• AAAA
• CNAME
• MX
• TXT
• NS
• SOA
• CAA
• SRV

This makes authoritative DNS the source of record data for the zones it serves.

Redundancy is important because if all authoritative DNS infrastructure for a domain becomes unreachable, users may eventually be unable to resolve its names even if the application servers themselves remain operational.

10. Recursive DNS vs Authoritative DNS

Recursive and authoritative DNS perform different jobs.

The simplest distinction is:

Recursive resolver: “I will find the answer for you.”

Authoritative DNS: “I am an authoritative source for this zone.”

Confusing these roles can make DNS troubleshooting much harder.

11. Recursive and Iterative DNS Queries

DNS resolution involves different query behaviors.

Recursive Query

In a recursive request, the client asks the recursive resolver to return a final answer or an appropriate error.

Conceptually:

Client
   ↓
Recursive Resolver
   ├── Root
   ├── TLD
   └── Authoritative DNS

The client does not need to perform each intermediate lookup itself.

Iterative Query

In iterative resolution, a DNS server can return the best information it has, including a referral to another DNS server.

For example:

Resolver → Root
Root → Ask .com

Resolver → .com
.com → Ask example.com's authoritative server

Resolver → Authoritative DNS
Authoritative DNS → Final answer

This combination of recursion and referrals is central to normal DNS resolution.

12. How a Complete DNS Lookup Works

Suppose a user enters:

https://www.example.com

into a browser.

Before the browser can communicate with the web server, it needs network information for www.example.com.

A simplified lookup can proceed as follows.

Step 1: Application and Local Cache

The browser or operating system may already have usable cached information.

If it does, a new external DNS lookup may not be necessary.

Step 2: Recursive Resolver

If the local system does not have the required answer, it sends the query to its configured recursive DNS resolver.

Step 3: Resolver Cache

The recursive resolver checks its own cache.

If a valid cached answer exists, it can return it immediately.

Step 4: Root Query

If the resolver has no usable cached information, it can begin walking the DNS hierarchy.

For a .com domain, root infrastructure can direct it toward the .com TLD infrastructure.

Step 5: TLD Query

The resolver asks the appropriate TLD infrastructure about the domain.

The TLD response provides delegation information for the domain’s authoritative nameservers.

Step 6: Authoritative Query

The resolver queries the authoritative DNS infrastructure.

The authoritative server returns the requested record or other appropriate DNS response.

Step 7: Cache and Return

The recursive resolver can cache the information according to DNS caching rules and return the answer to the client.

Step 8: Network Connection

DNS resolution does not load the website itself.

After receiving an IP address, the client must still establish the appropriate network and application connection.

For HTTPS, this can involve:

DNS
 ↓
IP Address
 ↓
Network Connection
 ↓
TLS
 ↓
HTTP
 ↓
Web Application

This is why a successful DNS lookup does not necessarily mean that the website itself is functioning correctly.

13. DNS Caching

Without caching, DNS would generate an enormous amount of repeated traffic.

Suppose a recursive resolver has already resolved:

example.com → 203.0.113.10

A later request may be answered from cache:

Client
   ↓
Recursive Resolver
   ↓
Cache HIT
   ↓
203.0.113.10

This can avoid repeating:

Root → TLD → Authoritative DNS

for every request.

DNS caching can occur at multiple layers, including:

• Applications
• Browsers
• Operating systems
• Local network devices
• Recursive resolvers

These different caches are one reason DNS troubleshooting can sometimes appear inconsistent.

Two users can request the same hostname and temporarily receive different results because they are using different caches or resolvers.

14. DNS TTL Explained

TTL means Time To Live.

A DNS record can contain a TTL value that influences how long the information may remain cached.

For example:

example.com. 3600 IN A 203.0.113.10

A TTL of:

3600

represents:

3600 seconds = 1 hour

A lower TTL can allow cached data to expire sooner, which may be useful before planned infrastructure changes.

However, lower TTLs can also increase query frequency.

A higher TTL can reduce repeated DNS lookups but may cause old information to remain cached longer after a change.

The trade-off can be represented as:

Lower TTL
   ↓
Faster cache turnover
   ↓
More DNS queries

versus:

Higher TTL
   ↓
Fewer repeated queries
   ↓
Longer-lived cached information

There is no universal TTL that is ideal for every record.

The correct value depends on operational requirements.

15. DNS Propagation Explained

The phrase DNS propagation is commonly used after changing a DNS record.

For example, an administrator changes:

Old:
example.com → 203.0.113.10

New:
example.com → 198.51.100.25

Some users may begin receiving the new address before others.

It is tempting to imagine that the new DNS record is slowly being copied around the world.

That is not a complete description.

What users often experience as “propagation” is heavily influenced by caching and TTL expiration.

For example:

10:00 — DNS changed

Resolver A → old answer still cached

Resolver B → old answer still cached

Resolver C → cache expired → new answer retrieved

Other factors can include:

• Local caches
• Recursive resolver caches
• Negative caching
• Delegation changes
• Nameserver changes
• Application behavior

Therefore, “DNS propagation” is better understood as a collection of caching and delegation effects rather than a single global synchronization process.

16. DNS Record Types Explained

DNS records are the individual data elements stored within DNS zones.

Understanding the major record types is essential for administering DNS.

A Record

An A record associates a hostname with an IPv4 address.

Example:

example.com. IN A 203.0.113.10

Conceptually:

example.com
     ↓
203.0.113.10

A records are commonly used by websites, APIs, application servers, and other IPv4-based services.

AAAA Record

An AAAA record associates a hostname with an IPv6 address.

Example:

example.com. IN AAAA 2001:db8::10

A hostname can have both an A and AAAA record:

example.com
├── A    → IPv4
└── AAAA → IPv6

The client and network environment determine how the available addresses are used.

CNAME Record

CNAME means Canonical Name.

A CNAME record creates an alias from one hostname to another hostname.

Example:

www.example.com. IN CNAME example.com.

Conceptually:

www.example.com
      ↓
example.com
      ↓
A / AAAA
      ↓
IP Address

A CNAME points to another DNS name, not directly to an IP address.

Traditional DNS rules also place restrictions on using CNAME data alongside other record types at the same owner name.

Some DNS providers implement proprietary features such as alias records or CNAME flattening to address use cases where a traditional CNAME is not suitable.

MX Record

MX means Mail Exchange.

MX records identify servers responsible for receiving email for a domain.

Example:

example.com. IN MX 10 mail.example.com.

The number is a preference value.

Generally, a lower value indicates higher priority.

For example:

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

If the preferred server is unavailable, another configured mail server may be attempted.

TXT Record

TXT records store text data.

They are widely used for:

• Domain verification
• SPF
• DKIM
• DMARC
• Service verification
• Security policies

Example:

example.com. IN TXT "verification-token"

TXT itself is generic; the meaning of the data depends on the application or protocol using it.

NS Record

NS means Name Server.

NS records identify authoritative nameservers associated with a DNS zone.

Example:

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

NS records are fundamental to DNS delegation.

SOA Record

SOA means Start of Authority.

The SOA record contains important administrative information about a DNS zone.

A simplified example is:

example.com. IN SOA ns1.example.net. admin.example.com. (
    2026100601
    3600
    600
    86400
    3600
)

The SOA includes information related to:

• Primary nameserver
• Responsible administrator
• Serial number
• Refresh timing
• Retry timing
• Expiration
• Negative caching behavior

The exact interpretation of these values is particularly important in authoritative DNS administration.

CAA Record

CAA means Certification Authority Authorization.

CAA records allow a domain owner to specify certificate authorities that are authorized to issue certificates for the domain.

Example:

example.com. IN CAA 0 issue "letsencrypt.org"

CAA is therefore related to certificate issuance policy rather than normal hostname resolution.

PTR Record and Reverse DNS

Forward DNS commonly performs:

Hostname
   ↓
IP Address

Reverse DNS performs:

IP Address
   ↓
Hostname

PTR records are used for reverse DNS.

IPv4 reverse DNS uses the:

in-addr.arpa

namespace.

Reverse DNS is particularly relevant to:

• Email infrastructure
• Logging
• Network administration
• Troubleshooting
• Some reputation systems

SRV Record

SRV records help clients locate specific network services.

An SRV record can contain information such as:

• Service
• Protocol
• Priority
• Weight
• Port
• Target

This allows applications to discover not just a host but also information about how to reach a particular service.

17. DNS Zones and Zone Files

A DNS zone is an administratively managed portion of the DNS namespace.

For example:

example.com

may be managed as one zone.

That zone might contain:

example.com       A       203.0.113.10
www.example.com   CNAME   example.com
mail.example.com  A       203.0.113.20
example.com       MX      10 mail.example.com

A zone does not necessarily contain every descendant name.

Responsibility for a subdomain can be delegated to another set of authoritative DNS servers, creating another zone.

What Does @ Mean in DNS?

Many DNS control panels and zone files use:

@

to represent the current zone apex.

If the zone is:

example.com

then:

@ IN A 203.0.113.10

represents:

example.com. IN A 203.0.113.10

A configuration such as:

@       A       203.0.113.10
www     CNAME   example.com.
blog    A       203.0.113.20

can therefore represent:

• example.com
• www.example.com
• blog.example.com

Example DNS Zone File

A simplified zone file might look like this:

$TTL 3600

@ IN SOA ns1.example.net. admin.example.com. (
    2026100601
    3600
    600
    86400
    3600
)

@ IN NS ns1.example.net.
@ IN NS ns2.example.net.

@ IN A 203.0.113.10

www IN CNAME example.com.

mail IN A 203.0.113.20

@ IN MX 10 mail.example.com.

@ IN TXT "example-verification"

This illustrates how multiple DNS record types can coexist within the same zone.

18. Does DNS Use UDP or TCP?

DNS is frequently described as a UDP protocol, but this is incomplete.

Traditional DNS commonly uses:

UDP port 53

and can also use:

TCP port 53

UDP is efficient for many ordinary DNS request-and-response operations.

TCP can be used when required, including circumstances involving response size, truncation, zone-transfer operations, and other protocol behavior.

Modern DNS also uses EDNS extensions that expand DNS capabilities, including support for larger UDP messages.

Therefore:

DNS does not always use UDP.

This distinction is important when designing firewall policies. Blocking required DNS transport can create failures that appear inconsistent. Our Firewalls Explained guide provides a broader explanation of how firewall rules interact with network protocols and services.

19. DNS over HTTPS — DoH

Traditional DNS queries between a client and resolver are not inherently encrypted.

DNS over HTTPS (DoH) transports DNS messages over HTTPS.

Conceptually:

Application
     ↓
Encrypted HTTPS
     ↓
DNS Resolver

DoH can protect DNS traffic from some forms of observation and modification between the client and resolver.

However, encrypted DNS should not be confused with complete anonymity.

The DNS resolver still needs to process the requested DNS information, and other network metadata can remain observable elsewhere in the communication path.

20. DNS over TLS — DoT

DNS over TLS (DoT) provides encrypted DNS transport using TLS.

A commonly assigned port is:

TCP 853

Conceptually:

Client
   ↓
TLS
   ↓
DNS Resolver

DoH and DoT both provide encrypted DNS transport, but their deployment and traffic characteristics differ.

It is also important to distinguish encrypted DNS transport from DNSSEC.

DoH/DoT → confidentiality of transport

DNSSEC → authentication and integrity of DNS data

They address different security problems.

21. DNSSEC Explained

Traditional DNS was not originally designed to cryptographically authenticate ordinary DNS responses.

An attacker who successfully interferes with resolution may attempt to redirect a user:

User
 ↓
example.com
 ↓
False DNS Answer
 ↓
Malicious Destination

DNSSEC, or Domain Name System Security Extensions, adds cryptographic mechanisms that allow DNS data to be signed and validated.

IANA maintains information about the DNS root trust infrastructure and DNSSEC.

Important DNSSEC Records

DNSSEC introduces records including:

• DNSKEY
• DS
• RRSIG
• NSEC
• NSEC3

A simplified chain of trust can look like:

Root
 ↓
TLD
 ↓
DS
 ↓
Domain DNSKEY
 ↓
RRSIG
 ↓
Signed DNS Data

A validating resolver can verify signatures and determine whether signed DNS data can be authenticated through the chain of trust.

DNSKEY

DNSKEY records publish public keys used in DNSSEC.

RRSIG

RRSIG records contain digital signatures for DNS record sets.

DS

A DS record in the parent zone helps connect the parent to the child’s DNSSEC key material.

For a domain under .com, the conceptual relationship is:

.com
 ↓
DS for example.com
 ↓
example.com DNSKEY
 ↓
Signed records

NSEC and NSEC3

DNSSEC must also provide authenticated denial of existence.

NSEC and NSEC3 are mechanisms associated with proving that requested DNS data does not exist.

What DNSSEC Protects

DNSSEC helps provide:

• DNS data authenticity
• DNS data integrity
• Protection against certain forged DNS responses

What DNSSEC Does Not Provide

DNSSEC does not automatically provide:

• DNS transport encryption
• User anonymity
• HTTPS encryption
• Protection from every DNS attack
• General application security

The technologies should not be confused:

DNSSEC
→ Authenticity and integrity

DoH / DoT
→ Encrypted DNS transport

HTTPS
→ Encrypted application communication

Testing DNSSEC with dig

Request DNSSEC information:

dig example.com +dnssec

Inspect DNSKEY:

dig DNSKEY example.com

Inspect DS:

dig DS example.com

When using a validating recursive resolver, the ad flag may indicate that the resolver authenticated the answer.

DNSSEC failures should be investigated across the complete chain of trust rather than by looking at only one record.

22. DNS and Email Security

DNS plays an essential role in email delivery and authentication.

Important DNS-related email mechanisms include:

• MX
• SPF
• DKIM
• DMARC
• PTR

Conceptually:

MX
↓
Where should mail be delivered?

SPF
↓
Which systems are authorized to send?

DKIM
↓
Is the message cryptographically signed?

DMARC
↓
What authentication policy should receivers apply?

PTR
↓
What reverse identity is associated with the sending IP?

This means a website can function correctly while email fails completely.

When troubleshooting mail delivery, DNS investigation may include:

dig example.com MX

dig example.com TXT

and, when appropriate:

dig selector._domainkey.example.com TXT

The DKIM selector depends on the mail system.

Reverse DNS may also need to be checked for mail-server IP addresses.

DNS configuration is only one part of email delivery, however. SMTP configuration, server reputation, authentication, firewall rules, and provider policies can also affect mail.

23. Split-Horizon DNS

Some organizations intentionally return different DNS answers depending on where the query originates.

For example:

Internal user:
app.example.com → 10.10.10.50

Internet user:
app.example.com → 203.0.113.50

This architecture is commonly known as:

• Split DNS
• Split-horizon DNS
• Split-view DNS

It can be useful in:

• Enterprise networks
• VPN environments
• Internal applications
• Private cloud environments
• Hybrid networks

However, it also creates an important troubleshooting consideration.

Two users can receive different answers for the same hostname and both answers can be correct for their respective environments.

24. Anycast DNS

Large DNS providers often need to serve queries from users around the world with high availability and low latency.

One technology commonly used for this purpose is Anycast.

With Anycast, the same service address can be announced from multiple network locations.

Conceptually:

             DNS Service IP
                   │
        ┌──────────┼──────────┐
        ↓          ↓          ↓
      Europe      USA        Asia
        │          │          │
       DNS        DNS        DNS

Internet routing can direct users toward an appropriate instance.

Potential benefits include:

• Lower latency
• Geographic distribution
• Resilience
• Increased capacity
• Improved resistance to certain large-scale failures or attacks

Anycast is particularly valuable for globally distributed DNS infrastructure.

25. DNS Load Balancing

DNS can also participate in traffic distribution.

Suppose:

www.example.com

has multiple addresses:

203.0.113.10
203.0.113.11
203.0.113.12

DNS responses can help distribute clients across multiple destinations.

More advanced DNS services may support strategies such as:

• Weighted responses
• Geographic routing
• Latency-based routing
• Health-aware responses
• Failover

However, DNS load distribution is not equivalent to every type of application or network load balancer.

DNS behavior is influenced by:

• Resolver caching
• TTL
• Client behavior
• DNS provider implementation

DNS should therefore be considered one layer of the wider traffic-management architecture.

26. DNS Security Risks

Because DNS is foundational infrastructure, attackers frequently target or abuse it.

DNS Cache Poisoning

DNS cache poisoning attempts to place incorrect DNS information into a resolver’s cache.

If successful, clients can be directed toward an unintended destination.

DNS Spoofing

DNS spoofing broadly refers to presenting forged or manipulated DNS information to a victim.

DNS Amplification

DNS infrastructure can be abused in reflection and amplification attacks when systems are exposed or configured in ways that allow attackers to exploit them.

DNS Tunneling

DNS queries and responses can potentially be abused as a communication channel for unauthorized data transfer or command-and-control traffic.

DNS Hijacking

An attacker who gains control over DNS configuration may alter:

• A/AAAA records
• Nameservers
• Delegation
• MX records
• Other DNS settings

The result can be redirection of websites, interception attempts, or disruption of services.

Dangling DNS Records

A particularly important cloud-era risk occurs when a DNS record continues pointing to an external resource that has been deleted or released.

For example:

old.example.com
     ↓
External Cloud Service
     ↓
Resource Deleted

If another party can claim the abandoned external resource, the DNS record may contribute to a subdomain takeover risk.

DNS security should therefore be integrated into the broader controls discussed in Network Security Basics.

Security teams may also correlate suspicious DNS behavior with other events in centralized monitoring platforms. Our SIEM Explained guide covers how security information can be collected and correlated across infrastructure.

27. A Systematic DNS Troubleshooting Method

One of the biggest mistakes in troubleshooting is assuming that every hostname-related problem is automatically a DNS problem.

A better workflow is:

Does the hostname resolve?
        ↓
Does it resolve correctly?
        ↓
Is the destination reachable?
        ↓
Is the service port reachable?
        ↓
Does TLS work?
        ↓
Does the application work?

This separates DNS from:

• Routing failures
• Firewall failures
• TCP problems
• TLS problems
• HTTP errors
• Server failures
• Application failures
• CDN problems

For Linux environments, the Linux Network Tools Guide provides additional commands for diagnosing connectivity beyond DNS.

28. DNS Troubleshooting on Windows

Using nslookup

Basic query:

nslookup example.com

Query a specific resolver:

nslookup example.com 1.1.1.1

Query MX records:

nslookup -type=MX example.com

Query nameservers:

nslookup -type=NS example.com

Using PowerShell Resolve-DnsName

PowerShell provides a more structured DNS tool:

Resolve-DnsName example.com

Query IPv4:

Resolve-DnsName example.com -Type A

Query IPv6:

Resolve-DnsName example.com -Type AAAA

Query MX:

Resolve-DnsName example.com -Type MX

Query NS:

Resolve-DnsName example.com -Type NS

Query TXT:

Resolve-DnsName example.com -Type TXT

Inspecting the Windows DNS Cache

Display cached DNS information:

ipconfig /displaydns

Flush the local Windows DNS cache:

ipconfig /flushdns

An important distinction is:

Local Cache
≠
Recursive Resolver Cache
≠
Authoritative DNS

Flushing the Windows DNS cache does not clear cached information held by an ISP or public recursive resolver.

29. DNS Troubleshooting on Linux

One of the most useful DNS tools on Linux is dig.

Basic Query

dig example.com

Short Output

dig example.com +short

Query a Specific Resolver

dig @1.1.1.1 example.com

Query an A Record

dig example.com A

Query an AAAA Record

dig example.com AAAA

Query MX

dig example.com MX

Query NS

dig example.com NS

Query TXT

dig example.com TXT

Query SOA

dig example.com SOA

Trace DNS Delegation

One of the most useful diagnostic commands is:

dig +trace example.com

This exposes the delegation path more directly:

Root
 ↓
TLD
 ↓
Authoritative DNS
 ↓
Answer

It is especially useful when investigating:

• Delegation problems
• Nameserver migrations
• Incorrect authoritative configuration
• Some DNSSEC problems
• Differences between recursive and authoritative answers

resolvectl

On Linux systems using systemd-resolved, inspect resolver configuration with:

resolvectl status

Query a domain:

resolvectl query example.com

Where supported, flush the local resolver cache with:

resolvectl flush-caches

Not every Linux system uses systemd-resolved, so identify the resolver architecture before assuming these commands apply.

30. Common DNS Troubleshooting Scenarios

Domain Does Not Resolve

Start with:

dig example.com

Then compare another resolver:

dig @1.1.1.1 example.com

and, if useful:

dig @8.8.8.8 example.com

If resolution still fails, inspect:

dig NS example.com

and:

dig +trace example.com

The goal is to identify where the chain breaks:

Delegation
 ↓
Authoritative DNS
 ↓
Zone
 ↓
Requested Record

DNS Returns the Wrong IP Address

Suppose you expect:

203.0.113.10

but receive:

198.51.100.20

Possible causes include:

• Cached data
• Multiple A records
• Split DNS
• Different authoritative servers
• CDN/proxy architecture
• Incorrect DNS configuration
• An incomplete migration

Compare multiple resolvers and then query the authoritative infrastructure directly.

Do not immediately change DNS records until you know which layer is returning the unexpected answer.

Website Works for Some Users but Not Others

Possible causes include:

• Different recursive resolvers
• Cached records
• Inconsistent authoritative servers
• Delegation errors
• DNSSEC validation problems
• Split-horizon DNS
• Network problems unrelated to DNS

Compare actual DNS responses from affected and unaffected environments.

Email Is Not Arriving

Start with:

dig example.com MX

Then inspect the address of the mail server:

dig mail.example.com A

and, where relevant:

dig mail.example.com AAAA

Inspect TXT records:

dig example.com TXT

Email troubleshooting may also require checking DKIM, DMARC, PTR, SMTP availability, and provider configuration.

DNSSEC Failure

DNSSEC misconfiguration can create a particularly confusing failure pattern.

For example:

Non-validating resolver → works
Validating resolver → fails

Inspect:

dig example.com +dnssec

dig DS example.com

dig DNSKEY example.com

Then evaluate the trust relationship:

Parent
 ↓
DS
 ↓
Child DNSKEY
 ↓
RRSIG
 ↓
Signed data

DNSSEC records should not be changed randomly because incorrect parent-child trust information can make a signed domain unreachable through validating resolvers.

31. DNS vs DHCP

DNS and DHCP are often found together in network configurations, but they solve different problems.

DNS primarily provides naming information.

DHCP dynamically provides network configuration to clients.

A DHCP server may provide a client with:

• IP address
• Subnet mask or prefix information
• Default gateway
• DNS resolver addresses
• Other configuration options

This creates a common relationship:

Client
 ↓
DHCP
 ↓
Receives DNS Server Address
 ↓
Uses DNS Resolver
 ↓
Resolves Hostnames

Our complete DHCP Explained guide covers DHCP operation and its relationship with client network configuration in more detail.

32. DNS vs HTTP

DNS and HTTP solve completely different problems.

Suppose a user visits:

https://example.com

DNS helps answer:

Where should example.com resolve?

HTTP helps the application exchange web requests and responses.

The sequence can look like:

DNS
 ↓
IP Address
 ↓
Network Connection
 ↓
TLS
 ↓
HTTP
 ↓
Web Application

Therefore:

DNS working does not prove the website is working.

For example:

DNS → Success
TCP → Failure

This points away from DNS and toward network connectivity, firewall policy, routing, or server availability.

Similarly:

DNS → Success
TCP → Success
TLS → Failure

suggests investigating TLS or certificate configuration.

Layered troubleshooting is much more effective than assuming every inaccessible domain has a DNS problem.

33. DNS and HTTPS

DNS resolution normally occurs before an HTTPS connection can be established using a hostname.

A simplified process is:

1. Resolve the hostname.
2. Obtain a destination address.
3. Establish network transport.
4. Perform the TLS handshake.
5. Send the HTTP request.
6. Receive the HTTP response.

Conceptually:

Domain
 ↓
DNS
 ↓
IP Address
 ↓
TCP / Transport
 ↓
TLS
 ↓
HTTPS
 ↓
Application

This separation is particularly useful when troubleshooting.

If DNS returns the expected address but HTTPS fails, changing DNS may not solve the actual problem.

34. DNS in Production Infrastructure

Production DNS should be designed as infrastructure rather than treated as an afterthought.

A typical public domain might include:

example.com
│
├── @
│   └── Main website
│
├── www
│   └── Website alias or endpoint
│
├── api
│   └── Application API
│
├── mail
│   └── Mail infrastructure
│
└── TXT / CAA
    └── Verification and security policies

The actual design depends on:

• Hosting platform
• Cloud architecture
• CDN
• Mail provider
• Application design
• Security requirements
• Availability requirements

For a wider view of the systems surrounding DNS, Servers and Infrastructure Explained covers the role of servers, storage, virtualization, availability, and supporting infrastructure.

In cloud environments, DNS may interact with virtual networks, cloud load balancers, private DNS zones, public DNS zones, and hybrid connectivity. These concepts are explored further in Cloud Networking Explained.

35. DNS Best Practices

Use Reliable Authoritative DNS Infrastructure

If authoritative DNS is unavailable for an extended period, users may eventually be unable to resolve services even when those services themselves remain healthy.

Use Redundancy

Avoid architectures where one avoidable infrastructure failure can remove all authoritative DNS availability.

Protect DNS and Registrar Accounts

Use:

• Strong unique passwords
• Multi-factor authentication
• Appropriate registrar security controls
• Account alerts
• Restricted administrative access

Compromise of a DNS or registrar account can affect multiple services simultaneously.

Keep DNS Records Organized

Document important records and remove obsolete entries.

Large unmanaged zones make troubleshooting and security review more difficult.

Audit Old Subdomains

Look for records that point to services that are no longer controlled.

This is especially important for:

• Cloud platforms
• SaaS services
• Old hosting providers
• Deprecated applications

Choose TTL Values Deliberately

Use TTL values appropriate to the stability and operational requirements of each record.

Do not use extremely low TTL values everywhere simply because they appear more flexible.

Reduce TTL Before Planned Migrations When Appropriate

If an address change is planned, administrators may choose to reduce TTL sufficiently in advance so older cached responses expire sooner around the migration.

After the environment stabilizes, the TTL can be reviewed again.

Monitor DNS Changes

Critical DNS should be monitored for unexpected changes involving:

• A
• AAAA
• MX
• NS
• CAA
• DNSSEC
• Important TXT records

Use DNSSEC Where Appropriate

DNSSEC can strengthen DNS authenticity, but operational procedures must ensure that DS and DNSKEY changes remain synchronized.

Maintain Email DNS Correctly

Review:

• MX
• SPF
• DKIM
• DMARC
• PTR

when the domain is used for email.

Keep DNS Documentation

For important infrastructure, record:

• Why the record exists
• Which service owns it
• Who manages the service
• Whether the record is public or private
• Dependencies
• Migration requirements

Good documentation reduces the chance that an apparently unused record is deleted while still supporting a production service.

36. DNS Performance

DNS is often only the first stage of application access, but slow DNS resolution can still affect perceived application performance.

Important factors include:

• Recursive resolver performance
• Authoritative DNS latency
• Geographic distribution
• Anycast
• DNS caching
• TTL strategy
• CNAME chains
• Resolver location
• Authoritative availability

Avoid Excessive CNAME Chains

Consider:

www.example.com
 ↓
app.example.net
 ↓
service.example.org
 ↓
final.example.net

Each dependency can add complexity and potentially additional lookup work.

This does not mean CNAME records are inherently bad. They are extremely useful. The goal is to avoid unnecessary chains.

DNS Performance Is Not Website Performance

A fast DNS response does not guarantee a fast website.

Total user experience can depend on:

DNS
+
Network Latency
+
TCP / QUIC
+
TLS
+
Server Processing
+
Application
+
Content Delivery

DNS should therefore be measured as one component of end-to-end performance.

37. DNS Monitoring

DNS monitoring should answer more than:

“Does the domain resolve?”

A stronger monitoring strategy can examine:

• Does the record exist?
• Does it return the expected value?
• Are authoritative servers reachable?
• Are authoritative servers consistent?
• Is DNSSEC valid?
• Has delegation changed?
• Has the response time changed significantly?
• Have critical MX or NS records changed unexpectedly?

For security-sensitive environments, DNS logs can also contribute to detection and investigation.

Unusual DNS behavior can sometimes reveal:

• Malware activity
• Command-and-control traffic
• DNS tunneling
• Misconfigured systems
• Unexpected external dependencies

Centralized analysis can be particularly useful here, which is one reason DNS telemetry may become part of a broader SIEM monitoring strategy.

38. Practical DNS Investigation Workflow

Suppose a user reports:

app.example.com is not working.

Do not immediately edit the DNS zone.

Start systematically.

Step 1: Check Resolution

dig app.example.com

Ask:

• Did it resolve?
• What record type was returned?
• Is the address expected?

Step 2: Compare Resolvers

dig @1.1.1.1 app.example.com

dig @8.8.8.8 app.example.com

If different resolvers return different information, caching or authoritative inconsistency may be involved.

Step 3: Check Delegation

dig +trace app.example.com

Inspect the path from root to authoritative infrastructure.

Step 4: Identify Authoritative Servers

dig NS example.com

Then query an authoritative server directly when appropriate.

This helps distinguish:

Authoritative answer

from:

Cached recursive answer

Step 5: Check TTL

Determine whether older information may legitimately remain cached.

Step 6: Check Network Connectivity

If DNS is correct, continue beyond DNS.

Test the destination network and service.

For Linux environments, tools such as ping, traceroute, ip, ss, curl, and other utilities discussed in the Linux Network Tools Guide can help identify whether the failure occurs after resolution.

Step 7: Check Firewall Policy

If the destination is correct but the service is unreachable, investigate relevant firewall rules and network security controls.

See Firewalls Explained for the networking principles behind these controls.

Step 8: Check TLS and Application Behavior

For HTTPS applications, test the actual HTTPS service.

DNS can be completely healthy while the application itself is failing.

39. Common DNS Mistakes

Assuming Every Website Failure Is DNS

If the hostname resolves correctly, investigate the next network and application layers.

Changing Several DNS Records at Once

This makes it difficult to identify which change solved or created the problem.

Make controlled changes and document them.

Forgetting About TTL

Cached records can continue to affect clients after the authoritative zone has been updated.

Flushing Only the Local Cache

A local cache flush does not clear caches on recursive DNS resolvers elsewhere.

Confusing CNAME with Redirects

A CNAME is a DNS alias.

It is not an HTTP redirect.

DNS operates before HTTP.

Pointing MX Directly at an IP Address

MX records identify mail exchanger hostnames rather than simply acting as arbitrary IP fields. Ensure the mail target has appropriate address records.

Ignoring Reverse DNS

Reverse DNS can matter in operational environments, particularly for email and infrastructure administration.

Assuming DNSSEC Encrypts DNS

DNSSEC authenticates DNS data.

It does not provide the same function as DoH or DoT.

Forgetting Old Cloud DNS Records

Dangling DNS references to decommissioned third-party services can create security risk.

40. A Mental Model for DNS

A useful way to remember DNS is to divide it into four conceptual layers.

Layer 1: Namespace

.
└── com
    └── example.com
        └── www

This describes the hierarchical naming structure.

Layer 2: Delegation

Root
 ↓
TLD
 ↓
Authoritative DNS

This describes who is responsible for which part of the namespace.

Layer 3: Resolution

Client
 ↓
Recursive Resolver
 ↓
DNS Hierarchy
 ↓
Answer

This describes how a client obtains DNS information.

Layer 4: Records

A
AAAA
CNAME
MX
TXT
NS
SOA
CAA
PTR
SRV

This describes the information published through DNS.

Add two cross-cutting concepts:

Caching
+
Security

and you have a practical mental model for understanding most DNS architectures.

41. DNS Security Checklist

For an important production domain, review the following:

• Are authoritative nameservers correct?
• Is unnecessary DNS data removed?
• Are registrar credentials protected?
• Is multi-factor authentication enabled where available?
• Are important DNS changes monitored?
• Are obsolete subdomains audited?
• Are old third-party service references removed?
• Is DNSSEC appropriate for the environment?
• If DNSSEC is enabled, is the chain of trust valid?
• Are CAA records appropriate?
• Are MX records correct?
• Are SPF, DKIM, and DMARC configured where needed?
• Is reverse DNS correct for relevant infrastructure?
• Are public recursive DNS services intentionally configured?
• Are DNS logs available where operationally appropriate?

DNS should be considered part of the organization’s security boundary because control over DNS can influence many other services.

42. DNS Troubleshooting Checklist

When troubleshooting a DNS-related incident, use a repeatable sequence.

Resolution

dig example.com

or:

Resolve-DnsName example.com

Resolver Comparison

dig @1.1.1.1 example.com

Delegation

dig +trace example.com

Nameservers

dig example.com NS

Authority

Query the authoritative DNS server directly where appropriate.

Record Types

Inspect the relevant record:

A
AAAA
CNAME
MX
TXT
NS
SOA
CAA

DNSSEC

dig example.com +dnssec
dig DS example.com
dig DNSKEY example.com

Network

If DNS is correct, continue troubleshooting:

• Routing
• Connectivity
• Firewall
• Transport
• TLS
• HTTP
• Application

This workflow prevents hours of unnecessary DNS changes when the actual failure exists elsewhere.

43. Frequently Asked Questions

What is DNS?

DNS stands for Domain Name System. It is a distributed hierarchical naming system used to associate domain names and hostnames with information such as IP addresses, mail servers, nameservers, service information, and security-related records.

How does DNS work?

A client normally sends a DNS query to a recursive resolver. If the answer is not already cached, the resolver can navigate the DNS hierarchy through root, TLD, and authoritative DNS infrastructure until it obtains the required information.

What is a DNS server?

“DNS server” is a broad term. A server may operate as a recursive resolver, authoritative nameserver, root server, TLD server, or another DNS role.

What is a DNS resolver?

A recursive DNS resolver accepts queries from clients and performs or coordinates the work needed to obtain DNS answers.

What is an authoritative DNS server?

An authoritative DNS server provides authoritative DNS data for the zones it serves.

What is the difference between recursive and authoritative DNS?

A recursive resolver searches for answers on behalf of clients. An authoritative DNS server publishes authoritative information for its zones.

What is a DNS record?

A DNS record is an individual data element in DNS. Examples include A, AAAA, CNAME, MX, TXT, NS, SOA, CAA, PTR, and SRV.

What is an A record?

An A record maps a hostname to an IPv4 address.

What is an AAAA record?

An AAAA record maps a hostname to an IPv6 address.

What is a CNAME record?

A CNAME record creates an alias from one DNS hostname to another hostname.

What is a DNS MX record?

An MX record identifies the mail servers responsible for receiving email for a domain.

What is DNS TTL?

TTL means Time To Live. It influences how long DNS information may remain cached before it needs to be refreshed.

Why do DNS changes take time?

DNS changes may appear at different times because cached responses can remain valid until their applicable TTLs expire. Delegation and local caching behavior can also contribute.

Does DNS use UDP or TCP?

Traditional DNS can use both UDP and TCP on port 53. Which transport is used depends on the DNS operation and circumstances.

What is DNSSEC?

DNSSEC is a set of security extensions that provides cryptographic authentication and integrity mechanisms for DNS data.

Does DNSSEC encrypt DNS queries?

No. DNSSEC is designed primarily to authenticate DNS data. Technologies such as DoH and DoT provide encrypted transport between clients and DNS resolvers.

What is DNS over HTTPS?

DNS over HTTPS, or DoH, carries DNS messages over HTTPS to provide encrypted transport between a client and resolver.

What is DNS over TLS?

DNS over TLS, or DoT, encrypts DNS communication using TLS and commonly uses TCP port 853.

What is reverse DNS?

Reverse DNS maps an IP address back toward a hostname using PTR records and the reverse-DNS namespace.

What is split DNS?

Split DNS returns different DNS information depending on the querying environment, such as internal users receiving private addresses while Internet users receive public addresses.

How do I troubleshoot DNS?

Start by checking whether the hostname resolves and whether the returned information is correct. Compare multiple resolvers, inspect delegation and authoritative DNS, review TTL and DNSSEC where relevant, and then continue troubleshooting the network and application layers if DNS is working.

44. Key Takeaways

DNS is not simply a system that converts website names into IP addresses.

It is a distributed, hierarchical infrastructure that enables modern Internet naming and service discovery.

The most important concepts to remember are:

• DNS uses a hierarchical namespace.
• Responsibility is distributed through delegation.
• Clients commonly query recursive resolvers.
• Root and TLD infrastructure help resolvers find authoritative DNS.
• Authoritative servers publish DNS zone information.
• DNS caching improves performance and scalability.
• TTL influences how long DNS information can remain cached.
• A and AAAA records identify IPv4 and IPv6 addresses.
• CNAME records create aliases.
• MX records identify mail servers.
• NS records identify authoritative nameservers.
• SOA records contain zone administration information.
• CAA records contribute to certificate-authority policy.
• PTR records support reverse DNS.
• DNS can use both UDP and TCP.
• DoH and DoT encrypt DNS transport.
• DNSSEC provides authentication and integrity for signed DNS data.
• DNS problems should be separated from routing, firewall, TLS, HTTP, and application problems.

Conclusion

The Domain Name System is one of the fundamental building blocks of the Internet.

When a user enters a domain name, a sophisticated distributed system can determine which infrastructure is responsible for that name, retrieve the required DNS information, cache it efficiently, and return an answer that allows the application to continue communicating.

A simplified resolution path looks like:

User
 ↓
Application
 ↓
Stub Resolver
 ↓
Recursive Resolver
 ↓
Root
 ↓
TLD
 ↓
Authoritative DNS
 ↓
DNS Record
 ↓
IP Address
 ↓
Network Connection
 ↓
Application Service

But mastering DNS requires understanding more than this basic sequence.

Network administrators need to understand caching and TTL. Infrastructure engineers need to understand zones, delegation, authoritative DNS, Anycast, and redundancy. Security professionals need to understand DNSSEC, DNS hijacking, tunneling, dangling records, and DNS monitoring. System administrators need to know how to use tools such as dig, nslookup, Resolve-DnsName, and resolvectl to determine exactly where a resolution problem occurs.

DNS also does not operate in isolation. It works alongside the networking concepts covered in Computer Networking Explained, TCP/IP Explained, DHCP Explained, Firewalls Explained, and the Linux Network Tools Guide.

Once you understand the hierarchy, delegation model, recursive resolution process, DNS records, caching behavior, security mechanisms, and troubleshooting workflow, DNS becomes much easier to diagnose and design correctly.