[dns-operations] Anycast vs. unicast NS

Jim Reid 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,  
> and
> that covers ORG, INFO, and a slew of ccTLD and a handful of other  
> gTLD.

Hmmmm.....

> 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  
> on)
> 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  
servers? :-)



More information about the dns-operations mailing list