主页 / server / 问题 / 820072
Accepted
Calimo
Asked: 2016-12-12 05:40:14 +0800 CST

如何使用自动 dnssec 更新区域：维护

  • 772

我在 Debian Jessie 上运行权威的 BIND 9.9.5-9+deb8u8-Debian。我有一个可以正常工作的工作区robin.info（各种测试报告成功，例如 pingdom.com 的 DNS 检查工具上的那个）

我正在尝试使用 dnssec 保护它。我正在按照BIND DNSSEC 指南第 4 章中的说明进行操作，轻松上手。我成功生成了 ZSK 和 KSK，并更新了我的区域，添加了粗体行：

区域“robin.info”{
        类型大师；
        文件“/etc/bind/zones/robin.info”；
        包括“/etc/bind/include-zones/acls”；
        密钥目录“/etc/bind/dnssec/robin.info/2016”；
        内联签名是；
        自动dnssec维护；
};

我确保 no .jnl, .jbk,.signed和.signed.jnlfiles 与 zone 文件一起存在，然后重新启动 bind withrndc reload并确认 zone 已加载并具有 DNSKEY 条目，尽管我在日志中有一些错误：

11-Dec-2016 13:54:20.742 zone robin.info/IN/internal (signed): loaded serial 2016121111
11-Dec-2016 13:54:20.742 zone robin.info/IN/external (signed): loaded serial 2016121111
11-Dec-2016 13:54:20.750 zone robin.info/IN/external (signed): receive_secure_serial: unchanged
11-Dec-2016 13:54:20.750 zone robin.info/IN/external (signed): reconfiguring zone keys
11-Dec-2016 13:54:20.766 zone robin.info/IN/external (signed): next key event: 11-Dec-2016 14:54:20.750
11-Dec-2016 13:54:20.796 zone robin.info/IN/internal (signed): receive_secure_serial: unchanged
11-Dec-2016 13:54:20.796 zone robin.info/IN/internal (signed): reconfiguring zone keys
11-Dec-2016 13:54:20.805 malformed transaction: /etc/bind/zones/robin.info.signed.jnl last serial 2016121113 != transaction first serial 2016121111
11-Dec-2016 13:54:20.805 zone robin.info/IN/internal (signed): zone_rekey:dns_journal_write_transaction -> unexpected error

当我想更新我的区域时，这些串行错误似乎会导致问题。我在未签名区域中进行了更改/etc/bind/zones/robin.info，并将我的序列号增加到2016121121

11-Dec-2016 13:57:58.658 zone robin.info/IN/internal (signed): serial 2016121121 (unsigned 2016121121)
11-Dec-2016 13:57:58.658 zone robin.info/IN/internal (signed): could not get zone keys for secure dynamic update
11-Dec-2016 13:57:58.658 zone robin.info/IN/internal (signed): receive_secure_serial: not found
11-Dec-2016 13:57:58.659 malformed transaction: /etc/bind/zones/robin.info.jnl last serial 2016121121 != transaction first serial 2016121111
11-Dec-2016 13:57:58.659 zone robin.info/IN/external (unsigned): not loaded due to errors.
11-Dec-2016 13:57:58.659 all zones loaded
11-Dec-2016 13:57:58.659 running
11-Dec-2016 13:57:58.661 zone robin.info/IN/internal (signed): reconfiguring zone keys
11-Dec-2016 13:57:58.670 malformed transaction: /etc/bind/zones/robin.info.signed.jnl last serial 2016121115 != transaction first serial 2016121111
11-Dec-2016 13:57:58.670 zone robin.info/IN/internal (signed): zone_rekey:dns_journal_write_transaction -> unexpected error
11-Dec-2016 13:57:58.670 zone robin.info/IN/external (signed): reconfiguring zone keys
11-Dec-2016 13:57:58.671 zone robin.info/IN/external (signed): next key event: 11-Dec-2016 14:57:58.670

我可以确认dig我的旧区域仍在加载（来自 SOA 和不可见的更改）。

这里有几个错误消息：

1) 提示我在使用密钥时遇到问题（“无法获取用于安全动态更新的区域密钥”）。但是 bind 在第一次加载时没有问题，并且我的密钥文件可以通过 bind 读取（命名为作为bindgroup 成员的用户运行bind）：

