GeoDNS and DNS Load Balancing

Ways to steer traffic with DNS

Plain round robin needs no special software; any authoritative server can return several address records. Clients usually try the first address and fall back to the others, but the order is not something to rely on, because resolvers may reorder or cache a single ordering. The other methods need an authoritative service that evaluates rules per query, which is why they are usually offered as managed DNS features or by CDNs. For how CDNs combine these methods with their own networks, see How CDNs Use DNS to Route Users.

How the location is decided

The authoritative server never sees the user’s device. It sees a query from a recursive resolver. Without extra information, it maps the resolver’s address to a location using an IP geolocation database and answers for that location. This works well when users rely on their ISP’s nearby resolver. It works poorly when users send queries to a distant corporate or public resolver, because everyone behind it looks like they are in the resolver’s city.

RFC 7871 defines EDNS Client Subnet (ECS) to close that gap. A resolver that supports ECS includes a shortened version of the client’s address, such as the first 24 bits of an IPv4 address, in an EDNS option on its query. Resolvers send ECS selectively: many send it only to authoritative servers known to use it, some never send it for privacy reasons (Cloudflare's 1.1.1.1 does not), and an authority that does not support ECS ignores it. When ECS is present, the authoritative server uses that subnet for its decision and replies with a scope prefix that tells the resolver which clients the answer may be reused for. The option itself is carried in the EDNS OPT record described in EDNS, Large Responses and TCP Fallback.

ECS has costs. It reveals part of the user’s address to every authoritative server the resolver talks to, and it fragments caches, since one name may need a separate cached answer for each subnet. RFC 7871 itself discusses these privacy concerns, and some public resolvers choose not to send ECS at all. When planning GeoDNS, assume a share of your users will be located by their resolver only.

Seeing different answers with dig

You can test a GeoDNS setup by asking an authoritative server directly and supplying a client subnet yourself with the +subnet option. Servers that ignore ECS will answer the same each time.

$ dig @ns1.example.com www.example.com A +subnet=198.51.100.0/24 +noall +answer +comments
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; CLIENT-SUBNET: 198.51.100.0/24/24
;; ANSWER SECTION:
www.example.com.   60  IN  A  198.51.100.10

$ dig @ns1.example.com www.example.com A +subnet=203.0.113.0/24 +noall +answer +comments
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; CLIENT-SUBNET: 203.0.113.0/24/24
;; ANSWER SECTION:
www.example.com.   60  IN  A  203.0.113.10

$ dig @ns1.example.com www.example.com A +noall +answer
www.example.com.   60  IN  A  192.0.2.10

The third number in the CLIENT-SUBNET line is the scope prefix returned by the server. The last query, sent without ECS, is answered based on your own resolver’s or machine’s address. Comparing answers from several networks is the most reliable way to confirm that each region gets the endpoint you expect.

Limits of DNS-based balancing

Caching sets the reaction time

Every answer is cached for its TTL by the resolver, and browsers and operating systems may keep addresses for the life of a connection or longer. That is why GeoDNS records usually carry short TTLs, often 30 to 300 seconds. Shorter TTLs mean faster failover but more queries. Even so, failover is never instant. DNS TTLs and Caching Explained explains how those timers interact.

DNS sees queries, not load

One resolver may represent a single home or a million mobile users, so balancing by answer count is coarse. DNS can spread traffic between sites, but sharing load evenly among servers within a site is the job of a load balancer; see Load Balancers: Layer 4 vs Layer 7.

Health checks are only as good as their probes

A health check that tests a single URL from one location may keep a broken region in rotation, or remove a healthy one after a network blip between the checker and the site. Check from several places, and test what users actually depend on.

Anycast is the other approach

Anycast publishes one address from many sites and lets BGP routing choose the nearest one. It does not depend on resolver location or TTLs, but you have less control over which site a user reaches. Many providers use anycast for their DNS servers and GeoDNS for the answers they give. DNS Anycast Explained compares the two in more depth.

Design tips

• Always define a default answer for locations that match no rule, and make it a healthy, well-connected site.
• Keep the same record types in every region. If one region has AAAA records and another does not, IPv6 users will see inconsistent behavior.
• Use GeoDNS for public names only. For different answers on internal and external networks, use split-horizon DNS instead, covered in Split-Brain DNS / Split Horizon.
• Document which regions map to which endpoints, so on-call staff can explain why two users see different addresses.

How DNS Panopticon helps

Domain Visualizer resolves names through Cloudflare and Google DNS-over-HTTPS resolvers, so it shows the answer those resolvers received. For a GeoDNS name, that answer reflects how your rules treat those resolvers and may differ from what a particular user sees. That is expected, not a fault. Visualizer also caches scan results for 24 hours by default, configurable by the administrator from one minute to seven days. This application cache is independent of DNS record TTLs: rescanning after a record’s TTL expires may still return the saved scan. Wait for the configured scan cache to expire, ask an administrator to purge it, or query the authoritative name servers directly to verify a new change.

Website Recon looks up the network and AS number behind each resolved address and detects when a name is fronted by a CDN, which helps confirm that an endpoint belongs to the provider you meant to use. Compare those results with dig queries run from your own networks to build a complete picture.