在调查事件时,我注意到我的系统日志中有一个错误,看起来像这样(匿名):
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 无法从主服务器加载
此日志消息是什么意思?为什么这会发生在二月中旬?
事实证明,日志消息意味着 - 消息中的区域未加载。:-)。更具体地说,RPZ 从属区域无法获得更新。现在是明显的后续问题:为什么?这里真正的问题是什么?
虽然 RPZ 无法加载可能有几个原因(主服务器关闭、FW 规则更改等),但我们的问题是我们从未应用新的年度许可证。这就是 TSIG 密钥允许我们订阅服务的地方。
我们的许可证遵循阳历年,那么为什么会在 2 月中旬发生这种情况?事实证明,供应商提供了相当长的宽限期!(之后它可能会达到刷新或过期限制并最终“死亡”。)
我获得了许可证,申请了,部署了,我们又恢复了业务——不再有奇怪的日志消息(至少不再像上面描述的那样)。
我在 Pastebin 中找到了另一个可能的答案:
https://pastebin.com/NCwum7up