xavier@dent:/etc/bind/zones$ ls -l /etc/bind/dnssec/robin.info/2016
total 17k
-rw-r--r-- 1 root bind  603 Dec 10 17:23 Krobin.info.+008+43324.key
-rw-r----- 1 root bind 1.8k Dec 10 17:23 Krobin.info.+008+43324.private
-rw-r--r-- 1 root bind  604 Dec 10 17:22 Krobin.info.+008+44679.key
-rw-r----- 1 root bind 1.8k Dec 10 17:22 Krobin.info.+008+44679.private

2) 提示连续剧有错误（最初的错误是last serial 2016121113 != transaction first serial 2016121111）。但是我认为我不必为连续剧担心太多，因为在 ISC 的 KB 中我可以读到：

请注意，此响应中的序列号与文件 example.com.db 中的序列号不同。Named 独立于未签名版本跟踪区域的签名版本的序列号。如果未签名区域使用比签名副本中的序列号更高的新序列号进行更新，则签名副本将增加以匹配它，否则两者将保持分开。[1]

到目前为止，我发现更新区域的唯一方法是停止绑定，删除.jnl、和文件，然后重新开始绑定.jbk。这似乎是错误的，我需要确保增加序列号足以激活新区域。我做错了什么，如何修复我的 dnssec？.signed.signed.jnl

bind dnssec

3 个回答

  1. Best Answer

    我想我终于找到了问题的根本原因。我有两个视图，它们被配置为包含两次相同的主区域文件。

    您不能对两个区域使用相同的文件。所以这是无效的，并导致了我的问题：

    view "internal" {
    match-clients ...;
    zone "example.com" {
        type master;
        file "/etc/bind/zones/example.net";
    };
};
view "external" {
    match-clients ...;
    zone "example.com" {
        type master;
        file "/etc/bind/zones/example.net";
    };
};

    “通过示例了解 BIND 9 中的视图”指南的第 4 章描述了共享区域的正确方法。基本上，只有一个 zone 必须是 master zone，而另一个必须是 slave。在正确的位置添加一些 acls、密钥和也通知本地主机后，我摆脱了这些错误。

    最后这是我的最终配置：

    key "internal" {
    // TSIG Key generated with dnssec-keygen -a HMAC-MD5 -b 512 -n USER internal
    algorithm hmac-md5;
    secret "XXXX";
};

view "internal" {
    match-clients { key internal; ...IPs...; }; // our network
    zone "robin.info" {
        type slave;
        file "/etc/bind/slave-zones/robin.info"; // Not the same file as external view!
        masters { 127.0.0.1; };
    };
};

view "external" {
    match-clients { !key internal; "any"; }; // everyone else
    server 127.0.0.1 {
        /* Deliver notify messages to internal view with internal key. */
        keys { internal; };
    };
    zone "robin.info" {
        type master;
        file "/etc/bind/zones/robin.info";
        // ACL file with allow-transfer and also-notify
        // including secondary DNS servers and 127.0.0.1
        include "/etc/bind/acls"; 
        key-directory "/etc/bind/dnssec/robin.info/2017";
        inline-signing yes;
        auto-dnssec maintain;
    };
};
    • 2

  2. 核心似乎是could not get zone keys for secure dynamic update错误消息，因此退回到未签名；并且由于它没有通过自动触发 SOA 进行签名的签名路径，因此它抱怨 SOA 已过时。

    将签名添加到三个区域时，我收到了相同的错误消息并挠了挠头，然后叹了口气，然后完全重新启动命名。这为我解决了它。绑定 9.11.0P3。

    我不记得过去在添加签名时看到过这个问题，但所有其他区域都是很久以前在早期版本的 Bind 下转换的。此外，这三个区域是反向 DNS 文件，因此文件名略有不同。这就是我要解释的全部内容。

    所以：绑定bug，完全重启，让它找到真正的密钥文件然后签名。

    • 1

  3. 我也遇到了类似的问题，也使用了 debian jessie 的绑定。我没有几个视图也没有共享文件，但 bind 抱怨与以下相同的错误：

    11-Dec-2016 13:54:20.796 zone robin.info/IN/internal (signed): reconfiguring zone keys
11-Dec-2016 13:54:20.805 malformed transaction: /etc/bind/zones/robin.info.signed.jnl last serial 2016121113 != transaction first serial 2016121111
11-Dec-2016 13:54:20.805 zone robin.info/IN/internal (signed): zone_rekey:dns_journal_write_transaction -> unexpected error

    我的解决方案是使用

    rndc sync -clean

    以及重新加载绑定（即使未启用动态更新！）。来自男人：

    Sync changes in the journal file for a dynamic zone to the master file. If the 
"-clean" option is specified, the journal file is also removed. If no zone is 
specified, then all zones are synced.
    • 1

相关问题