[dns-operations] Anycast vs. unicast NS

[Shane Kerr]

Giles,

On Fri, 2011-03-18 at 11:33 +0100, Gilles Massen wrote:
> On 03/18/2011 11:13 AM, Shane Kerr wrote:
> 
> > Having a fewer number of entries in your NS RRSET and making those
> > highly anycast should result in a better user experience than having
> > more unicast servers. This is because resolvers don't have to go through
> > as much pain figuring out the best RTT, as the routing system has
> > already done that work.
> 
> I don't think that's true: routing doesn't care for TTL but for shortest
> AS path. Once your packet hits one of the large Tier-1 ASs, all bets are
> of as on which anycast node it will end...

In principle you're right, although in practice I see quite good
correspondence between physical location and routing topology.

It also depends on the scope of your anycast setup. If I have anycast
nodes on a continental scale, then you will see tremendous gain. Packets
to California take longer than packets to the UK if you're sitting in
Amsterdam, and the hop count matches that. If your anycasting is much
more fine grained with perhaps tens or hundreds of sites - like I think
PCH and Verisign do - then you're going to spend a lot of time tweaking
routing to make sure people get the best results. (Of course, with that
large number of nodes, you simply can't use unicasting, so it's probably
almost always better in that case too.)

> > It's magic! And you are probably better off not having unicast at
> > all. :)
> 
> My view is the exact opposite: I'd always keep at least one unicast node
> running: the resolver takes care of not querying it, if it is too slow,
> and it should be visible to anyone, even to those with
> broken/pathological/paranoid routing.

The problem is that if you have, for example, 3 NS in your RRSET and one
of them is unicast and 2 are anycast, then 1/3 of the initial queries
will end up going to your unicast server. If I have the misfortune to be
on the other side of the planet, that could be 1/4 of a second or so of
extra delay.

Yes, this is not *that* big of a delay and it only matters when any
particular resolver is getting RTT information about a particular
server, but I do see it as unnecessary delay and a worse user
experience.

--
Shane