/etc/resolv.conf in SUSE 10.1 (2.6.16.13-4-smp)

Due to my broadbang provider going through a sticky patch, I have
discovered that my system is using only the first nameserver in
/etc/resolv.conf. If the reply is a non-authoritative does not
exist, it doesn't try the others.

Does anyone recognise this, and preferably know what to do about it?


Regards,
Nick Maclaren.

On 9 Aug 2006 17:39:09 GMT
(E-Mail Removed) (Nick Maclaren) wrote:

> Due to my broadbang provider going through a sticky patch, I have
> discovered that my system is using only the first nameserver in
> /etc/resolv.conf. If the reply is a non-authoritative does not
> exist, it doesn't try the others.
>
> Does anyone recognise this, and preferably know what to do about it?

That's the correct behaviour. If the NS responds with "DOES NOT EXIST"
do you want it to confirm, by trying every other NS in /etc/resolv.conf?

What you might consider is setting up your own caching name server. See
http://cr.yp.to/djbdns.html for setting up your own caching name server.

--
Regards, Ed :: http://www.bsdwarez.net
proud linux person
The failing economy didn't end communism in Soviet Russia, Chuck
Norris did.

In article <(E-Mail Removed)>,
d <(E-Mail Removed)> writes:
|>
|> > Due to my broadbang provider going through a sticky patch, I have
|> > discovered that my system is using only the first nameserver in
|> > /etc/resolv.conf. If the reply is a non-authoritative does not
|> > exist, it doesn't try the others.
|> >
|> > Does anyone recognise this, and preferably know what to do about it?
|>
|> That's the correct behaviour. If the NS responds with "DOES NOT EXIST"
|> do you want it to confirm, by trying every other NS in /etc/resolv.conf?

No, that is the correct behaviour for an AUTHORITATIVE "does not exist".
A non-authoritative one really means "not known to me - try elsewhere".
What it meant in this case was that the DNS server had lost its
upstream links and couldn't pass the request on.

