‘query_getzonedb()失败:区域未加载’DNS日志中的错误

Question

在调查一起事件时，我注意到我的syslog中出现了如下(匿名)错误：

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未能从主服务器加载服务。

这条日志信息是什么意思？为什么这样的事情发生在二月中旬？

Answer 1

结果，日志消息的意思是-消息中的区域未被加载。-)。更具体地说，RPZ从区无法获得更新。下面是显而易见的后续问题:为什么？这里真正的问题是什么？

虽然RPZ可能有几个原因无法加载(主服务器故障、FW规则更改等)原来我们的问题是我们从来没有申请过新的年度许可证。这就是TSIG密钥允许我们订阅服务的地方。

我们的许可证遵循太阳日历年，那么为什么会在二月中旬发生这种情况呢？结果是有一个很大的宽限期从供应商！(在此之后，它可能会达到刷新或过期限制，最后“死亡”。)

我获得了许可证，应用了，部署了，我们回到了业务中--不再有奇怪的日志消息(至少不再像上面所描述的那样)。