給阿骁兄的賀禮二: DNS 流量統計~超強版
程序又升级了，我增加了一个所有dns解析合计的功能。程序如下：
#cat dns_flow.sh
#!/usr/bin/sh
USAGE="Usage: $0 serverip\n or \n $0 all\n"
if [ $# -le 0 ]
then
echo $USAGE 2>;&1
exit 1
fi
TMPDATAFILE="/var/named/.${1}.tmp"
TMPALLFILE="/var/named/.all.tmp"
if [ !-f $TMPALLFILE ]
then
printf "0\n0\n">;$TMPALLFILE
fi
case $1 in
all)
query=`head -1 $TMPALLFILE`
reply=`tail -1 $TMPALLFILE`
printf "$query\n$reply\n"
printf "0\n0\n" >;$TMPALLFILE;;
*)
RUN_1=0
query_old=0
reply_old=0
query=0
reply=0
if [ -f $TMPDATAFILE ]
then
RUN_1=1
query_old=`head -2 $TMPDATAFILE|tail -1 |awk '{print $4}'`
reply_old=`head -3 $TMPDATAFILE|tail -1 |awk '{print $4}'`
fi
/usr/local/sbin/rndc -s $1 status >;$TMPDATAFILE
query=`head -2 $TMPDATAFILE|tail -1 |awk '{print $4}'`
reply=`head -3 $TMPDATAFILE|tail -1 |awk '{print $4}'`
if [ $query -gt $query_old ] && [ $reply -gt $reply_old ]
then
query=`expr $query - $query_old`
reply=`expr $reply - $reply_old`
fi
if [ $RUN_1 -eq 0 ]
then
#first time to run
printf "0\n0\n"
else
printf "$query\n$reply\n"
query_all=`head -1 $TMPALLFILE`
reply_all=`tail -1 $TMPALLFILE`
printf "`expr $query + $query_all`\n`expr $reply + $reply_all`\n">;$TMPALLFILE
fi;;
esac
mrtg的配置文件也要相应修改成如下：
#cat dns.cfg
# for UNIX
WorkDir: /usr/local/apache/htdocs/mrtg/html/dns
# or for NT
# WorkDir: c:\mrtgdata
### Global Defaults
# to get bits instead of bytes and graphs growing to the right
Options: growright, noinfo,nopercent,integer,absolute
MaxBytes: 10000
Legend1: DNS查询(次数/秒)
Legend2: DNS回应(次数/秒)
LegendI: DNS查询
LegendO: DNS回应
ShortLegend:次/秒
YLegend: Q. per second
PageTop: <h1>;DNS_Server Query/Response</h1>;
#---------------------------------------------------------------
Target: `/var/named/dns_flow.pl 192.168.1.2`
Title: mydns1
Target: `/var/named/dns_flow.pl 192.168.1.3`
Title: mydns2
.
.
.
Target: `/var/named/dns_flow.sh all`
Title: alldns
MaxBytes: 100000
注意：由于程序设计问题，dns合计一项一定要放在最后一行，切记切记。
給阿骁兄的賀禮二: DNS 流量統計~超強版
我的dns统计給阿骁兄的賀禮二: DNS 流量統計~超強版
嗯...cpss 也是箇中高手呀 !您的觀點很正確, gauge 確時是較好的型態, counter 則是重設時會有
一段時間會不正常, 至於合計功能,倒建議您可學學 rrdtool ,
可以有較佳的處理效果
http://phorum.study-area.org/viewtopic.php?t=18496&postdays=0&postorder=asc&start=0
也或許您早巳懂了
用 rrdtool interval 可以精確到秒哦,不似 mrtg 最小只有 5min(300s)
給阿骁兄的賀禮二: DNS 流量統計~超強版
最近有些郁闷，查询数与回复数曲线有时间距太大，请问各位也是否碰到，怎么处理？
附图
給阿骁兄的賀禮二: DNS 流量統計~超強版
我覺得你應該去看其他的資料,例如流量資料等,是否和DNS 圖上的資料有一定相關.或是在 DNS 上先開 query log , 以觀察看看
給阿骁兄的賀禮二: DNS 流量統計~超強版
原帖由 "abel" 发表：我覺得你應該去看其他的資料,例如流量資料等,是否和DNS 圖上的資料有一定相關.
或是在 DNS 上先開 query log , 以觀察看看
一、首先感谢abel。
你的提示中，我的理解如下：
1、你可能觉得是否是我DNS有其他流量与DNS相关。
（1）从两线间距较大的情况来看，说明还是正常的DNS查询数远大于响应数。
我在ns1和ns2上，都没有启动除ns服务以外的服务器进程。
（2）在时间上看，ns1和ns2在相同的时间上，出现两条线间距较大。某些时
候，间距不大，说明较为正常。
所以我认为，一般的，应该不是恶意流量攻击。
2、关于你叫我在ns1和ns2上打开query log看看
谢谢。我觉得你的建议很好，毕竟分析log是解决问题的最有效的途径之一。
到目前为此，我一直使用/var/log/messages来看bind 的log信息。如果
这个问题解决不了，我想抽个时间，开启ns2上的query log看看。
二、借此机会，顺便问两个小问题：
1、我的DNS是ns1.xxx.net或ns2.xxx.net，我不知道用xxx.com
和xxx.net作ISP的域名服务器时，有什么不一样的地方？（第一问）
考虑到大陆的互联网用户，多数是查询的是.cn的域名，是不是使用
xxx.net.cn或xxx.com.cn作为域名服务器的域会更好呢？（第二问）
2、关于查询数与回应数两线相距很远的问题，我曾经使用dnstop分析过。
我个人认为，某个window用户将我的ns1和ns2作为它的主备域名服务器，
但该window平台可能受病毒攻击过或是该计算机上有恶意攻击DNS服务器的
程序，从而导致查询数与回应数两线相距很远。即查询的正确率较低。
当出现上述情况时，我通常的做法是看/var/log/messages文件，此时会发现
系统中出现大量的如下信息：
Nov 25 19:55:22 ns2 named: client xxx.xxx.xxx.xxx(ip)#2441:
view external: no more recursive clients: quota reached
上面这段代码，已经出现很久了，我想其他ns管理员也经常碰到。
针对这种情况，我就会修改named.conf，将recursive-clients 的值加大。
例如：
recursive-clients 100000;
其实，我原来没有使用这个参数，但我为了解决这个问题，逐步将值由1000，
提高到5000，再提高到1万，直到现在的10万。
这个问题，一直让我最为郁闷。理由很简单，我的ns1和ns2是为好几万用户
服务，如果ns1和n2的查询正确率很低的话，势必影响到用户的利益。
为此，请各位高手帮助指点！谢谢。
給阿骁兄的賀禮二: DNS 流量統計~超強版
不是吧，jsquan，你的dns为几万用户服务，但从你的dns解析数一般才100～200次/秒？那也太少了吧。我这边的解析数已经到了12K/秒，痛苦啊，太多了。
給阿骁兄的賀禮二: DNS 流量統計~超強版
不错啊。谢谢。好东西！！！！！給阿骁兄的賀禮二: DNS 流量統計~超強版
我沒有用過 windows 的 v6 , 都只有在 linux 上用 (client or dns)所以沒法回答你的問題,我猜是 windows 對 v6 的支援不夠所致
但我無法證明,建議您到一些有論 v6 較深的論壇去問問,不然到我們這邊也可以
http://www.ipv6.org.tw
recursive-clients 設為多少意義應不大,預設好像是 1000
因為如 cpss 提到的,你的 query/response 並沒有很大,
我們的一台例子:
http://log.twnic.net.tw/dns-sample.png
我個人認為你的問題應該先看:
1. 網路是否正常 ? Router/Switch/本機 都要看, 看 Error 是否會太多
2. 同時間的流量是否有瓶頸,不見得是本機或現在的網路, 出口處也要多注意
3. 各設備的系統狀況是否正常(CPU/MEMORY/device..)
若以上都沒有問題,再找 query log 看看,畢竟 query log 佔大量的 I/O,
上面的圖可以看到,我們的流量和你差不多,但兩條線是重疊的,也就是
幾乎沒有背離現象,這也只是一台普通的 Server 而以,用一般的 PC 跑到
每秒數千一定沒有什麼問題,我認為你的問題是在網路上為主,並不是這台
DNS Server. (我測過每秒 1000 次查詢, CPU Loading 不會高於 20%, CPU
是 1G, RAM 1G 的機器).
1、我的DNS是ns1.xxx.net或ns2.xxx.net，我不知道用xxx.com
和xxx.net作ISP的域名服务器时，有什么不一样的地方？（第一问）
考虑到大陆的互联网用户，多数是查询的是.cn的域名，是不是使用
xxx.net.cn或xxx.com.cn作为域名服务器的域会更好呢？（第二问）
無所謂,因為這是給 user 用的,用什麼名稱都無關, user 的 resolver
是認 IP 的.
2、关于查询数与回应数两线相距很远的问题，我曾经使用dnstop分析过。
我个人认为，某个window用户将我的ns1和ns2作为它的主备域名服务器，
但该window平台可能受病毒攻击过或是该计算机上有恶意攻击DNS服务器的
程序，从而导致查询数与回应数两线相距很远。即查询的正确率较低。
這個問題,若一般的 worm 通常是掃 IP 較無關,若 Email 的 worm 或 virus,
會狂發信沒錯,但 User 設的 smtp server 是 mail.xxx.com , 信是發到
mail.xxx.com , user 會解析的只有 mail.xxx.com , 而 windows 2000 以上
的機器,一般的都會做 Cache , 也就是只能解析一次,除非重開機(這個功能可關閉
但一般 99% 的人一定不會去關),所以,viurs mail 來查你的 dns server, 不是
Client, 所以,若您有這種考量,看到的 IP 應該是 Mail Server 才是
而通常 Mail Server 的發信速度肯定比不上 dns 的查詢速度的.
除非您的問題不是一台影起,而是多台累積下來的結果.
除你的圖中可以看到,查詢量是差不多的,這表示什麼 ?
如果你的 user 設了 DNS 為 IP1, IP2 , 理論上應該是 IP1 量應遠高於 IP2
因為 Resolver 不是輪詢的,而是會先用第一筆,所以我想你的圖和你的說明
肯定有差距(我猜這是dns 代管主機,而不是像一般 ISP 給 user 用的 DNS Server)
再來看, 查詢差不多,失敗也差不多,何解呢 !? 大概您置這兩台 Server 於
同一個 subnet 之下所致,應該在網路上適當的分隔,例如一台放在電信,一台放在
聯通,或許失敗量也不會這麼一致了.
如果我的猜測沒有錯,這是代管主機,那就設代管主機為 recursion no, 因為這
不是給 user 設 DNS Server 用(Resolver), 而是給其他的 DNS Server 用.
我們的代管主機都是這麼設, User 再將 TCP/IP 中的 DNS 指到電信的 DNS Server 上
即可,本末上適當的分開會是較好的
所以...您多想想. 或許我有猜錯的,看您是否有其他補充.
給阿骁兄的賀禮二: DNS 流量統計~超強版
再次感谢abel的分析，特别是对网友问题执着的回答，这一点，难能可贵。netman一样，也具备这种精神。1、
所以?#93;法回答你的問?#125;,我猜是 windows 對 v6 的支援不夠所致
但我無法證明,建議您到一些有論 v6 較深的論壇去問問,不然到我們這邊也可以
http://www.ipv6.org.tw
你的建议是很好的，我对v6真可是一点也不通。只是工作还是不够专注。
2、
因為如 cpss 提到的,你的 query/response 並?#93;有很大,
是的，Query/Response并不大，但的确ns1、ns2是chinanetcom即CNC
在南方某省的公网域名服务器。目前用户2万户左右。同时在线，我不清楚有多不少。
3、
1. 網路是否正常 ? Router/Switch/本機 都要看, 看 Error 是否會太多
这个应该没问题。我先后在中电信、中网通，从事router/switch多年，对FreeBSD学习也有六年。
2. 同時間的流量是否有瓶頸,不見得是本機或現在的網路, 出口處也要多注意
我们网络是China169(CNCnet)中的一部分，由于China169跟Sprint-globalone之间的出国带宽比较拥挤。与ChinaNet也是拥挤严重。以下是从ns1到root-server的时延。内容较多，详见附件一。
3. 各設備的系統狀況是否正常(CPU/MEMORY/device..)
这个没有问题。我的ns1和ns2是FreeBSD 4.8 releases平台。
1G Ram, 1*cpu 2.0 Ghz我设置的swsap根本没有用到。如ns1信息。
详见附件二。
4、
我猜這是dns 代管主機,而不是像一般 ISP 給 user 用的 DNS Server
你猜错了。我的是ISP给user的DNS server。这一点不用怀疑。所以，我要
对用户负责。
5、
再來看, 查詢差不多,失敗也差不多,何解呢 !? 大概您置這兩台 Server 於
同一個 subnet 之下所致,應該在網路上適當的分隔,例如一台放在電信,一台放在
聯通,或許失敗量也不會這麼一致了.
我的ns1与ns2分别在不同的城域网。举例假设ns1在台北，那么ns2就在高雄。当然不在同一个subnet了。并且ns1与ns2是2*pos 155互联。
6、
我的ns1和ns2都设置为recursion yes，并且，启用了internal-view和external-view。
7、补充
我刚看到你在线，如果你方便使用QQ的话，能否与我联络。我的QQ：86269149
附件一：
%sh pingdns
A.ROOT-SERVERS.NET
PING 198.41.0.4 (198.41.0.4): 56 data bytes
64 bytes from 198.41.0.4: icmp_seq=0 ttl=238 time=336.644 ms
--- 198.41.0.4 ping statistics ---
2 packets transmitted, 1 packets received, 50% packet loss
round-trip min/avg/max/stddev = 336.644/336.644/336.644/0.000 ms
B.ROOT-SERVERS.NET
PING 192.228.79.201 (192.228.79.201): 56 data bytes
--- 192.228.79.201 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
C.ROOT-SERVERS.NET
PING 192.33.4.12 (192.33.4.12): 56 data bytes
64 bytes from 192.33.4.12: icmp_seq=0 ttl=48 time=343.485 ms
64 bytes from 192.33.4.12: icmp_seq=1 ttl=48 time=351.860 ms
--- 192.33.4.12 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 343.485/347.673/351.860/4.188 ms
D.ROOT-SERVERS.NET
PING 128.8.10.90 (128.8.10.90): 56 data bytes
64 bytes from 128.8.10.90: icmp_seq=0 ttl=42 time=269.159 ms
64 bytes from 128.8.10.90: icmp_seq=1 ttl=42 time=268.628 ms
--- 128.8.10.90 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 268.628/268.894/269.159/0.265 ms
E.ROOT-SERVERS.NET
PING 192.203.230.10 (192.203.230.10): 56 data bytes
--- 192.203.230.10 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
F.ROOT-SERVERS.NET
PING 192.5.5.241 (192.5.5.241): 56 data bytes
64 bytes from 192.5.5.241: icmp_seq=0 ttl=56 time=61.969 ms
64 bytes from 192.5.5.241: icmp_seq=1 ttl=56 time=53.861 ms
--- 192.5.5.241 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 53.861/57.915/61.969/4.054 ms
G.ROOT-SERVERS.NET
PING 192.112.36.4 (192.112.36.4): 56 data bytes
--- 192.112.36.4 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
H.ROOT-SERVERS.NET
PING 128.63.2.53 (128.63.2.53): 56 data bytes
64 bytes from 128.63.2.53: icmp_seq=0 ttl=27 time=469.883 ms
--- 128.63.2.53 ping statistics ---
2 packets transmitted, 1 packets received, 50% packet loss
round-trip min/avg/max/stddev = 469.883/469.883/469.883/0.000 ms
I.ROOT-SERVERS.NET
PING 192.36.148.17 (192.36.148.17): 56 data bytes
64 bytes from 192.36.148.17: icmp_seq=0 ttl=44 time=422.592 ms
64 bytes from 192.36.148.17: icmp_seq=1 ttl=44 time=422.066 ms
--- 192.36.148.17 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 422.066/422.329/422.592/0.263 ms
J.ROOT-SERVERS.NET
PING 192.58.128.30 (192.58.128.30): 56 data bytes
64 bytes from 192.58.128.30: icmp_seq=0 ttl=245 time=448.464 ms
64 bytes from 192.58.128.30: icmp_seq=1 ttl=245 time=436.557 ms
--- 192.58.128.30 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 436.557/442.510/448.464/5.954 ms
K.ROOT-SERVERS.NET
PING 193.0.14.129 (193.0.14.129): 56 data bytes
64 bytes from 193.0.14.129: icmp_seq=0 ttl=45 time=342.935 ms
64 bytes from 193.0.14.129: icmp_seq=1 ttl=45 time=343.755 ms
--- 193.0.14.129 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 342.935/343.345/343.755/0.410 ms
L.ROOT-SERVERS.NET
PING 198.32.64.12 (198.32.64.12): 56 data bytes
64 bytes from 198.32.64.12: icmp_seq=0 ttl=53 time=197.546 ms
64 bytes from 198.32.64.12: icmp_seq=1 ttl=53 time=197.011 ms
--- 198.32.64.12 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 197.011/197.279/197.546/0.267 ms
M.ROOT-SERVERS.NET
PING 202.12.27.33 (202.12.27.33): 56 data bytes
64 bytes from 202.12.27.33: icmp_seq=0 ttl=243 time=502.941 ms
64 bytes from 202.12.27.33: icmp_seq=1 ttl=243 time=478.207 ms
--- 202.12.27.33 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 478.207/490.574/502.941/12.367 ms
附件二：
%top
last pid: 97006;load averages:0.00,0.01,0.00 up 530+17:46:55 14:08:41
19 processes:2 running, 17 sleeping
CPU states:2.3% user,0.0% nice,0.9% system,0.9% interrupt, 95.8% idle
Mem: 376M Active, 213M Inact, 85M Wired, 68K Cache, 112M Buf, 330M Free
Swap: 2000M Total, 2000M Free
PID USERNAME PRI NICESIZE RES STATE TIME WCPU CPU COMMAND
95497 bind 2 0 368M 368M select41.6H1.42%1.42% named
97006 root 28 01872K1104K RUN 0:002.07%0.68% top
73 root 2 0 940K 536K select38:050.00%0.00% syslogd
84 root 2 03000K1456K select 3:130.00%0.00% sshd
82 root 10 01016K 620K nanslp 1:210.00%0.00% cron
80 root 2 01088K 608K select 0:000.00%0.00% inetd
96942 jsquan 28 05700K2152K RUN 0:000.00%0.00% sshd
96962 root 18 01308K 896K pause 0:000.00%0.00% csh
96940 root 2 05700K2024K sbwait 0:000.00%0.00% sshd
96943 jsquan 18 01300K 892K pause 0:000.00%0.00% csh
3659 root 3 0 944K 456K ttyin 0:000.00%0.00% getty
3658 root 3 0 944K 456K ttyin 0:000.00%0.00% getty
7769 root 3 0 944K 652K ttyin 0:000.00%0.00% getty
111 root 3 0 944K 420K ttyin 0:000.00%0.00% getty
108 root 3 0 944K 420K ttyin 0:000.00%0.00% getty
112 root 3 0 944K 420K ttyin 0:000.00%0.00% getty
113 root 3 0 944K 420K ttyin 0:000.00%0.00% getty
110 root 3 0 944K 420K ttyin 0:000.00%0.00% getty
23 root 18 0 208K 64K pause 0:000.00%0.00% adjkerntz