給阿驍兄的賀禮二: DNS 流量統(tǒng)計~超強版

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查詢(次數(shù)/秒)
Legend2[_]: DNS回應(次數(shù)/秒)
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統(tǒng)計

abel

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

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

jsquan

最近有些郁悶，查詢數(shù)與回復數(shù)曲線有時間距太大，
請問各位也是否碰到，怎么處理？

附圖

abel

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

jsquan

原帖由 "abel" 發(fā)表：
我覺得你應該去看其他的資料,例如流量資料等,是否和DNS 圖上的資料有一定相關.
或是在 DNS 上先開 query log , 以觀察看看

一、首先感謝abel。

你的提示中，我的理解如下：
1、你可能覺得是否是我DNS有其他流量與DNS相關。
（1）從兩線間距較大的情況來看，說明還是正常的DNS查詢數(shù)遠大于響應數(shù)。
我在ns1和ns2上，都沒有啟動除ns服務以外的服務器進程。
（2）在時間上看，ns1和ns2在相同的時間上，出現(xiàn)兩條線間距較大。某些時
候，間距不大，說明較為正常。
所以我認為，一般的，應該不是惡意流量攻擊。

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的域名服務器時，有什么不一樣的地方？（第一問）
考慮到大陸的互聯(lián)網用戶，多數(shù)是查詢的是.cn的域名，是不是使用
xxx.net.cn或xxx.com.cn作為域名服務器的域會更好呢？（第二問）


2、關于查詢數(shù)與回應數(shù)兩線相距很遠的問題，我曾經使用dnstop分析過。
我個人認為，某個window用戶將我的ns1和ns2作為它的主備域名服務器，
但該window平臺可能受病毒攻擊過或是該計算機上有惡意攻擊DNS服務器的
程序，從而導致查詢數(shù)與回應數(shù)兩線相距很遠。即查詢的正確率較低。

當出現(xiàn)上述情況時，我通常的做法是看/var/log/messages文件，此時會發(fā)現(xiàn)
系統(tǒng)中出現(xiàn)大量的如下信息：

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

復制代碼

上面這段代碼，已經出現(xiàn)很久了，我想其他ns管理員也經常碰到。


針對這種情況，我就會修改named.conf，將recursive-clients 的值加大。
例如：

1. 
   
2. recursive-clients 100000;

復制代碼

其實，我原來沒有使用這個參數(shù)，但我為了解決這個問題，逐步將值由1000，
提高到5000，再提高到1萬，直到現(xiàn)在的10萬。

這個問題，一直讓我最為郁悶。理由很簡單，我的ns1和ns2是為好幾萬用戶
服務，如果ns1和n2的查詢正確率很低的話，勢必影響到用戶的利益。

為此，請各位高手幫助指點！謝謝。[/code]

cpss

不是吧，jsquan，你的dns為幾萬用戶服務，但從你的dns解析數(shù)一般才100～200次/秒？那也太少了吧。
我這邊的解析數(shù)已經到了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. 同時間的流量是否有瓶頸,不見得是本機或現(xiàn)在的網路, 出口處也要多注意
3. 各設備的系統(tǒng)狀況是否正常(CPU/MEMORY/device..)

若以上都沒有問題,再找 query log 看看,畢竟 query log 佔大量的 I/O,
上面的圖可以看到,我們的流量和你差不多,但兩條線是重疊的,也就是
幾乎沒有背離現(xiàn)象,這也只是一臺普通的 Server 而以,用一般的 PC 跑到
每秒數(shù)千一定沒有什麼問題,我認為你的問題是在網路上為主,並不是這臺
DNS Server. (我測過每秒 1000 次查詢, CPU Loading 不會高於 20%, CPU
是 1G, RAM 1G 的機器).

1、我的DNS是ns1.xxx.net或ns2.xxx.net，我不知道用xxx.com
和xxx.net作ISP的域名服務器時，有什么不一樣的地方？（第一問）
考慮到大陸的互聯(lián)網用戶，多數(shù)是查詢的是.cn的域名，是不是使用
xxx.net.cn或xxx.com.cn作為域名服務器的域會更好呢？（第二問）

無所謂,因為這是給 user 用的,用什麼名稱都無關, user 的 resolver
是認 IP 的.

2、關于查詢數(shù)與回應數(shù)兩線相距很遠的問題，我曾經使用dnstop分析過。
我個人認為，某個window用戶將我的ns1和ns2作為它的主備域名服務器，
但該window平臺可能受病毒攻擊過或是該計算機上有惡意攻擊DNS服務器的
程序，從而導致查詢數(shù)與回應數(shù)兩線相距很遠。即查詢的正確率較低。

這個問題,若一般的 worm 通常是掃 IP 較無關,若 Email 的 worm 或 virus,
會狂發(fā)信沒錯,但 User 設的 smtp server 是 mail.xxx.com , 信是發(fā)到
mail.xxx.com , user 會解析的只有 mail.xxx.com , 而 windows 2000 以上
的機器,一般的都會做 Cache , 也就是只能解析一次,除非重開機(這個功能可關閉
但一般 99% 的人一定不會去關),所以,viurs mail 來查你的 dns server, 不是
Client, 所以,若您有這種考量,看到的 IP 應該是 Mail Server 才是
而通常 Mail Server 的發(fā)信速度肯定比不上 dns 的查詢速度的.
除非您的問題不是一臺影起,而是多臺累積下來的結果.

除你的圖中可以看到,查詢量是差不多的,這表示什麼 ?
如果你的 user 設了 DNS 為 IP1, IP2 , 理論上應該是 IP1 量應遠高於 IP2
因為 Resolver 不是輪詢的,而是會先用第一筆,所以我想你的圖和你的說明
肯定有差距  (我猜這是dns 代管主機,而不是像一般 ISP 給 user 用的 DNS Server)

再來看, 查詢差不多,失敗也差不多,何解呢 !? 大概您置這兩臺 Server 於
同一個 subnet 之下所致,應該在網路上適當?shù)姆指?例如一臺放在電信,一臺放在
聯(lián)通,或許失敗量也不會這麼一致了.

如果我的猜測沒有錯,這是代管主機,那就設代管主機為 recursion no, 因為這
不是給 user 設 DNS Server 用(Resolver), 而是給其他的 DNS Server 用.
我們的代管主機都是這麼設, User 再將 TCP/IP 中的 DNS 指到電信的 DNS Server 上
即可,本末上適當?shù)姆珠_會是較好的

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

jsquan

再次感謝abel的分析，特別是對網友問題執(zhí)著的回答，這一點，難能可貴。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. 同時間的流量是否有瓶頸,不見得是本機或現(xiàn)在的網路, 出口處也要多注意

復制代碼

我們網絡是China169(CNCnet)中的一部分，由于China169跟Sprint-globalone之間的出國帶寬比較擁擠。與ChinaNet也是擁擠嚴重。以下是從ns1到root-server的時延。內容較多，詳見附件一。

1. 3. 各設備的系統(tǒng)狀況是否正常(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 之下所致,應該在網路上適當?shù)姆指?例如一臺放在電信,一臺放在
   
3. 聯(lián)通,或許失敗量也不會這麼一致了.

復制代碼

我的ns1與ns2分別在不同的城域網。舉例假設ns1在臺北，那么ns2就在高雄。當然不在同一個subnet了。并且ns1與ns2是2*pos 155互聯(lián)。

6、
我的ns1和ns2都設置為recursion yes，并且，啟用了internal-view和external-view。


7、補充
我剛看到你在線，如果你方便使用QQ的話，能否與我聯(lián)絡。我的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]