使用多个视图绑定 DNS 区域通知

使用多个视图绑定 DNS 区域通知

我遇到了一些问题,本应是内部视图(使用 RFC1918 地址和公共 IPv6)的区域泄漏到外部视图(公共 IPv4 和公共 IPv6)。我想我把它固定在主notify explicit服务器上,但没有固定在从服务器上。我认为这导致从服务器以某种方式通知自己(因为我可以看到来自它自己的 IPv6 地址的通知导致内部区域以某种方式转移到外部。我昨晚留下了一些测试记录,在内部视图和外部视图上有一个虚拟主机名和一个不同的无意义 IP。我今天验证了客户端到目前为止看到的响应是正确的。

但是,区域日志显示,始终是外部视图报告被更新,即使两个区域都返回了正确的数据。以下结果是在主服务器上更改内部视图区域并运行 systemctl reload named 后的日志:

主显示区域从内部通知(看起来不错)

28-Jan-2023 10:24:59.831 general: info: reloading configuration succeeded
28-Jan-2023 10:24:59.833 general: info: reloading zones succeeded
28-Jan-2023 10:24:59.835 zoneload: info: zone host.example.org/IN/internal: loaded serial 2023012851
28-Jan-2023 10:24:59.839 notify: info: zone host.example.org/IN/internal: sending notifies (serial 2023012851)

以下是从属设备上的相应日志(显示外部区域通知)

28-Jan-2023 10:24:59.841 notify: info: client @0xabcdef 192.168.240.12#35167: view external: received notify for zone 'host.example.org'
28-Jan-2023 10:24:59.841 general: info: zone host.example.org/IN/external: notify from 192.168.240.12#35167: serial 2023012851

显然,内部区域通知是从主服务器发送的,但从服务器上的外部区域收到了通知。

我似乎有与此非常相似的问题:

BIND 区域传输的两个视图

我已经审查了这个问题,它与通知和多个视图有些相关:

在 DNS 视图上绑定通知

我已经审查过这个问题,它可能是相关的:

拆分视图绑定 DNS 系统上的区域传输

和这个:

BIND 区域还通知语法

这是我的主区域通知:

also-notify { 192.168.240.11; };
allow-transfer { key keytransfer; };

在奴隶身上:

masters { 192.168.240.12 key keytransfer; };

我见过其他帖子使用一个内部区域独有的 tsig 密钥和一个外部区域独有的 tsig 密钥(再次......这个家伙BIND 区域传输的两个视图),但仍然有问题,因此删除了该部分配置。我正在借助以下内容再次尝试:

https://kb.isc.org/docs/aa-00296

更新 1 好的,我根据我的观点实现了以下内容,它似乎按预期工作,并且我在日志中看到了适当的通知:

view "internal" {
    match-clients   { !key keyexternal; key keyinternal; private_nets; };

view "external" {
    match-clients   { !key keyinternal; key keyexternal; any; };

在我尝试再次加载完整的内部区域之前,是否需要进行其他更改?

答案1

在 BIND9 中使用视图时,任何给定的传入 DNS 消息(查询、通知、更新、区域传输等)将仅根据您定义的视图match-clientsmatch-destinationsmatch-recursive-only设置命中第一个匹配的视图。没有“相同视图”的固有概念。

只要您确保所有“维护”操作都使用与相关视图对应的密钥的 TSIG 签名消息,您的基于 TSIG 的解决方案(创建一个密钥来代表每个视图并基于!key otherview1; !key otherview2; key thisview; ...-style 设置进行匹配)就应该可以解决问题。(签名通知、签名区域传输等)

相关内容