給阿骁兄的賀禮二: DNS 流量統計~超強版

cpss

程序又升级了，我增加了一个所有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[DNS_Server1]: `/var/named/dns_flow.pl 192.168.1.2`
Title[DNS_Server1]: mydns1
Target[DNS_Server2]: `/var/named/dns_flow.pl 192.168.1.3`
Title[DNS_Server2]: mydns2
.
.
.
Target[DNS_Server100]: `/var/named/dns_flow.sh all`
Title[DNS_Server100]: alldns
MaxBytes[DNS_Server100]: 100000


注意：由于程序设计问题，dns合计一项一定要放在最后一行，切记切记。

cpss

我的dns统计

abel

嗯...cpss 也是箇中高手呀 !
您的觀點很正確, gauge 確時是較好的型態, counter 則是重設時會有
一段時間會不正常, 至於合計功能,倒建議您可學學 rrdtool ,
可以有較佳的處理效果
http://phorum.study-area.org/viewtopic.php?t=18496&postdays=0&postorder=asc&start=0
也或許您早巳懂了

用 rrdtool interval 可以精確到秒哦,不似 mrtg 最小只有 5min(300s)

jsquan

最近有些郁闷，查询数与回复数曲线有时间距太大，
请问各位也是否碰到，怎么处理？

附图

abel

我覺得你應該去看其他的資料,例如流量資料等,是否和DNS 圖上的資料有一定相關.
或是在 DNS 上先開 query log , 以觀察看看

jsquan

原帖由 "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文件，此时会发现
系统中出现大量的如下信息：

1. Nov 25 19:55:22 ns2 named[50127]: client xxx.xxx.xxx.xxx(ip)#2441:
   
2. view external: no more recursive clients: quota reached

复制代码

上面这段代码，已经出现很久了，我想其他ns管理员也经常碰到。


针对这种情况，我就会修改named.conf，将recursive-clients 的值加大。
例如：

1. 
   
2. recursive-clients 100000;

复制代码

其实，我原来没有使用这个参数，但我为了解决这个问题，逐步将值由1000，
提高到5000，再提高到1万，直到现在的10万。

这个问题，一直让我最为郁闷。理由很简单，我的ns1和ns2是为好几万用户
服务，如果ns1和n2的查询正确率很低的话，势必影响到用户的利益。

为此，请各位高手帮助指点！谢谢。[/code]

cpss

不是吧，jsquan，你的dns为几万用户服务，但从你的dns解析数一般才100～200次/秒？那也太少了吧。
我这边的解析数已经到了12K/秒，痛苦啊，太多了。

fuleru

不错啊。谢谢。好东西！！！！！

abel

我沒有用過 windows 的 v6 , 都只有在 linux 上用 (client or dns)
所以沒法回答你的問題,我猜是 windows 對 v6 的支援不夠所致
但我無法證明,建議您到一些有論 v6 較深的論壇去問問,不然到我們這邊也可以
http://www.ipv6.org.tw

recursive-clients 設為多少意義應不大,預設好像是 1000
因為如 cpss 提到的,你的 query/response 並沒有很大,
我們的一台例子:

我個人認為你的問題應該先看:
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 上
即可,本末上適當的分開會是較好的

所以...您多想想. 或許我有猜錯的,看您是否有其他補充.

jsquan

再次感谢abel的分析，特别是对网友问题执着的回答，这一点，难能可贵。netman一样，也具备这种精神。

1、

1. 所以?#93;法回答你的問?#125;,我猜是 windows 對 v6 的支援不夠所致
   
2. 但我無法證明,建議您到一些有論 v6 較深的論壇去問問,不然到我們這邊也可以
   
3. http://www.ipv6.org.tw

复制代码

你的建议是很好的，我对v6真可是一点也不通。只是工作还是不够专注。

2、

1. 因為如 cpss 提到的,你的 query/response 並?#93;有很大,

复制代码

是的，Query/Response并不大，但的确ns1、ns2是chinanetcom即CNC
在南方某省的公网域名服务器。目前用户2万户左右。同时在线，我不清楚有多不少。

3、

1. 1. 網路是否正常 ? Router/Switch/本機 都要看, 看 Error 是否會太多

复制代码

这个应该没问题。我先后在中电信、中网通，从事router/switch多年，对FreeBSD学习也有六年。

1. 2. 同時間的流量是否有瓶頸,不見得是本機或現在的網路, 出口處也要多注意

复制代码

我们网络是China169(CNCnet)中的一部分，由于China169跟Sprint-globalone之间的出国带宽比较拥挤。与ChinaNet也是拥挤严重。以下是从ns1到root-server的时延。内容较多，详见附件一。

1. 3. 各設備的系統狀況是否正常(CPU/MEMORY/device..)

复制代码

这个没有问题。我的ns1和ns2是FreeBSD 4.8 releases平台。
1G Ram, 1*cpu 2.0 Ghz  我设置的swsap根本没有用到。如ns1信息。
详见附件二。

4、

1. 我猜這是dns 代管主機,而不是像一般 ISP 給 user 用的 DNS Server

