Understanding Round Robin DNS

Original Article ↗ Hacker News Discussion ↗

Round-robin DNS—returning multiple IPs for a single hostname—emerges here as a cheap, simple way to spread load and provide basic failover, but one whose reliability depends heavily on how clients and intermediate resolvers honor TTLs and retry behavior. Commenters contrast it with “real” load balancers and Anycast-based CDNs, arguing that DNS-based approaches can work well for tolerant or internal use cases but are risky for high-availability services like e‑commerce. The thread also touches on modern DNS features (health-checked pools, georouting, HTTPS/SVCB records) and notes that providers such as Cloudflare now offer improved failover even on free plans, blurring the line between plain DNS and managed traffic management.

Round Robin DNS vs Load Balancers

  • Many argue DNS round robin (RR-DNS) is fundamentally not a real load balancer: DNS’s job is only name→IP, and once IPs are handed out, behavior is entirely client- and resolver-dependent.
  • Critics say RR-DNS is inadequate for high availability, failover control, and geographic routing; dedicated L4/L7 load balancers or anycast/BGP are preferred where reliability matters.
  • Others counter that RR-DNS can be a pragmatic choice, especially when load balancers are too costly or complex, and that “perfect” reliability is not required for all services.

Client Behavior, Caching, and TTLs

  • Reliability and failover heavily depend on how clients and intermediate resolvers handle:
    • TTLs (some resolvers clamp to minimums like 1 hour; some clients ignore TTLs entirely).
    • Multiple A records (some always pick lowest IP; some don’t retry on failure).
    • Timeouts (refused vs silent hang yields very different user experience).
  • Browsers are generally described as “good enough”: they try multiple IPs and fail over quickly; many non-browser or legacy clients are described as buggy or overly cache-happy (e.g., older Java, some Go HTTP/2 / gRPC behavior, embedded devices).

Use Cases and Context

  • Several commenters note RR-DNS is acceptable or even excellent when:
    • You control clients and can implement smart retry / fallback IP logic.
    • The service can tolerate occasional or slow failover (e.g., free/public APIs, internal systems, training environments, SSH endpoints).
  • For e‑commerce or revenue-critical services, even a small fraction of users failing due to DNS quirks is seen as unacceptable and hard to measure.

Anycast, GeoDNS, and Cloud Providers

  • Large CDNs successfully use DNS-based approaches, often combined with anycast and sophisticated geo-routing.
  • Anycast is seen as ideal but out of reach for many small operators due to BGP, IP space, and operational complexity.
  • Some build custom DNS backends (e.g., with PowerDNS) that do health checks, weighted/geo RR, and failover on the DNS layer, often with low TTLs (~30–60s).

Cloudflare-Specific Behavior

  • Discussion highlights Cloudflare’s DNS+proxy model, its load balancing product (with monitors, affinity, and failover), and a feature gap between free and paid plans regarding “zero downtime failover.”
  • After the thread, Cloudflare changes behavior so free accounts also get automatic failover behind their proxy, and the original tests are reported to pass.

Alternative DNS-Based Approaches

  • SRV records are discussed as a better-designed mechanism (priority/weight), but HTTP never officially adopted them.
  • New HTTPS/SVCB records offer SRV-like functionality plus TLS/bootstrap benefits and better handling of apex domains; adoption status is still emerging.