A long time ago in an Internet far away, nobody paid for DNS services. Not directly at least. We either ran our own servers, or got DNS service as part of our IP transit contract, or traded services with others. In ~1990 I was the operator of one of the largest name servers in existence (UUCP-GW-1.PA.DEC.COM) and I exchanged free DNS secondary service with UUNET. Two thousand zones seemed like a lot of zones back then—little did we dream that there would some day be a billion or so DNS zones world wide.

Anyway the decades went by and it turned out that almost everything connected in any way to the Internet was something important enough to pay for. I’ve watched various friends start companies for secondary name service, primary name service, even recursive name service. The standard for my incredulity has steadily risen, I like to think I’m ready for anything now, that nobody could still find some new way to monetize DNS that could still surprise me.

Ok so that was a setup. I’m surprised by something. Companies who want to sell DNS authoritative name services are out there beating each other up with competitive claims about something I would have said was crazy, which is whether it’s better to serve a DNS zone by pure anycast, pure unicast, or a deliberate and somehow necessary mixture of both anycast and unicast.

Now that I’ve seen it, the appeal of this kind of argument is understandable—it’s a subtle and complicated topic, claims on this topic are unprovable and non-falsifiable, and it’s unlikely that your competitors will be willing to change their approach to beat your claims. It’s the perfect market differentiator!

