Two very basic named question.

Let's say I install bind, and get named going on boot with no changes
to named.conf.

I change /etc/resolv.conf to something like
nameserver 127.0.0.1
nameserver 8.8.8.8
search home.test

And other config files have

$ grep hosts: /etc/nsswitch.conf
hosts: files dns

$ cat /etc/host.conf
order hosts,bind
multi on
nospoof on
spoofalert on


When I look up something like yahoo.com, does named go through the
root-servers to get a yahoo dns server resolution?

Is the only time I go to nameserver 8.8.8.8 is when nameserver
127.0.0.1 fails to respond?

On Fri, 12 Nov 2010 03:24:14 -0500, Bit Twister <(E-Mail Removed)> wrote:

> Let's say I install bind, and get named going on boot with no changes
> to named.conf.
> And other config files have
> $ grep hosts: /etc/nsswitch.conf
> hosts: files dns

> $ cat /etc/host.conf
> order hosts,bind
> multi on
> nospoof on
> spoofalert on

> When I look up something like yahoo.com, does named go through the
> root-servers to get a yahoo dns server resolution?

Yes, unless it already has a result in its cache, that has not
timed out.

> Is the only time I go to nameserver 8.8.8.8 is when nameserver
> 127.0.0.1 fails to respond?

No. If it replies with "not found" or fails to respond, then
the resolver will go to the next name server in the list.

I was previously under the impression that if the first name
server responded "not found", that the search would stop at
that point. During the testing posted in the thread
"Howto get bind to validate dnssec keys", I learned that the
resolver will use each name server listed in /etc/resolv.conv
until it gets a response with an address, or runs out of name
servers to check. If the first name server responds with
"not found", the resolver will ask the next name server in
the /etc/resolv.conf.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

"David W. Hodgins" <(E-Mail Removed)> writes:
> Bit Twister <(E-Mail Removed)> wrote:

>> Is the only time I go to nameserver 8.8.8.8 is when nameserver
>> 127.0.0.1 fails to respond?
>
> No. If it replies with "not found" or fails to respond, then
> the resolver will go to the next name server in the list.
>
> I was previously under the impression that if the first name
> server responded "not found", that the search would stop at
> that point. During the testing posted in the thread
> "Howto get bind to validate dnssec keys", I learned that the
> resolver will use each name server listed in /etc/resolv.conv
> until it gets a response with an address, or runs out of name
> servers to check. If the first name server responds with
> "not found", the resolver will ask the next name server in
> the /etc/resolv.conf.

That is not what happens, as can be verified with strace and tcpdump.
An rcode of NXDOMAIN or an answer for a domain that exists but has no RR
of the required type, will both end the search even if there are further
servers list in resolv.conf. These two conditions together amount to
the required name+type being 'not found'.

--
http://www.greenend.org.uk/rjk/

On Mon, 2010-11-15, Richard Kettlewell wrote:
> "David W. Hodgins" <(E-Mail Removed)> writes:
>> Bit Twister <(E-Mail Removed)> wrote:
>
>>> Is the only time I go to nameserver 8.8.8.8 is when nameserver
>>> 127.0.0.1 fails to respond?
>>
>> No. If it replies with "not found" or fails to respond, then
>> the resolver will go to the next name server in the list.
>>
>> I was previously under the impression that if the first name
>> server responded "not found", that the search would stop at
>> that point. During the testing posted in the thread
>> "Howto get bind to validate dnssec keys", I learned that the
>> resolver will use each name server listed in /etc/resolv.conv
>> until it gets a response with an address, or runs out of name
>> servers to check. If the first name server responds with
>> "not found", the resolver will ask the next name server in
>> the /etc/resolv.conf.
>
> That is not what happens, as can be verified with strace and tcpdump.
> An rcode of NXDOMAIN or an answer for a domain that exists but has no RR
> of the required type, will both end the search even if there are further
> servers list in resolv.conf. These two conditions together amount to
> the required name+type being 'not found'.

I haven't investigated myself, but isn't it possible that you're
talking about two different resolver implementations, or two different
configurations of one implementation? I note that neither of you
state which one and which version you're talking about.

