I recently asked Rodney Joffe, chief technologist at Neustar, four-decade industry veteran and chair of the Conficker working group, about why he founded UltraDNS and implemented IP Anycast.
Joffe, whose early career involved creating technologies for load balancing and fault tolerance, part of content distribution system …

COMMENTS

Two separate concepts here

Anycast may have the ability to deliver different answers to different queriers, but that is not what happens in the root zone.

When the root zones moved to be mostly hosted on anycast nodes, so that it could better stand up to DoS attacks and provide faster, more local responses, the root servers all still serve up consistent data.

Serving up different answers is usually geo-specific DNS, which is sometimes (not always) implemented using anycast. However there is no requirement for the answers to be different. In the root zones, the answers are all consistent, but served up with anycast.

It is the serving of different answers to different requesters that was considered heresy and was complained about, not the serving of DNS via anycast itself.

Different DNS for different GEOs

The problem I see with different DNS for different locals, is that the user never sends the DNS request to the server that knows about different addresses for different locations. Their request goes to their provider, which may go to another, etc. This is then cached, and given out to anyone else who asks for the address. Given that I may be using a DNS in USA, but am located in Europe means that the idea doesn't work that well!

Perhaps DNS should instead return a series of addresses for a lookup, with some GEO type information for each one, and the USERS system, knowing it's location picks the correct one. In addition, it would allow some resliency for multiply hosted objects in a similar way to a MSlookup; if the first IP address you try does not work, try the second, rather than just failing and giving up.

Sorry for the mixup

I have asked my editor to post this as a footnote to the article.:

While Anycast provides a method for DNS servers to offer the same information to all askers, it is also an enabling technology for both Geocasting of DNS services and Geolocating the requestor. In this way, Anycasting is the technology used by services such as UltraDNS to provide different responses to DNS queries based upon geographic location.

Fantastic Infomercial

I had to support Level3 Europe Anycast DNS 1999-2001. 3 years before the "world supposedly seeing the light" according to this article. It was brought there from Level3 USA where it was in use even before that and unless I am mistaken Raul Alcala who now works for Google brought it there from MCI from even before that.

I also designed the local EU variety anycast radius for them for a while as well as did a couple of strawman redesign proposals for the DNS to improve it and make it more stable around the same time 1999. Once again - USA was there before us by a couple of years.

Providers who have a clue have been running shared address anycast LONG before Ultra DNS. There is nothing particularly heretical about the practice and there is even an RFC on it. RFC3258.

@Anton Ivanov

The dust-up between re: Rodney and the DNS geolocation/geocasting/anycast bit was, if I understand correctly, pre-UltraDNS. It was sort of what made him start UltraDNS. The timeframe he gives for the arguments taking place was 1998ish.

I really wish there was room in this article to include this level of detail...but sadly they do have word limits.

DNS shenanigans

Rodney's experience hardly surprises me.

Vixie and his supporters have a historical tendency to viciously attack _anyone_ who criticises the way DNS is operated, or the BIND software.

Nearly 20 years ago, I pointed out a gaping bug in BIND vs RFCs (RFCs state that IP addresses are always 4 decimal numbers, BIND treats 012 as octal, 0x12 as hex and 1234567890 as a decimal) and got roundly castigated for daring to suggest that BIND conform to the RFCs (and its own documentation)

Within 5 years scammers and spammers were using this "feature" to obfuscate spamvertised URLs. It's still there and still being exploited.

Rodney is a great guy but UltraDNS has stagnated

I started a DDoS defense company back in the early 90's called Prolexic. We had a very interesting relationship with UltraDNS. We were a customer and the DDoS attacks we received actually resulted in major pain and outages for UltraDNS. I'm sure their service infrastructure has improved but they are by no means the only solution in town.

For example, their "Sitebacker" (traffic management) product is from the stone ages. When it was initially launched it was a good solution. However, now it's horribly out of date. It was built from the prospective of old static DNS rather than hardcore traffic management.

At 3Crowd (my current new project) we've built basically the most hardcore loadbalancer as a service that competes with Ultra's system, specifically because people need to manage their traffic with more control. We've built our technology to be the brains behind full CDN systems than a simple DNS "is it up or down" tool.

Anyway I am a friend of Rodney's and UltraDNS is a good solution for a lot of companies. If you're looking for something more advanced in the traffic management area, you should talk to a number of different companies.

RTFM

You might want to look at the manpage for inet_addr(), in particular the sections that describe handling of "a", "a.b", "a.b.c" and how the "parts" can be specified. The behavior you're complaining about has existed in inet_addr() since before the DNS existed.