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

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

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.

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

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).

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.

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

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:

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.

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

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

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:

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:

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:

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

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

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

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