# DNS as a Protocol (Part 1)

## Introduction

DNS is often described as a "system"—the global infrastructure of nameservers. But DNS is also a **protocol**—a set of agreed-upon rules for how devices communicate.

Understanding DNS as a protocol means understanding:

*   **Message format** - How requests and responses are structured
    
*   **Transport methods** - TCP vs UDP, and why each is used
    
*   **Standards** - RFC 1035 and its extensions
    
*   **Evolution** - From basic DNS to modern secure variants
    
*   **Constraints** - Why packet size matters
    

In this chapter, we explore DNS as a protocol—the rules that make the system work.

## DNS as a Protocol

### Definition

A **protocol** is a set of agreed-upon rules that define how devices communicate.

Just like human communication requires agreed rules (language, grammar, tone), network communication requires agreed rules (format, order, timing).

### DNS Protocol Foundation

```plaintext
DNS Protocol defines:

1. Message Format
   ├─ How to structure a query
   ├─ How to structure a response
   ├─ What fields are included
   └─ What order fields appear

2. Query Types
   ├─ Standard query (A, AAAA, MX, etc.)
   ├─ Inverse query
   ├─ Status query
   └─ Notification query

3. Response Codes
   ├─ 0 = NOERROR (success)
   ├─ 3 = NXDOMAIN (not found)
   ├─ 2 = SERVFAIL (server error)
   └─ Others for different scenarios

4. Transport Rules
   ├─ Use UDP port 53 (default)
   ├─ Use TCP port 53 (when needed)
   ├─ Use TCP/UDP port 853 (DoT)
   └─ Use HTTPS port 443 (DoH)

5. Record Types
   ├─ A (IPv4 address)
   ├─ AAAA (IPv6 address)
   ├─ CNAME (Canonical name)
   ├─ MX (Mail exchange)
   ├─ NS (Nameserver)
   └─ ... 25+ more types

6. Standards
   ├─ RFC 1035 (Original DNS)
   ├─ RFC 2671 (EDNS)
   ├─ RFC 4034 (DNSSEC)
   └─ Modern RFCs for new features
```

### Protocol vs System

```plaintext
DNS System (Infrastructure):
├─ Root servers globally distributed
├─ TLD nameservers
├─ Authoritative nameservers
├─ Recursive resolvers
├─ Geographic organization
└─ "The physical infrastructure"

DNS Protocol (Rules):
├─ Message format (RFC 1035)
├─ Query/response structure
├─ Error codes
├─ Transport mechanisms
└─ "The communication rules"

Both Together:
├─ System provides infrastructure
├─ Protocol defines communication
├─ Both are essential
└─ Neither works without the other
```

## Protocol Layering and the OSI Model

### Understanding the OSI Model

The **OSI (Open Systems Interconnection) Model** describes how network communication works in layers.

```plaintext
OSI Model Layers:

Layer 7: Application Layer
├─ Protocols: DNS, HTTP, HTTPS, FTP, SSH
├─ What users interact with
└─ Provides services to applications

Layer 6: Presentation Layer
├─ Encryption, compression
├─ Format translation
└─ Data translation

Layer 5: Session Layer
├─ Establish/maintain connections
├─ Dialog management
└─ Session control

Layer 4: Transport Layer
├─ Protocols: TCP, UDP
├─ End-to-end communication
└─ Reliability and flow control

Layer 3: Network Layer
├─ Protocol: IP
├─ Routing
└─ Logical addressing

Layer 2: Data Link Layer
├─ Ethernet, WiFi
├─ Physical addressing
└─ Switch operations

Layer 1: Physical Layer
├─ Cables, fiber optics
├─ Electrical signals
└─ Physical transmission
```

### DNS in the OSI Model

```plaintext
DNS Positioning:

Layer 7 (Application):
    └─ DNS Protocol
       (Query/Response format, record types)

Layer 4 (Transport):
    └─ TCP or UDP
       (Reliability, port numbers)

Layer 3 (Network):
    └─ IP
       (Routing, IP addresses)
```

DNS operates at **Layer 7 (Application)**, while TCP and UDP operate at **Layer 4 (Transport)**.

```plaintext
How Layers Work Together:

DNS Query:
    │
    ├─ Layer 7: Create DNS query (format, record type)
    │
    ├─ Layer 4: Wrap in UDP packet (source/dest port)
    │
    ├─ Layer 3: Wrap in IP packet (source/dest IP)
    │
    └─ Layer 1-2: Transmit on network

Response:
    └─ Reverse process: Unwrap at each layer
```

## Understanding TCP

### TCP Characteristics

**TCP** ensures **reliable, ordered delivery** of data.

