早上开了个域名，自己用一切正常，但是同事用就是不行，ping返回的地址死活不对。

找了一下，92.242这个地址是comodo的网站。

然后查了一下他的dns，果然是变成了comodo的dns:

百度一下这个156.154.70.25，果然是COMODO的DNS。讽刺的是，这个DNS是用来反DNS劫持的…结果把自己的网站劫持了。

问题：

1、教育网限速，10m，经常拥堵，非常卡。

2、大网站都有cdn

3、用校内dns解析，解析出的是cernet地址。访问的是cernet的cdn。

4、一旦拥堵，访问就很卡。

 

解决：

1、将.edu.cn转向cernet dns

2、将其他所有请求转向电信dns。

3、也就是本地只做forwarder

 

添加两条：

zone "edu.cn" {
        type forward;
        forwarders {121.194.2.2;121.194.2.3;};
//        allow-update { none; };
};

将.edu.cn的指向教育网的dns。

options下添加

forwarders {218.2.135.1;202.102.24.35;};

 

检测结果：

没做之前nslookup

> www.sina.com.cn
服务器:  dns1.nau.edu.cn
Address:  210.28.92.7

非权威应答:
名称:    cernetnews.sina.com.cn
Addresses:  121.194.0.210
          121.194.0.203
          121.194.0.205
          121.194.0.206
          121.194.0.207
          121.194.0.208
          121.194.0.209
Aliases:  www.sina.com.cn
          jupiter.sina.com.cn

>

 

做了之后解析：

> www.sina.com.cn
服务器:  dns1.nau.edu.cn
Address:  210.28.92.7

非权威应答:
名称:    newsnj.sina.com.cn
Addresses:  202.102.75.164
          202.102.75.165
          202.102.75.166
          202.102.75.167
          202.102.75.168
          202.102.75.169
          202.102.75.170
          202.102.75.161
          202.102.75.162
          202.102.75.163
Aliases:  www.sina.com.cn
          jupiter.sina.com.cn

>

 

问题：

 

目前还比较严重…

就是cernet的dns会把dns query转发到电信去，结果这个速度…实在是受不了。经常网页半天打不开（解析Ing），然后刷新，刷的出来了（解析出地址，直接从电信访问）。

试试看把教育地址从电信弄出去？

另外发现个好玩的：

http://121.194.2.2/dns/log/2010/05/17/2010.05.17.00.10.html

怎么做的呢…

想要分析你的dns都在解析那些站点？可以用dnstop~。基于的是tcpdump，类似于抓包，然后分析。

安装很简单，在这里下载：http://dns.measurement-factory.com/tools/dnstop/src/，需要libcacp以及ncurse的支持。

yum install ncurses-devel
yum install libpcap-devel

./configure
make
make install

然后就可以运行了。直接打

[root@cernetdns-vm ~]# dnstop -4 -Q -R eth0

 

就可以看到分析开始工作了。注意eth0，也就是说如果装在其他机器上也是可以生效的，他不是分析的dns的log，而是tcpdump中53端口的信息。

默认是查询者的ip，我们可以通过按键来实时改变结果

