Table of Contents

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

Introduction: What Is DNS?

Every time you type a website address such as:

https://corginetwork.com/

your computer has to determine where that domain should connect.

Networks do not fundamentally communicate using human-friendly names. They communicate using IP addresses.

For example:

corginetwork.com/
        ↓
DNS resolution
        ↓
IP address
        ↓
Server connection
        ↓
Website

The system responsible for translating human-readable domain names into network information is the Domain Name System, commonly called DNS.

DNS is much more than a simple “domain-to-IP converter.” It is a distributed database and delegation system that helps the Internet locate web servers, mail servers, services, applications, and other network resources.

A DNS lookup can involve:

Your browser
The operating system
A local DNS cache
A recursive resolver
Root DNS servers
TLD DNS servers
Authoritative nameservers
DNS records
DNS caching
DNSSEC validation
Network transport protocols

Understanding DNS is therefore essential for anyone working with:

Networking
Linux
Windows Server
Cloud infrastructure
Web hosting
WordPress
Cybersecurity
DevOps
Email systems
CDN infrastructure
Domain management

Modern DNS also includes technologies such as DNSSEC, DNS over HTTPS (DoH) and DNS over TLS (DoT), which address different security and privacy requirements.

1. Why Does DNS Exist?

Imagine if websites did not have domain names.

Instead of visiting:

https://corginetwork.com/

you might have to remember:

203.0.113.10

This would be inconvenient for humans.

But IP addresses are useful for computers and routers.

DNS creates a layer between the human-readable name and the network address.

Human
  │
  │ corginetwork.com/
  ▼
DNS
  │
  │ 203.0.113.10
  ▼
Network
  │
  ▼
Web Server

This separation is extremely important.

A website can change its underlying infrastructure while keeping the same domain name.

For example:

corginetwork.com/
       │
       ├── Old server
       │   203.0.113.10
       │
       └── New server
           198.51.100.25

The DNS record can be updated while users continue accessing the same domain.

2. DNS Is a Distributed Database

One of the most important concepts to understand is that DNS is distributed.

There is not one central DNS database containing every domain on the Internet.

Instead, responsibility is divided across a hierarchy.

A simplified structure looks like this:

.
└── com
    └── corginetwork.com/
        ├── www
        ├── mail
        ├── api
        └── blog

The dot at the top represents the DNS root.

Below the root are Top-Level Domains (TLDs) such as:

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

Below the TLD is the domain:

corginetwork.com/

And below the domain can be subdomains:

www.corginetwork.com
blog.corginetwork.com
api.corginetwork.com
mail.corginetwork.com

This hierarchy allows DNS responsibility to be delegated.

3. The DNS Hierarchy

DNS resolution follows a hierarchical structure.

At the top:

Root
  ↓
TLD
  ↓
Authoritative DNS
  ↓
DNS Record

For example, resolving:

www.example.com

may conceptually involve:

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

The root servers do not normally contain the final IP address for every website.

Instead, they help direct resolvers toward the appropriate TLD nameservers.

The TLD nameservers then provide delegation information for the domain’s authoritative nameservers.

The authoritative DNS servers contain the actual DNS data for the domain.

This delegation model is one of the foundations of the Internet’s scalability.

4. The Main Types of DNS Servers

A typical DNS resolution process can involve four important server roles.

4.1 Stub Resolver

The stub resolver is usually part of the operating system or local networking stack.

It receives requests such as:

What is the IP address of corginetwork.com/?

The stub resolver normally forwards the query to a configured recursive resolver.

For example:

Computer
   ↓
DNS Resolver

The computer does not normally communicate directly with the root DNS infrastructure.

5. Recursive DNS Resolver

A recursive resolver performs the work of finding the answer on behalf of the client.

For example:

Client:
What is the IP of example.com?

Recursive Resolver:
I'll find out.

The resolver may contact:

Root server
      ↓
TLD server
      ↓
Authoritative server
      ↓
Answer

The resolver then returns the result to the client.

Recursive resolvers also cache DNS responses, allowing future requests to be answered without repeating the entire lookup process.

6. Root DNS Servers

