历史：一切都从这个日志条目开始
postfix/smtpd[10001]: warning: x.x.x.x.list.dsbl.org: RBL lookup error: Host or domain name not found. Name service error for name=x.x.x.x.list.dsbl.org type=A: Host not found, try again
我尝试手动解决它，确实超时了。尝试使用 Google 的公共 DNS 服务器效果很好，戏剧就开始了：
我已将绑定配置为允许从本地主机进行递归，然后将 DNS 服务器切换为/etc/resolv.conf用作127.0.0.1名称服务器。另外，我尝试将 google 的公共 DNS 服务器指定为转发器，并且没有它们（询问根服务器）。结果是相同的：
挖一个 1.2.3.4.list.dsbl.org
; <<>> DiG 9.9.5-9+deb8u7-Debian <<>> a 1.2.3.4.list.dsbl.org ;;全局选项：+cmd ;;得到答案：;; ->>HEADER<<- 操作码：QUERY，状态：SERVFAIL，id：12810 ;;标志：qr rd ra；查询：1，答案：0，权限：0，附加：1
;;选择伪节：; EDNS：版本：0，标志：； UDP：4096；；问题部分：;1.2.3.4.list.dsbl.org。在一个
;;查询时间：0毫秒；；服务器：127.0.0.1#53(127.0.0.1);;时间： UTC 2017 年 1 月 4 日星期三 12:55:36 ;;味精大小 rcvd：50
3-4秒后，失败。尝试使用 Google 的公共 DNS：
挖一个 1.2.3.4.list.dsbl.org @8.8.8.8
; <<>> DiG 9.9.5-9+deb8u7-Debian <<>> 1.2.3.4.list.dsbl.org @8.8.8.8 ;;全局选项：+cmd ;;得到答案：;; ->>HEADER<<- 操作码：QUERY，状态：SERVFAIL，id：62982 ;;标志：qr rd ra；查询：1，答案：0，权限：0，附加：1
;;选择伪节：; EDNS：版本：0，标志：； UDP: 512;;问题部分：;1.2.3.4.list.dsbl.org。在一个
;;查询时间：28毫秒；；服务器：8.8.8.8#53(8.8.8.8);;时间：2017 年 1 月 4 日星期三 12:57:28 UTC 2017 ;;味精大小 rcvd：50
虽然这个有效
挖一个 somedomain.com
; <<>> DiG 9.9.5-9+deb8u7-Debian <<>> a somedomain.com ;;全局选项：+cmd ;;得到答案：;; ->>HEADER<<- 操作码：QUERY，状态：NOERROR，id：35713 ;;标志：qr rd ra；查询：1，答案：1，权限：2，附加：5
;;选择伪节：; EDNS：版本：0，标志：； UDP：4096；；问题部分：;somedomain.com。在一个
;;答案部分：somedomain.com。 300 于 69.172.201.153
;;权威部分：somedomain.com。 172800 IN NS sell.internettraffic.com。 somedomain.com。 172800 IN NS buy.internettraffic.com。
;;附加部分：buy.internettraffic.com。 172800 IN A 64.96.240.54 buy.internettraffic.com。 172800 IN A 64.96.241.73 sell.internettraffic.com。 172800 IN A 176.74.176.176 sell.internettraffic.com。 172800 在 176.74.176.175
;;查询时间：49 毫秒；；服务器：127.0.0.1#53(127.0.0.1);;时间：2017 年 1 月 4 日星期三 12:56:30 UTC 2017 ;;味精大小 rcvd：176
脚注：仅使用谷歌的 DNS 在/etc/resolv.conf本地工作正常，当我重新启动 postfix 时，文件正在被复制，/var/spool/postfix/etc/resolv.conf但仍然是无法解析主机的相同日志。
我缺少什么？
答案1
DSBL已于2008年底停产；很长一段时间（一年？）他们的 DNS 仍然解决了查询。
虽然一些旧的说明可能会引用其黑名单/域，但不建议配置该列表，因为它早已消失，并且 DNS 请求不再解析。
Google DNS 有解决已知问题的快捷方式/优化，并且该域可能位于黑名单或某种 RPZ 配置中；在大规模操作中，我也会对仍然大量配置的地址执行相同的操作，因为尝试解决不存在的域会占用宝贵的资源。
一些类似的配置也是成为“好”网民的一部分，因为创建类似的黑名单过滤请求，最终结果是节省顶级根名称服务器（TLD）上的资源。
强化 Google 定制的理念，众所周知，他们拥有定制代码，而且众所周知，他们（曾经）具有一些“不寻常”的功能，例如，以性能的名义忽略 RR 中过低的 TTL。 （从那时起，BIND 创建了一个全局选项来定义您为 RR 接受的较低 TTL，如果我没记错的话）
我不知道您的服务器在dsbl.org配置了黑名单的情况下存活了这么长时间，因为当该地址停止使用时，由于电子邮件服务器延迟，我们必须将其从黑名单配置中删除。
根据要求，将 BIND 中的域列入黑名单：
区域文件在/etc/bind/rpz.db
*.list.dsbl.org CNAME *.
将区域文件添加到named.conf或添加到定义的内部视图：
zone "rpz" {
type master;
file "/etc/bind/rpz.db";
allow-query { your_internal_network; };
};
添加named.conf.options：
options {
...
response-policy { zone "rpz"; };
}
另请参阅：
答案2
DSBL 已消失 DSBL 已消失并且极不可能返回。请将其从您的邮件服务器配置中删除。