```plaintext
TCP Key Features:

1. Connection-Oriented
   ├─ Establish connection (3-way handshake)
   ├─ Send data
   ├─ Close connection
   └─ Stateful communication

2. Sequence Numbers
   ├─ Each packet numbered
   ├─ Allows proper reassembly
   ├─ Receiver acknowledges receipt
   └─ Sender retransmits if needed

3. Acknowledgment (ACK)
   ├─ Receiver confirms: "Got packet N"
   ├─ Sender sends: "Sending packets 1-100"
   ├─ Receiver: "Confirm 1-50 received"
   ├─ Sender: "Confirm 51-100 sent"
   └─ Every byte tracked

4. Error Detection
   ├─ Checksums verify data integrity
   ├─ Corrupted packets discarded
   ├─ Receiver requests retransmission
   └─ Guaranteed accuracy

5. Flow Control
   ├─ Receiver tells sender: "Send slower"
   ├─ Prevents overwhelming receiver
   ├─ Dynamic rate adjustment
   └─ Optimal performance
```

### TCP Message Structure

```plaintext
TCP Segment (Packet):

┌─────────────────────────────────┐
│  TCP Header (20+ bytes)         │
│  ├─ Source Port                 │
│  ├─ Destination Port            │
│  ├─ Sequence Number             │
│  ├─ Acknowledgment Number       │
│  ├─ Flags (SYN, ACK, FIN, etc.) │
│  ├─ Window Size                 │
│  └─ Checksum                    │
├─────────────────────────────────┤
│  Data (up to ~1,460 bytes)      │
│  (DNS message or other payload) │
└─────────────────────────────────┘

Typical TCP packet: ~1,500 bytes total
  = 20 bytes TCP header
  + 20 bytes IP header
  + ~1,460 bytes data
```

### TCP Use Cases for DNS

DNS uses TCP when:

```plaintext
1. Response Too Large
   ├─ Response exceeds 512 bytes
   ├─ And EDNS not negotiated
   ├─ Retry query over TCP
   └─ Allows full response

2. Zone Transfers
   ├─ Primary → Secondary nameserver
   ├─ Large data transfer
   ├─ Requires reliability
   ├─ Always uses TCP
   └─ Ensures all records copied

3. Secure DNS (DoT)
   ├─ DNS over TLS
   ├─ Requires TCP for encryption
   ├─ Port 853
   └─ Privacy protection

4. Fallback
   ├─ UDP query truncated (TC flag)
   ├─ Client receives truncated response
   ├─ Client retries over TCP
   └─ Full answer retrieved
```

## Understanding UDP

### UDP Characteristics

**UDP** provides **fast, unreliable delivery** of individual datagrams.

```plaintext
UDP Key Features:

1. Connectionless
   ├─ No connection setup
   ├─ Send immediately
   ├─ No teardown
   └─ Stateless

2. No Sequencing
   ├─ Datagrams have no order
   ├─ May arrive out of order
   ├─ No reassembly guarantee
   └─ Receiver processes as-is

3. No Acknowledgment
   ├─ Sender doesn't know if received
   ├─ No confirmation sent
   ├─ Fire and forget
   └─ Fast operation

4. Minimal Overhead
   ├─ 8-byte UDP header
   ├─ No flow control
   ├─ No error recovery
   └─ Very lightweight

5. Speed First
   ├─ Minimal latency
   ├─ Low processing
   ├─ Ideal for real-time
   └─ Loss acceptable
```

### UDP Message Structure

```plaintext
UDP Datagram (Packet):

┌─────────────────────────────┐
│  UDP Header (8 bytes)       │
│  ├─ Source Port             │
│  ├─ Destination Port        │
│  ├─ Length                  │
│  └─ Checksum               │
├─────────────────────────────┤
│  Data (up to ~1,472 bytes)  │
│  (DNS message or payload)   │
└─────────────────────────────┘

Typical UDP packet: ~1,500 bytes total
  = 8 bytes UDP header
  + 20 bytes IP header
  + ~1,472 bytes data
```

### UDP Use Cases

```plaintext
DNS Queries (Primary):
├─ Fast response needed
├─ Usually small messages
├─ Tolerate occasional loss
└─ Timeout and retry if needed

Streaming/Gaming:
├─ Real-time performance critical
├─ Occasional packet loss acceptable
└─ Speed more important than reliability

Video Conferencing:
├─ Live communication needed
├─ Missing frames acceptable
└─ Delay worse than loss
```

## DNS and UDP

### Why DNS Prefers UDP

DNS defaults to UDP because:

```plaintext
1. Speed ⚡
   ├─ Typical query: ~20ms
   ├─ TCP would add handshake: +3-5ms
   ├─ Total TCP: ~25-30ms
   ├─ UDP advantage: ~25% faster
   └─ Critical for global scale

2. Simplicity 🔧
   ├─ No connection state
   ├─ No timeout management
   ├─ Stateless servers
   ├─ Easier implementation
   └─ Lower server load

3. Scalability 📊
   ├─ No connection tracking needed
   ├─ Can handle more simultaneous queries
   ├─ Less memory per query
   ├─ Scales to billions of queries
   └─ Cost efficient

4. Resilience 🛡️
   ├─ No connection to maintain
   ├─ Network issues don't block
   ├─ Timeout and retry simple
   ├─ Graceful degradation
   └─ Works through transient issues
```