(I note though that R.K.'s description matches what resolv.conf(5)
says on my system.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Jorgen Grahn <grahn+(E-Mail Removed)> writes:
> On Mon, 2010-11-15, Richard Kettlewell wrote:

>> That is not what happens, as can be verified with strace and tcpdump.
>> An rcode of NXDOMAIN or an answer for a domain that exists but has no RR
>> of the required type, will both end the search even if there are further
>> servers list in resolv.conf. These two conditions together amount to
>> the required name+type being 'not found'.
>
> I haven't investigated myself, but isn't it possible that you're
> talking about two different resolver implementations, or two different
> configurations of one implementation? I note that neither of you
> state which one and which version you're talking about.

Possible in principle, though I'm describing the C library's resolver,
which is what most program use. I'd expect others to have the same
behavior (the alternative is rather mad) but haven't checked.

--
http://www.greenend.org.uk/rjk/

On Mon, 15 Nov 2010 18:02:45 -0500, Richard Kettlewell <(E-Mail Removed)> wrote:

> Possible in principle, though I'm describing the C library's resolver,
> which is what most program use. I'd expect others to have the same
> behavior (the alternative is rather mad) but haven't checked.

[dave@hodgins ~]$ host www.dnssec-failed.org 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
Host www.dnssec-failed.org not found: 2(SERVFAIL)
[dave@hodgins ~]$ host www.dnssec-failed.org
www.dnssec-failed.org has address 68.87.64.48

$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
nameserver 127.0.0.1
nameserver 216.240.0.1
nameserver 216.240.1.1

$ rpm -q -i resolvconf|grep Version
Version : 1.45

$ cat /etc/release
Mandriva Linux release 2010.1 (Official) for i586

As shown above, my localhost version of bind, which is configured
to check dsnsec correctly returns not found for www.dnssec-failed.org,
when it is explicitly queried.

If I don't comment out the other nameserver entries in /etc/resolv.conf,
and don't specify only to use 127.0.0.1, the ip address is found.

Running the host lookup under strace show it first check 127.0.0.1,
and then 216.240.0.1.

Further testing shows that, for a name that really doesn't exist,
the first server returns NXDOMAIN, and no other name servers
listed in /etc/resolv.conf are used, as you stated, and I understood
until the dnssec tests.

So the difference is whether the name lookup is failing due to
the name not being found, or due to the name failing the dnssec
check, where the resolver gets a response of SERVFAIL from the
dnssec enabled name server.

Your understanding is correct (as was mine, prior to getting
the confused by the results from my dsnsec tests) for a name
that doesn't exist. Thanks for making me test further, and
getting my understanding corrected.

The exception that confused me, only applies for a host with
an invalid RRSIG record, and a name server with dnssec checking
enabled.

Regards, Dave hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

On Mon, 15 Nov 2010 19:18:58 -0500, David W. Hodgins wrote:

First, Thank You David and Richard.


> So the difference is whether the name lookup is failing due to
> the name not being found, or due to the name failing the dnssec
> check, where the resolver gets a response of SERVFAIL from the
> dnssec enabled name server.
>
> Your understanding is correct (as was mine, prior to getting
> the confused by the results from my dsnsec tests) for a name
> that doesn't exist.

Good, I thought only SERVFAIL advanced search to next server.

But, playing with host www.dnssec-failed.org 127.0.0.1
brought me back to my first question.

I did set resolv.conf to
nameserver 127.0.0.1
# nameserver 8.8.8.8
search home.test

removed forwarders in named.conf

# dif /var/lib/named/etc/named.conf~ /var/lib/named/etc/named.conf
53c53
< forwarders { 208.67.222.222; 208.67.220.220; };
---
> // forwarders { 208.67.222.222; 208.67.220.220; };

and restarted named but it appeared to still work.

$ host 68.87.64.48 127.0.0.1
48.64.87.68.in-addr.arpa domain name pointer speedlab-app03.ndceast.pa.bo.comcast.net.
48.64.87.68.in-addr.arpa domain name pointer www.comcast6.net.
48.64.87.68.in-addr.arpa domain name pointer cmportal.comcast.net.

I guess what I wanted to find out was if using forwarders did
named look locally, the forwarders, then root-servers.

At one point I did get a SERVFAIL but was unable to recreate it. ;(

I assumed a caching problem, but I though a named restart would flush that.

On Tue, 16 Nov 2010 01:51:37 -0500, Bit Twister <(E-Mail Removed)> wrote:

> On Mon, 15 Nov 2010 19:18:58 -0500, David W. Hodgins wrote:
> But, playing with host www.dnssec-failed.org 127.0.0.1
> brought me back to my first question.
> I did set resolv.conf to
> nameserver 127.0.0.1
> # nameserver 8.8.8.8
> search home.test
>
> # dif /var/lib/named/etc/named.conf~ /var/lib/named/etc/named.conf
> 53c53
> < forwarders { 208.67.222.222; 208.67.220.220; };
>> // forwarders { 208.67.222.222; 208.67.220.220; };

Why are you setting forwarders at all? I never have, as I'm only running
a caching name server, with adblocking, based on a list of names, where I've
forgotten where I originally got it from, and have since modified quite a bit.

$ grep forward /var/lib/named/etc/named.conf
// forwarders { first_public_nameserver_ip; second_public_nameserver_ip; };

> $ host 68.87.64.48 127.0.0.1
> 48.64.87.68.in-addr.arpa domain name pointer speedlab-app03.ndceast.pa.bo.comcast.net.
> 48.64.87.68.in-addr.arpa domain name pointer www.comcast6.net.
> 48.64.87.68.in-addr.arpa domain name pointer cmportal.comcast.net.

Why are you running a lookup on the reverse dns address, instead of the
name intended to be used for testing the dnssec features of a nameserver?

> I guess what I wanted to find out was if using forwarders did
> named look locally, the forwarders, then root-servers.

Run the host command under strace, or use wireshark, to see which
name servers are being queried.

If "host www.dnssec-failed.org 127.0.0.1" returns
"Host www.dnssec-failed.org not found: 2(SERVFAIL)"
then the localhost version of bind has been properly configured to use
dnssec. If it returns "www.dnssec-failed.org has address 68.87.64.48",
then it has not been properly configured.

I think this thread has gotten sidetracked by my failure to notice the
difference between the handling of nxdomain, and servfail, and I've
now forgotten the original question.

I've never used the forwarders option, and have no idea what impact it
may have on lookups.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

On Tue, 16 Nov 2010 03:08:34 -0500, David W. Hodgins wrote:
> On Tue, 16 Nov 2010 01:51:37 -0500, Bit Twister <(E-Mail Removed)> wrote:
>
>>
>> # dif /var/lib/named/etc/named.conf~ /var/lib/named/etc/named.conf
>> 53c53
>> < forwarders { 208.67.222.222; 208.67.220.220; };
>>> // forwarders { 208.67.222.222; 208.67.220.220; };
>
> Why are you setting forwarders at all?

Hopefully those opendns servers would be used before going to root
servers so I bypass known malware addresses.

> Why are you running a lookup on the reverse dns address, instead of the
> name intended to be used for testing the dnssec features of a nameserver?

Just assumed reverse was just as good a test as a forward look up.


> I think this thread has gotten sidetracked by my failure to notice the
> difference between the handling of nxdomain, and servfail, and I've
> now forgotten the original question.

Not really. I was pretty sure servfail caused next nameserver to used
and had asked the second question for verification.


> I've never used the forwarders option, and have no idea what impact it
> may have on lookups.

If I mis-understand wireshark output correctly, it showed the forwarders were
used before going to root servers.

What started me down this track was your post in alt.os.linux.mandriva
<http://groups.google.com/group/alt.os.linux.mandriva/msg/1d7697d1203c5bc0?dmode>
about a dns problem with www.google.ca, . The fact that dns/ping worked
and wget failed was weird. Only thing I could guess was a poisoned dns value.

On Mon, 2010-11-15, Richard Kettlewell wrote:
> Jorgen Grahn <grahn+(E-Mail Removed)> writes:
>> On Mon, 2010-11-15, Richard Kettlewell wrote:
>
>>> That is not what happens, as can be verified with strace and tcpdump.
>>> An rcode of NXDOMAIN or an answer for a domain that exists but has no RR
>>> of the required type, will both end the search even if there are further
>>> servers list in resolv.conf. These two conditions together amount to
>>> the required name+type being 'not found'.
>>
>> I haven't investigated myself, but isn't it possible that you're
>> talking about two different resolver implementations, or two different
>> configurations of one implementation? I note that neither of you
>> state which one and which version you're talking about.
>
> Possible in principle, though I'm describing the C library's resolver,
> which is what most program use. I'd expect others to have the same
> behavior (the alternative is rather mad) but haven't checked.

Ok, but even if you just look at current Linux distributions there are
at least two different libc implementations in use -- Gnu libc, EGLIBC.
If I recall correctly, one reason Debian switched to EGLIBC was that
they believed some aspects of the glibc resolver was broken.

Or it could have been configurable, like many other aspects of the
glibc resolver seems to be.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .