problem with resolving SOME EXTERNAL domains

mayer mayer at gis.net
Wed Jun 15 13:05:44 UTC 2005


----- Original Message Follows -----
> "mayer" <mayer at gis.net> wrote:
> 
> > ----- Original Message Follows -----
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > 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 www.usno.navy.mil. a +trace" with /etc/resolv.conf pointing to
> a resolver with query-logging turned on.
> 
> dig reports (truncated):
> 
> ; <<>> DiG 9.3.1 <<>> www.usno.navy.mil. a +trace
> ;; global options:  printcmd
>                        33231   IN      NS      L.ROOT-SERVERS.NET.
> [snip]
> ;; Received 436 bytes from 194.83.56.246#53(194.83.56.246) in 9 ms
> 
> mil.                    86400   IN      NS      G.ROOT-SERVERS.NET.
> [snip]
> ;; Received 426 bytes from 198.32.64.12#53(L.ROOT-SERVERS.NET) in 160
> ms
> 
> navy.mil.               86400   IN      NS      NS-NORVA.navy.mil.
> [snip]
> ;; Received 237 bytes from 192.112.36.4#53(G.ROOT-SERVERS.NET) in 286
> ms
> 
> usno.navy.mil.          86400   IN      NS      CHARON.usno.navy.mil.
> [snip]
> ;; Received 145 bytes from 205.56.138.34#53(NS-NORVA.navy.mil) in 90
> ms
> 
> www.usno.navy.mil.      43200   IN      A       198.116.61.213
> [snip]
> ;; Received 161 bytes from 199.211.133.5#53(CHARON.usno.navy.mil) in
> 84 ms
> 
> 
> The query log on the (BIND 8) resolver shows (truncated):
> 
>  XX /..././NS/IN
>  XX+/.../L.ROOT-SERVERS.NET/A/IN
>  XX+/.../G.ROOT-SERVERS.NET/A/IN
>  XX+/.../NS-NORVA.navy.mil/A/IN
>  XX+/.../CHARON.usno.navy.mil/A/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 ...
> 

You didn't specify a nameserver to use so it goes to /etc/resolv.conf
to get one. If you had specified one on the command line (@nameserver)
it would not even have done that.

dig +trace is meant to use the nameserver for all lookups. It just
does iterative queries to that nameserver. dig isn't designed to
do resolution itself. All it can do is ask for a specific piece of
information from a specific nameserver and get an answer back. +trace
makes it ask for each piece one after the other. But all it's doing
is iterating.

Danny
> -- 
>                       Ronan Flood <R.Flood at noc.ulcc.ac.uk>
>                         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