Anycast Vs. Unicast: The Skinny on Nameserver Routing

01.11.2012 By

Home » Blog Home » DNS » Anycast Vs. Unicast: The Skinny on Nameserver Routing

You’re the guy/gal charged with making sure your business’ web site and ecommerce storefront are running nice and fast, so you run a quick waterfall chart on your site and learn that DNS is limiting your site’s performance. You jump on the Internet, do some Google searches and learn about this thing called Anycast DNS.

You then follow some more links and learn about another thing called Unicast DNS. You read people talking about having both and others talking about having one or the other. You can’t really decipher between the two because there’s hardly any accessible documentation about it. I’m going to break this mystery down for you in this post, kicking it off with a simple guidance statement:

It’s all about the routing, redundancy and geography.

Overview

Dyn Anycast

The Dyn Anycast Network

In a traditional Unicast DNS architecture, authoritative DNS servers (ADNS) are deployed in single server units or clusters in disperse geographic locations. Each delegation hostname / IP address maps to a single physical location, with one or more servers providing ADNS service.

Load balancing and redundancy is achieved within the site using traditional server load balancing techniques. No matter how Internet routing changes or where you connect to the Internet from, you will be taken to a specific nameserver in a specific location.

The network design for Unicast DNS is straightforward, simple to implement and is simpler to maintain than an Anycast DNS implementation. Dyn’s Standard DNS service is setup this way. The key point here is that if you traceroute to these hostnames, you will always be taken to the nameservers in the geographic locations indicated here:

  • ns1XXX.dns.dyn.com is located in Amsterdam, NL
  • ns2XXX.dns.dyn.com is located in Hong Kong, HK
  • ns3XXX.dns.dyn.com is located in Newark, NJ
  • ns4XXX.dns.dyn.com is located in Palo Alto, CA

In a modern Anycast DNS architecture, ADNS “instances” are deployed globally with multiple copies of each ADNS server located in many geographically dispersed locations. Just like Unicast DNS, each instance is referenced by one hostname / IP address, but instead of a single server in a single location, there’s multiple copies of the ADNS servers in multiple locations all over the world.

By playing a trick with global Internet routing (known as the Border Gateway Protocol or BGP), an implementation of Anycast DNS allows for multiple servers to sit behind a single IP address. Dyn’s DynECT Managed DNS platform is set up in this fashion with each ADNS instance mapping to many physical sites:

  • ns1.pXX.dynect.net is mapped to 17 global data centers
  • ns2.pXX.dynect.net is mapped to 17 global data centers
  • ns3.pXX.dynect.net is mapped to 10 global data centers
  • ns4.pXX.dynect.net is mapped to 9 global data centers

Benefits Of Anycast

The benefits of a modern Anycast DNS architecture are significant. First, there’s the overall redundancy that each nameserver instance achieves by distributing DNS service for the same IP address across multiple data centers. If there’s a problem with an instance, that’s fine. Just pull it out of production Anycast DNS, fix it and re-inject it into the service.

Second, a global distribution of ADNS nameservers significantly reduces the latency for users to reach / obtain a DNS response when connecting to a site because of the distributed nature of the network. Coincidentally, this decision ends up being made at the network layer — not at the DNS application layer — which helps to abstract certain issues with certain RDNS implementations. This means users automatically get routed to the fastest available DNS servers automatically.

Finally, Anycast DNS gives us information about the topology of the Internet, enabling advanced services such as DynECT Traffic Management.

Let’s break it down. Anycast DNS, Unicast DNS or both?

If you have requirements for a highly available, low-latency DNS service with advanced traffic routing features, you want to go with an Anycast DNS solution, no matter what. If you are looking for a robust DNS service but global latency and advanced services are not important for your application, Unicast DNS will meet your needs and help you save money.

The combination of using both Anycast DNS and Unicast DNS at the same time for a domain is an interesting intersection of techniques. The reason for doing so is to compromise between the complexity tax and performance reward of an Anycast DNS network against the simplicity and ease of robustness of a Unicast DNS network.

For Anycast DNS architectures, there’s significant cost in deploying the required number of data center locations and underlying network topology in a global fashion. To be able to withstand distributed attacks against the DNS infrastructure, these systems must be deployed homogeneously across all sites with each site able to handle as much of an attack as the next.