复制代码

你猜错了。我的是ISP给user的DNS　server。这一点不用怀疑。所以，我要
对用户负责。

5、

1. 再來看, 查詢差不多,失敗也差不多,何解呢 !? 大概您置這兩台 Server 於
   
2. 同一個 subnet 之下所致,應該在網路上適當的分隔,例如一台放在電信,一台放在
   
3. 聯通,或許失敗量也不會這麼一致了.

复制代码

我的ns1与ns2分别在不同的城域网。举例假设ns1在台北，那么ns2就在高雄。当然不在同一个subnet了。并且ns1与ns2是2*pos 155互联。

6、
我的ns1和ns2都设置为recursion yes，并且，启用了internal-view和external-view。


7、补充
我刚看到你在线，如果你方便使用QQ的话，能否与我联络。我的QQ：86269149

1. 
   
2. 附件一：
   
3. %sh pingdns
   
4. A.ROOT-SERVERS.NET
   
5. PING 198.41.0.4 (198.41.0.4): 56 data bytes
   
6. 64 bytes from 198.41.0.4: icmp_seq=0 ttl=238 time=336.644 ms
   
7. 
   
8. --- 198.41.0.4 ping statistics ---
   
9. 2 packets transmitted, 1 packets received, 50% packet loss
   
10. round-trip min/avg/max/stddev = 336.644/336.644/336.644/0.000 ms
    
11. B.ROOT-SERVERS.NET
    
12. PING 192.228.79.201 (192.228.79.201): 56 data bytes
    
13. 
    
14. --- 192.228.79.201 ping statistics ---
    
15. 1 packets transmitted, 0 packets received, 100% packet loss
    
16. C.ROOT-SERVERS.NET
    
17. PING 192.33.4.12 (192.33.4.12): 56 data bytes
    
18. 64 bytes from 192.33.4.12: icmp_seq=0 ttl=48 time=343.485 ms
    
19. 64 bytes from 192.33.4.12: icmp_seq=1 ttl=48 time=351.860 ms
    
20. 
    
21. --- 192.33.4.12 ping statistics ---
    
22. 2 packets transmitted, 2 packets received, 0% packet loss
    
23. round-trip min/avg/max/stddev = 343.485/347.673/351.860/4.188 ms
    
24. D.ROOT-SERVERS.NET
    
25. PING 128.8.10.90 (128.8.10.90): 56 data bytes
    
26. 64 bytes from 128.8.10.90: icmp_seq=0 ttl=42 time=269.159 ms
    
27. 64 bytes from 128.8.10.90: icmp_seq=1 ttl=42 time=268.628 ms
    
28. 
    
29. --- 128.8.10.90 ping statistics ---
    
30. 2 packets transmitted, 2 packets received, 0% packet loss
    
31. round-trip min/avg/max/stddev = 268.628/268.894/269.159/0.265 ms
    
32. E.ROOT-SERVERS.NET
    
33. PING 192.203.230.10 (192.203.230.10): 56 data bytes
    
34. 
    
35. --- 192.203.230.10 ping statistics ---
    
36. 2 packets transmitted, 0 packets received, 100% packet loss
    
37. F.ROOT-SERVERS.NET
    
38. PING 192.5.5.241 (192.5.5.241): 56 data bytes
    
39. 64 bytes from 192.5.5.241: icmp_seq=0 ttl=56 time=61.969 ms
    
40. 64 bytes from 192.5.5.241: icmp_seq=1 ttl=56 time=53.861 ms
    
41. 
    
42. --- 192.5.5.241 ping statistics ---
    
43. 2 packets transmitted, 2 packets received, 0% packet loss
    
44. round-trip min/avg/max/stddev = 53.861/57.915/61.969/4.054 ms
    
45. G.ROOT-SERVERS.NET
    
46. PING 192.112.36.4 (192.112.36.4): 56 data bytes
    
47. 
    
48. --- 192.112.36.4 ping statistics ---
    
49. 2 packets transmitted, 0 packets received, 100% packet loss
    
50. H.ROOT-SERVERS.NET
    
51. PING 128.63.2.53 (128.63.2.53): 56 data bytes
    
52. 64 bytes from 128.63.2.53: icmp_seq=0 ttl=27 time=469.883 ms
    
53. 
    
54. --- 128.63.2.53 ping statistics ---
    
55. 2 packets transmitted, 1 packets received, 50% packet loss
    
56. round-trip min/avg/max/stddev = 469.883/469.883/469.883/0.000 ms
    
57. I.ROOT-SERVERS.NET
    
58. PING 192.36.148.17 (192.36.148.17): 56 data bytes
    
59. 64 bytes from 192.36.148.17: icmp_seq=0 ttl=44 time=422.592 ms
    
60. 64 bytes from 192.36.148.17: icmp_seq=1 ttl=44 time=422.066 ms
    
61. 
    
62. --- 192.36.148.17 ping statistics ---
    
63. 2 packets transmitted, 2 packets received, 0% packet loss
    
