[dns-operations] Anycast vs. unicast NS

Elmar K. Bins elmi at 4ever.de
Mon Mar 21 10:32:02 UTC 2011

Re Jim,

Bill has already said quite a bit about this topic, but...

jim at rfc1035.com (Jim Reid) wrote:

> >Aren't all of these differences dependent on the number of servers, rather than 
> >whether they're anycast or unicast?
> No Bill. I was/am specifically referring to the special sauce that goes on inside an 
> anycast node and then to assimilate that node into the anycast cloud. I hoped that 
> was clear from my previous posting. Oh well...

Interesting that you see it that way - seems to be you have some "specialised"
experience with anycasted nodes. We (.de) run the unicast nodes *exactly* the
same as the anycast nodes (except that the unicast service prefix is part of
the transit's PA space). So there's nothing added, BGP is straightforward,
monitoring is easy internally (out of band) and difficult externally (as expected),
but not impossible. I see no additional SPOFs at anycast nodes I would not
have at the unicast nodes. To me it feels exactly the other way around: In
the case of a not-replicated unicast node (with another one on standby or
active load-balanced duty, that is) I feel the unicast nodes much more prone
to failure due to a "central" component/idea/process failing.

Actually, I believe, keeping this all straight, simple and *exactly* identical
is the only way to go with the whole bunch of servers inside nodes inside "clouds"
that big DNS deployments have to deal with.

> I am saying that an all-anycast solution *is* a SPoF if it's the only DNS service 
> offering that's used: ie sourced from one provider, no matter how robust and 
> redundant their service is. YMMV.

I concur with that, of course. Don't put all your packets inside one prefix.



"Machen Sie sich erst einmal unbeliebt. Dann werden Sie auch ernstgenommen."
							     (Konrad Adenauer)

--------------------------------------------------------------[ ELMI-RIPE ]---

More information about the dns-operations mailing list