Re: Strange BIND9 issue

In article <cs2220$3lv$1@sf1.isc.org>,
Brad Knowles <brad@stop.mail-abuse.org> wrote:

> At 7:42 PM -0600 2005-01-11, Will Yardley wrote:
>
> > radon: 04:56pm# while true ; do dig yahoo.com @66.33.216.127 | grep
> >Query ; done
> > ;; Query time: 790 msec
> > ;; Query time: 868 msec
> > ;; Query time: 753 msec
> > ;; Query time: 798 msec
> > ;; Query time: 982 msec
> > ;; Query time: 1178 msec
> > ;; Query time: 1284 msec
> > ;; Query time: 1291 msec
> > ;; Query time: 1208 msec
> > ;; Query time: 738 msec
>
> You're completely by-passing the local caching BIND nameserver
> here. You're going directly the the nameserver specified in the
> command line, and the local copy of BIND is not involved at all.
> Unless that is the public IP address of your machine, but then
> queries to 127.0.0.1 or the public IP address should be going to the
> same copy of BIND running on the same machine, and I don't understand
> why this would result in the kind of difference you're seeing.

Isn't that the point of his question?

When I was at Genuity, we were seeing a problem like this at one time.
Our servers implemented anycasting; if you queried the virtual address
that we advertised to customers, response was poor, but if you queried
the machine's real address you always got an immediate response
(assuming the answer was already in the cache).

The problem appeared to be that the OS (Solaris 2.6 was what we were
running then) had separate queues for each logical interface. So the
queue for the address that all the customers used was long and
overflowing, while the queue for the machine's real address was
practically empty.

This was happening when we were growing our DSL service, so we solved
the problem by assigning additional virtual IP addresses to the servers,
and having the DSL DHCP servers give these out, while our leased-line
customers continued to use the old virtual addresses.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***