Strange BIND9 issue

Barry Margolin barmar at
Wed Jan 12 06:09:54 UTC 2005

In article <cs2220$3lv$1 at>,
 Brad Knowles <brad at> wrote:

> At 7:42 PM -0600 2005-01-11, Will Yardley wrote:
> >  radon: 04:56pm# while true ; do dig @ | 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 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 at
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

More information about the bind-users mailing list