DNS劫持与RBL使用

出处：www.anti-spam.org.cn 作者：wxy 时间：2008-10-21 11:12:14

　　最近接到了一些反馈说，在使用我们的RBL时，会拒绝所有入站信件。据我们判断，应该是查询者使用了具有DNS劫持的DNS服务器所导致。

　　首先，我们先简单说一下RBL的原理。目前用于垃圾邮件过滤的RBL服务，应该称之为基于DNS的实时黑名单查询，也就是说，这个服务是通过DNS协议来完成的。

　　具体而言，当一个客户端希望查询某个IP地址（如11.22.33.44）是否在某个RBL（如cbl.anti-spam.org.cn）中是，其实际上是查询如下地址是否存在解析： 44.33.22.11.cbl.anti-spam.org.cn. （IP地址逆转附加在RBL地址后）。DNS的解析分为几种类型，对于RBL查询，通常是查询这个地址是否存在A记录、TXT记录或者任意（ANY）记录。

　　如果该地址被列入了这个RBL，那么查询会返回一个具体的解析结果，根据RBL和查询的不同，可以返回一段文本，也可以返回一个或几个IP地址，也可以同时返回文本和IP。返回的文本通常是一个说明，用来说明这个IP地址被列入了哪个RBL，具体信息去哪里查询等。返回的IP地址并不具有实际意义，只是标识该查询有结果，通常这个IP地址是一个保留IP段的地址，如127.0.0.1、127.0.0.2等。

　　如果该地址没有被列入这个RBL，那么该查询会返回一个查询错误（NXDOMAIN），表示该地址未列入。DNS劫持就发生在这里，具体情况我们下面再详细解释。

　　举例说明这个查询过程：

　　当查询的IP地址不在RBL中时，返回状态为MXDOMAIN。

# dig 44.33.22.11.cbl.anti-spam.org.cn.

; <<>> DiG 9.3.3rc2 <<>> 44.33.22.11.cbl.anti-spam.org.cn.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 58553
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;44.33.22.11.cbl.anti-spam.org.cn. IN A

;; AUTHORITY SECTION:
cbl.anti-spam.org.cn. 3600 IN SOA cbl.anti-spam.org.cn. wxy.anti-spam.org.cn. 2008061006 14400 3600 14400 3600

;; Query time: 8 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jun 10 09:28:55 2008
;; MSG SIZE rcvd: 90

　　当查询的IP地址在RBL中时，返回状态为NOERRO，并给出具体的结果：127.0.8.2（这里使用RBL的测试地址127.0.0.2，通常RBL都会提供一个特定地址，用于测试RBL是否工作）。

# dig 2.0.0.127.cbl.anti-spam.org.cn.

; <<>> DiG 9.3.3rc2 <<>> 2.0.0.127.cbl.anti-spam.org.cn.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5032
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 0

;; QUESTION SECTION:
;2.0.0.127.cbl.anti-spam.org.cn. IN A

;; ANSWER SECTION:
2.0.0.127.cbl.anti-spam.org.cn. 10800 IN A 127.0.8.2

;; AUTHORITY SECTION:
cbl.anti-spam.org.cn.   10800   IN      NS      ns1.anti-spam.org.cn.
cbl.anti-spam.org.cn.   10800   IN      NS      ns3.anti-spam.org.cn.
cbl.anti-spam.org.cn.   10800   IN      NS      ns4.anti-spam.org.cn.
cbl.anti-spam.org.cn.   10800   IN      NS      ns5.anti-spam.org.cn.
cbl.anti-spam.org.cn.   10800   IN      NS      ns7.anti-spam.org.cn.
cbl.anti-spam.org.cn.   10800   IN      NS      ns8.anti-spam.org.cn.

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jun 10 09:31:01 2008
;; MSG SIZE rcvd: 172

　　查询TXT记录的结果如下（通常收到由于RBL列入而退回的信件中的退信消息就是来自这里的）：

# dig 2.0.0.127.cbl.anti-spam.org.cn. TXT

; <<>> DiG 9.3.3rc2 <<>> 2.0.0.127.cbl.anti-spam.org.cn. TXT
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21173
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 0

;; QUESTION SECTION:
;2.0.0.127.cbl.anti-spam.org.cn. IN TXT

;; ANSWER SECTION:
2.0.0.127.cbl.anti-spam.org.cn. 10800 IN TXT "Mail from 127.0.0.2 refused, see http://anti-spam.org.cn/Rbl/Query/Result?IP=127.0.0.2"

;; AUTHORITY SECTION:
cbl.anti-spam.org.cn.   10675   IN      NS      ns5.anti-spam.org.cn.
cbl.anti-spam.org.cn.   10675   IN      NS      ns7.anti-spam.org.cn.
cbl.anti-spam.org.cn.   10675   IN      NS      ns8.anti-spam.org.cn.
cbl.anti-spam.org.cn.   10675   IN      NS      ns1.anti-spam.org.cn.
cbl.anti-spam.org.cn.   10675   IN      NS      ns3.anti-spam.org.cn.
cbl.anti-spam.org.cn.   10675   IN      NS      ns4.anti-spam.org.cn.

