DNS Architecture and Operations

NSEC3 zone enumeration resistance is not absolute. An attacker with sufficient resources can Brute-force the hashes for common names. NSEC3 with opt-out (unsigned delegations are not covered) Provides weaker security but better performance for large zones.

Anycast assigns the same IP address to multiple servers in different locations. BGP routes traffic To the nearest (topologically closest) server. For DNS, this means queries are answered by the Closest name server instance.

Client in Tokyo           Client in London
  |                          |
  |--> 198.51.100.1 -------->|--> 198.51.100.1 ---------|
  |    (anycast)              |    (anycast)
  v                          v
[Tokyo DNS instance]    [London DNS instance]
198.51.100.1           198.51.100.1

All 13 root server operators use anycast. The a-root (198.41.0.4) has over 100 instances worldwide. This provides:

• Latency reduction: Queries are answered by the closest instance ( under 50ms)
• Availability: If one instance fails, BGP withdraws the route and traffic goes to the next closest
• DDoS resilience: Attack traffic is distributed across all instances

CDNs like Cloudflare, Akamai, and Fastly use anycast for their authoritative DNS. When a client Queries www.example.com and the CDN’s DNS returns an IP address, the client is directed to the Nearest CDN edge server.

# Test which root server instance you hit
dig @198.41.0.4 . NS +short
# Compare with another location
dig @198.41.0.4 . NS +short +timeout=2

# Measure latency to different DNS servers
dig @8.8.8.8 example.com +stats | grep "Query time"
dig @1.1.1.1 example.com +stats | grep "Query time"

Split-horizon DNS (also called split-view DNS or split-brain DNS) provides different DNS responses Depending on the source of the query. Internal clients get internal IP addresses; external clients Get external IP addresses.

Internal query for db.example.com:
  Response: 10.0.0.50  (private database server)

External query for db.example.com:
  Response: REFUSED or different public IP

// Internal view (for 10.0.0.0/8 clients)
view "internal" {
    match-clients { 10.0.0.0/8; };
    zone "example.com" {
        type master;
        file "/etc/bind/db.example.com.internal";
    };
};

// External view (for everyone else)
view "external" {
    match-clients { any; };
    zone "example.com" {
        type master;
        file "/etc/bind/db.example.com.external";
    };
};

• Internal services: Database servers, management interfaces, internal APIs should not be resolvable from the Internet
• Development vs production: Developers resolve api.example.com to a staging server; production users resolve to the production server
• GeoDNS: Different responses based on geography (but anycast is better for this)

The simplest form of DNS load balancing. Multiple A records for the same name, with the resolver Cycling through them.

example.com.  300  IN  A   93.184.216.1
example.com.  300  IN  A   93.184.216.2
example.com.  300  IN  A   93.184.216.3

Limitations:

• No health checking. If one server goes down, DNS still returns its IP. Clients get connection refused.
• Caching. Resolvers cache the full RRset and distribute it independently of the authoritative server’s order.
• Uneven distribution. Clients that share a recursive resolver all get the same answer.

Some DNS providers (AWS Route 53, Cloudflare) support weight-based routing:

example.com.  300  IN  A   93.184.216.1  ; weight 3 (75% of traffic)
example.com.  300  IN  A   93.184.216.2  ; weight 1 (25% of traffic)

Return different IP addresses based on the query source’s geographic location:

; European clients
example.com.  300  IN  A   93.184.216.1  ; geo: EU

; US clients
example.com.  300  IN  A   93.184.216.2  ; geo: US

; Asian clients
example.com.  300  IN  A   93.184.216.3  ; geo: APAC

This is how CDNs direct users to the nearest edge server.

Active Directory is completely dependent on DNS. AD domain controllers register SRV records that Clients use to locate domain services:

_ldap._tcp.dc._msdcs.corp.example.com.  IN  SRV  0 100 389 dc1.corp.example.com.
_kerberos._tcp.dc._msdcs.corp.example.com. IN SRV  0 100 88 dc1.corp.example.com.

