[dns-operations] Anycast vs. unicast NS
jim at rfc1035.com
Fri Mar 18 12:32:42 UTC 2011
On 18 Mar 2011, at 10:13, Shane Kerr wrote:
> IIRC, all of Afilias' authoritative servers are anycast these days,
> that covers ORG, INFO, and a slew of ccTLD and a handful of other
> Other than the usual problems with anycasting in general (where *did*
> that query hit, whoops one of the hosts at node X is behind, and so
> I can't think of any special problems with such a setup.
Well if all the DNS servers are anycast, that in itself becomes a
single point of failure. Which is probably not a Good Thing. Although
anycasting is inherently very robust it does however introduce new
failure modes that wouldn't otherwise be there. Even if those failures
are highly unlikely. So having everything anycast means there would be
no backup if/when one of those once-in-a-lifetime (tm) failures happens.
> 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.
... until Something Bad happens to the anycast provisioning. eg Too
much route flapping upsets BGP implementations, fat finger syndrome at
an anycast node or cluster, etc.
I agree with you Shane that a smaller NS RRset with highly anycast
servers is a Good Thing. However this does not mean that should
completely displace a zone's unicast servers. Some diversity in how
DNS is provided would be better IMO. Even if the zone's anycast
servers end up handling most (all?) of the query load.
> It's magic! And you are probably better off not having unicast at
> all. :)
In the same way that a TLD would be much better off only using a
single DNS implementation and just one hardware/OS platform for its
More information about the dns-operations