### Reliability Despite UDP

DNS is reliable even though UDP is unreliable:

```plaintext
How DNS Achieves Reliability with UDP:

1. Caching
   ├─ Results cached at multiple levels
   ├─ Reduces queries that require network
   ├─ Higher hit rate = higher reliability
   └─ Even if one query fails, cache serves

2. Retries
   ├─ Client retries failed queries
   ├─ Multiple attempts possible
   ├─ Resolver retries to upstream
   ├─ Eventually succeeds or times out
   └─ System tolerates occasional loss

3. Redundancy
   ├─ Multiple nameservers per zone
   ├─ Multiple copies via anycast
   ├─ If one server fails, others respond
   ├─ Distributed infrastructure
   └─ No single point of failure

4. Fallback to TCP
   ├─ Response too large → TCP
   ├─ Automatic escalation
   ├─ Ensures full response
   └─ Reliability for large responses
```

## Packet Size Constraints

### The 512-Byte Limit

Original DNS (1987) had a strict limitation:

```plaintext
UDP Packet Size Breakdown:

Maximum UDP Packet: 1,500 bytes (Ethernet MTU)
  ├─ IP Header: 20 bytes
  ├─ UDP Header: 8 bytes
  └─ Available for data: 1,472 bytes

But DNS designed for: 512 bytes maximum

Why 512?

IPv4 Standard (RFC 791):
├─ Minimum datagram size: 576 bytes
├─ IP header: 60 bytes (max)
├─ UDP header: 8 bytes
├─ Available: 576 - 60 - 8 = 508 bytes
├─ Rounded down: 512 bytes
└─ "Safe size" that works everywhere

Impact of 512-Byte Limit:

1. Root Servers (13 limit)
   ├─ 512 bytes available
   ├─ ~30 bytes per NS record
   ├─ ~512 ÷ 30 = ~17 servers max
   ├─ Practical: 13 servers
   └─ This is WHY 13!

2. Large Responses
   ├─ Many A records → exceeds 512
   ├─ Zone transfers → huge data
   ├─ DNSSEC responses → large
   └─ Falls back to TCP

3. Modern Constraints
   ├─ 512 bytes still impacts responses
   ├─ Larger records truncated
   ├─ TCP fallback required
   └─ Performance impact
```

### Packet Size in Real Queries

```plaintext
Typical DNS Query:

Query Message:
├─ Header: 12 bytes
├─ Question: ~20 bytes (domain name + type)
└─ Total: ~32 bytes

Response Message:
├─ Header: 12 bytes
├─ Question Echo: ~20 bytes
├─ Answer (1 A record): ~16 bytes
├─ Authority: ~20-30 bytes
└─ Total: ~68 bytes

Most queries fit easily in 512 bytes

Large Response Example:

DNSSEC Signed Response:
├─ Base response: ~100 bytes
├─ RRSIG record: ~150 bytes
├─ DNSKEY record: ~300 bytes
├─ Additional records: ~100 bytes
└─ Total: ~650 bytes > 512!
    └─ Truncated! Falls back to TCP
```

## DNS in the Network Stack

### Complete Protocol Stack

```plaintext
DNS Communication Path:

Application Layer (Layer 7):
    │
    ├─ DNS Protocol
    │  ├─ Query format
    │  ├─ Response format
    │  └─ Record types
    │
    ▼
Transport Layer (Layer 4):
    │
    ├─ UDP or TCP
    │  ├─ Port 53 (standard)
    │  ├─ Port 853 (DoT)
    │  └─ Port 443 (DoH)
    │
    ▼
Network Layer (Layer 3):
    │
    ├─ IP (IPv4 or IPv6)
    │  ├─ Source IP
    │  ├─ Destination IP
    │  └─ Routing
    │
    ▼
Data Link Layer (Layer 2):
    │
    ├─ Ethernet or WiFi
    │  ├─ MAC addresses
    │  └─ Physical switching
    │
    ▼
Physical Layer (Layer 1):
    │
    ├─ Cables/Fiber/Wireless
    │  ├─ Electrical signals
    │  └─ Light pulses
```

**Encapsulation**

```plaintext
DNS Query Encapsulation:

Start: DNS Query Message
├─ 32 bytes (small query)

Add UDP Header:
├─ +8 bytes
├─ Total: 40 bytes

Add IP Header:
├─ +20 bytes
├─ Total: 60 bytes

Add Ethernet Header:
├─ +14 bytes
├─ Total: 74 bytes

Add Ethernet Trailer:
├─ +4 bytes
├─ Final: 78 bytes (minimum frame)

This packet traverses:
├─ Layer 1 (Physical): Electrical signals
├─ Layer 2 (Data Link): Ethernet switching
├─ Layer 3 (Network): IP routing
├─ Layer 4 (Transport): UDP processing
└─ Layer 7 (Application): DNS interpretation
```