If DNS for AD is misconfigured, authentication, group policy, and all AD-dependent services fail.

Forwarding: The DNS server forwards queries it cannot answer to an upstream resolver (e.g., 8.8.8.8 or the ISP’s resolver). Simple to configure but adds latency and a dependency.

Recursion: The DNS server performs the full resolution itself (querying root, TLD, authoritative Servers). More control, can be faster with caching, but more complex to configure and secure.

Best practice for enterprise: use dedicated recursive resolvers (Unbound, BIND) that perform Recursion, not forwarding. This gives you control over caching behavior, logging, and security Policies.

# Unbound configuration for recursive resolution
server:
    interface: 0.0.0.0@53
    access-control: 10.0.0.0/8 allow
    do-not-query-localhost: no
    hide-identity: yes
    hide-version: yes
    prefetch: yes
    prefetch-key: yes

forward-zone:
    name: "."
    forward-addr: 8.8.8.8
    forward-addr: 1.1.1.1

The most important DNS troubleshooting command. It traces the full resolution path from the root Down to the authoritative server.

# Full resolution trace
dig +trace example.com

# Trace with DNSSEC validation
dig +trace +dnssec example.com

# Trace specific record type
dig +trace example.com MX

# Trace from a specific recursive resolver
dig @8.8.8.8 +trace example.com

# Query a specific authoritative server
dig @ns1.example.com example.com A

# Show the full DNSSEC chain
dig example.com DNSKEY +dnssec +multiline
dig example.com DS +dnssec +multiline

# Check delegation
dig example.com NS @a.gtld-servers.net

# Test DNSSEC validation
dig example.com A +dnssec +cd  # disable checking (cd = checking disabled)
dig example.com A +dnssec      # enable checking

# Measure query time
dig example.com +stats

# Query over TCP (when UDP is blocked or truncated)
dig +tcp example.com

# Query with EDNS0
dig +edns=0 example.com

# Show all record types for a name
dig example.com ANY +noall +answer

Real-time DNS traffic monitoring:

# Monitor DNS traffic on eth0
dnstop eth0

# Filter by source
dnstop -l 10.0.0.0/8 eth0

# Capture DNS queries and responses
tcpdump -i eth0 -n port 53

# Capture only queries (no responses)
tcpdump -i eth0 -n 'port 53 and udp[10:2] & 0x8000 = 0'

# Capture only responses
tcpdump -i eth0 -n 'port 53 and udp[10:2] & 0x8000 != 0'

# Capture DNS over TCP
tcpdump -i eth0 -n 'tcp port 53'

# Save to pcap for analysis
tcpdump -i eth0 -n -w /tmp/dns-capture.pcap port 53

The queried name does not exist in the zone. Causes:

• Typo in the domain name
• Record not yet created (propagation delay)
• Record deleted
• Wildcard not configured (if expected)

# Check if the name exists
dig example.com A @ns1.example.com

# Check for typos
dig exmple.com A  # oops

The authoritative server encountered an error. Causes:

• DNSSEC validation failure (broken chain of trust)
• Server misconfiguration
• Server overloaded or unreachable
• Broken zone file syntax

# Check DNSSEC chain
dig example.com DNSKEY +dnssec @ns1.example.com
dig example.com RRSIG A +dnssec @ns1.example.com

# Check server health
dig example.com A @ns1.example.com +timeout=5
dig example.com SOA @ns1.example.com

Cache poisoning occurs when an attacker injects forged DNS responses into a recursive resolver’s Cache, causing subsequent queries to return malicious IP addresses.

Mitigations:

• Source port randomization: The resolver uses random source ports for queries (RFC 5452). An attacker must guess both the query ID (16 bits) and the source port (16 bits), making spoofing much harder.
• DNSSEC: The resolver validates signatures. Even if a forged response is accepted into the cache, DNSSEC validation rejects it.
• DNS-over-TLS / DNS-over-HTTPS: Encrypt the query path, preventing interception and injection.
• 0x20 encoding: Randomize the case of the query name. The response must match the case, making forgery harder.