However, it’s more irritating than amusing, especially since one of of the ways my nonprofit employer (Internet Systems Consortium, which you may know as ISC or as “the BIND people”) raises funds for our free software efforts is by selling DNS secondary services (find us on the web at http://sns.isc.org/). Since there’s a good chance that some competitor will try to take a sale away from us on the basis that “ISC SNS uses anycast, and we don’t, so we’re better” I’m going to try to get out ahead of that game and lay down the facts as I see them.

History

In the beginning there was unicast, and it was good enough, because nobody’s revenue stream depended on the resiliency and performance of their DNS. Also because all of the caching recursive servers in the world ran BIND which had even at that time a really cool “server selection” method whereby the best of every DNS zone’s name servers would be found and used by each party doing DNS look-ups.

Later, commerce started. This brought in a lot of other (non-BIND) caching recursive servers who lacked BIND’s server selection methods and thus had the ability to make really bad decisions about which of a DNS zone’s name servers to talk to. This created an opportunity to do something different:

.

Anycast was first used in commercial production by Rodney Joffe in 1997 or so at Genuity/GTE. For the record I started out not liking anycast since I wanted all caching recursive name servers to all have a server selection method as good as BIND’s. Anycast also makes it easier to deploy tricky CDN like features which at the time seemed like really bad ideas to me. I have since grown more sanguine about name servers being both dumber and smarter than I wanted them to be. (The market waits for no man.)

Techie Stuff

To glue itself together the Internet uses distance vector routing. This means the router connected to 192.5.5.0/24 (a block of 256 end-host addresses) tells its buddy routers “hey guys and girls, you can reach 192.5.5.0/24 through me” and they tell their buddy routers and so on until pretty soon everybody knows. In fact (and this is important) most routers hear many different paths to each of these “net-blocks”. Which path each of those far distant routers decides to use depends a lot on their local policy but it usually comes down to using the shortest path they heard or sometimes the first path they heard. What’s really important to note is that they only use one path at a time—fall-backs are fine but multi-path load sharing is just not done unless you’re inside the same network and most likely operated by the same team.

If you built a really strong name server able to answer all of the queries your zone will receive every second and if you built a global backbone network full of private fiber and beefy routers at every peering point on every continent and then you could interconnect with every network at every one of those peering points and use the distance vector routing system to tell everybody to send their traffic for your name server into your network.

There are at least three good reasons not to build name service that way.

First, private fiber and beefy routers are expensive. And once you start cheaping out by buying circuits and virtual circuits you’d lose control over your latency and you’d be subject to over-commit. The most unreliable part of the Internet is OPN—Other People’s Networks. Use them only when you have no better options.

Second, the speed of light is at this moment in history still a constant. So the further someone is from your name server the longer it will take their query to evoke a response and for that response to reach them. If you want high DNS performance then you need low round trip latency and that means putting a name server close to… well, close to everybody. No single name server no matter how well constructed or how powerful its network can be close to more than one part of the world.

Third, there’s an alternative which violates the good, fast, cheap rule (which rule states, you can choose only two.) Anycast: it’s better, it’s faster, and it’s cheaper. Don’t do it for less than all three reasons, but in any case, do it—or buy name service from someone who does it for you.

Anycast uses a loophole in distance vector routing. Instead of having a network (let’s say 192.5.5.0/24 again) with name servers on it (which in this case means F.ROOT-SERVERS.NET) connected to a global backbone with links to every peering point in the world, anycast cuts out the middle part where there’s a server in the middle with a network to the edges.

With anycast you still have to show up at a lot of peering points with a lot of equipment but you don’t need a backbone network and you don’t have one big name server in the middle—you have a lot of littler cheaper name servers installed inside of the peering points themselves. I call this a “loophole” because the networks you are connecting to can’t tell that you don’t have a backbone network. They just see distance vector routing. They don’t know and can’t tell and wouldn’t care that the network you’re advertising reachability for is not a single network in one place but is actually a local copy of a network that exists in many places.

This is faster because the speed of light gets respect and you really are really close to everyone who is sending you queries. This is better because you have a lot of small servers or locally load-balanced clusters of small servers which means you have no single point of failure and few points of visible failure. This is cheaper because you don’t have to pay for a backbone network that you didn’t need and that was just hurting your performance anyway.

Not every zone needs anycast. If you can get unicast name service for free or for trade or for much cheaper than anycast name service and if the opportunity cost of downtime is low because you aren’t driving revenue with your uptime then unicast will probably be fine for you. It was good enough for the whole Internet back before commerce came along, so don’t worry about it. But if your DNS responses really have to get there now for reasons related to business continuity or shareholder value then you will have to receive your DNS requests and transmit your DNS responses as close to the end users as possible. That’s what anycast can do for you.

Diversity

Those of us who have been doing DNS since the 1980’s find it hard to let go of certain ideals like infrastructure diversity. It’s theoretically possible to serve a DNS zone with a single well-anycasted name server, but we won’t. Long ago wise men sagely wrote that there should be at least two name servers for every DNS zone and that these name servers should be as diverse as possible. An interpretationist like myself says that this call for diversity means “please don’t put your only two name servers into the same rack on the same power strip”. On the other hand a literalist (also like myself) thinks this call for diversity means “don’t use a single name server even if it’s really hundreds of name servers hiding behind a single name server name.” Because that would just be creepy.

Other forms of diversity are worth considering. For example for the root zone that is the parent of all top level domains like COM or NET or UK we’ve tried for many years to ensure that they don’t all run the exact same software. It would be bad if a single bug present in all servers could wipe out the whole Internet. Monoclonal architectures are dust-bowl risks. Back when BIND was all there was, we root name server operators staggered our upgrades so that we would never all be running the same version. (Nowadays some of us run BIND and some run NSD.) I’m not sure this degree of care is warranted outside the root zone and I suspect that most TLD operators including VeriSign for “COM” run a single kind of software on all their servers. But it’s an example of how else to think about “diversity”.

Wierd Stuff

Lately I’ve heard indirectly sales pitches about hybrid anycast and unicast. Apparently it’s now being called risky to put all of your eggs into the anycast basket. I expect it goes something like “...and if something goes wrong with all that new fangled anycast widgetry won’t you be glad you’ve got good old fashioned unicast working for you?” My answer would be: no. And not just because anycast has been working fine since the 1990’s.

In a pure unicast or pure anycast service environment a DNS zone has the best and worst of one world and none of the other world. In a hybrid service environment where both anycast and unicast are in use you’re getting the best and worst of both worlds. I’m fine with getting the best of both worlds but it’s that bit about getting the worst of both worlds part I’d say let’s look at more closely.

The worst thing that can happen with anycast is path failure in which case some subset of your customers will think you are down for a short period while the distance vector routing system figures out a new path from them to you. Anycast limits the scope of this risk by limiting the size of the affected subset of customers. Anycast has other risks but this one is the worst since it means you’re losing money. This risk is also present for unicast but it’s not the worst thing that can happen for unicast. Yes, that means the worst thing that can happen with unicast is worse than the worst thing that can happen with anycast.

The worst thing that can happen with unicast is bad server selection which is pretty common among non-BIND recursive name servers although I’m sure that OpenDNS and Google DNS both get it right. Some large subset of your customers are using recursive name servers with really silly server selection methods—never mind why. Whenever these servers pick a unicast server that’s not close to them then your customers will get slower service. This doesn’t sound as bad as failure since they are still getting service, right? It is worse than failure, for two reasons. First, it’s persistent, it happens a little bit all the time, it’s like a slow leak in one of the main fuel lines of your business. Second, there’s no way to detect it or measure it or make investments to limit its effect on your revenue—so, no risk management.

Conclusion

When I was in primary school back in 1968 or so I learned from my experience with painting that if you mix enough colours together you always get “brown”. Perhaps that’s why I’m sensitive on the topic of getting the worst of both worlds. I don’t want the worst of both worlds. I think buyers should make a clear choice based on the costs and risks and benefits available to them and then accept only the best and worst of only the one world they choose to step into.

If it doesn’t matter how many milliseconds it takes for people to look up your web site or more generally for any DNS client to look up one of your domain names, then you’re a candidate for the kind of unicast name service that we all used to do for free or for trade and which many ISPs and ASPs still bundle as an extra if you’re buying something else from them. The domain name I use for my friends and family is REDBARN.ORG and I wouldn’t pay even one more nickel than I had to for that domain’s name service. If it takes some people five milliseconds and others fifty (50) milliseconds and a few as much as a hundred (100) milliseconds—that’s a tenth of a second—to look up my personal domain name, it’s all fine by me. There’s no commerce going on here, when my kids sell girl scout cookies they do it web-free.

If speed matters and you’re in no mood to compromise then use DNS anycast. If you want diversity then buy anycast name services from multiple providers each having a slightly different global footprint. DNS allows you to designate up to about a dozen different name servers for each zone and that is enough space to list several anycast name server names from each of several anycast name service providers. Chances are you only need two name servers if each is well anycasted but what I’m saying is you can have a lot more than two name servers if provider and technology diversity matters to you and you’re willing to pay what that kind of diversity costs.

There is no risk management case to be made for mixing unicast and anycast. As explained above, anycast isn’t some new fangled widget that you should be wary of and should protect against by also using unicast—anycast is well established technology which is the gold standard in DNS content reachability. Anycast’s benefits to your domains would in fact be undercut by mixing in some unicast name servers since this mixture would open the door for simple minded recursive DNS servers to guess wrong about which of your servers is closest to them and to thereby serve your customers poorly.