在调查事件时,我注意到我的系统日志中有一个错误,如下所示(匿名):
Feb 3 21:59:59 ns1 named[18824]: client xxx.xxx.xxx.xxx#2091 (us-east1-aws.api.snapchat.com): view MyView: rpz QNAME rewrite us-east1-aws.api.snapchat.com via us-east1-aws.api.snapchat.com.rpz.vendorsite.com query_getzonedb()failed: zone not loaded
Feb 3 21:59:59 ns1 named[18824]: client yyy.yyy.yyy.yyy#27720 (time-ios.apple.com): view MyView: rpz QNAME rewrite time-osx.g.aaplimg.com via time-osx.g.aaplimg.com.rpz.vendorsite.com query_getzonedb()failed: zone not loaded
Feb 3 21:59:59 ns1 named[18824]: client yyy.yyy.yyy.yyy#27720 (time-ios.apple.com): view MyView: rpz QNAME rewrite time.apple.com via time.apple.com.rpz.vendorsite.com query_getzonedb()failed: zone not loaded
我们已打开查询日志记录。底层是 BIND 9。我们使用供应商提供 DNS 服务,该供应商使用 Spamhaus 作为威胁源。我们订阅了该服务。这种消息对于该服务来说很奇怪。该服务通过从属供应商托管的 RPZ 来实现。
注意到:
- 域中的“rpz”似乎是指响应策略区域问题
- 该服务本应屏蔽的网站并未被屏蔽
- 几乎每个未列入白名单的 DNS 查询都会出现同样的消息
- 错误消息似乎意味着服务 RPZ 无法从主服务器加载
此日志消息意味着什么?为什么这种情况发生在二月中旬?
答案1
事实证明,日志消息的意思是 - 消息中的区域未加载。:-)。更具体地说,RPZ 从属区域无法获取更新。现在来看看显而易见的后续问题:为什么?这里真正的问题是什么?
虽然 RPZ 加载失败可能有多种原因(主服务器关闭、FW 规则更改等),但事实证明我们的问题是我们从未应用新的年度许可证。这就是允许我们订阅服务的 TSIG 密钥所在。
我们的许可证遵循阳历年,那么为什么这种情况会发生在二月中旬呢?原来是供应商给了相当长的宽限期!(此后,它可能达到了刷新或过期限制,最终“死亡”。)
我获得了许可证、申请、部署,然后我们重新开始工作 - 不再有奇怪的日志消息(至少不再像上面描述的那样)。
答案2
我在 Pastebin 中找到了另一个可能的答案:
由于某种原因,我的设置上的 RPZ 重写一直失败,dns 查询日志显示以下内容:
4 月 18 日 12:26:28 Internal-DNS-DHCP 命名 [7257]:客户端 172.16.11.17#58306:rpz QNAME 通过 gateway.fe.apple-dns.net.rpz.local.net 重写 gateway.fe.apple-dns.net query_getzonedb() 失败:区域未加载 4 月 18 日 12:26:31 Internal-DNS-DHCP 命名 [7257]:客户端 172.16.10.13#64377:rpz QNAME 通过 teredo.ipv6.microsoft.com.rpz.local.net 重写 teredo.ipv6.microsoft.com query_getzonedb() 失败:区域未加载
错误是:query_getzonedb()失败:区域未加载
修复:
- 检查您的 Bind DNS 启动日志:
4 月 18 日 12:39:23 Internal-DNS-DHCP 命名 [7551]: zone rpz/IN: 从主文件 /etc/named/zone/response-override.db 加载失败:权限被拒绝
4 月 18 日 12:39:23 Internal-DNS-DHCP 名为 [7551]: 区域 rpz/IN: 由于错误而未加载。
- 修复区域文件权限错误。
- 重新启动命名
- 完毕。