请教关于dnstop和Query/respone比例

jsquan

一、dnstop 的输出结果如下：

1. Sources              count      %
   
2. ---------------- --------- ------
   
3. 220.173.230.2         7008   19.8 (client's ip1)
   
4. 220.173.222.25        1252    3.5 (client's ip2)
   
5. 220.173.222.23        1043    2.9 (client's ip3)
   
6. 220.171.231.251        749    2.1 (client's ip4)
   
7. 220.171.226.123        651    1.8 (client's ip5)
   
8. 220.172.128.68         647    1.8 (我的primary DNS's ip)

复制代码

二、分析
client's ip1 ~ client's ip5，查询的次数，竟然比我的DNS's ip
还要大，应该是client感染了病毒所致。
我是通过在named.conf中增加如下语句解决的。
recursive-clients 10000;  (该值默认为100)。

三、结果




四、问题，请教abel

这种情况下，正如附图所示，query 远远大于　respone。
按照你某文说，failure所占的比例应为3%~5%，我想我的
肯定超过这个范围，请你指教。谢谢。

我的dns输出结果图正常吗?

abel

先請教您 dnstop 工作原理 ?
那幾個欄位意義 ?
mrtg 您怎產生 ?

client IP 的 DNS 指到您身上嗎 ?

failure所占的比例应为3%~5%

我那文的意思是說, Faillure 比例不要太高,以不超過此值較好
就像我們看 Packet Lost rate 一般

jsquan

原帖由 "abel" 发表：

我那文的意思是說, Faillure 比例不要太高,以不超過此值較好
就像我們看 Packet Lost rate 一般

1、关于dnstop，请你看看
http://bbs.chinaunix.net/forum/viewtopic.php?t=196600&show_type=new

精华版有不少。

2、我的mrtg是参照你的方法（跟你学的，我原来一直想通过ssh/fetch，
从远端DNS获得named.stats数据，但由于mrtg server与dns server
时间很难同步，获得正确的mrtg图真难。毕意，为确保dns server的安全
性，肯定不能在dns server上安装mrtg和apache等软件，以免带来安全漏洞。）。
看到你的文章，通过在mrtg server上，使用
rndc -s remote-dns-ip status
产生，并且下载使用了你的9.3.0_abel文件。

这方面，希望你有更多的文章，特别是，某种情况下，如何获得远端
dns的failure数据。（正如你所说，rndc -s remote-dns-ip stats，
named.stats数据依然在dns server上！）
我的shell比较差，所以，请你能将目前最新的9.3.0_abel举一所三，
或者直接教我们写一份Query/Failure，total/Failure的shell，来
产生两维的mrtg图。


3、你可能没有使用过dnstop，所以无法判定如下信息：
Sources 　　　　count      %
----------------    ---------   ------
220.173.230.2   7008    19.8 (client's ip1)
220.173.222.25  1252   3.5 (client's ip2)
220.173.222.23  1043   2.9 (client's ip3)
220.171.231.251 749    2.1 (client's ip4)
220.171.226.123  651    1.8 (client's ip5)
220.172.128.68 647       1.8 (我的primary DNS's ip)

我在这里解释一下：
第一栏，是连结我的dns server (220.172.128.6的来查询dns记录的client
IP地址。
第二栏，count，是在某个统计时间段内，每个clients 查询DNS的记录数量。
第三栏，是第二栏所占的百分比。

按正常情况下，所有client ip查询的数量=dns sever的查询数量。
在这里，排在前面的client ip查询dns记录的数量远远大于dns sever
本身向root servers的查询量。因此，可以判断这些客户端是感染了计
算机病毒，这些病毒对我的DNS服务器产生DDOS（拒绝服务攻击所致）。

由于我的DNS是公网server，所以不能通过named.conf中的ACL来拒绝
这些感染病毒的计算机。而是通过
通过在named.conf中增加如下语句解决的。
recursive-clients 10000; (该值默认为100)。
从而提高我的DNS服务器处理性能。

但这么一来，攻击依然存在。换句话讲，这种攻击是随意的查询某些并不
存在的域名记录。从而导致query >;>;（远远大于）respone。

所以我认为，这是导致图上青色的线与蓝色线分离较远。同样的道理，导致了
failure 百分比肯定是远大于了5%。

4、关于病毒攻击DNS，我想很多同行都应该碰到过，或许解决办法是一样的。


请abel对上述予以解释或评论。谢谢。

abel

Sources count %
---------------- --------- ------
220.173.230.2 7008 19.8 (client's ip1)
220.173.222.25 1252 3.5 (client's ip2)
220.173.222.23 1043 2.9 (client's ip3)
220.171.231.251 749 2.1 (client's ip4)
220.171.226.123 651 1.8 (client's ip5)
220.172.128.68 647 1.8 (我的primary DNS's ip)

我看了一下,想來 dnstop 是一個單純的 sniffer dns packet 的軟體,他做的是監看流過網卡的 DNS 封包.
對照於 tcpdump 應只是 tcpdump udp port 53 這類的指令,而您用 rndc 看的是進到 named 這個服務程式的
查詢/回應數,我想就跟本上是有點差別的,我相信排名在您 DNS 之上的 IP,其 DNS Server 並未指向您的
220.172.128.68 身上,或是您的 220.172.128.68 的網卡效能較差(我相信這點的可能性較小)
dnstop 在 pcap 中使用的語法為(我從 dnstop source code 中找到的):

1. 
   
2. udp dst port 53 and udp[10:2] & 0x8000 = 0
   

复制代码

代表著只查看目的port 53,且 udp 封包中的第十個 bytes 起的2個bytes(udp[10]) , AND 0x8000 後需為0
這兩個 bytes 在 DNS Packet 來看為

1. 
   
2.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   
3.     |QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
   
4.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   
5. 0x8000=1000000000000000
   
6. 對應上面即只比 QR 值需為 0,QR 值為0表示為 DNS查詢,詳情可見 RFC 1035,4.1.1. Header section format
   

复制代码

所以,推論 dnstop 只能看"經過網卡的查詢數"

如果要驗證這個想法,常用的方式您可直接以 tcpdump src host 220.173.230.2 and port 53 的指令來驗證
就可以觀察出第一名的 220.173.230.2 到底將 DNS Packet 送到那裏去了.我覺得應先確認的是上面的 IP
是否真的將 DNS Server 設到了 220.172.128.68. 有些問題我們才能持續探討下去,我個人認為他們並沒有設
到 220.172.128.68 上,或是您運行 dnstop 的位置不在 220.172.128.68 上,這得視您整個網路的結構,及跑的
dnstop 節點是否正確,但我相信您的 dnstop 位置應是在 220.172.128.68 上.

另外,就您附的圖來看,我想最後的一筆 mrtg 資料時間應相近於您 dnstop 的結果,我個人認為,這是因為您的
排名前四名,將頻寬(bandwidth)吃掉了,造成整個網路掉包(Packet Lost)嚴重,所以 查詢/回應 數才會漸分開,
基本上,查詢-回應=失敗數,所以就最後的狀況來看,您的 DNS Failure 率巳近 50%,若從經驗來看,應該是網路
滿載問題為主,因為 bind 至少可以上5000次/每秒,且 Failure 比率也不會過5%,當然,還有一種可能性,就是我的
程式沒改好,但個人認為機會不高,因為我們巳經用兩年了,自己在做時也做了許多驗證.

按正常情况下，所有client ip查询的数量=dns sever的查询数量。

應誤植,正確應為 client ip查询的数量>;=dns sever的回應数量
或在 bind 9 的統計資料來看, client ip查询的数量>;=dns sever的遞歸查詢次數
(BIND 8 的統計資料會分開算遞歸次數,BIND 9 不管來回幾次僅算一次)

個人猜測的結論即是:
dnstop 結果可以參考,但不代表對您的 dns 發生查詢,可能僅是流過網卡的封包而以
mrtg 結果是真正到 named 裏的資料,但剛開始失敗率很低,但網路可能漸滿載,造成 Packet Lost 嚴重所致
其他,待您提供更多資料,以確認狀況

此外,個人會建議您,勿在標題寫明某人,基本上如此會妨礙了他人的討論意願,您可在發表主題後,有需要,再 pm
給我,如此您才不會錯失其他觀點的看法,指名,對您,對個人,或對其他人可能都不是一個好的方式,一點建議.還望
海涵.