我使用 RPZ 将一些域列入黑名单，我的配置如下：
*.com A 127.0.0.1
mydomain.net A 127.0.0.1
如果我查询任何域名 .com，它都能正常工作，给我 127.0.0.1
让我们dig fun.com @localhost，我的回复是：
;; ANSWER SECTION:
fun.com. 5 IN A 127.0.0.1
现在让我们编辑之前的配置并使我的区域现在看起来像：
*.com A 127.0.0.1
mydomain.net A 127.0.0.1
this.fun.com 127.0.0.1
这是不必要的，因为主服务器*.com应该涵盖所有情况，但是我的域由多个源加载，因此列表会自动编译，这样的事情可能会发生。
虽然这似乎是一个无害的更改，如果我这样做，dig this.fun.com @localhost它会再次回复如下内容：
;; ANSWER SECTION:
this.fun.com. 5 IN A 127.0.0.1
如果我现在查询根域，dig fun.com @localhost我将得到：
;; ANSWER SECTION:
fun.com. 86400 IN A 209.61.131.188
就像..什么？这里发生了什么？从上部全包添加this.fun.com屏蔽主域？fun.com*.com
这是绑定的想要的行为吗？我是不是发现了什么奇怪的bug？
如何避免这种情况呢？我应该编写一个脚本来递归所有域，删除包含在较大域中的域吗？ （烦人但可行 - 寻找更好的替代方案）
TL;DR：在绑定 rpz 中添加第三级域，以便将其列入黑名单，使第二级域不遵循主过滤器导致的白名单。
答案1
至于 BIND RPZ 行为和正则表达式：*.com将以下所有 DNS 子域列入黑名单com，然而如果您打算将com根域本身列入黑名单，您需要添加到 rpz 文件中：
com
所以如果不将com引入到rpz列表中，就会解决。你所描述的情况属于正常行为。
至于 RPZ 黑名单解析器，我建议编写一个，至少可以节省资源。运行时的影响应该很小，因为 BIND 使用哈希表，但是重新启动 BIND 时读取 RPZ 表的延迟很明显（例如，当 BIND 读取和解析 RPZ 表时），并且它使用的内存稍多。我还没有写过这样的解析器目前。