我遇到了一些问题,本应是内部视图(使用 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
显然,内部区域通知是从主服务器发送的,但从服务器上的外部区域收到了通知。
我似乎有与此非常相似的问题:
我已经审查了这个问题,它与通知和多个视图有些相关:
我已经审查过这个问题,它可能是相关的:
和这个:
这是我的主区域通知:
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-clients
的match-destinations
和match-recursive-only
设置命中第一个匹配的视图。没有“相同视图”的固有概念。
只要您确保所有“维护”操作都使用与相关视图对应的密钥的 TSIG 签名消息,您的基于 TSIG 的解决方案(创建一个密钥来代表每个视图并基于!key otherview1; !key otherview2; key thisview; ...
-style 设置进行匹配)就应该可以解决问题。(签名通知、签名区域传输等)