problem with resolving SOME EXTERNAL domains
ronan at noc.ulcc.ac.uk
Tue Jun 14 17:41:30 UTC 2005
"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.
;; Received 436 bytes from 126.96.36.199#53(188.8.131.52) in 9 ms
mil. 86400 IN NS G.ROOT-SERVERS.NET.
;; Received 426 bytes from 184.108.40.206#53(L.ROOT-SERVERS.NET) in 160 ms
navy.mil. 86400 IN NS NS-NORVA.navy.mil.
;; Received 237 bytes from 220.127.116.11#53(G.ROOT-SERVERS.NET) in 286 ms
usno.navy.mil. 86400 IN NS CHARON.usno.navy.mil.
;; Received 145 bytes from 18.104.22.168#53(NS-NORVA.navy.mil) in 90 ms
www.usno.navy.mil. 43200 IN A 22.214.171.124
;; Received 161 bytes from 126.96.36.199#53(CHARON.usno.navy.mil) in 84 ms
The query log on the (BIND 8) resolver shows (truncated):
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 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