bind9 does not resolve dnssec correctly

25,288

The forwarders that you have configured will only cause problems when running a validating resolver as the Opendns servers do not cooperate when doing DNSSEC validation.

I suppose it might mostly work anyway for you as you didn't specify forward only, so named will fall back to resolving things on its own more or less all the time as the forwarders keep failing to produce useful results. But even if it sort of works it will still make a complete mess of your logs.

To demonstrate, if I set forward only and use those same forwarders this is what happens:

named[20057]: error (no valid RRSIG) resolving 'net/DS/IN': 208.67.220.220#53
named[20057]: error (no valid RRSIG) resolving 'net/DS/IN': 208.67.222.222#53
named[20057]: error (no valid DS) resolving 'sigfail.verteiltesysteme.net/A/IN': 208.67.222.222#53
named[20057]: validating @0x7f36805ecb10: sigfail.verteiltesysteme.net A: bad cache hit (net/DS)
named[20057]: error (broken trust chain) resolving 'sigfail.verteiltesysteme.net/A/IN': 208.67.220.2

As you can see, it fails but for entirely the wrong reason. (It failed at the DS for net, not when validating the actually broken signatures at sigfail.verteiltesysteme.net.)

I expect your logs are currently a mix of stuff like the above combined with actually relevant entries from when named falls back to querying properly working servers. Fixing this ought to help troubleshooting.

As for the inconsistent results, I'm not sure that anything in your configuration can really explain that. Are you positive that it's actually that same named instance that answered the query? No strange NAT rules or something like that which would cause clients to transparently talk to some different server or whatnot?

Queries like dig @192.168.10.36 version.bind CH TXT and dig @192.168.10.36 hostname.bind CH TXT could expose such a thing going on.

Share:
25,288

Related videos on Youtube

Admin
Author by

Admin

Updated on September 18, 2022

