0

Update: I should have checked the BIND change-log to start with, I see this entry between the two versions I was using:

4957. The default setting for "dnssec-validation" is now
      "auto", which activates DNSSEC validation using the
      IANA root key. (The default can be changed back to
      "yes", which activates DNSSEC validation only when keys
      are explicitly configured in named.conf, by building
      BIND with "configure --disable-auto-validation".)
      [GL #30]

Apparently DNSSEC has been "off" by default until recently, at least in my config which doesn't have keys "explicitly configured in named.conf".

I'm leaving the question open because I'd still like to figure out why DNSSEC works when I have named.conf pointed to Google (8.8.8.8) but not when I have it pointed to my local router (192.168.1.1).


After a recent upgrade of my Arch Linux packages, I found that DNS requests were no longer working. I traced the problem to my local BIND configuration. (I have /etc/resolv.conf pointing to localhost (127.0.0.1) so that I can intercept DNSBL queries and forward them directly to the relevant servers, thus avoiding URIBL_BLOCKED rule hits in Spamassassin)

The named output mentioned "broken trust chain", which led me to this thread. Then I got the idea to play around with dnssec-enable and dnssec-validate options in named.conf. Setting both options to "yes" makes it work again, but ironically this combination has the effect of disabling DNSSEC. Apparently setting dnssec-enable to "yes" and dnssec-validate to "auto" forces DNSSEC and recreates the problem for me.

The problem goes away when I change the "forwarders" line from 192.168.1.1 (my router) to 8.8.8.8 (Google's public DNS).

Here is my named.conf:

options {
    # 10 Aug 2018 setting dnssec-validation to "no" or "yes"
    # makes it work; "auto" breaks it
    dnssec-validation yes;

    directory "/var/named";
    pid-file "/run/named/named.pid";

    allow-recursion { 127.0.0.1; };
    allow-transfer { none; };
    allow-update { none; };

    version none;
    hostname none;
    server-id none;

    forward only;
    forwarders {
        # problem goes away if I change this to 8.8.8.8
        192.168.1.1;
    };
};

zone "localhost" IN {
    type master;
    file "localhost.zone";
};

zone "0.0.127.in-addr.arpa" IN {
    type master;
    file "127.0.0.zone";
};

zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
    type master;
    file "localhost.ip6.zone";
};

zone "255.in-addr.arpa" IN {
    type master;
    file "empty.zone";
};

zone "0.in-addr.arpa" IN {
    type master;
    file "empty.zone";
};

zone "." IN {
    type hint;
    file "root.hint";
};

This is the output of named when I do a failed lookup. I'm including the output for two separate lookups because they seem to be slightly different, only the second one mentions "broken trust chain":

$ ping google.com
ping: google.com: Name or service not known

$ sudo named -d 2 -f -g -u named
...
14-Aug-2018 23:24:55.701 fetch: google.com/A
14-Aug-2018 23:24:55.744 delete_node(): 0x7f82b150b010 google.com (bucket 3)
14-Aug-2018 23:24:55.744 delete_node(): 0x7f82b150b010 google.com (bucket 3)
14-Aug-2018 23:24:55.744 delete_node(): 0x7f82b150d010 ns1.google.com (bucket 0)
14-Aug-2018 23:24:55.744 delete_node(): 0x7f82b150d010 ns2.google.com (bucket 11)
14-Aug-2018 23:24:55.744 delete_node(): 0x7f82b150d010 ns3.google.com (bucket 2)
14-Aug-2018 23:24:55.744 delete_node(): 0x7f82b150d010 ns4.google.com (bucket 5)
14-Aug-2018 23:24:55.744 fetch: com/DS
14-Aug-2018 23:24:55.746 no valid RRSIG resolving 'com/DS/IN': 192.168.1.1#53
14-Aug-2018 23:24:55.746 delete_node(): 0x7f82b150b010 google.com (bucket 3)
14-Aug-2018 23:24:55.746 no valid DS resolving 'google.com/A/IN': 192.168.1.1#53
14-Aug-2018 23:24:55.746 client @0x7f82ac0aa5e0 127.0.0.1#54841 (google.com): query failed (SERVFAIL) for google.com/IN/A at query.c:10721
14-Aug-2018 23:24:55.746 fetch completed at resolver.c:4017 for google.com/A in 0.045257: SERVFAIL/no valid DS [domain:.,referral:1,restart:2,qrysent:1,timeout:0,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:1,qminsteps:1]
14-Aug-2018 23:24:55.747 client @0x7f82a402d9d0 127.0.0.1#54841 (google.com): servfail cache hit google.com/A (CD=0)
14-Aug-2018 23:24:55.747 client @0x7f82a402d9d0 127.0.0.1#54841 (google.com): query failed (SERVFAIL) for google.com/IN/A at query.c:6112
...
15-Aug-2018 00:20:10.998 fetch: google.com/A
15-Aug-2018 00:20:11.040 delete_node(): 0x7f267b6e7160 ns2.google.com (bucket 0)
15-Aug-2018 00:20:11.040 delete_node(): 0x7f267b6e70f0 ns1.google.com (bucket 11)
15-Aug-2018 00:20:11.041 delete_node(): 0x7f267b6e7160 ns4.google.com (bucket 14)
15-Aug-2018 00:20:11.041 delete_node(): 0x7f267b6e70f0 ns3.google.com (bucket 9)
15-Aug-2018 00:20:11.041 validating google.com/A: bad cache hit (com/DS)
15-Aug-2018 00:20:11.041 broken trust chain resolving 'google.com/A/IN': 192.168.1.1#53
15-Aug-2018 00:20:11.041 client @0x7f26740aa5e0 127.0.0.1#58953 (google.com): query failed (SERVFAIL) for google.com/IN/A at query.c:10721
15-Aug-2018 00:20:11.041 fetch completed at resolver.c:5276 for google.com/A in 0.042605: broken trust chain/broken trust chain [domain:.,referral:1,restart:1,qrysent:1,timeout:0,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:1,qminsteps:1]
15-Aug-2018 00:20:11.041 client @0x7f2674055aa0 127.0.0.1#58953 (google.com): servfail cache hit google.com/A (CD=0)
15-Aug-2018 00:20:11.041 client @0x7f2674055aa0 127.0.0.1#58953 (google.com): query failed (SERVFAIL) for google.com/IN/A at query.c:6112

With the above named.conf, I can resolve dnssec-failed.org, which as I understand it is a bad thing:

$ host dnssec-failed.org 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases: 

dnssec-failed.org has address 69.252.80.75

I cannot resolve this if I use 8.8.8.8 as the forwarder.

I'm curious about the cause of the problem and the solution, but I'm also curious how I should properly debug a failed host lookup. Maybe all the necessary information is in the debugging output I posted, or maybe there is a tool that I don't know about, like traceroute for DNS or something.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.