Terabyte Systems

DNS (Domain Name System) Architecture

By Tera • • 8 min read
networking

The Domain Name System (DNS) is one of the Internet’s most critical yet often overlooked infrastructures. Every time you visit a website, send an email, or use any Internet service, DNS silently translates human-readable domain names into machine-usable IP addresses. This deep dive explores DNS architecture, from recursive resolution to zone files and security considerations.

DNS Fundamentals

What DNS Does

DNS translates domain names to IP addresses:

Human-Friendly:    www.example.com
Machine-Usable:    93.184.216.34 (IPv4)
                   2606:2800:220:1:248:1893:25c8:1946 (IPv6)

DNS Hierarchy

                    Root (.)
                       │
        ┌──────────────┼──────────────┐
       .com           .org           .net
        │              │              │
    ┌───┼───┐      ┌───┼───┐      ┌───┼───┐
  google  amazon  wikipedia  gnu  example  etc
    │       │         │        │      │
   www     www       www      www    www

Fully Qualified Domain Names (FQDN)

www.example.com.
│   │       │   └─ Root (implied)
│   │       └───── Top-Level Domain (TLD)
│   └───────────── Second-Level Domain (SLD)
└───────────────── Subdomain/Host

Components:
- Root: .
- TLD: com
- Domain: example
- Subdomain: www

DNS Architecture Components

DNS Servers

Root Name Servers

Function: Authoritative for root zone
Count: 13 root server identifiers (A-M)
Actual Servers: Hundreds via anycast

Root Servers (examples):
a.root-servers.net (VeriSign)
b.root-servers.net (USC-ISI)
c.root-servers.net (Cogent)
...
m.root-servers.net (WIDE Project)

TLD Name Servers

Generic TLDs (gTLD):
.com, .org, .net, .info, .biz

Country Code TLDs (ccTLD):
.uk, .us, .de, .jp, .cn

New gTLDs:
.tech, .app, .dev, .blog, .shop

Authoritative Name Servers

Purpose: Provide authoritative answers for specific domains
Examples:
- ns1.example.com
- ns2.example.com

Responsible for:
- Zone file management
- Resource records
- DNSSEC signing (if enabled)

Recursive Resolvers

Purpose: Query on behalf of clients
Common Public Resolvers:
- Google Public DNS: 8.8.8.8, 8.8.4.4
- Cloudflare DNS: 1.1.1.1, 1.0.0.1
- Quad9: 9.9.9.9
- OpenDNS: 208.67.222.222, 208.67.220.220

Functions:
- Cache responses
- Iterate through DNS hierarchy
- Return results to clients

DNS Resolution Process

Recursive Query Flow

1. Client queries resolver
   "What is www.example.com?"
   
2. Resolver checks cache
   - If cached, return immediately
   - If not, begin resolution

3. Resolver queries root server
   "Where can I find .com?"
   → Returns .com TLD servers

4. Resolver queries .com TLD server
   "Where can I find example.com?"
   → Returns example.com nameservers

5. Resolver queries example.com nameserver
   "What is www.example.com?"
   → Returns IP address

6. Resolver caches result
   - TTL determines cache duration

7. Resolver returns answer to client

Detailed example:

Client                Recursive      Root     TLD (.com)    Authoritative
                      Resolver       Server   Server        (example.com)
  │                      │            │            │               │
  │─1─ www.example.com ─>│            │            │               │
  │                      │            │            │               │
  │                      │─2─ .com? ─>│            │               │
  │                      │            │            │               │
  │                      │<─3─ TLD NS─┤            │               │
  │                      │            │            │               │
  │                      │─4─ example.com? ───────>│               │
  │                      │            │            │               │
  │                      │<─5─ Auth NS─────────────┤               │
  │                      │            │            │               │
  │                      │─6─ www.example.com? ────────────────────>│
  │                      │            │            │               │
  │                      │<─7─ 93.184.216.34 ──────────────────────┤
  │                      │            │            │               │
  │<─8─ 93.184.216.34 ──┤            │            │               │

DNS Record Types

Common Resource Records

A Record (IPv4 Address)

example.com.    IN  A   93.184.216.34

Format:
NAME            TTL CLASS TYPE DATA
example.com.    300 IN    A    93.184.216.34

AAAA Record (IPv6 Address)

example.com.    IN  AAAA  2606:2800:220:1:248:1893:25c8:1946

CNAME Record (Canonical Name)

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

Purpose: Creates alias
Note: CNAME cannot coexist with other records at same name

MX Record (Mail Exchange)

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