;; Query time: 37 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jun 10 09:33:06 2008
;; MSG SIZE rcvd: 255

　　在明白了RBL查询的原理后，我们来看一下RBL劫持的发生原因。

　　由于国内很多用户在使用电信企业的线路连接互联网时，都会使用接入的ISP所提供的DNS，有的是明确设置使用的，有的是通过PPPoE或DHCP分配使用的。最近一些年来，电信企业为了引导用户访问其增值站点或合作站点，通过会对其DNS做一些修改，在接收到一个不存在结果的DNS查询时，总是返回一些特定的IP地址，使用户访问到这些增值站点。比如你在使用ADSL上网时，如果随便在浏览器的地址栏中任意敲入一个无效的域名，通常都会给你重定向到电信企业自己的门户站点。

　　一般而言，这种行为对于用户没有多大的损害，最多只是扭曲了用户意志，强制其访问另外一个站点而已。但是，对于使用RBL来防范垃圾邮件的用户，这种DNS劫持就会带来较大的麻烦。在这种情况下，所有的DNS查询都会返回一个有效的结果，换言之，无论任何发来邮件的IP地址，都会被认为列入到了RBL中，用户将接收不到任何外部邮件。

　　那么如何应对这种情况呢？有两种办法：

　　一是使用一个可信的，没有被DNS劫持的DNS服务器。国内电信企业的DNS被劫持的情形比较多，尤其是做接入的ISP的DNS服务器，很多都存在劫持问题。可以考虑使用国外的公开DNS、或者一些未劫持的DNS服务器。但是要注意的是，不能使用不支持公开解析请求的DNS，即那种只解析特定域名的DNS服务器是不能用来解析其他域名的；类似的，根域服务器（*.ROOT-SERVERS.NET）也是不提供这种公开解析请求的功能的。可以通过nslookup或dig以及其它工具来测试一个DNS服务器是否可以提供公开解析功能，以及是否被劫持。

　　查询一个DNS服务器是否提供公开查询可以做如下测试：

# dig sina.com. @A.ROOT-SERVERS.NET.

