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

jsquan

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

附图

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]

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]

jsquan

现上传2004年12月18日的流量图如下：

对比这两幅图，也发现一个奇怪问题：
在11：10至12：00之间，对ns2而言，Query有一突发的高峰，Respone却
没有什么变化。对ns1而言，Query有一突发的高峰，Respone跟Query变化相
一致。

jsquan

请教，按abel采集Query/Respone流量时，mrtg.cfg文件，
是设置
Options[_]: growright, noinfo （见上一贴的图）
还是
Options[_]: growright,bits （见本贴的图）

jsquan

原帖由 "coolgg" 发表：
to jsquan

关于request和response相差大的情况，我这个星期也遇到2次，原因是网络不畅（路由器内存溢出），dns和外网基本断开。

平时负载发生很大变化除了病毒以及恶意攻击外，我认为还和某些设备（如缓存服务..........

谢谢。我想我该抽个时间，好好从下面两个方向自行分析一下，有结果再交流。
主要是自己工作太忙。不能潜心下来分析这个。

1、Querylog　＆　Querypref (abel推荐的)

2、跟踪一下厂家路由器设备。我的ns1与ns2连接在不同的城域网核心层节点。
设备也不一样。的确让我很郁闷。

jsquan

相关贴子如下：

1. 请教关于dnstop和Query/respone比例
   
2. http://bbs.chinaunix.net/forum/viewtopic.php?t=430300&highlight=jsquan

复制代码

回过头来，我们再看这个贴子，对于以下内容，请教又作何理解。

1. 
   
2. 一、dnstop 的输出结果如下：
   
3. 
   
4. 代码:
   
5. Sources              count      %
   
6. ---------------- --------- ------
   
7. 220.173.230.2         7008   19.8 (client's ip1)
   
8. 220.173.222.25        1252    3.5 (client's ip2)
   
9. 220.173.222.23        1043    2.9 (client's ip3)
   
10. 220.171.231.251        749    2.1 (client's ip4)
    
11. 220.171.226.123        651    1.8 (client's ip5)
    
12. 220.172.128.68         647    1.8 (我的primary DNS's ip)
    
13. 
    
14. 二、分析
    
15. client's ip1 ~ client's ip5，查询的次数，竟然比我的DNS's ip
    
16. 还要大，应该是client感染了病毒所致。
    
17. 我是通过在named.conf中增加如下语句解决的。
    
18. recursive-clients 10000; (该值默认为100)。
    
19. 
    

复制代码