Anycast DNS — Resilient Scalability for Critical Network Infrastructure Software, Part 1

I recently attended an Infoblox User Group where I was encouraged by some peers to consider using Anycast for DNS. “This sounds too good to be true,” I thought, baffled over the simplicity. After checking out their design I wondered why I hadn’t heard of this before. Since then I have implemented Anycast for our DNS infrastructure and there is no doubt it was a great decision.

In this post I’ll explain why Anycast DNS has been the right choice (and why you should consider using it too!), and in Part 2 I’ll give details on how to implement the solution.

Classic DNS Scenario

Before Anycast, our DNS infrastructure was fairly typical, with multiple DNS servers distributed throughout the network for resiliency and most clients receiving DNS configuration from DHCP with a smaller subset of clients being statically configured.

This design worked fine for many years, but we began to recognize some pain points:

1. The burden of HA and load balancing is placed directly on the client device. How does a device know when one of its configured DNS servers is down? How do you ensure that the client always prefers the closest DNS server on the network? Does the client use the first server configured and move to the next only when it gets no response, or does it randomly pick the next one? Hopefully DHCP is used to issue DNS configuration, but what happens when a client device only uses two DNS servers instead of four? The answers to these questions are often as numerous as client operating systems. In any case, client device behaviors are consistently unpredictable.
2. Keeping track of multiple DNS IPs is tedious and static configuration is not standardized. This may sound trivial, but what if all your ACLs only had to reference one IP address instead of four, six, or even hundreds depending on your environment? What if every time someone came to you and asked “What are our DNS IPs again?” you didn’t have to give them a list of IPs.

Enter Anycast Routing for DNS

Put simply, Anycast Routing is this: multiple routers in your network advertise the same /32 subnet into the network, and when devices communicate with the /32 address the traffic is always routed to the nearest instance of that /32. This /32 is the Anycast address.

For Anycast DNS, just replace the routers in the above example with DNS servers that have a built-in routing process. The diagram below shows only four DNS servers, but the design could easily support hundreds more.

Each DNS server in your network advertises the same /32 subnet, the single IP address you want to use for DNS. When clients send DNS requests to the Anycast address the core network takes care of the rest, sending the request to the nearest DNS server based on the best Anycast route metric.

It’s important to note that Anycast Routing is Anycast Routing, whether it’s for DNS or some other service, like NTP. (In fact, if you use Infoblox for DNS and NTP it also ties the NTP service to the same Anycast address used for DNS.)

Advantages

Simplicity. With Anycast DNS the complexity of the entire DNS infrastructure is presented as one IP address. Routing takes care of high availability and load balancing much better than client devices can.

DNS maintenance is hitless and predictable. With Infoblox, the routing process is aware of DNS process health through internal health checks. This means that anytime DNS encounters an issue or gets shut down, the Anycast route for that server gets removed from the network-wide routing table. Depending on your environment, this graceful removal of a DNS server from production makes server upgrades a mid-day project rather than an after-hours one.

DNS load is more evenly distributed among servers. In some designs ECMP can be used to evenly distribute DNS requests among multiple servers. In our environment, pre-anycast reports taken from DNS logs made it apparent how lopsided the DNS traffic had become, heavily favoring one or two DNS servers out of the four in our environment (I’ll talk more about logging in Part 2.)

DDoS Attack Mitigation. This one pertains more to public DNS deployments, but the idea is the same: if an attack is made against an Anycast address, only the nearest server is affected and can feasibly bounce back after the attack moves on the next nearest server.

Moving Forward

By this point I’m hopeful you can see the benefits of Anycast and how simple the solution can be. I believe one of the great selling points of Anycast is it’s return on investment in time and resources — no new products to purchase and a simple migration path. Check out Part 2 for implementation details.

Contact Me

If you have any questions or comments, feel free to reach out to me on LinkedIn or shoot me an email at bowles.thomas@gmail.com.