如何调试损坏 dnssec 的本地命名

2024-6-19 • tag-icon

更新：我应该首先检查 BIND 更改日志，我在我使用的两个版本之间看到了这个条目：

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]

显然，直到最近，DNSSEC一直默认处于“关闭”状态，至少在我的配置中是这样的，因为它没有“在named.conf中明确配置”的键。

我没有回答这个问题，因为我仍然想弄清楚为什么当我指向named.confGoogle（8.8.8.8）时 DNSSEC 可以工作，而当我将其指向我的本地路由器（192.168.1.1）时却不工作。

最近升级 Arch Linux 软件包后，我发现 DNS 请求不再起作用。我将问题追溯到本地绑定配置。（我/etc/resolv.conf指向 localhost (127.0.0.1)，这样我就可以拦截域名解析查询并直接转发到相关服务器，从而避免 Spamassassin 中出现 URIBL_BLOCKED 规则）

输出named中提到“信任链断裂”，这让我想到此主题。然后我就有了玩弄的想法dnssec-enable 和 dnssec-validate 选项在中named.conf。将两个选项都设置为“是”可以使其再次工作，但讽刺的是，这种组合具有禁用的效果DNSSEC。显然，设置dnssec-enable为“是”和dnssec-validate“自动”会强制 DNSSEC 并为我重现该问题。

当我将“转发器”行从 192.168.1.1（我的路由器）更改为 8.8.8.8（Google 的公共 DNS）时，问题就消失了。

这是我的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";
};

这是我执行失败查找时的输出named。我包括了两个单独查找的输出，因为它们似乎略有不同，只有第二个查找提到了“信任链中断”：

$ 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

通过上述内容named.conf，我可以解决dnssec-failed.org，据我所知，这是一件坏事：

$ 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

如果我使用 8.8.8.8 作为转发器，则无法解决此问题。

我很好奇问题的原因和解决方案，但我也想知道如何正确调试失败的主机查找。也许所有必要的信息都在我发布的调试输出中，或者也许有一个我不知道的工具，比如tracerouteDNS 之类的。

相关内容