64. round-trip min/avg/max/stddev = 422.066/422.329/422.592/0.263 ms
    
65. J.ROOT-SERVERS.NET
    
66. PING 192.58.128.30 (192.58.128.30): 56 data bytes
    
67. 64 bytes from 192.58.128.30: icmp_seq=0 ttl=245 time=448.464 ms
    
68. 64 bytes from 192.58.128.30: icmp_seq=1 ttl=245 time=436.557 ms
    
69. 
    
70. --- 192.58.128.30 ping statistics ---
    
71. 2 packets transmitted, 2 packets received, 0% packet loss
    
72. round-trip min/avg/max/stddev = 436.557/442.510/448.464/5.954 ms
    
73. K.ROOT-SERVERS.NET
    
74. PING 193.0.14.129 (193.0.14.129): 56 data bytes
    
75. 64 bytes from 193.0.14.129: icmp_seq=0 ttl=45 time=342.935 ms
    
76. 64 bytes from 193.0.14.129: icmp_seq=1 ttl=45 time=343.755 ms
    
77. 
    
78. --- 193.0.14.129 ping statistics ---
    
79. 2 packets transmitted, 2 packets received, 0% packet loss
    
80. round-trip min/avg/max/stddev = 342.935/343.345/343.755/0.410 ms
    
81. L.ROOT-SERVERS.NET
    
82. PING 198.32.64.12 (198.32.64.12): 56 data bytes
    
83. 64 bytes from 198.32.64.12: icmp_seq=0 ttl=53 time=197.546 ms
    
84. 64 bytes from 198.32.64.12: icmp_seq=1 ttl=53 time=197.011 ms
    
85. 
    
86. --- 198.32.64.12 ping statistics ---
    
87. 2 packets transmitted, 2 packets received, 0% packet loss
    
88. round-trip min/avg/max/stddev = 197.011/197.279/197.546/0.267 ms
    
89. M.ROOT-SERVERS.NET
    
90. PING 202.12.27.33 (202.12.27.33): 56 data bytes
    
91. 64 bytes from 202.12.27.33: icmp_seq=0 ttl=243 time=502.941 ms
    
92. 64 bytes from 202.12.27.33: icmp_seq=1 ttl=243 time=478.207 ms
    
93. 
    
94. --- 202.12.27.33 ping statistics ---
    
95. 2 packets transmitted, 2 packets received, 0% packet loss
    
96. round-trip min/avg/max/stddev = 478.207/490.574/502.941/12.367 ms
    

复制代码

1. 
   
2. 附件二：
   
3. %top
   
4. 
   
5. last pid: 97006;  load averages:  0.00,  0.01,  0.00                       up 530+17:46:55 14:08:41
   
6. 19 processes:  2 running, 17 sleeping
   
7. CPU states:  2.3% user,  0.0% nice,  0.9% system,  0.9% interrupt, 95.8% idle
   
8. Mem: 376M Active, 213M Inact, 85M Wired, 68K Cache, 112M Buf, 330M Free
   
9. Swap: 2000M Total, 2000M Free
   
10. 
    
11.   PID USERNAME PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU COMMAND
    
12. 95497 bind       2   0   368M   368M select  41.6H  1.42%  1.42% named
    
13. 97006 root      28   0  1872K  1104K RUN      0:00  2.07%  0.68% top
    
14.    73 root       2   0   940K   536K select  38:05  0.00%  0.00% syslogd
    
15.    84 root       2   0  3000K  1456K select   3:13  0.00%  0.00% sshd
    
16.    82 root      10   0  1016K   620K nanslp   1:21  0.00%  0.00% cron
    
17.    80 root       2   0  1088K   608K select   0:00  0.00%  0.00% inetd
    
18. 96942 jsquan    28   0  5700K  2152K RUN      0:00  0.00%  0.00% sshd
    
19. 96962 root      18   0  1308K   896K pause    0:00  0.00%  0.00% csh
    
20. 96940 root       2   0  5700K  2024K sbwait   0:00  0.00%  0.00% sshd
    
21. 96943 jsquan    18   0  1300K   892K pause    0:00  0.00%  0.00% csh
    
22. 3659 root       3   0   944K   456K ttyin    0:00  0.00%  0.00% getty
    
23. 3658 root       3   0   944K   456K ttyin    0:00  0.00%  0.00% getty
    
24. 7769 root       3   0   944K   652K ttyin    0:00  0.00%  0.00% getty
    
25.   111 root       3   0   944K   420K ttyin    0:00  0.00%  0.00% getty
    
26.   108 root       3   0   944K   420K ttyin    0:00  0.00%  0.00% getty
    
27.   112 root       3   0   944K   420K ttyin    0:00  0.00%  0.00% getty
    
28.   113 root       3   0   944K   420K ttyin    0:00  0.00%  0.00% getty
    
29.   110 root       3   0   944K   420K ttyin    0:00  0.00%  0.00% getty
    
30.    23 root      18   0   208K    64K pause    0:00  0.00%  0.00% adjkerntz
    

复制代码

[/code]