This is why some providers deploy a mix of Anycast and Unicast DNS as it helps control cost while providing a robust infrastructure in a few key sites. During an attack, this can mean that users in the degraded region will experience additional latency while their queries get answered from the further away Unicast DNS sites.

At Dyn, we believe a pure Anycast DNS architecture is the best option for deployment, especially for a service such as DynECT Managed DNS.

The redundancy, coupled with network level latency reduction and the ability to offer advanced services via our Anycast DNS network, is paramount to the value we offer to our clients. We deploy our network in a robust fashion globally designed to fend off attacks. In the event of a significant attack, we have developed a specialized set of routing techniques which can be used to “convert” certain instances of our Anycast DNS nodes to Unicast DNS nodes in the event more horsepower is needed.

With all that said, I’d love to hear your questions about Anycast and Unicast in the comments section below.

Related Posts

Tom Daly is the CTO of Dyn, the Internet IaaS Infrastructure-as-a-Service leader that specializes in Managed DNS and Email Delivery. Follow on Twitter: @TomDynInc and @dyninc.

Enjoyed this post? Share It!

  • Roger D. Parish

    Clear as mud. :-(

  • http://twitter.com/sebas0816 Sebastian Brynx

    “playing a trick with BGP”… that somehow sounds dangerous. Or at least as unintended use. Can you clarify this?

    • http://twitter.com/tomdyninc Thomas Daly

       Sebastian,
      Not so much a trick with BGP, I suppose, but a general trick of how we internally route the address space. The key with anycast is same data, same servers, same responses, and stateless throughout the network. Actually, from a BGP perspective, we just look like a big backbone.

  • corentin barbu

    very helpful to me thank yoy.

  • Mark Bryant

    Is the Anycast DNS server network subject to modification (either forced or voluntary) of lookup information by other entities?

    Thank you for the information on Anycast DNS. The article is very informative.  

    • http://dyn.com/ Jeremy Hitchcock

      “subject to modification”?  Anycast bases decisions on network topography and some providers have interesting relationships so the answer is kinda yes.

  • David Ponzone

    I don’t think the trick is that difficult. They just announce from all their border routers a, probably small but not too small, prefix containing all their nameservers. This way, every client sending a request will always go through the shortest path its ISP sees. For failover, they just have to stop announcing the prefix from the site where they need to stop the service.

    I just checked by resolving ns1.pXX.dynect.net and they actually use 4 /24.

    Nice idea, but guys, if one day, ISPs start not accepting /24s anymore in a general manner (we are hearing about that for at least 10 years), big trouble :)

    • http://dyn.com/ Jeremy Hitchcock

      That is true but /24 seems to be where things are staying.  It’s an issue for IPv6 since the block sizes are so big (/48 seems to be where things are right now)

    • http://twitter.com/tomdyninc Thomas Daly

       David – additionally, we announce aggregates of our anycast routes as well (/23s and /22s). It helps cover this situation should it become a problem. However, a /24 has been a generally accepted maximum prefix length in eBGP for decades now – somehow I don’t think this is going to change.

      As Jeremy points out, in IPv6, it seems like the border is going to fall at /48, but it has been as large as /32.

  • Guest

    Would the complexity of a large anycast network make it more difficult to detect an active bgp mitm attack?  There will be so many AS announcing the anycast address space anyway, that it may be a pain to monitor if a new announcement is bogus or not.

    • http://dyn.com/ Jeremy Hitchcock

      It depends but for us it doesn’t matter since all of our monitoring is super distributed (on-net and off-net).  The monitoring is really tricky to get good information but the BGP MITM would probably come up the same way.

    • http://twitter.com/tomdyninc Thomas Daly

       In addition to the monitoring that Jeremy mentioned, we also actively grok BGP data from the Internet at large looking for people trying to hijack routes. If they do, an alarm goes off, and we have ways of dealing with it.

  • Rvandervort

    I find all this confusing to say the least, can you try a write up for dummies? Also, is there also another factor such as authority to issue a domain versus submit a customer request to an authoriy for approval?