; <<>> DiG 9.3.3rc2 <<>> sina.com. @A.ROOT-SERVERS.NET.
; (2 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63123
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14

;; QUESTION SECTION:
;sina.com. IN A

;; AUTHORITY SECTION:
com.                    172800 IN      NS      H.GTLD-SERVERS.NET.
com.                    172800 IN      NS      I.GTLD-SERVERS.NET.
com.                    172800 IN      NS      J.GTLD-SERVERS.NET.
com.                    172800 IN      NS      K.GTLD-SERVERS.NET.
com.                    172800 IN      NS      L.GTLD-SERVERS.NET.
com.                    172800 IN      NS      M.GTLD-SERVERS.NET.
com.                    172800 IN      NS      A.GTLD-SERVERS.NET.
com.                    172800 IN      NS      B.GTLD-SERVERS.NET.
com.                    172800 IN      NS      C.GTLD-SERVERS.NET.
com.                    172800 IN      NS      D.GTLD-SERVERS.NET.
com.                    172800 IN      NS      E.GTLD-SERVERS.NET.
com.                    172800 IN      NS      F.GTLD-SERVERS.NET.
com.                    172800 IN      NS      G.GTLD-SERVERS.NET.

;; ADDITIONAL SECTION:
A.GTLD-SERVERS.NET.     172800 IN      A       192.5.6.30
A.GTLD-SERVERS.NET.     172800 IN      AAAA    2001:503:a83e::2:30
B.GTLD-SERVERS.NET.     172800 IN      A       192.33.14.30
B.GTLD-SERVERS.NET.     172800 IN      AAAA    2001:503:231d::2:30
C.GTLD-SERVERS.NET.     172800 IN      A       192.26.92.30
D.GTLD-SERVERS.NET.     172800 IN      A       192.31.80.30
E.GTLD-SERVERS.NET.     172800 IN      A       192.12.94.30
F.GTLD-SERVERS.NET.     172800 IN      A       192.35.51.30
G.GTLD-SERVERS.NET.     172800 IN      A       192.42.93.30
H.GTLD-SERVERS.NET.     172800 IN      A       192.54.112.30
I.GTLD-SERVERS.NET.     172800 IN      A       192.43.172.30
J.GTLD-SERVERS.NET.     172800 IN      A       192.48.79.30
K.GTLD-SERVERS.NET.     172800 IN      A       192.52.178.30
L.GTLD-SERVERS.NET.     172800 IN      A       192.41.162.30

;; Query time: 267 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Tue Jun 10 09:58:33 2008
;; MSG SIZE rcvd: 498

　　在上面这个测试中，我们使用根域服务器来查询 sina.com这个域名，返回的结果是NOERROR，但是没有ANSWER区来给出具体的IP地址。这表明该服务器（A.ROOT-SERVERS.NET.）不支持公开查询。

# dig sina.com. @202.106.196.115

; <<>> DiG 9.3.3rc2 <<>> sina.com. @202.106.196.115
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47283
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;sina.com. IN A

;; ANSWER SECTION:
sina.com. 1978 IN A 71.5.7.191

;; AUTHORITY SECTION:
sina.com.               1976    IN      NS      ns1.sina.com.cn.
sina.com.               1976    IN      NS      ns2.sina.com.cn.
sina.com.               1976    IN      NS      ns3.sina.com.cn.

;; ADDITIONAL SECTION:
ns1.sina.com.cn.        84804   IN      A       202.106.184.166
ns2.sina.com.cn.        84804   IN      A       61.172.201.254
ns3.sina.com.cn.        84804   IN      A       202.108.44.55

;; Query time: 2 msec
;; SERVER: 202.106.196.115#53(202.106.196.115)
;; WHEN: Tue Jun 10 11:19:13 2008
;; MSG SIZE rcvd: 155

　　在上面这个测试中，我们使用了一个公开的DNS服务器来查询sina.com 这个域名，返回了正确的解析结果。说明该服务器支持公开查询。

　　当使用该服务器查询一个不存在的域名时，如查询sina11111.com ：

# dig sina11111.com. @202.106.196.115

; <<>> DiG 9.3.3rc2 <<>> sina11111.com. @202.106.196.115
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48272
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;sina11111.com. IN A

;; AUTHORITY SECTION:
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1213068006 1800 900 604800 900

;; Query time: 697 msec
;; SERVER: 202.106.196.115#53(202.106.196.115)
;; WHEN: Tue Jun 10 11:19:22 2008
;; MSG SIZE rcvd: 104

　　这里返回了NXDOMAIN结果，表明该服务器没有被DNS劫持。

　　而当我们使用了一个被劫持的DNS（在笔者测试期间还存在劫持情形）来查询一个不存在的域名：sina1234122323.com. ，查询返回结果是一个特定的IP ： 220.250.64.22 （这是一个网通的地址）。

# dig sina1234122323.com. @210.22.70.3

; <<>> DiG 9.3.3rc2 <<>> sina1234122323.com. @210.22.70.3
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43129
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;sina1234122323.com. IN A

;; ANSWER SECTION:
sina1234122323.com. 3600 IN A 220.250.64.22

;; AUTHORITY SECTION:
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1213069571 1800 900 604800 900

;; Query time: 2389 msec
;; SERVER: 210.22.70.3#53(210.22.70.3)
;; WHEN: Tue Jun 10 11:45:29 2008
;; MSG SIZE rcvd: 125

　　当使用该DNS查询一个存在的域名是能正确返回其IP地址。这种针对不存在的域名强制劫持到一个特定的IP的行为导致了RBL的查询返回错误。

　　二是对RBL查询结果进行验证。基本上所有的RBL服务都会返回特定的查询结果，即每次都返回同样的一个或几个IP地址，而且这种IP地址通常都是特定的保留IP，不会出现在正常的DNS查询中，如127.0.0.2、127.0.8.2等。目前绝大多数支持RBL查询的邮件服务器都支持对查询结果进行验证，你可以根据RBL服务所公示的查询结果来设置你的RBL查询。

　　本站所提供的RBL的查询验证码如下：

名称	地址	测试地址	返回状态码
CBL	cbl.anti-spam.org.cn	2.0.0.127.cbl.anti-spam.org.cn.	127.0.8.2
CDL	cdl.anti-spam.org.cn	0.0.0.240.cdl.anti-spam.org.cn.	127.0.8.4
CBL+	cblplus.anti-spam.org.cn	2.0.0.127.cblplus.anti-spam.org.cn.	127.0.8.6
CBL-	cblless.anti-spam.org.cn	2.0.0.127.cblless.anti-spam.org.cn.	127.0.8.5

　　因此，鉴于国内DNS劫持的情形日益严重，在使用RBL服务时，要确认自己的DNS是否存在劫持；而且最好设置验证码，这样即便DNS当时未被劫持，将来发生了劫持也不会影响到邮件服务。

分享到：

相关文章	热门文章
动手验证电信DNS劫持对RBL的影响常用的RBL服务器列表及介绍 RBL技术:实时黑名单--攻防日志(八) 在MDaemon中增加anti-spam.org.cn 的RBL Exchange 2003 Server 配置连接筛选使用实时阻止列表(RBL)；如何配置收件人筛选实时黑名单服务（RBL）—CBL/CDL/CBL+/CBL-	Imail反垃圾邮件技术 Qmail反垃圾邮件技术防范垃圾邮件技术谢绝第三方邮件转发 Postfix反垃圾邮件技术 Sendmail反垃圾邮件技术追踪垃圾邮件来源邮件过滤技术 OPEN RELAY的解决方案美讯智SMG邮件安全网关使用FAQ 三分钟打造反垃圾邮件服务器黑名单服务器

自由广告区

反垃圾邮件

DNS劫持与RBL使用