Priority: Lower number = higher priority

NS Record (Name Server)

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

Purpose: Delegates subdomain to nameservers

PTR Record (Pointer - Reverse DNS)

34.216.184.93.in-addr.arpa.  IN  PTR  example.com.

Purpose: Maps IP to hostname (reverse lookup)

TXT Record (Text)

example.com.  IN  TXT  "v=spf1 mx -all"

Common uses:
- SPF (Sender Policy Framework)
- DKIM (DomainKeys Identified Mail)
- DMARC (Domain-based Message Authentication)
- Domain verification

SOA Record (Start of Authority)

example.com. IN SOA ns1.example.com. admin.example.com. (
    2024032301  ; Serial (YYYYMMDDnn)
    3600        ; Refresh (1 hour)
    1800        ; Retry (30 minutes)
    604800      ; Expire (1 week)
    300         ; Minimum TTL (5 minutes)
)

Components:
- Primary NS: ns1.example.com.
- Admin email: [email protected] (@ replaced with .)
- Serial: Version number (increment on changes)
- Refresh: Secondary checks primary interval
- Retry: Retry interval if refresh fails
- Expire: Secondary stops answering after this
- Minimum TTL: Default TTL for negative responses

SRV Record (Service)

_service._proto.name.  TTL  IN  SRV  priority  weight  port  target.

Example:
_sip._tcp.example.com.  IN  SRV  10  60  5060  sipserver.example.com.

Purpose: Defines location of services

CAA Record (Certification Authority Authorization)

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild "letsencrypt.org"
example.com.  IN  CAA  0 iodef "mailto:[email protected]"

Purpose: Restricts which CAs can issue certificates

DNS Zone Files

Zone File Structure

; Zone file for example.com
$ORIGIN example.com.
$TTL 86400

; SOA Record
@   IN  SOA ns1.example.com. admin.example.com. (
        2024032301  ; Serial
        3600        ; Refresh
        1800        ; Retry
        604800      ; Expire
        300         ; Minimum TTL
    )

; Name Servers
@   IN  NS  ns1.example.com.
@   IN  NS  ns2.example.com.

; A Records
@   IN  A   93.184.216.34
www IN  A   93.184.216.34
mail IN  A   93.184.216.35

; AAAA Records
@   IN  AAAA  2606:2800:220:1:248:1893:25c8:1946

; MX Records
@   IN  MX  10  mail.example.com.

; CNAME Records
ftp  IN  CNAME  www.example.com.
blog IN  CNAME  www.example.com.

; TXT Records
@   IN  TXT  "v=spf1 mx -all"
_dmarc IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

BIND Configuration

// named.conf

options {
    directory "/var/named";
    listen-on { any; };
    listen-on-v6 { any; };
    allow-query { any; };
    recursion no;
    dnssec-validation auto;
};

zone "example.com" IN {
    type master;
    file "example.com.zone";
    allow-transfer { 192.0.2.2; };  // Secondary NS
    notify yes;
};

zone "2.0.192.in-addr.arpa" IN {
    type master;
    file "2.0.192.rev";
};

DNS Caching

TTL (Time To Live)

Purpose: Controls cache duration

example.com.  300  IN  A  93.184.216.34
              │
              └─ TTL in seconds (5 minutes)

Considerations:
- High TTL: Better performance, slower changes
- Low TTL: Faster changes, more DNS queries
- Common values: 300-86400 seconds

Strategy:
- Before changes: Lower TTL
- During normal operation: Higher TTL
- After changes stabilize: Raise TTL again

Negative Caching

Purpose: Cache non-existent domain responses

NXDOMAIN response is cached per SOA minimum TTL

Prevents:
- Repeated queries for non-existent domains
- DNS amplification attacks

DNS Security

DNSSEC (DNS Security Extensions)

Provides:

  1. Origin authentication
  2. Data integrity
  3. Authenticated denial of existence

DNSSEC Record Types

RRSIG: Contains signature for record set
DNSKEY: Public key for zone
DS: Delegation Signer (in parent zone)
NSEC/NSEC3: Proof of non-existence

Example signed record:

example.com. 300 IN A 93.184.216.34
example.com. 300 IN RRSIG A 8 2 300 (
                    20240401000000 20240301000000 12345 example.com.
                    WQ2vHvHQAADrZqZKfN... )

DNSSEC Validation

1. Client requests www.example.com
2. Resolver retrieves A record + RRSIG
3. Resolver retrieves DNSKEY from zone
4. Resolver validates DNSKEY using DS from parent
5. Resolver validates RRSIG using DNSKEY
6. If valid, return answer
7. If invalid, return SERVFAIL

