problem with resolving SOME EXTERNAL domains

Ronan Flood ronan at
Tue Jun 14 17:41:30 UTC 2005

"mayer" <mayer at> wrote:

> ----- Original Message Follows -----
> > Hash: SHA1
> > 
> > | (Question to group/list: does dig 9.3.1 rely on the configured
> > resolver, | using gethostbyname or similar, to resolve the NS names to
> > addresses, | ignoring any glue A in additional sections?  I've seen
> > something that | does)
> > 
> > dig does rely on a well maintained /etc/hosts file :)
> That would come as a big surprise to the BIND development team.
> dig and all of the other tools don't know or care about the
> /etc/hosts file and wouldn't look at it. DNS was developed
> to replace /etc/hosts files.
> dig only looks at the /etc/resolv.conf if it needs to find the
> nameserver to use (if not defined on the command line) and only
> looks at the rest of the content if requested to.

Well in answer to my question, I've just built dig 9.3.1 and tried
"dig a +trace" with /etc/resolv.conf pointing to
a resolver with query-logging turned on.

dig reports (truncated):

; <<>> DiG 9.3.1 <<>> a +trace
;; global options:  printcmd
.                       33231   IN      NS      L.ROOT-SERVERS.NET.
;; Received 436 bytes from in 9 ms

mil.                    86400   IN      NS      G.ROOT-SERVERS.NET.
;; Received 426 bytes from in 160 ms               86400   IN      NS
;; Received 237 bytes from in 286 ms          86400   IN      NS
;; Received 145 bytes from in 90 ms      43200   IN      A
;; Received 161 bytes from in 84 ms

The query log on the (BIND 8) resolver shows (truncated):

 XX /..././NS/IN

So dig +trace *is* querying the resolver for the addresses of the
intermediate nameservers on the descent from the root, rather than
using any associated glue.  Is there any way to override this and
force dig +trace to do *all* the resolution itself?  If not, perhaps
there should be ...

                      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