8 min read #networking #DNS
On this page

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

Anycast: Same IP announced in multiple locations, BGP routes to the nearest instance via the shortest path Anycast Instance A · Tokyo AS Path: AS1 → dns-root Anycast Instance B · Frankfurt AS Path: AS2 → AS3 → dns-root BGP sees a shorter path BGP sees a shorter path Client in Asia → Queries Tokyo instance Client in Europe → Queries Frankfurt instance There is no guarantee that two queries from the same client will hit the same instance (unless the same /24 is consistently announced)— but this is perfect for DNS: each query is handled independently.

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

CDN DNS = Traffic Entry Point: Query resolves to the path of the nearest edge node Client Query www.example.com Authoritative DNS Hosted by CDN Check query source IP Select nearest edge PoP Return edge IP Client → edge → CDN edge → backend 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

Related pages

© 2026 liz's doc