I could tell you a lot of history about the politics of the networking
people with pre-Internet experience trying to explain to the others why
it was essential to have the difference. Unfortunately, education has
only a transitory effect :-(



Regards,
Nick Maclaren.

On Wed, 09 Aug 2006 18:26:32 +0000, Nick Maclaren wrote:

>
> In article <(E-Mail Removed)>, d
> <(E-Mail Removed)> writes:
> |>
> |> > Due to my broadbang provider going through a sticky patch, I have
> |> > discovered that my system is using only the first nameserver in
> |> > /etc/resolv.conf. If the reply is a non-authoritative does not
> |> > exist, it doesn't try the others.
> |> >
> |> > Does anyone recognise this, and preferably know what to do about it?
> |>
> |> That's the correct behaviour. If the NS responds with "DOES NOT EXIST"
> |> do you want it to confirm, by trying every other NS in
> |> /etc/resolv.conf?
>
> No, that is the correct behaviour for an AUTHORITATIVE "does not exist". A
> non-authoritative one really means "not known to me - try elsewhere". What
> it meant in this case was that the DNS server had lost its upstream links
> and couldn't pass the request on.

Yes, that is correct behaviour for a resolver. A caching nameserver
shouldn't ever return an authoritative answer for a domain hosted on
another server (older versions of bind used to if they had just fetched
the answer from the authoritative server, rather then answering from the
cache, but this isn't correct and has been fixed in bind9). The non
authoritative answer from a caching nameserver means "here is the answer,
I got it from somewhere else". It doesn't mean the answer shouldn't be
believed.

If a server really means "not known to me, try elsewhere", and a
legitimately used caching server never should, it should respond NOERROR,
no answer and an authority section (often listing the root or GTLD
nameservers). This will happen if you send a query to a server which is
denying you recursion, which a resolver shouldn't be doing.

The correct thing to do in this case is not to answer. Then the resolver
*will* try the next server in the list. If this is really what this
nameserver is doing it's not just its network links which are broken.

> I could tell you a lot of history about the politics of the networking
> people with pre-Internet experience trying to explain to the others why
> it was essential to have the difference.

The difference between an authoritative and unauthoritative answer
matters to servers, not to resolvers. Servers use it to verify delegations
are correct - if a domain is delegated to a server, that server should
answer authoritatively for it. If it answers unauthoritatively it means it
doesn't actually hold the domain and the delegation is incorrect, so in
this case the answer is not believed.

The Windows resolver will do what you seem to want In this respect it's
broken and this brokenness is just one reason why Windows machines cause
excessive network traffic. This is probably why your ISP is getting away
with this poor behaviour, their Windows customers don't notice it.

To fix this you can:

Complain to your ISP, but as they seem to be somewhat useless this is
unlikely to be effective;

Change ISPs;

Run your own caching server as Ed suggested (which is what I'd do,
although I'd use bind not djbdns. I run my own caching server as my ISP's
aren't very good either);

Disable updating resolv.conf in your DHCP client and hard code a list of
servers which work (dangerous as it could become incorrect but possibly a
viable temporary kludge until your ISP fixes their network).

Regards, Ian

In comp.os.linux.networking Nick Maclaren <(E-Mail Removed)>:

> In article <(E-Mail Removed)>,
> d <(E-Mail Removed)> writes:
> |>
> |> > Due to my broadbang provider going through a sticky patch, I have
> |> > discovered that my system is using only the first nameserver in
> |> > /etc/resolv.conf. If the reply is a non-authoritative does not
> |> > exist, it doesn't try the others.
> |> >
> |> > Does anyone recognise this, and preferably know what to do about it?
> |>
> |> That's the correct behaviour. If the NS responds with "DOES NOT EXIST"
> |> do you want it to confirm, by trying every other NS in /etc/resolv.conf?

> No, that is the correct behaviour for an AUTHORITATIVE "does not exist".
> A non-authoritative one really means "not known to me - try elsewhere".
> What it meant in this case was that the DNS server had lost its
> upstream links and couldn't pass the request on.

Complete wrong, "non-authoritative" just means I know the answer
but I am not authoritative for the domain, since that are only the
master and his secondary DNS servers for the zone. It is quite
unlikely to ever get an authoritative answer and there's no reason
to do so. It's just what the purpose of DNS is, distributed name
resolving using little bandwidth with high availability.

[..]

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 280: Traceroute says that there is a routing
problem in the backbone. It's not our problem.

In article <imrpq3-(E-Mail Removed)>,
Michael Heiming <michael+(E-Mail Removed)> writes:
|>
|> Complete wrong, "non-authoritative" just means I know the answer
|> but I am not authoritative for the domain, since that are only the
|> master and his secondary DNS servers for the zone. It is quite
|> unlikely to ever get an authoritative answer and there's no reason
|> to do so. It's just what the purpose of DNS is, distributed name
|> resolving using little bandwidth with high availability.

Well, thank you all for correcting my long-held delusions!

I thought that debate had been settled the other way (which is by far
the technically better one). Kludging up negative responses in the
other ways isn't nice at all.


Regards,
Nick Maclaren.

On Thu, 10 Aug 2006 08:44:38 +0000, Nick Maclaren wrote:

>
> In article <imrpq3-(E-Mail Removed)>, Michael Heiming
> <michael+(E-Mail Removed)> writes:
> |>
> |> Complete wrong, "non-authoritative" just means I know the answer but I
> |> am not authoritative for the domain, since that are only the master and
> |> his secondary DNS servers for the zone. It is quite unlikely to ever
> |> get an authoritative answer and there's no reason to do so. It's just
> |> what the purpose of DNS is, distributed name resolving using little
> |> bandwidth with high availability.
>
> Well, thank you all for correcting my long-held delusions!
>
> I thought that debate had been settled the other way (which is by far the
> technically better one). Kludging up negative responses in the other ways
> isn't nice at all.

Why do you think the other way is technically better? In my view the way
it works is quite logical. The authority bit means you have authority for
the domain in question.

Of course your ISP's nameserver faking an NXDOMAIN because it can't
contact an authoritative server is dead wrong, but this has nothing to do
with the way DNS is supposed to work. If that's really what it's doing
it's badly broken and is responsible for your problems. A non
authoritative NXDOMAIN (or any non authoritative answer) should only be
given if you've received the same answer from an authoritative server and
this isn't the case here.

Regards, Ian

In article <(E-Mail Removed)>,
Ian Northeast <(E-Mail Removed)> writes:
|> >
|> > I thought that debate had been settled the other way (which is by far the
|> > technically better one). Kludging up negative responses in the other ways
|> > isn't nice at all.
|>
|> Why do you think the other way is technically better? In my view the way
|> it works is quite logical. The authority bit means you have authority for
|> the domain in question.

Drop back 25 years, to when people attempted to design protocols that
eliminated 'false answer' failure modes, even in the presence of race
conditions and network outage. For every such response, you need a flag
that says "This answer is known to be correct", because the presence or
absence of that changes the error recovery strategies (as in this case).
Note that you DON'T want a separate return code, as that applies to
EVERY answer.

[ Note that I am not talking about spoofing or delusions, which need
different approaches, but where answers given in good faith can be
known to be reliable or unreliable. ]

For example, if a DNS server has a cached, known-correct, answer,
but has lost its upstream link so can't recheck, it has the choice
of returning the answer or refusing to provide information that it
does have. The best solution is the former with the known-correct flag
unset so, if the client has alternative paths, it can check for itself
via another route if appropriate.

I was on the periphery of a discussion of which the authority bit should
mean, and thought that it had been resolved the other way.

|> Of course your ISP's nameserver faking an NXDOMAIN because it can't
|> contact an authoritative server is dead wrong, but this has nothing to do
|> with the way DNS is supposed to work. ...

Right. A standard protocol should be disregarded only when it is so
demented that following it will cause more chaos than not doing so will
introduce. This is not such an example.


Regards,
Nick Maclaren.

On Thu, 10 Aug 2006 20:13:42 +0000, Nick Maclaren wrote:

>
> In article <(E-Mail Removed)>,
> Ian Northeast <(E-Mail Removed)> writes:
> |> >
> |> > I thought that debate had been settled the other way (which is by far
> |> > the technically better one). Kludging up negative responses in the
> |> > other ways isn't nice at all.
> |>
> |> Why do you think the other way is technically better? In my view the
> |> way it works is quite logical. The authority bit means you have
> |> authority for the domain in question.
>
> Drop back 25 years, to when people attempted to design protocols that
> eliminated 'false answer' failure modes, even in the presence of race
> conditions and network outage. For every such response, you need a flag
> that says "This answer is known to be correct", because the presence or
> absence of that changes the error recovery strategies (as in this case).
> Note that you DON'T want a separate return code, as that applies to EVERY
> answer.
>
> [ Note that I am not talking about spoofing or delusions, which need
> different approaches, but where answers given in good faith can be known
> to be reliable or unreliable. ]
>
> For example, if a DNS server has a cached, known-correct, answer, but has
> lost its upstream link so can't recheck, it has the choice of returning
> the answer or refusing to provide information that it does have. The best
> solution is the former with the known-correct flag unset so, if the client
> has alternative paths, it can check for itself via another route if
> appropriate.

If a caching server has the answer cached, it will respond with that
answer *without* checking the authoritative servers. Tbis is the point of
caching. It saves bandwidth. If the TTL has expired, requiring a new query
to an authoritative server, and none is forthcoming, it should not answer.
The lack of answer will cause the resolver to try its next server.

The authority bit does not mean "known correct". It indicates whether the
server returning the answer is authoritative for the domain in question,
i.e. whether it holds it itself (on) or it has had to consult other
servers to obtain it (off).

There is no mechanism that I know of for a server to return "I knew this
once, but it's out of date".

Regards, Ian

In article <(E-Mail Removed)>,
Ian Northeast <(E-Mail Removed)> writes:
|>
|> If a caching server has the answer cached, it will respond with that
|> answer *without* checking the authoritative servers. Tbis is the point of
|> caching. It saves bandwidth. If the TTL has expired, requiring a new query
|> to an authoritative server, and none is forthcoming, it should not answer.
|> The lack of answer will cause the resolver to try its next server.

There is/was no TTL on a non-existent entry :-)

|> The authority bit does not mean "known correct". It indicates whether the
|> server returning the answer is authoritative for the domain in question,
|> i.e. whether it holds it itself (on) or it has had to consult other
|> servers to obtain it (off).

Yes, that's what you said. The debate to which I referred was which of
the two meanings it should have.

|> There is no mechanism that I know of for a server to return "I knew this
|> once, but it's out of date".

Precisely. And that is the mistake.


Regards,
Nick Maclaren.