无法解析1.2.3.4.list.dsbl.org

Question

历史记录:一切都从这个日志条目开始

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+Debian <<>> a 1.2.3.4.list.dsbl.org ;；全局选项：+cmd ;；得到答案：；->头<->头<-操作码:查询，状态: id: 12810；标志: qr ra；查询: 1，回答: 0，权威: 0，附加:1；1.2.3.4.list.dsbl.org。在A；查询时间:0毫秒;；服务器: 127.0.0.1#53(127.0.0.1)；时:12/ 04 12:55:36 UTC 2017 ;；MSG大小rcvd: 50

3-4秒后，就失败了。尝试Google的公共DNS：

挖掘一个1.2.3.4.list.dsbl.org @8.8.8.8；<<>> dig 9.9.5-9+Debian <<>> a 1.2.3.4.list.dsbl.org @8.8.8；全局选项：+cmd ;；获取答案：；>头<->标题<- opcode:查询，状态: SERVFAIL，id: 62982；标志: qr ra；查询: 1，回答: 0，权威: 0，附加:1 ;；udp: 512；问题部分：;1.2.3.4.list.dsbl.org。在A；查询时间: 28毫秒;；服务器: 8.8.8.8#53(8.8.8.8)；时: Jan : Wed 04 12:57:28 UTC 2017 ;；MSG大小rcvd: 50

当这个起作用的时候

挖掘一个somedomain.com；<<>> dig 9.9.5-9+Debian <<>> a somedomain.com ;；全局选项：+cmd ;；得到答案：；>头<->标题<- opcode:查询，状态: NOERROR，id: 35713；标志: qr ra；查询: 1，回答: 1，权威: 2，附加:5；选择PSEUDOSECTION：；EDNS:版本: 0，标志：；udp: 4096 ;；问题部分：;somedomain.com。在A ;；回答部分: somedomain.com。[ 300 ]A 69.172.201.153；权威部分: somedomain.com。172800在NS sell.internettraffic.com。somedomain.com。172800在NS buy.internettraffic.com。补充部分: buy.internettraffic.com。172800在64.96.240.54 buy.internettraffic.com。172800在64.96.241.73 sell.internettraffic.com。172800在176.74.176.176 sell.internettraffic.com。172800 : 176.74.176.175；查询时间: 49毫秒；服务器: 127.0.0.1#53(127.0.0.1)；时间: Wed 04-12:56:30 UTC 2017；MSG大小rcvd: 176

注解:仅在/etc/resolv.conf中使用google的DNS在本地运行良好，当我重新启动后缀时，文件正在/var/spool/postfix/etc/resolv.conf中被复制，但与主机无法解析的日志相同。

我遗漏了什么？

Answer 1

DSBL已于2008年底停用；有一段时间(一年？)他们的DNS仍然解析查询。

虽然一些旧的指令可能会引用他们的黑名单/域，但是不应该配置这个列表，因为它已经消失了，并且DNS请求不再解析了。

Google有解决已知问题的快捷方式/优化，这个域可能在黑名单或某种RPZ配置中；在它们大规模的操作中，我也会对仍然被配置的地址做同样的操作，因为试图解决不存在的域占用了宝贵的资源。

一些类似的配置也是“好”网民的一部分，因为创建类似的黑名单过滤请求，其最终结果是在顶级根名服务器(TLD)上节省资源。

强化Google自定义的想法，这是大家都知道的，他们有自定义代码，而且众所周知，他们(过去)有一些“不寻常”的功能，例如，在性能的名义下忽略RR中太低的TTL。(从那时起，BIND创建了一个全局选项来定义您接受的较低的RR (如果我没有弄错的话)。

我不知道，因为您有一个服务器，它通过配置dsbl.org黑名单保存了这么长时间，因为当这个地址被终止时，由于电子邮件服务器延迟，我们不得不将它从黑名单配置中删除。

根据请求，将绑定中的域列入黑名单：

/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"; };
}

另请参阅：

用于bind9 9的大区域文件:ad-阻塞

(、加密+ RPZ黑名单/白名单)

用不同级别的域绑定RPZ配置

Answer 2

DSBL已经消失，DSBL已经消失，并且极不可能返回。请从您的邮件服务器配置中删除它。

• http://dsbl.org/node/3