[ednog] anycast DNS

John Kristoff jtk at northwestern.edu
Tue Apr 5 19:59:27 EDT 2005

On Tue, 5 Apr 2005 17:26:42 -0500 (CDT)
Jay Ford <jay-ford at uiowa.edu> wrote:

> I'm also thinking about cases where named is still running but not answering
> queries for whatever reason.  That would require killing the routing if named
> failed to answer a test query.  I guess a loop containing

I asked Joe Abley about this awhile back and his response was:

  "We rely on BIND 9's named to exit if it ever becomes inoperative;
  this turns out to be a reasonable way of carrying on, since BIND 9
  is   designed to behave that way if any internal checks fail."

So apparently they don't (or didn't) do anything automated to handle
that case at F-root.  I've not seen BIND become inoperative that I
recall either, but I imagine it's possible you or someone else has.

The one possible exception I've witnessed is when a recursive server
receives a high rate of recursive queries within a small timeframe,
overrunning the recursive query rate threshold.  Even then that isn't
inoperative per se.  Presumably that can be addressed through design
and tuning.  Though if you've seen hosts making excessive recursive
queries (and if you haven't then you haven't been looking :-), you
may be pleased to know that the BIND folks have in front of them a
feature request to do some kind of congestion control on recursive
queries.  I don't know what form this would eventually take, but for
example, the server may be able to rate limit per host or perform
some kind of RED-based dropping of recursive queries.

>    host -t a ${q_name} ${serv_addr} || ifconfig ${interface} down
> would about do the trick.

That sounds like it could work.  Maybe also make a special RR on
some other authoritative server with TTL equal to 0 so that it will
never be cached, forcing the server under test to always go fetch it.
Although if link to just that other server is down, the test will
fail in that scenario also and that may not be what you want.  :-)


More information about the ednog mailing list