DNS traffic steering and anycast

DNS can do more than return one fixed address. The authoritative server can choose the answer for each lookup, based on who is asking, how healthy each target is, or how the traffic should be split. This is traffic steering. It is cheap, global and coarse: the answer is cached by resolvers, so routing changes lag behind.

Anycast works at a different layer. It doesn't change the DNS answer. It announces one IP address from many places on the internet, so routing sends each user's packets to the nearest location.

Routing policies

The DNS provider picks an answer according to a policy:

Two details matter. Geolocation usually sees the resolver's address, not the user's. A user on a public resolver far from home may be routed by the resolver's location. Also, every policy is subject to caching: the TTL decides how fast a weight or failover change reaches users, so a failover set at 300 seconds takes at least that long to act.

Health checks are the part that makes failover real. The provider must probe the target, and it should drop an unhealthy answer quickly. Check that the health check tests the service, not just whether a port answers.

Anycast

With anycast, the same IP range is announced from many data centers. Routers use BGP to send each packet along the shortest path to whichever location they reach. The user doesn't choose; the network does.

Anycast suits stateless, short-lived traffic such as DNS resolvers, CDN edges and DDoS absorption. Spreading attack traffic across many sites limits the damage to any one of them. The drawback is less control. You can't easily pin a user to a site, and a routing change can move a user's traffic mid-session.

That is why anycast is often combined with TCP-based protocols carefully. A route flip can break a long connection, so keep sessions short or stateless at the edge.

Where steering stops

DNS steering works at the granularity of a name. It can't split traffic within one connection, and it can't react in seconds. For fast failover between servers in a region, a load balancer with health checks is the right tool. DNS sends users to the right region, and the load balancer picks the server.

Common mistakes

• Expecting a failover to take effect in seconds when the TTL is 300 or more.
• Using geolocation to enforce legal boundaries, when resolvers may be far from users.
• Running anycast for a service that holds long TCP sessions, then being surprised by mid-session route changes.

Check yourself

• Why does a 300-second failover take minutes to protect users, not 300 seconds? Answer: after the health check fails, resolvers still hold the old answer until their cached copy expires, and some enforce longer minimums.
• How does anycast send users to different sites with one IP address? Answer: routers use BGP to announce the same prefix from many places, so each packet follows the shortest route to a nearby site.

Key takeaways

• DNS steering chooses answers by policy: weight, location, latency, health or random spread.
• Anycast sends one IP address to the nearest site through BGP routing.
• DNS steering is coarse and cached. Use load balancers for fast, per-request failover.

Further learning

Next, see DNS outages and ndots for how DNS failures spread across services.