DNS over HTTPS (DoH)

Traditional DNS:
Client ───┬─ UDP/TCP Port 53 ──> DNS Server
          └─ Plaintext, observable

DNS over HTTPS:
Client ──── HTTPS (Port 443) ──> DoH Server
            Encrypted, private

DoH Providers:
- Cloudflare: https://1.1.1.1/dns-query
- Google: https://dns.google/dns-query
- Quad9: https://dns.quad9.net/dns-query

DNS over TLS (DoT)

Traditional DNS: Port 53 (plaintext)
DNS over TLS: Port 853 (encrypted)

Client ──── TLS (Port 853) ──> DoT Server
            Encrypted, private

Configuration example:
echo "nameserver 1.1.1.1" > /etc/resolv.conf
# Configure system to use DoT

DNS Security Best Practices

1. Implement DNSSEC
   - Sign zones
   - Validate responses
   
2. Use DNS filtering
   - Block malicious domains
   - Prevent data exfiltration

3. Rate limiting
   - Prevent amplification attacks
   - Limit queries per source

4. Access control
   - Restrict zone transfers
   - Allow-query policies

5. Monitoring
   - Log query patterns
   - Alert on anomalies

6. Redundancy
   - Multiple authoritative servers
   - Geographic distribution

DNS Tools and Commands

dig (Domain Information Groper)

## Basic query
dig example.com

## Specific record type
dig example.com MX
dig example.com AAAA

## Query specific server
dig @8.8.8.8 example.com

## Reverse lookup
dig -x 93.184.216.34

## Trace resolution path
dig +trace example.com

## Short answer only
dig +short example.com

## Show only specific section
dig +noall +answer example.com

## DNSSEC validation
dig +dnssec example.com

nslookup

## Interactive mode
nslookup
> server 8.8.8.8
> set type=MX
> example.com

## Command line
nslookup example.com
nslookup -type=mx example.com
nslookup example.com 8.8.8.8

host

## Basic lookup
host example.com

## Specific type
host -t MX example.com
host -t NS example.com

## Reverse lookup
host 93.184.216.34

## Verbose output
host -v example.com

DNS Performance Optimization

Geographic Distribution

Use GeoDNS to route users to nearest server:

User in US    → us-server.example.com (1.2.3.4)
User in Europe → eu-server.example.com (5.6.7.8)
User in Asia   → asia-server.example.com (9.10.11.12)

Implementation:
- DNS-based load balancing
- Latency-based routing
- Health checks

Anycast DNS

Same IP announced from multiple locations:

1.1.1.1 announced from:
- New York
- London
- Singapore
- São Paulo
- ...

BGP routes user to nearest location

DNS Load Balancing

Round Robin:
www.example.com.  IN  A  1.2.3.4
www.example.com.  IN  A  5.6.7.8
www.example.com.  IN  A  9.10.11.12

Responses rotated among addresses
Simple but no health checking

Common DNS Issues

Propagation Delays

Problem: Changes not visible everywhere
Cause: TTL-based caching

Solution:
1. Lower TTL before changes
2. Wait for old TTL to expire
3. Make changes
4. Verify with multiple resolvers
5. Raise TTL after stabilization

Cache Poisoning

Attack: Inject false DNS data into cache
Prevention:
- Source port randomization
- Transaction ID randomization
- DNSSEC validation
- Rate limiting

DDoS Attacks

Types:
- Query floods
- Amplification attacks
- NXDOMAIN floods

Mitigation:
- Rate limiting
- Anycast distribution
- Response rate limiting (RRL)
- Filtering at edge

Conclusion

DNS is the invisible infrastructure that makes the Internet usable. Understanding its architecture—from hierarchical resolution to zone management and security considerations—enables you to:

  • Design resilient DNS infrastructure
  • Troubleshoot resolution issues
  • Implement security measures
  • Optimize performance
  • Understand Internet fundamentals

Key takeaways:

  • DNS uses hierarchical delegation
  • Caching improves performance
  • DNSSEC provides authentication
  • DoH/DoT encrypt DNS traffic
  • Multiple servers provide redundancy
  • Monitoring prevents issues
  • Geographic distribution improves latency

As the Internet evolves, DNS continues adapting with new security features, performance optimizations, and privacy enhancements while maintaining backward compatibility with decades of existing infrastructure.

Thank you for reading! If you have any feedback or comments, please send them to [email protected].