Bind9是如何作为私有DNS工作的，以避免URIBL查询被拒绝？

Question

如果对URIBL的查询被阻止，因为URIBL“检测到”您的DNS查询使用的dns解析器ip地址已经进行了太多的查询并超过了限制.

如何使用像Bind9这样的本地DNS服务？

我有限的理解是：

当启动对URIBL提供程序的查询时，

本地Bind9区域将不包含任何有关URIBL的记录

因此，它需要转到DNS转发器来解析URIBL编辑:我的术语是不正确的。Bind9将查询rootsrvrs以获取gTLD提示。

但是，如果服务器的dns转发器为8.8.8.8 ( Google dns场)，并且该ip地址已被拒绝向URIBL查询，

你怎么才能避开这个明显的陷阱-22？

编辑:在学习了bind9如何使用根srvrs之后，我删除了dns转发器值8.8.8.8和邮件服务器的名称服务器设置，bind9返回了一个答案，因为它是自己进行查找，而不是将其传递给8.8.8.8名称服务器。

我已经阅读了至少50个关于这方面的网页，但没有一个解释它是如何解决的细节。

编辑:这个问题的其余部分被删除了，这是多余的，我会问一个关于它的单独问题。

Answer 1

我认为您对bind作为缓存名称服务器的工作方式感到困惑。DNS转发器实际上只在您从客户端角度发言时才起作用，并且与配置缓存名称服务器的上下文无关。当查询bind是否有它没有的记录时，它遵循解析域名的常规过程，从根服务器开始。我发现此链接是演示这个过程所发生的事情的一个有趣的方法。您还可以看到您感兴趣的任何域的整个丑陋过程--使用dig +trace serverfault.com尝试它。您所看到的将有相同的解析链，绑定如下。一旦bind接收到结果，并假设为其启用了缓存，则将从缓存中处理后续请求，直到记录TTL过期为止，在这种情况下，它将再次执行该过程以刷新其缓存。

因此，如果您设置了一个缓存名称服务器，并且试图通过它来查询URIBL，并且它被拒绝了，那么它不会是Google被拒绝的--它将是您自己的服务器IP。要确认，尝试挖掘两个名称服务器--你自己的(dig @<your_bind_server> test.uribl.com.multi.uribl.com)和谷歌(dig @8.8.8.8 test.uribl.com.multi.uribl.com)，看看拒绝发生在哪里。

此外，不，绑定不应该缓存拒绝。