[dns-operations] How to get the anycast networks?

Bill Woodcock woody at pch.net
Tue Oct 16 02:48:45 UTC 2012

On Oct 14, 2012, at 4:36 AM, "Patrick W. Gilmore" <patrick at ianai.net> wrote:
> First, is it possible to anycast your name servers (or anything else) without your own ASN.  You'll need a /24 (at least) of your own, and you'll need to convince multiple providers to announce it, but it can be done.
> This will result in your prefix showing up as "inconsistent origin". That doesn't mean anything, and doesn't break anything.  That won't stop some people telling you it is broken, so be prepared.
> Please note that though it /can/ be done, think carefully about whether it /should/ be done.  Anycast is useful, a powerful tool in the right hands, but it can also have unintended consequences.  For instance, I have seen users in London go to anycast instances in Tokyo because of poor design & deployment.  Of course, the same thing can - will - happen with unicast.  But you do not want to go through the time & effort of anycasting your name servers for zero performance gain, or worse.

Following on to Patrick's answer, which is entirely correct…

Getting your own ASN will make your negotiation with transit providers easier and simpler, because you'll fit into their model.  If you use your own ASN, you want to use it everywhere, and not mix-and-match, because doing so will make the locations where you use it less attractive by one hop than those where you don't.

The big problem comes if you select different transit providers in different locations.  That's what Patrick is alluding to when he says that London queries can be directed to Tokyo servers…  Network operators will always deliver to a customer rather than a peer, even if they have to haul halfway around the world to do so.  The consequence of this is that if you have transit at an anycast location, it has to have exactly the same transit provider (or transit providers, plural, if you can find an exactly overlapping set) at each location.  That can make for difficult vendor selection.


More information about the dns-operations mailing list