The DNS root is represented by:

Root DNS infrastructure helps resolvers locate the nameservers responsible for TLDs.

For example:

example.com
      ↓
Root
      ↓
.com nameservers

A common misconception is that there are only 13 physical DNS root servers.

The important distinction is that there are 13 named root-server identities, but the actual root-server infrastructure is distributed globally using many instances and routing techniques.

Therefore, the root DNS system is much more geographically distributed than the phrase “13 servers” suggests.

7. TLD DNS Servers

TLD means:

Top-Level Domain

Examples include:

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

Suppose a resolver wants to find:

corginetwork.com/

The root system can direct it toward the nameservers responsible for:

.com

The .com TLD infrastructure can then provide delegation information for:

corginetwork.com/

This may include the authoritative nameservers for the domain.

8. Authoritative DNS Servers

An authoritative DNS server contains the authoritative DNS information for a zone.

For example:

corginetwork.com/

could have authoritative nameservers such as:

ns1.example-dns-provider.com
ns2.example-dns-provider.com

Those servers contain records such as:

A
AAAA
CNAME
MX
TXT
NS
SOA
CAA

The authoritative server is therefore the source of truth for the DNS data it serves.

9. Recursive vs Authoritative DNS

This distinction is extremely important.

Feature	Recursive Resolver	Authoritative DNS
Main purpose	Finds answers	Stores authoritative answers
Queries other DNS servers	Yes	Usually not for normal resolution
Caches results	Yes	Not in the same recursive sense
Final source of zone data	No	Yes
Used by clients	Directly/indirectly	Usually indirectly
Example role	ISP/public resolver	Domain DNS provider

Think about it this way:

Client
  │
  ▼
Recursive Resolver
  │
  ├── Root
  ├── TLD
  └── Authoritative DNS
          │
          ▼
       DNS Record

10. Recursive and Iterative Queries

DNS terminology can become confusing because there are different query behaviors.

Recursive Query

The client asks:

“Give me the answer.”

The recursive resolver is expected to continue the lookup process.

Client
   │
   │ Recursive query
   ▼
Resolver
   │
   ├── Root
   ├── TLD
   └── Authoritative

The resolver returns the final answer or an error.

Iterative Query

With an iterative process, a DNS server can respond with the best information it currently has, such as a referral to another nameserver.

Conceptually:

Resolver → Root
Root → Ask .com

Resolver → .com
.com → Ask authoritative server

Resolver → Authoritative
Authoritative → Answer

This distinction is fundamental when learning how DNS resolution actually works.

11. Complete DNS Lookup Example

Suppose you enter:

https://www.example.com

The browser needs the IP address for:

www.example.com

A simplified process is:

1. Browser checks local information
              ↓
2. Operating system checks DNS cache
              ↓
3. Stub resolver sends query
              ↓
4. Recursive resolver checks its cache
              ↓
5. Resolver queries DNS hierarchy if necessary
              ↓
6. Root provides TLD delegation
              ↓
7. TLD provides domain delegation
              ↓
8. Authoritative DNS provides record
              ↓
9. Recursive resolver caches response
              ↓
10. Client receives IP address
              ↓
11. Browser connects to server

This is why DNS is so important.

DNS happens before the browser can normally establish the application connection to the destination hostname.

12. DNS Caching

DNS would be significantly slower if every request required a complete trip through the DNS hierarchy.

Caching solves this.

Suppose thousands of users request:

example.com

A recursive resolver may already have:

example.com → 203.0.113.10

in its cache.

Instead of asking authoritative DNS again, it can return the cached result.

Client
   ↓
Recursive Resolver
   ↓
Cache HIT
   ↓
IP address

This reduces:

DNS latency
Network traffic
Authoritative server load
Repeated queries

13. What Is TTL?

TTL means:

Time To Live

A DNS record can specify how long recursive resolvers may cache the record.

Example:

example.com. 3600 IN A 203.0.113.10

Here:

3600 seconds = 1 hour

The TTL influences how long cached information remains usable.

A shorter TTL can make changes visible sooner after cache expiration.

A longer TTL can reduce repeated DNS queries.

