[dns-operations] Anycast vs. unicast NS

[Warren Kumari]

On Mar 18, 2011, at 11:18 AM, David Miller wrote:

> On 3/18/2011 8:32 AM, Jim Reid wrote:
>> 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.
> 
> OK.  I'll bite.  Please provide exactly what the "single point of failure" is with anycast that isn't present in unicast?

Erm, reaching here....

Anycast nodes should have a daemon that performs healthchecks against the nameserver daemon(s) and withdraw the route if the node is no longer able to answer queries (to prevent blackholing of queries). This code does not exist in unicast instances, so this *code* could be considered (distributed) single point of failure that doesn't exist in unicast (hey, I did say I was reaching!)...

I've actually seen this happen in practice on an anycast setup...
Fairly standard layout -- healthcheck on nodes injects a /32 into local OSPF instance, local router redistributes  (with distribute list) OSPF into BGP, so cluster will only announce an anycast /24 if there are usable nodes. Obviously a few different /24s, etc...

Of course, the healthcheck code uses something like `dig +short example.com | grep 192.0.2.1` for the healthcheck.... Guess which domain expired? Yup, that's right...


W

[ Not claiming that this is a reason to keep unicast boxen around, that this was a good healthcheck, etc, rather trying to answer the question ]

> 
> 
>> 
>>> 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? :-)
>> _______________________________________________
>> dns-operations mailing list
>> dns-operations at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> 
> 
> -- 
> -___________________________________
> David Miller
> Tiggee LLC
> dmiller at tiggee.com
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>