DNS: forwarding - what if forwarders are not reacheable etc...?

[mar_q]

Hello.

Im continuosly learning DNS on linux and have some doubts sometimes.

Assuming that in named.conf I have following settings in options

options {
forwarders {X.X.X.X; X.X.X.Y;};
forward only;

Now.

Assuming that named was running some time and sudenly forwarders are not reacheable.

However when I do nslookup I get proper response. Is it from cache or maybe it is from the fact that

in named.conf there is - apart of clauses where this server is master for own zones -  clause like:

zone "." IN {
type hint;
file "named.ca";

and in filename is a list of root servers known as root zone.

Anyway. Studying documentation I see that

When a name server cannot resolve a query
from its local zone files or its cache, it uses the name servers obtained via this query to return a
referral (if an iterative query) or to find an answer (if a recursive query).

Now how it is dealing when forwarders are defined and forward only is set in globa options.

Do forwarder settings in global sections  "overwrites"  this zone "." settings?

And what if forwarders are not reacheable?

Thanks for hints.

[Matti_Kurkela]

If nslookup says "Non-authoritative answer", then the response is from cache.

A global "forward only;" should be overrideable only by having authoritative zones configured (i.e. either "master" or "slave" zones) or a set of zone-specific forwarding settings (a "forward" type zone). The hint zone should not affect forwarding at all: if you find it does, you have found a bug.

Queries for authoritative zones are never forwarded (unless it's an expired slave zone): since an authoritative zone is by definition a "complete" set of records for that zone, BIND can just use the information it already has; there would be no point of asking another name server.

The root hint zone has been a requirement for named for a very long time. If the hint zone does not exist, modern versions of named have a built-in set of hints to use. When global configuration says "forward only" and there are no zone-specific forwarding overrides configured, BIND has no need for root hints at all.

I made some quick tests on BIND 9.7.3 on a Debian 6.0.2 system: apparently, if the global configuration is "forward only" and there are no zones with overriding forwarding settings, BIND won't try to fetch an up-to-date list of root name servers at all. So it looks like the hint zone is completely ignored in this case.

If the configuration says "forward only" and the forwarders are not reachable and the requested information is not in BIND's cache, you will get a SERVFAIL error instead of any answer.

Using nslookup, it should look like this:

# nslookup www.google.com.
Server:         127.0.0.1
Address:        127.0.0.1#53

** server can't find www.google.com: SERVFAIL

[mar_q]

Hello.

Thank you very much for answer and big effort.

Your answer is quite clear for me.

However.

I'm a little bit confused thought.

I've noticed that  I get the SERVFAIL (talking about forwarders) in log for some requests... but doing nslookup I get proper answer for the same names reported. (the server answering for nslookup is my local DNS which configuration we here discuss)

From your post I understand that all requests (which are not for zones for which my DNS is authoritative) should be forwarded and the entry

zone "." IN {
type hint;
file "named.ca"

has nothing to do here.

So what is going on here in my case?

[Matti_Kurkela]

So you get SERVFAIL logged by BIND, and at the same time your nslookup is giving you a correct result?

A complete understanding of the situation might require a trace of the DNS traffic... but my first guesses would be one of the following:

A.) if you have more than one forwarder configured: one forwarder may be unable/unwilling to answer, so BIND logs an error and sends the query to another forwarder, which successfully returns the requested information.

or

B.) if you have previously made the same query successfully, BIND has cached the information; but all DNS information that's stored outside an authoritative server has a limited lifetime. BIND may be thinking: "this cached information will soon be stale, and since the client keeps asking for it, maybe I should proactively refresh it." It sends a query to the forwarder, and gets a SERVFAIL. "Oh well. Since the cached information is not quite stale yet, I'll just keep giving copies of it to the clients now and try to refresh it again later."

[mar_q]

Yes that's true. I got SERVFAIL for certain queries and and get proper response the same time using nslookup.

A) No. It's not the case. Both forwarders are failing.

B) If it is so it might be true. But I'm not so experienced in it to say this is it :-)

I will also study the book about DNS because I'm intersted in that.

But you see. In fact. In the book there is no clear description how it works. What I mean there is no certain scenarios discussed - examples.

Thank you for your support. We can continue the case if you want.

I will also try to install linux on laptop at home with bind and do some practises.

[Matti_Kurkela · Accepted solution]

Perhaps your book does not discuss some scenarios because they are described in the relevant Internet standards documents (RFCs)?

If you want to understand DNS, you should read these RFCs:

http://tools.ietf.org/html/rfc1035

http://tools.ietf.org/html/rfc1123

http://tools.ietf.org/html/rfc2181