Therefore:

Low TTL
→ faster changes
→ potentially more DNS queries

High TTL
→ fewer queries
→ potentially slower changes

14. DNS Propagation: What Actually Happens?

People often say:

“DNS propagation takes 24–48 hours.”

This description is too simplistic.

There is no single global DNS switch that slowly propagates from one server to another.

What users experience as “DNS propagation” is usually a combination of:

Cached DNS responses
TTL expiration
Recursive resolver behavior
Client-side caching
Authoritative nameserver changes
Nameserver delegation changes
Negative caching

For example:

10:00
DNS record changed

Resolver A
→ old record cached

Resolver B
→ old record cached

Resolver C
→ queries authoritative DNS
→ new record

Therefore, two users can temporarily receive different DNS answers.

15. DNS Records Explained

DNS records are the individual pieces of information stored in a DNS zone.

Some of the most important records are:

A
AAAA
CNAME
MX
NS
SOA
TXT
SRV
CAA
PTR

Let’s examine them.

16. A Record

An A record maps a hostname to an IPv4 address.

Example:

example.com.    IN    A    203.0.113.10

Meaning:

example.com
      ↓
203.0.113.10

This is one of the most common DNS records for websites.

17. AAAA Record

An AAAA record maps a hostname to an IPv6 address.

Example:

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

IPv6 support is increasingly important as networks adopt IPv6.

A website can have both:

A
↓
IPv4

AAAA
↓
IPv6

Clients capable of IPv6 can potentially use the IPv6 address.

18. CNAME Record

CNAME means:

Canonical Name

It 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 a hostname, not directly to an IP address.

A standard CNAME also cannot normally coexist with other DNS data at the same owner name.

Modern DNS providers may offer features such as CNAME flattening or provider-specific alias records to solve some apex-domain use cases.

19. MX Record

MX means:

Mail Exchange

It identifies mail servers responsible for receiving email for a domain.

Example:

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

The number:

is the preference value.

Generally, a lower preference number has higher priority.

A domain can have multiple MX records:

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

This can provide mail delivery redundancy.

20. TXT Records

TXT records store text data associated with a DNS name.

They are commonly used for:

Domain verification
SPF
DKIM public keys
DMARC
Service verification
Security policies

For example, a domain may publish a verification token:

example.com. IN TXT "verification-token"

TXT is a flexible record type, but the exact syntax and purpose depend on the application consuming it.

21. NS Records

NS means:

Name Server

NS records identify the authoritative nameservers for a DNS zone.

Example:

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

These records are essential to DNS delegation.

22. SOA Record

SOA means:

Start of Authority

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

Example:

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

The fields include values associated with:

Primary nameserver
Responsible administrator
Serial number
Refresh
Retry
Expire
Negative caching behavior

The exact operational behavior can depend on DNS software and configuration.

23. CAA Records

CAA means:

Certification Authority Authorization

CAA records can specify which certificate authorities are authorized to issue TLS certificates for a domain.

For example:

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

This can reduce the risk of an unauthorized certificate authority issuing a certificate for the domain.

24. PTR Records and Reverse DNS

Normal DNS lookup:

hostname
   ↓
IP address

is called forward resolution.

Reverse DNS works in the opposite direction:

IP address
   ↓
hostname

This commonly uses:

PTR

records.

For IPv4, reverse DNS uses the:

in-addr.arpa

namespace.

Reverse DNS is particularly important for:

Email servers
Network troubleshooting
Logging
Infrastructure management
Some reputation systems

25. SRV Records

SRV records help locate services.

They can provide information such as:

Service
Protocol
Port
Target hostname
Priority
Weight

They are commonly used by applications and network services that need service discovery.

26. The DNS Zone

A DNS zone is a portion of the DNS namespace administered as a unit.

For example:

example.com

could represent a DNS zone.

A simplified 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 is not necessarily identical to the entire domain namespace.

Delegation can create separate zones for subdomains.

27. What Does @ Mean in DNS?

When configuring DNS records, you may see:

This generally represents the zone apex.

For a zone:

example.com

the following:

@ IN A 203.0.113.10

means:

example.com

