Problem resolving a domain on my cache server. (part II)

Ronan Flood ronan at
Wed Mar 23 17:07:27 UTC 2005

"Fabiano Silos Reis" <fsilos at> wrote:

> I know what you mean. The problem is that my cache server keeps
> resolving for a while but somehow from time to times this host
> ( cannot be resolved by my cache server (my server
> answer with timeout responses). But when this host cannot be resolved by

When this happens, what does your server show for

dig ns +norec
dig a +norec
dig a +norec

I mean, does it still have the information about how to get to the
record for

> my cache server I setup a script that dig this host directly from their
> two ns
> dig -b mycacheserver_ip_address#the_same_src_port_namded_is_using
> @
> dig -b mycacheserver_ip_address#the_same_src_port_namded_is_using
> @
> I get positive answers. So I suppose it is not communication fault or
> their fault.
> Don't you think my cache server daemon may be losing something when it
> tries to resolve this specific host?

One thing I notice is that on a direct query, their nameservers do not
return authority and additional records for the NS/A:

% dig @ a +norec

; <<>> DiG 9.2.3 <<>> @ a +norec
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23575
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;           IN      A

;; ANSWER SECTION:    3600    IN      A

Could that be significant?  Also the records they do actually have:

% dig @ ns +norec

;; ANSWER SECTION:        3600    IN      NS        3600    IN      NS

;; ADDITIONAL SECTION: 3600 IN      A 3600 IN      A

have different TTLs from the delegation records:

% dig ns +norec

;; AUTHORITY SECTION:        86400   IN      NS        86400   IN      NS

;; ADDITIONAL SECTION: 86400 IN     A 86400 IN     A

which might cause problems.  I assume the upper/lowercase differences
are not relevant.

On a BIND 9.3.0 server here, when I do an initial query for I get

;; ANSWER SECTION:    3600    IN      A

;; AUTHORITY SECTION:        86399   IN      NS        86399   IN      NS

i.e. the NS records from the delegation.  BIND obviously has, or
had, the A records too, in order to get to,
but does not include them as additional, and does not respond to
a direct query:

% dig a +norec

;     IN      A

br.                     31117   IN      NS
br.                     31117   IN      NS
br.                     31117   IN      NS
br.                     31117   IN      NS
br.                     31117   IN      NS

                      Ronan Flood <R.Flood at>
                        working for but not speaking for
             Network Services, University of London Computer Centre
     (which means: don't bother ULCC if I've said something you don't like)

More information about the bind-users mailing list