主页 / computer / 问题 / 1727237
Accepted
JothamB
Asked: 2022-06-20 01:09:04 +0800 CST

bind9 不安全证明无法解决

  • 772

我有 2 个 ubuntu 服务器和 bind9 都安装在它们上面。

这是第一个的配置：

options {
    directory "/var/cache/bind";
    forwarders {
        1.1.1.1;
    };
    dnssec-validation auto;
};

zone "example.com" {
    type master;
    file "/etc/bind/zones/db.example.com";
};

$TTL    604800
@   IN  SOA dns-srv. root.dns-srv. (
                  2     ; Serial
             604800     ; Refresh
              86400     ; Retry
            2419200     ; Expire
             604800 )   ; Negative Cache TTL
;
@   IN  NS  dns-srv.
@   IN  A   172.16.194.4
www IN  A   172.16.194.4

这些是第二个的配置：

options {
        directory "/var/cache/bind";
        forwarders {
                172.16.194.3;
        };
        dnssec-validation auto;
};

所以第一个 dns 服务器将请求转发到 1.1.1.1，第二个 dns 服务器将请求转发到第一个 dns 服务器 172.16.194.3。

我从第一台服务器上的公共 dns 查询名称没有问题，将查询转发到第二台服务器也没有问题。有用。每个使用第二个 dns 服务器的主机都可以查询和获得回复。问题出在第一个 dns 服务器上定义的区域“example.com”上。当第二个 dns 服务器向第一个 dns 服务器查询“example.com”时，我收到错误：insecurity proof failed resolving 'example.com/A/IN': 172.16.194.3#53

为什么我会收到此错误，我该怎么做才能使第二个 dns 服务器解析在第一个 dns 服务器上定义的区域？

在两台服务器上，操作系统都是 ubuntu 服务器 20.4，绑定版本是 9.16

dns bind

1 个回答

  1. Best Answer

    为什么我会收到此错误

    因为您正在篡改 DNSSEC 签名区域。在这种情况下，错误消息是正常的，因为您所做的正是 DNSSEC 应该阻止的事情。

    Internet 上的真实 example.com区域是 DNSSEC 签名的，并且父com区域具有指示其签名密钥的 DS 记录（以及用于委托的通常 NS 记录）。当 Server#2 上的验证解析器找到这些 DS 记录时，它知道它应该接收 example.com 的签名数据，因此它从 Server#1 获取的未签名记录是未经授权的。

    （“不存在证明”指的是该com区域对于实际未签名区域的 NSEC 记录——NSEC 记录基本上说“有这些类型的记录，没有其他类型的记录”，在这种情况下，它将用于证明没有合法未签名区域的 DS 记录。）

    我该怎么做才能使第二个 dns 服务器解析在第一个 dns 服务器上定义的区域？

    首先，不要使用属于其他人的区域名称。使用您自己控制的域名——您可以为其发布一个实际的 NS 委托。

    即使由于某种原因您实际上不能将域委派给 Server#1，但仍要确保将其委派给某些名称服务器（即有 NS 记录），以便解析器能够获得他们想要的 NSEC 答案。不管委托指向哪里，验证器只检查 DS 记录，而不检查 NS。

    （home.arpa域名已以这种方式设置——它专门用于被家庭网关“覆盖”，因此您可以将其用作如何设置自己的（子）域以安全覆盖的示例。）

    最后，如果它必须是一个完全不受您控制的名称（例如，如果您想实际使用，example.com或者如果您想制作一个像直接在您的解析器中“信任锚”。验证过程向上进行，直到找到信任锚——通常它一直到达根，但 BIND 允许您为所需的任何域进行配置。.blahtrust-anchors{}

    一些验证解析器还支持“负信任锚”，允许您手动将某些域配置为从未验证，但在 BIND 中，这仅支持作为自动过期设置，rndc nta而不是您可以永久放入配置文件的设置。

    • 0

相关问题