如果对 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 如何使用根服务器后，我删除了邮件服务器的 DNS 转发器值 8.8.8.8 和名称服务器设置，bind9 返回了答案，因为它自己进行查找，而不是将其交给 8.8.8.8 名称服务器。
我已经阅读了至少 50 个有关此问题的网页，但没有一个解释如何解决这个问题的细节。
编辑：该问题的其余部分已被删除，它是多余的，我将就此提出一个单独的问题。
答案1
我认为您对 bind 作为缓存名称服务器的工作方式感到困惑。DNS 转发器实际上仅在您从客户端角度发言时才发挥作用，与配置缓存名称服务器无关。当 bind 查询它没有的记录时，它会遵循解析域名的常规过程，从根服务器开始。我发现此链接以有趣的方式展示该过程的进展。您还可以查看您感兴趣的任何域的整个丑陋过程 - 尝试使用dig +trace serverfault.com。您在那里看到的将是 bind 所遵循的相同解析链。一旦 bind 收到结果并假设已为其启用缓存，后续请求将从缓存中提供，直到记录 TTL 到期，在这种情况下，它会再次执行该过程以刷新其缓存。
因此，如果你设置了一个缓存名称服务器，并尝试查询 URIBL通过如果被拒绝，那么被拒绝的不是 Google，而是您自己的服务器 IP。要确认，请尝试挖掘两个名称服务器 - 您自己的 ( dig @<your_bind_server> test.uribl.com.multi.uribl.com) 和 Google 的 ( dig @8.8.8.8 test.uribl.com.multi.uribl.com)，然后查看被拒绝的位置。
此外，bind 不应该缓存拒绝。