On 10/21/10 08:26, Gordon A. Lang wrote:
It is actually counter-productive to have two resolvers configured
with this architecture, but to circumvent human nature, we publish two.
There is absolutely no functional difference between the two, and
there is no redundancy value for the second one -- they are both
hosted on each and every one of the any-cast servers. The only
reason for the the second resolver is to deter people from making
up their own second resolver -- people expect two resolvers, and
if you give them only one, they will go ahead and put something in
as the second resolver -- even if you tell them not to. This is a
very important aspect of having the architecture succeed in our
environment.
I mentioned this in another thread (perhaps on another list!), but there
are reasons you might want to have two separate redundant anycast clouds
and configure two servers in client stub resolvers.
Background: We have been doing anycast within our OSPF IGP since 1999
for DNS. Initially, we announced all resolver addresses from one set of
anycast servers, and each server advertised all configured addresses (we
had 4 back then for historical reasons). On very rare occasions, we
would have a weird error where a system would be unable to fork new
processes (such as the cron script to verify health of the server) or
the kernel would get into a weird bogged-down state where named would
effectively stop working but the system wouldn't get taken out of
routing. (That one turned out to be a kernel bug.) Clients within the
anycast catchment of such a server would be stuck talking over and over
to the same broken server. We now have two separate sets of anycast
servers so that the resolvers can still fail to a different set of
servers as a last resort. Having the stub resolver's own failover
mechanism in place provides an extra layer of protection, provided you
have separate anycast clouds. This is now considered a best practice.
See slide 38 of Woody's presentation here:
http://www.pch.net/resources/papers/ipv4-anycast/ipv4-anycast.pdf
michael
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
