resolver, search command....
cet1 at cam.ac.uk
Wed May 8 14:49:56 UTC 2013
On May 8 2013, John Williams wrote:
>my resolv.conf looks like....
>search path1.mydomain.com path2.mydomain.com
>I would expect if I type the following:
>It would search for that host in path1 or path2 listed above. It does not,
>a +trace shows the resolver querying the root servers for myhost.
>So it appears the search command does not work in environment.
>[root at server1 # dig myhost +trace
>; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.2 <<>> myhost +trace
>;; global options: +cmd
>. 98386 IN NS k.root-servers.net.
>. 98386 IN NS m.root-servers.net.
>. 98386 IN NS b.root-servers.net.
>. 98386 IN NS i.root-servers.net.
>. 98386 IN NS e.root-servers.net.
>. 98386 IN NS f.root-servers.net.
>. 98386 IN NS a.root-servers.net.
>. 98386 IN NS d.root-servers.net.
>. 98386 IN NS j.root-servers.net.
>. 98386 IN NS c.root-servers.net.
>. 98386 IN NS g.root-servers.net.
>. 98386 IN NS l.root-servers.net.
>. 98386 IN NS h.root-servers.net.
>;; Received 512 bytes from 10.176.156.20#53(10.16.16.20) in 9 ms
[Presumably 10.16.16.20 is in your resolv.conf, rather than what you
>^C[root at server1]# vi /etc/resolv.conf ^C
>Any idea why? Thanks in advance...
You are (probably) under two misapprehensions. First, dig does not use
the search path by default - you have to use the +search option for that.
See the man page.
Secondly, +trace always goes to the root nameservers and works its way
down from there. That's what it is intended for - it's not some sort
of debugging option as you seem to think. The only thing it uses the
nameservers specified in resolv.conf, or by an @ option, for is to look
up the nameservers for "." to get it started.
It isn't actually useful to combine +trace and +search - dig could start
all over again with the search path(s) added after a "negative" result,
but it doesn't.
Email: cet1 at cam.ac.uk
More information about the bind-users