Comments

  • Admin
    Admin over 1 year

    I have a problem with my dns server setup. My bind server is mainly a cache-server but does also serve some internal domains. It listens only on my private network and serves only requests from there.

    Today I wanted to enable the bind to validate DNSSEC but somehow it does it not correctly. If i resolve the host name on the bind linux machine itself, the invalid DNSSEC is perfectly shown as such. But if I try to resolve the same domain using the same dig command again on my other machine in the network, the DNSSEC check does not fail and the domain gets resolved just fine. What I want it to do is to send the correct SERVFAIL to my other DNS clients in the network.

    Here are all information you could need (bind version, configs, etc). I will append the digs I did at the end.

    OS Version

    root@thor:/etc/bind# lsb_release -a
    No LSB modules are available.
    Distributor ID: Debian
    Description:    Debian GNU/Linux 8.5 (jessie)
    Release:        8.5
    Codename:       jessie
    
    root@thor:/etc/bind# uname -a
    Linux thor.home.intranet 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux
    

    bind version

    BIND 9.9.5-9+deb8u6-Debian (Extended Support Version)
    

    named.conf

    include "/etc/bind/named.conf.options";
    include "/etc/bind/named.conf.local";
    include "/etc/bind/named.conf.default-zones";
    

    named.conf.options

    options {
            directory "/var/cache/bind";
    
            forwarders {
                    208.67.222.222; # resolver1.opendns.com
                    208.67.220.220; # resolver2.opendns.com
    #               8.8.8.8; # google-public-dns-a.google.com
    #               8.8.4.4; # google-public-dns-b.google.com
            };
    
            dnssec-enable yes;
            dnssec-validation auto;
            auth-nxdomain no;    # conform to RFC1035
    
            listen-on {
                    127.0.0.1;
                    192.168.10.36;
            };
    
            recursion yes;
            allow-recursion { 127.0.0.0/8; 192.168.10.0/24; };
    
            max-ncache-ttl 0;
    };
    

    named.conf.local

    zone "intranet" {
            type master;
            file "/etc/bind/master/db.intranet";
    };
    
    zone "10.168.192.in-addr.arpa" {
            type master;
            file "/etc/bind/master/db.10.168.192";
    };
    
    zone "box" {
            type master;
            file "/etc/bind/master/db.box";
    };
    

    named.conf.default-zones

    // prime the server with knowledge of the root servers
    zone "." {
            type hint;
            file "/etc/bind/db.root";
    };
    
    // be authoritative for the localhost forward and reverse zones, and for
    // broadcast zones as per RFC 1912
    
    zone "localhost" {
            type master;
            file "/etc/bind/db.local";
    };
    
    zone "127.in-addr.arpa" {
            type master;
            file "/etc/bind/db.127";
    };
    
    zone "0.in-addr.arpa" {
            type master;
            file "/etc/bind/db.0";
    };
    
    zone "255.in-addr.arpa" {
            type master;
            file "/etc/bind/db.255";
    };
    

    DNS results
    If I requst the invalid domain on my server (thor), I get the following:

    user@thor:/etc/bind$ dig @192.168.10.36 sigfail.verteiltesysteme.net
    
    ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @192.168.10.36 sigfail.verteiltesysteme.net
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 11750
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;sigfail.verteiltesysteme.net.  IN      A
    
    ;; Query time: 256 msec
    ;; SERVER: 192.168.10.36#53(192.168.10.36)
    ;; WHEN: Fri Jul 08 21:27:37 CEST 2016
    ;; MSG SIZE  rcvd: 57
    

    If I do the exact same query on my client running Windows 10 using cygwin, I'm getting this:

    user@COMPUTER:~$ dig @192.168.10.36 sigfail.verteiltesysteme.net
    
    ; <<>> DiG 9.10.3-P4 <<>> @192.168.10.36 sigfail.verteiltesysteme.net
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52681
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;sigfail.verteiltesysteme.net.  IN      A
    
    ;; ANSWER SECTION:
    sigfail.verteiltesysteme.net. 60 IN     A       134.91.78.139
    
    ;; AUTHORITY SECTION:
    verteiltesysteme.net.   3600    IN      NS      ns1.verteiltesysteme.net.
    verteiltesysteme.net.   3600    IN      NS      ns2.verteiltesysteme.net.
    
    ;; ADDITIONAL SECTION:
    ns1.verteiltesysteme.net. 2910  IN      A       134.91.78.139
    ns1.verteiltesysteme.net. 2910  IN      AAAA    2001:638:501:8efc::139
    ns2.verteiltesysteme.net. 2910  IN      A       134.91.78.141
    ns2.verteiltesysteme.net. 2910  IN      AAAA    2001:638:501:8efc::141
    
    ;; Query time: 52 msec
    ;; SERVER: 192.168.10.36#53(192.168.10.36)
    ;; WHEN: Fr Jul 08 21:27:46 CEST 2016
    ;; MSG SIZE  rcvd: 197
    

    I hope you can help me.

    Thank you in advance


    -- EDIT --
    Thanks to @HåkanLindqvist I noticed that the configuration was pretty messed up. To clean the thing a bit and to get rid of all those errors, I threw out all forwarding and resolve now on my own. This should not be that big of a deal since the server caches it anyways.
    My named.conf.options looks now like the following:

    options {
            directory "/var/cache/bind";
    
            dnssec-enable yes;
            dnssec-validation auto;
    
            auth-nxdomain no;    # conform to RFC1035
            listen-on {
                    127.0.0.1;
                    192.168.10.36;
            };
    
            recursion yes;
            allow-recursion { 127.0.0.0/8; 192.168.10.0/24; };
    
            max-ncache-ttl 0;
    };
    

    The log shows no more odd errors and invalid signatures are now corretly logged:

    Jul  9 00:33:05 thor named[2940]: validating @0x7fd2d0391140: sigfail.verteiltesysteme.net A: no valid signature found
    Jul  9 00:33:05 thor named[2940]: error (no valid RRSIG) resolving 'sigfail.verteiltesysteme.net/A/IN': 134.91.78.141#53
    

    But my problem with the inconsistent results still remains. Both clients are using the same bind server:

    computer:

    user@COMPUTER:~$ dig +short @192.168.10.36 hostname.bind CH TXT
    "thor.home.intranet"
    user@COMPUTER:~$ dig +short @192.168.10.36 version.bind CH TXT
    "9.9.5-9+deb8u6-Debian"
    

    server:

    user@thor:/etc/bind# dig @192.168.10.36 +short hostname.bind CH TXT
    "thor.home.intranet"
    user@thor:/etc/bind# dig @192.168.10.36 +short version.bind CH TXT
    "9.9.5-9+deb8u6-Debian"
    

    But the results are still different.
    computer:

    user@COMPUTER:~$ nslookup sigfail.verteiltesysteme.net
    Server:         192.168.10.36
    Address:        192.168.10.36#53
    
    Non-authoritative answer:
    Name:   sigfail.verteiltesysteme.net
    Address: 134.91.78.139
    

    server:

    root@thor:/etc/bind# nslookup sigfail.verteiltesysteme.net
    Server:         192.168.10.36
    Address:        192.168.10.36#53
    
    ** server can't find sigfail.verteiltesysteme.net: SERVFAIL
    

    An important thing to note (I think): Even if I send the request on my computer, my server says in the logs that there is no valid signature. That way it definitively recognizes, that the DNSSEC validation fails.. But it sends the NOERROR to my computer anyways.


    -- EDIT2 -- Even with the EDNS flag explicitly set, I still get a result.

    user@COMPUTER:~$ dig @192.168.10.36 +dnssec sigfail.verteiltesysteme.net
    
    ; <<>> DiG 9.10.3-P4 <<>> @192.168.10.36 +dnssec sigfail.verteiltesysteme.net
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48091
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 9
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 4096
    ;; QUESTION SECTION:
    ;sigfail.verteiltesysteme.net.  IN      A
    
    ;; ANSWER SECTION:
    sigfail.verteiltesysteme.net. 60 IN     A       134.91.78.139
    sigfail.verteiltesysteme.net. 60 IN     RRSIG   A 5 3 60 20200610081125 20150611081125 30665 verteiltesysteme.net. //This+RRSIG+is+deliberately+broken///For+more+informati on+please+go+to/http+//dnssec+vs+uni/hyphen/+due+de////r eplace+/hyphen/+with+character////////////////////////// //8=
    
    ;; AUTHORITY SECTION:
    verteiltesysteme.net.   3600    IN      NS      ns2.verteiltesysteme.net.
    verteiltesysteme.net.   3600    IN      NS      ns1.verteiltesysteme.net.
    verteiltesysteme.net.   3600    IN      RRSIG   NS 5 2 3600 20200610081125 20150611081125 30665 verteiltesysteme.net. s4iS0q402GTqtpy1WWspX1KHY3hb0/SOq79qWzRL5PFacAAKK+2ltxWW PTuwsYOWP3l+uq7xu80G0UQNtWPmISa2SYnktvXoZWbdy8F7q8GOH5xw 2t+JokxheEz5Xe4Xy7TmONIxVGq7M9FX4hDBva62PztcGq7UMZMWgyNs P/o=
    
    ;; ADDITIONAL SECTION:
    ns1.verteiltesysteme.net. 69    IN      A       134.91.78.139
    ns1.verteiltesysteme.net. 69    IN      AAAA    2001:638:501:8efc::139
    ns2.verteiltesysteme.net. 69    IN      A       134.91.78.141
    ns2.verteiltesysteme.net. 69    IN      AAAA    2001:638:501:8efc::141
    ns1.verteiltesysteme.net. 69    IN      RRSIG   A 5 3 3600 20200610081125 20150611081125 30665 verteiltesysteme.net. kIcbu+YRC6xby461JYrNE3WSOQmTM6UstxKYo8uO1mEysvfDUs23Yuv6 nG+yMo3enmdIg89pPuLWIsz16uYxswl4DlplCYYPP9nT4d+9bjbMHu5S 7hi/uTlYEFwUCDlyQn38sEwnDHwbBnuW0uvYwV/TPTTjtcfYEw0R8zGI QQU=
    ns1.verteiltesysteme.net. 69    IN      RRSIG   AAAA 5 3 3600 20200610081125 20150611081125 30665 verteiltesysteme.net. PzZiFVbjYHb1+xpIfZGbbtogY94uNvpqHBBibk0Sp7n5BLz4PJZ+dJYc rlikoNK1KyhnHugqCzh6Cr/t23lpioXUPjMWHFYcHsV4kcldTzt7Pl9Q 8h/IvlvtC33TYXnopmmGoV9vbjgpmgpAt//dY8UdNlXD/Dh6CDver+XT 34A=
    ns2.verteiltesysteme.net. 69    IN      RRSIG   A 5 3 3600 20200610081125 20150611081125 30665 verteiltesysteme.net. PVIDSVFi0GLHavnTFj2JnHn+1A/wOAKS8fMzavMhkFycWjudxDuC19uW Ak9vCV5dR/3ZW4UGQUjZFgVI45fQP2yCJ5H98Z7vfn4FF9gxKwGy+TDt dLeOzcdorOF70aYHEWyYWK5tcq1SqXLXJQMp3G/MY362vqCzbFiIUk32 3q4=
    ns2.verteiltesysteme.net. 69    IN      RRSIG   AAAA 5 3 3600 20200610081125 20150611081125 30665 verteiltesysteme.net. Fhg3JLyBsuXG4UCvG3y48gL8lz2Tu5Hx+ClxoXf4NjWs2MK/XScHEzwb UdOhz4aHnZbfWORoXHSD3DR92vBooix+522Z2GhCg1eiXBP66VDyypqT Ar7kUTXJHmsa70k/ubYHC6P6Imy68CbIi5xPr+OFZHrL/CTv9fcLVg3A ikU=
    
    ;; Query time: 53 msec
    ;; SERVER: 192.168.10.36#53(192.168.10.36)
    ;; WHEN: Sa Jul 09 01:07:08 CEST 2016
    ;; MSG SIZE  rcvd: 1277
    

    -- EDIT3 -- I enabled the query log on debug level 10 to ensure that the correct query are being sent. The following three entries are being generated by the query "dig @192.168.10.36 +dnssec sigfail.verteiltesysteme.net"

    09-Jul-2016 01:23:50.419 client 192.168.10.36#47038 (sigfail.verteiltesysteme.net): query: sigfail.verteiltesysteme.net IN A +ED (192.168.10.36)
    09-Jul-2016 01:23:59.620 client 192.168.10.2#64858 (sigfail.verteiltesysteme.net): query: sigfail.verteiltesysteme.net IN A +ED (192.168.10.36)
    09-Jul-2016 01:24:32.417 client 192.168.10.2#54071 (sigfail.verteiltesysteme.net): query: sigfail.verteiltesysteme.net IN A +ED (192.168.10.36)
    

    192.168.10.2 is my computer, 192.168.10.36 is the server on which bind runs.
    I additionally downloaded the current bind version from isc.org as you suggested and run it. The result is the same as with cygwin. The third result in the log above is generated by isc.org bind.


    -- EDIT 4 --

    As a very late but last edit: I finally found the solution. I was using Avast as my AV which seemingly intercepted DNS traffic and forwarded it to their Avast "secure server". Uninstalling Avast and just running Windows Defender solved the problem.

  • Admin
    Admin almost 8 years
    Thanks for your answer! I totally saw that my configuration made not that much sense. I threw out all the forwarding stuff and I'm resolving now on my own. The problem with the inconsistency is still there. I tried your two queries but they both showed up the same result. If I issue the query on my PC the logs also shows "sigfail.verteiltesysteme.net A: no valid signature found" but the result still tells me "status: NOERROR" There is definitively no strange NAT or so involved, I have not set up anything like that.
  • Admin
    Admin almost 8 years
    I just edited my initial start post to add the changed config file and some other things. I still have no idea what's happening here.
  • Håkan Lindqvist
    Håkan Lindqvist almost 8 years
    @Lyrex Does the behavior change at all with +dnssec (sets the DO bit in EDNS)?
  • Admin
    Admin almost 8 years
    No, it does not. It does show the invalid RRSIG but I still get a answer and NOERROR. I'll edit the response into my initial post.
  • Håkan Lindqvist
    Håkan Lindqvist almost 8 years
    @Lyrex I'm confused. Unless the CD flag is set in the query (which it isn't according to the output included in the question!), I don't really understand how the data failing validation is being returned. Could you either enable query logging in named temporarily (or use tcpdump/wireshark/... if you prefer that) and check that the two queries really have the same flags set? If there's a difference, could the Cygwin dig be bugged somehow? I've only used the native win32/win64 dig included in ISC's bind packaging recently for dig on Windows.
  • Admin
    Admin almost 8 years
    I have enabled the query log with debug level 10 and added the results into the first post. I additionally tried to use the latest native win32 dig I just downloaded from isc.org which did not change anything.
  • Admin
    Admin almost 8 years
    I know this topic is on the older side, but I could still not solve the problem. Do you or somebody else have an other idea?