Join Log in
Score:-1
avatar Server

bind9: forward to local name server does not work when internet connection is down

cz flag
p.g.

I have the following setup:

A bind9 instance (referred as L below) on very limited hardware for resolving the names on my local networks. It is an authoritative master for the zone home.mydomain.com. Queries to this server work and return homedns.home.mydomian.com as NS and the IP 192.168.1.77 of it as an additional record.

A bind9 instance (referred as M below) to resolve internet and local names. No global forward option is used here. There is a forward zone configured:

zone "home.mydomain.com" in {
        type forward;
        forward only;
        forwarders { 192.168.1.77; };
};

Note1: mydomain.com is an existing, registered domain but there is no record for home.mydomain.com

Note2: The bind9 version of M is very old: 9.8.1-P1

This setup works as long as the internet connection is up, but local name queries are not answered when the connection is down. Log is syslog is

Aug 30 09:05:42 M named[1611]: error (no valid DS) resolving 'xxx.home.mydomain.com/A/IN': 192.168.1.77#53

Capturing the network for a successful resolve when the connection is up reveals that M queries for mydomain.com on the internet after receiving the answer from L. In the answer from M to the client, the AUTHORITY SECTION is changed:

dig to L:

;; ANSWER SECTION:
syslog.home.mydomain.com. 3600  IN      A       192.168.1.99

;; AUTHORITY SECTION:
home.mydomain.com.        3600  IN      NS      homedns.home.mydomain.com.

;; ADDITIONAL SECTION:
homedns.home.mydomain.com. 3600 IN      A       192.168.1.77

dig to M:

;; ANSWER SECTION:
syslog.home.mydomain.com. 2134  IN      A       192.168.1.99

;; AUTHORITY SECTION:
net.                    171334  IN      NS      j.gtld-servers.net.
net.                    171334  IN      NS      m.gtld-servers.net.
net.                    171334  IN      NS      i.gtld-servers.net.
net.                    171334  IN      NS      k.gtld-servers.net.
net.                    171334  IN      NS      g.gtld-servers.net.
net.                    171334  IN      NS      e.gtld-servers.net.
net.                    171334  IN      NS      h.gtld-servers.net.
net.                    171334  IN      NS      a.gtld-servers.net.
net.                    171334  IN      NS      d.gtld-servers.net.
net.                    171334  IN      NS      f.gtld-servers.net.
net.                    171334  IN      NS      b.gtld-servers.net.
net.                    171334  IN      NS      c.gtld-servers.net.
net.                    171334  IN      NS      l.gtld-servers.net.

I do not understand why M is not just returning the answer from L to the client and I don't have any ideas left, what I could try to avoid the query to the internet for the forwarded zone.

105
1 + 0
Score:0
avatar Server
cn flag
Håkan Lindqvist

The log entry quoted in the question suggests that the error is tied to DNSSEC validation failing when there is no Internet connectivity.

Note the "no valid DS" part of the error message:

Aug 30 09:05:42 M named[1611]: error (no valid DS) resolving 'xxx.home.example.com/A/IN': 192.168.1.77#53

Presumably the answers for queries hitting this forward zone are normally accepted only because the public example.com zone exists as an unsigned zone (ie, there is proof of no DS as part of the delegation of the proper example.com zone), but when this proof can no longer be fetched because there is no Internet connectivity the answers can no longer be accepted as it's no longer possible to verify if/how these must be signed.

One option would be to sign the home.example.com zone and add a static trust anchor for this zone specifically.

Another would be to selectively disable validation; current BIND has a validate-except option that allows you to specify a list of domain names where no validation should be performed, as per:

validate-except

This specifies a list of domain names at and beneath which DNSSEC validation should not be performed, regardless of the presence of a trust anchor at or above those names. This may be used, for example, when configuring a top-level domain intended only for local use, so that the lack of a secure delegation for that domain in the root zone does not cause validation failures. (This is similar to setting a negative trust anchor except that it is a permanent configuration, whereas negative trust anchors expire and are removed after a set period of time.)

There is also the possibility of entirely disabling validation using the dnssec-validation option, which I would not recommend if this BIND instance has wider use than this specific forward.

(Note, I have replaced the domain name used in the question with example.com as it seems unlikely that the question has any relation to the domain name it references or the business that owns it.)

0 + 2
cz flag
p.g.
This sounds like an excellent explanation for the problem. Unfortunately the very old bind version 9.8.1 does not support validate-except and the doc on bind9.readthedocs.io does not cover the version any more. At the moment, I'm unable to verify the solution. An upgrade to the latest Ubuntu LTS is planned for later this year. I probably have to wait until then.
0
Reply
cz flag
p.g.
The latest bind9 version together with validate-except solves the problem perfectly.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.