What is the difference between Anycast and GeoDNS / GeoIP wrt HA?

Question

Based on the Wikipedia description of Anycast, it includes both the distribution of a domain-name-to-many-IP-mapping across many DNS servers as well as replying to clients with the most geographically close (or fastest) server.

In the context of a globally distributed, highly available site like google.com (or any CDN service with many global edge locations) this sounds like the two key features one would need.

DNS services like Amazon's Route53, EasyDNS and DNSMadeEasy all advertise themselves as Anycast-enabled networks.

Therefore my assumption is that each of these DNS services transparently offer me those two killer features: multi-IP-to-domain mapping AND routing clients to the closest node.

However, each of these services seem to separate out these two functionalities, referring to the 2nd one (routing clients to closest node) as "GeoDNS", "GeoIP" or "Global Traffic Director" and charge extra for the service.

If a core tenant of an Anycast-capable system is to already do this, why is this functionality being earmarked as this extra feature? What is this "GeoDNS" feature doing that a standard Anycast DNS service won't do (according to the definition of Anycast from Wikipedia -- I understand what is being advertised, just not why it isn't implied already).

I get extra-confused when a DNS service like Route53 that doesn't support this nebulous "GeoDNS" feature lists functionality like:

Fast – Using a global anycast network of DNS servers around the world, Route 53 is designed to automatically route your users to the optimal location depending on network conditions. As a result, the service offers low query latency for your end users, as well as low update latency for your DNS record management needs.

... which sounds exactly like what GeoDNS is intended to do, but geographically directing clients is something they explicitly don't support it yet.

Ultimately I am looking for the two following features from a DNS provider:

1. Map multiple IP addresses to a single domain name (like google.com, amazon.com, etc. does)
2. Utilize a DNS service that will respond to client requests for that domain with the IP address of the nearest server to the requestee.

As mentioned, it seems like this is all part of an "Anycast" DNS service (all of which these services are), but the features and marketing I see from them suggest otherwise, making me think I need to learn a bit more about how DNS works before making a deployment choice.

Thanks in advance for any clarifications.

Answer 1

The key benefit of GeoDNS is that it resolves the same name to different IP addresses based on the requester's IP address.

An Anycasted DNS server will return the same IP address regardless of who is doing the asking.

The two work at different network layers. Anycast is below GeoDNS since it has no sense of the requester IP address's location, just its place in the network diagram. What may be close to the DNS server may not be close to the resource being requested, and the Anycasted DNS server has no way to tell this.

GeoDNS uses a map of resource locations and performs logic to determine which of those resources is closest to a given requesting IP address, and then returns that IP address.

Unless you're colocating your DNS servers with your network resources, what's close to the DNS server won't always be close to the resource, so using Anycast as your data-locality method is less effective than straight up GeoDNS.

Answer 2

The BGP anycast aspect lets clients send a request to a given DNS server, and get that request sent to a nearby instance of the DNS server by virtue of the BGP routing table, hopefully getting a quick response.

However, a normal ol' DNS server that's geographically distributed and anycasted does not have the capability of responding to queries differently depending on the requesting client's location - this is the extra feature that those "Geo-DNS" services are providing for extra cost, allowing you to send clients to an instance of a service that's close to them.

The reason for this feature to exist is that BGP anycast works just fine for something stateless like DNS, where it's quick and dirty and needs no connection or session persistence, but for something like a web server, you want to stick instances all over the world and make sure a given client will stick to a specific instance - routing changes in the global BGP table mid-connection would break TCP connections, break web application sessions, and generally cause havoc; anycast is generally not used for web servers for this reason.

It's best to provide a user in county X with an IP for an instance in country X via DNS, which is what you're forking the cash over for with a Geo-DNS service.

Answer 3

Traditionally, you will have multiple DNS servers. A client will pick one at random, and ask it for your web server's IP address. This is good if the DNS server is close to the client, but bad if - as is often the case - the DNS server is far away from the client. Either way, the client will get the same IP address as an answer.

Anycast lets multiple servers respond to the same IP address. With anycast DNS, when a client tries to talk to your nameserver, the closest/fastest nameserver responds. This means that the client always gets a fast response to his DNS query. However, he'll still always get the same answer to his DNS query - the IP of your server. If your server is far away from the client, the client experience may not be optimal.

GeoDNS lets a DNS server respond with a different IP address, depending on where the client is. (Obviously this requires you to have multiple geographically distributed servers.) GeoDNS doesn't imply anycast, although typically you'd deploy both, so that a client ends up getting his DNS query answered by a geographically nearby DNS server, which then replies with the IP address of a geographically nearby web server.