not:

www.example.com

For example:

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

produces:

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

The zone apex is also commonly called the root domain or naked domain.

28. Example DNS Zone File

A simplified zone file might look like:

$TTL 3600

@ IN SOA ns1.example.net. admin.example.com. (
    2026090801
    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 demonstrates how several DNS records work together.

29. DNS Transport: UDP vs TCP

Traditional DNS commonly uses:

UDP port 53

and can also use:

TCP port 53

UDP is efficient and has low overhead.

However, DNS can use TCP in situations such as:

Large responses
Truncated UDP responses
Zone transfers
Protocol fallback requirements

Modern DNS also uses mechanisms such as EDNS to support larger DNS messages over UDP.

Therefore, saying:

“DNS always uses UDP”

is incorrect.

30. DNS Over HTTPS (DoH)

DNS queries traditionally travel in a way that can be observed by parties able to monitor the network path.

DNS over HTTPS encrypts DNS communication inside HTTPS.

Conceptually:

Application
     ↓
Encrypted HTTPS
     ↓
DNS Resolver

DoH commonly uses:

HTTPS / TCP 443

This makes DNS traffic resemble ordinary encrypted web traffic.

DoH can improve privacy against certain network observers and protect DNS queries from modification on the local network.

However, DoH does not mean that the DNS resolver itself cannot see the queries.

31. DNS Over TLS (DoT)

DNS over TLS also encrypts DNS queries.

The common transport is:

TCP 853

Conceptually:

Client
   │
   │ TLS
   ▼
DNS Resolver

The primary difference between DoH and DoT is the transport protocol and how the encrypted DNS traffic is integrated into the network.

Cloudflare’s DNS documentation describes DoH as DNS encrypted through HTTPS and DoT as DNS encrypted using TLS over its dedicated port 853.

32. DNSSEC: Securing DNS Integrity

DNS by itself does not automatically provide cryptographic authentication of DNS responses.

This creates an important security problem.

An attacker who can interfere with DNS resolution may attempt to provide false DNS information.

For example:

User
 ↓
example.com
 ↓
Fake DNS response
 ↓
Malicious server

DNSSEC helps address this by adding cryptographic signatures to DNS data.

DNSSEC stands for:

DNS Security Extensions

It provides mechanisms for validating the authenticity and integrity of DNS data.

33. How DNSSEC Works

Important DNSSEC-related records include:

DNSKEY
DS
RRSIG
NSEC / NSEC3

A simplified trust chain looks like:

Root
  ↓
TLD DS
  ↓
Domain DNSKEY
  ↓
RRSIG
  ↓
DNS Record

The goal is to create a cryptographic chain of trust.

If validation succeeds:

DNS answer
   ↓
Signature verification
   ↓
Trusted

If validation fails, a validating resolver may reject the response.

34. What DNSSEC Does NOT Do

DNSSEC is often misunderstood.

DNSSEC does not encrypt normal DNS traffic.

It provides:

Authentication of DNS data
Integrity protection
Protection against certain forms of DNS spoofing

It does not provide:

General browsing encryption
User anonymity
HTTPS replacement
Protection from every DNS attack
Encryption of application traffic

For encrypted DNS transport, technologies such as DoH and DoT serve a different purpose.

35. Testing DNSSEC with dig

On Linux or another Unix-like system with dig, you can inspect DNSSEC information.

dig example.com +dnssec

You can also inspect DNSKEY records:

dig DNSKEY example.com

For a concise lookup:

dig example.com +short

The ad flag in a DNS response can indicate that a validating resolver authenticated the DNS data.

dig is one of the most valuable tools for diagnosing DNS problems.

36. DNS and Email Security

DNS is fundamental to email infrastructure.

A typical email domain can use:

MX
SPF
DKIM
DMARC
PTR

For example:

MX
↓
Where should email be delivered?

SPF
↓
Which servers are authorized to send?

DKIM
↓
Cryptographic email signature

DMARC
↓
How should receiving systems handle authentication failures?

This makes DNS an important part of email security and deliverability.

37. Split-Horizon DNS

Organizations sometimes need internal users and external users to receive different DNS answers.

For example:

Internal network

app.example.com
→ 10.10.10.50

Internet

app.example.com
→ 203.0.113.50

This architecture is called:

Split-horizon DNS

or:

Split DNS

It is useful for:

Corporate networks
Internal applications
VPN environments
Private services
Hybrid cloud infrastructures

38. Anycast DNS

Large DNS providers often distribute services across many geographic locations.

With Anycast, the same IP address can be advertised from multiple locations.

Conceptually:

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

Routing can direct users toward a suitable network location.

This can improve:

Availability
Resilience
Latency
DDoS resistance

Anycast is particularly important for large-scale DNS infrastructure.

39. DNS Load Balancing

DNS can also participate in traffic distribution.

For example:

www.example.com
       │
       ├── Server A
       ├── Server B
       └── Server C

Possible techniques include:

Multiple A/AAAA records
Weighted DNS
Geographic DNS
Latency-based DNS
Health-aware DNS

However, DNS is not a replacement for a real load balancer in every architecture.

DNS decisions are affected by:

TTL
Resolver caching
Client behavior
Network topology

Therefore, DNS-based traffic distribution must be designed carefully.

40. DNS Security Risks

DNS is critical infrastructure, so it is also a major security target.

Common threats include:

DNS Cache Poisoning

An attacker attempts to cause a resolver to cache false DNS information.

DNS Spoofing

False DNS responses are presented to a client.

DNS Amplification

Poorly configured recursive DNS infrastructure can be abused as part of reflection/amplification attacks.

DNS Tunneling

Attackers can abuse DNS queries and responses as a communication channel.

Dangling DNS Records

A DNS record can continue pointing to an external service after the resource has been removed.

This can create the risk of:

Subdomain takeover

DNS Hijacking

An attacker may attempt to change DNS configuration or delegation.

These risks are why DNS configuration should be treated as part of the security architecture, not merely as a hosting setting.

Open recursive resolvers can be particularly dangerous because they may be abused for amplification and other attacks.

41. DNS Troubleshooting Methodology

When a website does not load, do not immediately assume that DNS is the problem.

Use a layered troubleshooting process.

1. Does the hostname resolve?
        ↓
2. Does it return the expected IP?
        ↓
3. Can the IP be reached?
        ↓
4. Is the correct port open?
        ↓
5. Is TLS working?
        ↓
6. Is the web server responding?

This prevents you from confusing DNS problems with:

Firewall problems
Routing problems
TLS problems
HTTP problems
Server failures
CDN issues

42. Windows DNS Troubleshooting

nslookup

Basic query:

nslookup example.com

Query a specific DNS server:

nslookup example.com 1.1.1.1

Query MX:

nslookup -type=MX example.com

Query NS:

nslookup -type=NS example.com

43. PowerShell Resolve-DnsName

Windows PowerShell provides:

Resolve-DnsName example.com

IPv4:

Resolve-DnsName example.com -Type A

IPv6:

Resolve-DnsName example.com -Type AAAA

MX:

Resolve-DnsName example.com -Type MX

NS:

Resolve-DnsName example.com -Type NS

TXT:

Resolve-DnsName example.com -Type TXT

This is particularly useful when troubleshooting Windows systems.

44. Windows DNS Cache

To display cached DNS entries:

ipconfig /displaydns

To flush the local DNS cache:

ipconfig /flushdns

You may need to flush the cache when testing DNS changes locally.

However, remember:

Local cache
≠
Recursive resolver cache
≠
Authoritative DNS

Flushing your computer’s cache does not instantly change caches elsewhere on the Internet.

45. Linux DNS Troubleshooting with dig

Basic lookup:

dig example.com

Short answer:

dig example.com +short

Query a specific resolver:

dig @1.1.1.1 example.com

Query an A record:

dig example.com A

Query AAAA:

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

46. Using dig +trace

One of the most useful DNS troubleshooting commands is:

dig +trace example.com

Instead of simply asking one resolver for the final answer, dig +trace can show the delegation process.

Conceptually:

Root
 ↓
.com
 ↓
example.com
 ↓
Authoritative server
 ↓
Answer

This is extremely useful when diagnosing:

Broken delegation
Nameserver problems
DNSSEC problems
Unexpected authoritative answers
Domain migration issues

47. Linux resolvectl

On systems using systemd-resolved, you may use:

resolvectl status

to inspect DNS configuration.

You can query:

resolvectl query example.com

Depending on the system configuration, local DNS caches can also be flushed with:

resolvectl flush-caches

Not every Linux distribution uses systemd-resolved, so always verify which resolver architecture your system actually uses.

48. Troubleshooting Scenario #1: Domain Does Not Resolve

Suppose:

dig example.com

returns an error.

Start by testing multiple resolvers:

dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

If both fail, investigate:

Domain delegation
       ↓
Authoritative nameservers
       ↓
DNS zone
       ↓
Record configuration

Then test:

dig NS example.com

and:

dig +trace example.com

49. Troubleshooting Scenario #2: DNS Returns the Wrong IP

Suppose your DNS provider contains:

203.0.113.10

but your computer receives:

198.51.100.20

Possible explanations include:

Local cache
Recursive resolver cache
Multiple DNS providers
Incorrect authoritative server
Multiple A records
CDN/proxy behavior
Split DNS
Delegation problem

Compare:

dig example.com
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

Then query the authoritative server directly.

This helps determine where the discrepancy occurs.

50. Troubleshooting Scenario #3: Website Works for Some Users but Not Others

This is a classic DNS problem.

Suppose:

User A → Website works
User B → Website fails
User C → Old server
User D → New server

Possible causes include:

Different recursive resolvers
Cached records
TTL differences
Multiple authoritative servers with inconsistent data
DNS delegation problems
DNSSEC validation failures

The key is to compare DNS answers from multiple networks and resolvers.

51. Troubleshooting Scenario #4: Email Is Not Arriving

First check MX:

dig example.com MX

Then inspect the mail host:

dig mail.example.com A
dig mail.example.com AAAA

Then inspect email authentication:

dig example.com TXT

Look for relevant SPF and DMARC records.

For DKIM, query the selector used by your mail provider:

dig selector._domainkey.example.com TXT

The selector is provider-specific.

52. Troubleshooting Scenario #5: DNSSEC Failure

If DNSSEC is incorrectly configured, validating resolvers may reject DNS responses.

A common symptom is:

Some users can access the site
Others cannot resolve it

Check:

dig example.com +dnssec

and:

dig DS example.com

You can also inspect:

dig DNSKEY example.com

If DNSSEC is broken, investigate the relationship between:

Registrar
   ↓
DS record
   ↓
Authoritative DNS
   ↓
DNSKEY
   ↓
RRSIG

DNSSEC configuration must be consistent across the chain of trust.

53. DNS vs HTTP: A Critical Distinction

Consider:

https://example.com

DNS answers:

Where should example.com resolve?

DNS does not answer:

Is the web server working?

After DNS resolution, the client still needs to establish the appropriate network and application connections.

A simplified sequence is:

DNS
 ↓
IP address
 ↓
TCP / QUIC
 ↓
TLS
 ↓
HTTP
 ↓
Web application

Therefore:

DNS works

does not necessarily mean:

Website works

54. DNS and HTTPS

A typical HTTPS connection may involve:

1. DNS lookup
2. IP selection
3. Network connection
4. TLS handshake
5. HTTP request
6. HTTP response

This explains why debugging a website should not stop after checking DNS.

For example:

DNS → OK
TCP → FAIL

is a network/firewall problem.

Whereas:

DNS → OK
TCP → OK
TLS → FAIL

is more likely a certificate or TLS configuration problem.

55. DNS Architecture for a Professional Website

For a production website such as CorgiNetwork, a clean DNS architecture should separate responsibilities.

Example:

corginetwork.com/
│
├── @
│   ├── A / AAAA
│   └── Website
│
├── www
│   └── CNAME
│
├── mail
│   └── Mail infrastructure
│
├── api
│   └── API service
│
├── blog
│   └── Content platform
│
└── verification records
    └── TXT / CAA / other records

The exact records depend on your hosting, CDN, email provider and infrastructure.

56. DNS Best Practices

For a production environment, follow these principles.

1. Use reliable authoritative DNS

DNS availability is foundational to website availability.

2. Keep records organized

Remove obsolete records.

3. Document DNS changes

Maintain a record of important changes.

4. Use appropriate TTL values

Do not automatically use extremely low TTLs for everything.

5. Enable DNSSEC when properly supported

DNSSEC adds cryptographic protection to DNS data.

6. Protect your registrar account

An attacker who gains control of the domain or nameserver delegation can potentially redirect DNS.

Use:

Strong unique passwords
MFA
Registrar lock features
Security alerts

7. Audit unused subdomains

Old DNS records can become security liabilities.

8. Avoid unnecessary public records

Expose only the DNS information required by your architecture.

9. Monitor DNS

Important domains should be monitored for:

Unexpected IP changes
Nameserver changes
DNSSEC problems
Expired records
Availability issues

10. Keep email authentication configured correctly

Use appropriate:

MX
SPF
DKIM
DMARC
PTR

where applicable.

57. A Practical DNS Investigation Workflow

When something goes wrong, use this workflow.

STEP 1
Identify hostname
        ↓
STEP 2
Query A / AAAA
        ↓
STEP 3
Query NS
        ↓
STEP 4
Query SOA
        ↓
STEP 5
Query authoritative server
        ↓
STEP 6
Compare public resolvers
        ↓
STEP 7
Check TTL
        ↓
STEP 8
Check DNSSEC
        ↓
STEP 9
Test network connectivity
        ↓
STEP 10
Test application layer

Useful commands:

dig example.com A
dig example.com AAAA
dig example.com NS
dig example.com SOA
dig example.com TXT
dig +trace example.com
dig example.com +dnssec

Windows:

Resolve-DnsName example.com
Resolve-DnsName example.com -Type MX
Resolve-DnsName example.com -Type TXT
nslookup example.com

58. Common DNS Mistakes

Mistake 1: Thinking DNS is only about websites

DNS also supports:

Email
Service discovery
Verification
Security policies
Internal infrastructure

Mistake 2: Confusing nameservers with DNS records

Nameservers host or serve DNS data.

Records contain specific DNS information.

Mistake 3: Assuming DNS changes are instant

Caching means different resolvers may temporarily have different answers.

Mistake 4: Using CNAME incorrectly

CNAME points to a hostname, not an IP address.

Mistake 5: Assuming DNSSEC encrypts DNS

DNSSEC provides authentication and integrity, not transport confidentiality.

Mistake 6: Flushing local DNS and expecting the entire Internet to update

Your local cache is only one caching layer.

Mistake 7: Assuming DNS works because the browser eventually loads

Browser and OS caches can hide DNS behavior.

59. DNS Performance Optimization

DNS performance can affect how quickly a client discovers the destination for a hostname.

Useful considerations include:

Reliable authoritative DNS
Geographic distribution
Anycast
Appropriate TTL values
Minimizing unnecessary DNS chains
Avoiding excessive CNAME dependencies
Reliable recursive resolvers
Monitoring DNS latency

However, DNS should not be optimized blindly.

A few milliseconds of DNS improvement may be irrelevant if:

Server response = 2 seconds

while DNS takes:

20 ms

Always optimize based on actual measurements.

60. DNS Monitoring

For important infrastructure, DNS should be monitored like any other production service.

Monitor:

DNS availability
DNS latency
A/AAAA changes
NS changes
MX changes
DNSSEC validation
Certificate records
Nameserver health

A useful monitoring strategy can test:

Resolver A
Resolver B
Resolver C

from different geographic locations.

This helps detect regional DNS problems that a single monitoring location might miss.

61. DNS Security Checklist

For a professional domain:

[ ] Registrar account protected with MFA
[ ] Nameserver configuration documented
[ ] DNSSEC evaluated/enabled where appropriate
[ ] Unused DNS records removed
[ ] Old CNAMEs reviewed
[ ] Email authentication configured
[ ] MX records verified
[ ] SPF reviewed
[ ] DKIM verified
[ ] DMARC configured
[ ] CAA reviewed
[ ] DNS changes monitored
[ ] Critical DNS records documented
[ ] DNS provider redundancy considered

62. DNS Mental Model

If you remember only one diagram from this article, remember this:

                 INTERNET DNS
                      │
                      ▼
                 Root (.)
                      │
                      ▼
                  TLD (.com)
                      │
                      ▼
             Domain Delegation
                      │
                      ▼
           Authoritative DNS
                      │
                      ▼
               DNS Record
                      │
                      ▼
             Recursive Resolver
                      │
                      ▼
                Your Device

In practice, caching can shorten this process dramatically:

Your Device
     │
     ▼
Recursive Resolver
     │
     ▼
CACHE HIT
     │
     ▼
IP Address

This is one of the main reasons DNS can operate efficiently at Internet scale.

63. Frequently Asked Questions

What does DNS stand for?

DNS stands for Domain Name System.

It provides a distributed naming system used to map domain names to IP addresses and other network information.

What is a DNS server?

A DNS server is a system involved in answering or serving DNS queries. Different DNS servers have different roles, including recursive resolvers, root servers, TLD servers and authoritative nameservers.

What is a recursive DNS resolver?

A recursive resolver receives DNS requests from clients and performs the necessary lookup process to obtain an answer.

What is an authoritative DNS server?

An authoritative DNS server contains the definitive DNS records for the zones it serves.

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?

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

What is an MX record?

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

What is DNSSEC?

DNSSEC adds cryptographic signatures and validation mechanisms to DNS data to help protect its authenticity and integrity.

Does DNSSEC encrypt DNS?

No. DNSSEC does not provide general DNS transport encryption.

What is DoH?

DNS over HTTPS encrypts DNS communication through HTTPS.

What is DoT?

DNS over TLS encrypts DNS communication using TLS, commonly over TCP port 853.

Why does DNS sometimes return an old IP address?

A recursive resolver, operating system or other DNS component may still have the previous response cached until its applicable TTL or cache policy expires.

What is reverse DNS?

Reverse DNS maps an IP address back to a hostname, commonly using PTR records.

What does `dig +trace` do?

It helps trace DNS delegation from the root through the TLD and toward the authoritative nameservers.

64. Key Takeaways

DNS is one of the fundamental systems that makes the Internet usable.

The most important concepts are:

DNS translates human-readable names into network information.
DNS is distributed rather than being a single central database.
Recursive resolvers perform lookups on behalf of clients.
Authoritative DNS servers provide definitive records for their zones.
Root and TLD infrastructure provide delegation.
DNS caching improves performance and reduces unnecessary queries.
TTL controls important aspects of DNS caching.
A and AAAA records map names to IPv4 and IPv6 addresses.
CNAME records create hostname aliases.
MX records are essential for email routing.
TXT records are widely used for verification and email security.
DNSSEC protects DNS data integrity and authenticity.
DoH and DoT provide encrypted DNS transport using different mechanisms.
Reverse DNS uses PTR records.
DNS troubleshooting should distinguish name resolution from network and application failures.

Conclusion

DNS is much more than an Internet phonebook.

It is a distributed, hierarchical and highly optimized system that connects human-readable names with the infrastructure behind Internet services.

When you enter:

https://corginetwork.com/

a surprisingly sophisticated process can occur before the browser even begins loading the page:

Browser
   ↓
OS / Stub Resolver
   ↓
Recursive Resolver
   ↓
Cache?
   ↓
Root
   ↓
TLD
   ↓
Authoritative DNS
   ↓
DNS Record
   ↓
IP Address
   ↓
Network Connection
   ↓
TLS
   ↓
HTTP
   ↓
Website

Once you understand this chain, many seemingly unrelated problems become easier to diagnose.

A website returning an old IP, email failing to arrive, a subdomain suddenly becoming unreachable, DNSSEC causing resolution failures, or users in different countries receiving different DNS responses can all be investigated systematically.

For network engineers, system administrators, DevOps engineers, cybersecurity professionals and web developers, DNS is not an optional concept.

It is foundational infrastructure.