1. s，显示源ip
2. d，显示目标Ip
3. t，解析类型，A，AAAA，还是其他
4. 1~9，显示解析层数，比如1就是.com，2就是qq.com
5. !~(，显示源+解析层数1~9。注意这是1~9键盘按键上面的字符。
6. 空格刷新（但是不清空计数）
7. ^R，清空计数
8. ^X，退出
9. ?，帮助。

很简单哦~来个截图，可见大家访问qq和迅雷很多呀...

Queries: 38 new, 47750 total                                                                               Wed Jan 13 14:57:24 2010
Replies: 35 new, 47097 total

Query Name                Count      %
--------------------- --------- ------
qq.com                    13664   14.4
sandai.net                 6533    6.9
edu.cn                     6322    6.7
com.cn                     4725    5.0
kaspersky.com              2998    3.2
baidu.com                  2497    2.6
xunlei.com                 2442    2.6
baofeng.com                2418    2.5
wpad                       2218    2.3
tencent.com                1504    1.6
renren.com                 1360    1.4
cnzz.com                   1238    1.3
360safe.com                1194    1.3
172.in-addr.arpa           1160    1.2
baofeng.net                1064    1.1
xiaonei.com                1058    1.1
xnimg.cn                    895    0.9

www.flashget.com，www.kuaiche.com均是如此。

 

难道得罪了电信？

> www.kuaiche.com
Server:  a.center-dns.jsinfo.net
Address:  218.2.135.1

Non-authoritative answer:
Name:    www.kuaiche.com
Address:  192.168.254.254

> www.flashget.com
Server:  a.center-dns.jsinfo.net
Address:  218.2.135.1

Non-authoritative answer:
Name:    www.flashget.com.showq.net
Address:  192.168.254.254
Aliases:  www.flashget.com

 

安全漏洞：CN-VA09-69
发布日期：2009年7月29日
漏洞类型：远程执行代码
漏洞评估：严重
受影响的软件：
    安装或捆绑BIND 9的操作系统及相关产品，目前FreeBSD和ISC发布公告确认该漏洞造成严重威胁。
漏洞描述： 
    ISC于7月28日公布了其域名系统软件BIND 9存在的一个高危漏洞，并且针对该漏洞攻击脚本在互联网上已出现。BIND是由ISC提供的一个常用的DNS软件，它支持动态DNS更新（参考IETF RFC 2136<http://tools.ietf.org/html/rfc2136>）。该漏洞允许远程攻击者进行拒绝服务攻击；当处理一个伪造的动态更新包时，BIND 9系统会崩溃。此漏洞影响所有的BIND 9服务器，不限于配置了动态更新的服务器。需要说明的是，目前发现此漏洞仅对将BIND 9作为主权威服务器时产生影响，对从权威服务器和纯递归服务器没有影响。
漏洞影响：
    通过给BIND 9服务器发送一个伪造的动态更新包而引起系统崩溃，可使远程攻击者发动拒绝服务攻击。
解决方案：
    安装补丁。
    此漏洞已在ISC BIND versions 9.4.3-P3、9.5.1-P3和BIND 9.6.1-P1中得到解决，原厂商用户可根据情况更新至这些版本。通过第三方厂商获得软件的用户可查看受影响的软件列表，确定是否受影响。
    原厂商公告详见：https://www.isc.org/node/474.
参考信息：
https://www.isc.org/node/474
http://tools.ietf.org/html/rfc2136
http://oldwww.isc.org/sw/bind/view?release=9.4.3-P3&noframes=1
http://oldwww.isc.org/sw/bind/view?release=9.5.1-P3&noframes=1
http://oldwww.isc.org/sw/bind/view?release=9.6.1-P1&noframes=1
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538975
信息提供者：
ISC
JPCERT
感谢北京启明星辰信息技术有限公司和北京神州绿盟科技有限公司为CNCERT提供相关技术支持。
其它信息：
    相关CVE编号： CVE-2009-0696
漏洞报告文档编写：
CNCERT/CC
安全公告文档编写：
CNCERT/CC

http://www.cert.org.cn/articles/bulletin/common/2009073024463.shtml

 

关于域名系统软件BIND 9高危漏洞的补充公告(重要)

安全漏洞：CN-VA09-70
发布日期：2009年7月30日
漏洞类型：远程攻击
漏洞评估：严重
受影响的软件：
    安装或捆绑BIND 9的操作系统及相关产品。
漏洞情况：
    7月29日，CNCERT发布了关于域名系统软件BIND 9存在高危漏洞的情况通报。经进一步测试分析，CNCERT对漏洞危险性和影响范围作如下补充公告。
    目前确定除安装BIND 9的主权威服务器受影响外，在BIND 9配置文件(named.conf)中存在带有Master类型的区域记录（Zone）的从权威服务器和递归服务器也会受到影响。BIND 9在缺省安装情况下，会在配置文件中包含如下几个带有Master类型的区域记录：“local host”、“127.in-addr.arpa”、“0.in-addr.arpa”、“255.in-addr.apra”；而使用BIND 9的多数用户一般不会删除上述内容，因此该漏洞对我国域名服务器的影响范围十分广泛。
解决方案：
    使用BIND 9作为域名服务器的用户需高度重视该漏洞的危害，及时做好修补和防护工作，具体建议如下：
    1.测试证明BIND 9厂商目前提供的补丁程序是有效的，具备条件的用户应考虑升级；
    2.因故不能对服务器进行升级的，如不作为主权威服务器使用，可考虑修改配置文件，删除所有Master记录；
    3.对于没有启用动态更新的域名服务器，可使用防护设备拦截带攻击意图的动态更新数据包；
    4.对基于BIND 9二次开发的软件系统，用户可在代码层级作修改，消除隐患。
    各企业和个人用户如发现其他问题或需技术支持，请与CNCERT联系。
信息提供者：
    北京启明星辰信息技术有限公司
    北京神州绿盟科技有限公司 
文档编写：
CNCERT/CC
-----------------------------------------------------------------------------------
CNCERT/CC在发布安全公告信息之前，都力争保证每条公告的准确性和可靠性。然而，采纳和实施公告中的建议则完全由用户自己决定，其可能引起的问题和结果也完全由用户承担。是否采纳我们的建议取决于您个人或您企业的决策，您应考虑其内容是否符合您个人或您企业的安全策略和流程。
在任何情况下，如果您确信您的计算机系统受到危害或是攻击，我们鼓励您及时告知国家计算机网络应急技术处理协调中心：http://www.cert.org.cn/servlet/Incident
同时，我们也鼓励所有计算机与网络安全研究机构，包括厂商和科研院所，向我们报告贵单位所发现的漏洞信息。我们将对所有漏洞信息进行验证并在CNCERT/CC网站公布漏洞信息及指导受影响用户采取措施以避免损失。
如果您发现本公告存在任何问题，请与我们联系： cncert@cert.org.cn

http://www.cert.org.cn/articles/bulletin/common/2009073124465.shtml

/usr/local/named/sbin/named –v

查看Bind的版本。

 

/usr/local/named/sbin/named –g

 

有点类似于nginx的-t参数，检测参数是否正确。运行之后会检测当前的参数，并且会将日志显示在屏幕上。

虽然rpm或者yum很容易，但是还是喜欢编译安装...

首先升级下ssl。如果用--prefix=installdir指定了openssl的安装目录的话，那么BIND的编译：

./configure --with-openssl=/usr/local/openssl/ --prefix=/usr/local/bind

 

 

接下来生成rndc，并根据rndc生成named.conf的rndc部分：

sbin/rndc-confgen > /etc/rndc.conf
tail -10 rndc.conf | head -9 | sed s/#\ //g > named.conf

下面就是配置named.conf了。

具体以后再补充。

启动bind

/usr/local/bind/sbin/named

重启貌似需要kill然后再运行。

首先是lame server错误

Aug 26 10:49:45 cernetdns2 named[24876]: lame server resolving 'kcds.net' (in 'kcds.net'?): 216.138.0.11#
53

基本上可以理解为，我的dns向对方请求某域名解析，但是由于对方的设置错误，无法解析到。所以产生了这个"瘸腿"错误。所以问题不是很大。我们不需要这个日志。

named.conf增加：

logging {
category lame-servers { null; };
};

参考：
http://linux.vbird.org/linux_server/0350dns.php#Lame_server
http://bbs.chinaunix.net/viewthread.php?tid=328597

 

接下来看disabling EDNS错误。

Aug 26 10:50:12 cernetdns2 named[24876]: too many timeouts resolving '3.xiaoyouxi.com/A' (in 'xiaoyouxi.c
om'?): disabling EDNS

 

这个据说是bug?由于错误的EDNS请求造成的。

在log部分关闭掉他：

logging {
category edns-disabled { null; };
};

参考：
http://bbs.chinaunix.net/viewthread.php?tid=1254909
http://groups.google.com/group/comp.protocols.dns.bind/browse_thread/thread/732e104148f762e3
http://www.isc.org/index.pl?/sw/bind/view/?release=9.5.0a6

 

还有FORMERR resolving 错误

Aug 26 10:51:31 cernetdns2 named[24876]: FORMERR resolving 'minisite.qq.com/AAAA/IN': 61.152.100.218#53

这个就有点奇怪了，有人说是IPv6的AAAA记录，但是没有打开ipv6啊。虽然AAAA确实是Ipv6的特性。
http://www.kholix.com/wiki/index.php/FORMERR_resolving

另外有人说是recursive queries造成的。尝试关闭recursive queries试试看。

named.conf增加：

allow-recursion { localhost; };

http://www.webhostingtalk.com/showthread.php?t=531585

ps,FORMERR应该是Format Error，格式错误的意思。

 

'./A/IN' denied错误

Aug 26 19:04:49 cernetdns2 named[32713]: client 219.133.104.90#59054: view chinanet-in: query (cache) './A/IN' denied
Aug 26 19:04:55 cernetdns2 named[32713]: client 219.133.104.90#60509: view chinanet-in: query (cache) './A/IN' denied
Aug 26 19:04:56 cernetdns2 named[32713]: client 119.60.56.129#1886: view chinanet-in: query (cache) 'xl.339xz.com/A/IN' denied
Aug 26 19:04:56 cernetdns2 named[32713]: client 119.60.56.129#1886: view chinanet-in: query (cache) 'xl.339xz.com/A/IN' denied
 

See This:http://bbs.chinaunix.net/thread-973203-1-1.html

 

view cernet-in: RFC 1918 response from Internet for 63.0.29.172.in-addr.arpa

Q: What does "RFC 1918 response from Internet for 0.0.0.10.IN-ADDR.ARPA" mean?

A: If the IN-ADDR.ARPA name covered refers to a internal address space you are using then you have failed to follow RFC 1918 usage rules and are leaking queries to the Internet. You should establish your own zones for these addresses to prevent you querying the Internet's name servers for these addresses. Please see http://as112.net/ for details of the problems you are causing and the counter measures that have had to be deployed.

If you are not using these private addresses then a client has queried for them. You can just ignore the messages, get the offending client to stop sending you these messages as they are most probably leaking them or setup your own zones empty zones to serve answers to these queries.

zone "10.IN-ADDR.ARPA" {
type master;
file "empty";
};

zone "16.172.IN-ADDR.ARPA" {
type master;
file "empty";
};

...

zone "31.172.IN-ADDR.ARPA" {
type master;
file "empty";
};

zone "168.192.IN-ADDR.ARPA" {
type master;
file "empty";
};

empty:
@ 10800 IN SOA <name-of-server>. <contact-email>. (
1 3600 1200 604800 10800 )
@ 10800 IN NS <name-of-server>.

 

http://www.isc.org/index.pl?/sw/bind/FAQ.php

RFC1918的私网地址不应当泄漏到公网上。

Jan 9 14:36:16 cernetdns2 named[21627]: dns_master_load: /var/named/nauchinanet.host:120: net.nau.edu.cn: multiple RRs of singleton type
Jan 9 14:36:16 cernetdns2 named[21627]: zone nau.edu.cn/IN/chinanet-in: loading from master file /var/named/nauchinanet.host failed: multiple RRs of singleton type
Jan 9 14:36:16 cernetdns2 named[21627]: zone nauzone.net/IN/chinanet-in: loaded serial 2007051102
Jan 9 14:36:16 cernetdns2 named[21627]: running

这个是因为存在两个相同的cname记录。参见第一行。因此在外网无法解析。

ps，dns的日志在/var/log/message里面。

DNS漏洞解析
最近炒的比较火的一个漏洞是 DNS 协议本身发现的一个严重问题（CERT VU#800113）。国内媒体对此的报道多数都语焉不详，因此我想有必要说说这个漏洞到底是怎么回事。

首先我们要明确的第一个问题是，DNS查询是如何进行的？对于绝大多数桌面系统来说，DNS的查询并不是由自己的机器完成的，DNS查询会提交给另一台DNS服务器（这台服务器通常是由ISP或者公司提供），然后这台服务器再去进行真正的查询操作。这样做的好处是DNS的查询结果可以由这台机器给缓存下来，从而提高查询效率并降低由DNS带来的流量开销（当然，在今天这种开销已经是可以忽略不计的了）。

我们可以看到的一个情况是，一台缓存DNS服务器（与权威DNS相对，这类系统提供的）下面的桌面系统可能有几百、几千、几万甚至几十万台，从攻击的有效性而言，如果能够影响这台服务器的话，相比攻陷其下的桌面系统而言，成本便会降低很多，这种攻击我们通常称之为杠杆式攻击。

针对缓存DNS服务器的杠杆式攻击其实从很早就有研究，除了希望通过劫持网站流量来牟利的骇客之外，还有一些人使用这种方法达到一些其他的目的，例如屏蔽存在安全问题的网站，以及在一些国家存在的互联网内容净化处理等等。

本次VU# 800113是一个足以引起人们重视的问题，尽管它采用的仍然是"Cache 投毒"（cache poisoning）的方法，但这种方法采用了一些新的技巧来使其更加有效。具体来说，DNS的查询过程是由客户端（无论是桌面计算机，或是缓存DNS服务器发起的查询）发出一个到权威DNS服务器（可能是根DNS，也可能是具体域名的权威DNS）一个UDP请求，然后等待其回应。

UDP是一种无连接的协议，为了能够识别来自不同服务器的回应，DNS协议利用端口和一个称为TXID的识别符（类似TCP的序号）来区分它们。事实上，早期的DNS协议实现甚至会使用固定的端口来发起DNS请求，这样一来，TXID就成了识别回应的唯一标识。由于DNS协议是在上世纪70年代设计的，因此TXID序号只有16个bit宽，而另一方面，伪造UDP包的来源地址又很容易（因为UDP并没有提供类似TCP那样内建的防止此类攻击的机制），因此，攻击者只需设法让DNS缓存服务器相信自己伪造的来自权威DNS的回应是真实的，就可以达到目的了。

具体地说这种攻击包括两个部分，其一是设法让缓存DNS服务器发起新的DNS查询请求（有很多方法），其二则是发出大量的伪造包并期待其命中，也就是在真实的权威DNS回应之前，将伪造的，但端口和TXID均能匹配的UDP回应发到缓存DNS服务器。

对于一些以线性递增方式来产生TXID的DNS客户端而言，攻击者可以自行架设一台DNS服务器、诱使对方发出DNS请求，从而大大提高攻击的效率。对于采用固定端口的DNS客户端来说，攻击者可以通过类似的手段来获取他关心的信息。攻击者可以用各种方式来达到这种目的，包括钓鱼邮件，也包括直接发起查询等等。

本次VU ＃800113所描述的问题是，多数DNS缓存服务器实现都存在这两种弱点之一或全部。

说完攻击的原理，我想更多的人关心的问题会是：我们能够做点什么？

如果你是一名桌面用户，那么最好的办法是等待公司或ISP的工作人员修正问题，通过安装适当的补丁，能够消除以上两种弱点。对于 FreeBSD 用户，减轻这类问题影响的办法是在 /etc/rc.conf 中加入 named_enable="YES"，执行 /etc/rc.d/named restart 并在 /etc/resolv.conf 中将 127.0.0.1 配置为域名服务器，这样一来攻击缓存服务器一点便变成了攻击所有的桌面系统，从而大大提高攻击的成本，但缺点是这样做意味着无法利用上游 DNS 的缓存。

如果你是缓存DNS服务器的管理员，那么除了需要打补丁之外（如果你的系统中存在这个漏洞），还需要考虑部署DNSsec。DNS协议的漏洞通过随机化查询端口和TXID只能部分缓解，而DNSsec才是解决问题的根本。

如果你是权威DNS服务器的管理员，那么事实上你做不了什么，因为缓存DNS服务器并不受你控制。唯一可以做的事情就只剩下为自己的权威域名配置DNSsec了。遗憾的是，目前并不是所有的顶级域名，以及域名注册服务提供商都支持DNSsec。

========

一些常见的误解。

误解A：靠，又是那个破烂BIND的漏洞，我不用BIND所以没事。
错。除了BIND之外，也有很多其他DNS服务器作为缓存DNS使用时会遇到同样的问题。

误解B：我的Ubuntu系统第一时间修补了这个问题，所以我不受影响。
错。除非你在本地运行DNS缓存服务，并只使用它作为DNS。

误解C：我是打酱油的，DNS被攻击跟我没关系，顶多给人家增加点流量而已，不碍事。
错。通过DNS Cache投毒攻击可以将你引导到一些伪造的钓鱼站点来骗取敏感数据。

误解D：我的权威DNS服务器配置了DNSsec，所以客户一定会访问到正确的网站。
错。事实是，许多早期的DNSsec实现都引入了其他安全漏洞；另一方面，多数缓存DNS服务器并不进行DNSsec校验，因此你仍然需要其他一些手段来减轻这个问题的影响。

全球DNS系统需要来一次DNSsec俯卧撑。

http://blog.delphij.net/archives/2008/07/dns-1.html
http://www.isc.org/index.pl?/sw/bind/index.php