DNS Infrastructure

Root servers are not 13 machines, but 13 anycast networks. From root to TLD to authoritative, every layer is distributed—understanding the architecture of this infrastructure reveals what happens behind the scenes when "changing a DNS record."

Overview

DNS is more than just a protocol—it is a globally distributed database consisting of 13 root servers (1000+ physical instances deployed via Anycast) and hundreds of TLD registries. CDN providers (Cloudflare/AWS/Azure) leverage DNS as a traffic entry point: returning the address of the nearest data center based on the query source IP. Split DNS separates internal and external views in enterprise/home networks. Understanding DNS infrastructure is key to understanding internet availability and fault recovery.

Root Server System

13 logical root server identifiers (a.root-servers.net ~ m.root-servers.net), with 1000+ physical instances distributed globally via Anycast.

Root zone size: ~10KB (only TLD delegation records). Root servers do not answer recursive queries (RD=0 only); they only provide referrals.

Root hints file (/usr/share/dns/root.hints or built into the recursive resolver) provides initial bootstrap.

Anycast

The same IP prefix is announced simultaneously from multiple physical locations. BGP automatically routes traffic to the nearest node (by AS path).

How Anycast works: There is no guarantee that two queries from the same client will go to the same instance (unless the same /24 is announced consistently). This is perfect for DNS — each query is independent.

CDN DNS

Key Technologies

GeoDNS source IP → geo database → nearest region → return IP Latency-based Real-time measurement of edge↔source IP latency → Select lowest latency ECS (Client Subnet) Resolver passes subnet /24 (v4) /56 (v6) → More precise edge selection, but leaks information ECS allows CDNs to select edges more precisely, but passes the client's subnet information to the authoritative server — it's a tradeoff between precision and privacy.

Split DNS

Internal networks use different DNS views:

Internal (Home/Corporate Network):
  grafana.liz6.com → 192.168.31.8 (Internal IP, does not traverse public internet)

Public Internet:
  grafana.liz6.com → VPS IP (via rathole tunnel)

Implementation:
  - BIND: views { match-clients { internal_net; }; ... }
  - Unbound: access-control-view
  - dnsmasq: address=/grafana.liz6.com/192.168.31.8

DNS-based Load Balancing

Weighted round-robin:
  www.example.com A 1.1.1.1
  www.example.com A 2.2.2.2
  → Resolver selects randomly (usually the client picks the first one, but behavior varies by resolver)

Latency-based (Route 53):
  latency alias + health checks → Automatically selects the healthy endpoint with the lowest latency

Geo-proximity (Traffic Manager):
  geographic routing + endpoint monitoring

References

RSSAC: root-servers.org
CDN: Cloudflare Anycast, AWS Route 53, Azure Traffic Manager

Keywords: root servers, anycast, CDN DNS, GeoDNS, split DNS, ECS, DNS-based load balancing