Solving Asymmetric Routing Challenges for Anycast DNS Local Nodes

Operating Anycast DNS nodes at Internet Exchanges (IXPs) offers significant resilience benefits, but it also introduces routing challenges that can impact service reliability. In a recent technical presentation, RcodeZero shared operational insights into one such issue: packet loss caused by asymmetric routing in combination with BCP38 ingress filtering, along with an implementation that resolves the problem without requiring changes from upstream providers.

Why Local Anycast Nodes Matter

Local Anycast nodes are nodes without the advertisement of their Anycast prefix via transit links. They are an attractive deployment model for authoritative DNS providers and IX members alike because they vastly improve resilience while reducing latency.

If this clearly has its benefits, it also creates some routing corner cases.

Internet Exchanges are meant for local data exchange. But it can still happen that traffic finds its way to a member for which no return path is found on the same interface.

Responses likely follow then the server's default route, usually the on the management interface. But if the upstream provider performs BCP38 filtering, return packets from the Anycast address on the management interface are then discarded because only the management address is considered valid on that interface. The answer simply gets lost. And since most DNS traffic is in UDP, the Anycast node is not even aware of this.

The resolver subsequently runs into a timeout and usually tries to switch to another authoritative server. The problem is that in some cases they are not fast enough, or they simply don’t do at all or they can’t.

So, from the end user’s perspective this then either result in the best case in increased latency and in the worst case even in non-resolvable zones.

Evaluating the Options

Several mitigation strategies were evaluated:

Request upstream providers to modify their BCP38 policies and explicitly allow the Anycast prefixes.
Add dedicated transit connectivity at the exchange, effectively turning the local node into a fully connected global node.
Introduce a routing-independent tunnel mechanism that forwards affected responses to a global node capable of delivering them correctly.
While the first two approaches may be appropriate in certain environments, both depend on external parties, introduce operational overhead, or incur additional cost.

A Tunnel-Based Solution

RcodeZero chose a solution that remains entirely under its own operational control.

The implementation uses source-based routing with separate routing tables for management and Anycast traffic. When a response cannot be returned directly through the Internet Exchange, it is sent via a GRE tunnel to one of RcodeZero's global nodes, which then delivers the packet to the client using its local transit link.

To further improve resilience, the GRE tunnel endpoint itself is provided through Anycast, enabling automatic selection of the nearest available global node while also providing seamless failover during maintenance events.

Engineering for Reliable Anycast Operations

The presented approach demonstrates how Anycast DNS operators can continue to benefit from local Internet Exchange deployments while remaining fully compatible with BCP38 filtering. By combining Linux source-based routing with Anycast GRE tunnels, RcodeZero eliminates packet loss caused by asymmetric routing without requiring modifications to upstream networks.

As Anycast deployments continue to expand across IXPs worldwide, operational solutions such as this help improve both resilience and user experience while preserving the performance advantages of local DNS nodes.

In this Video you´ll find the lecture held at ORAC45