給阿骁兄的賀禮二: DNS 流量統計~超強版 - 服务器类 - Dns服务器 - - 下载|源码|视频|软件|IT|新闻

其實也稱不上超強版,不過一般人可能較不會往這邊想而以... :mrgreen:
透過修改 bind 的 source code, 利用 rndc 從遠端直接抓出
dns 的query/response 次數,再利用 mrtg 或 rrdtool 來繪圖而以
(註:rndc 不懂的人自己去看,非本處主題)
這是我做的 bind-9.3.0 的 patch file, 有興趣的可拿去看看,如果懂程式
的話,你就會知道不同的版本如何改,如果不懂的話,你就將就用囉!
[code:1:f7a85c68b4]diff -cr bind-9.3.0/bin/named/query.c bind-9.3.0_abel/bin/named/query.c
*** bind-9.3.0/bin/named/query.c Wed Jun 30 22:13:05 2004
--- bind-9.3.0_abel/bin/named/query.c Wed Oct 13 00:45:07 2004
***************
*** 95,100 ****
--- 95,103 ----
  static void
  query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype);

+ static int querycount=0;
+ static int replycount=0;
+
  /*
   * Increment query statistics counters.
   */
***************
*** 112,121 ****
--- 115,132 ----
  zonestats[counter]++;
  }
  }
+ int get_query_count(void) {
+ return(querycount);
+ }
+
+ int get_reply_count(void) {
+ return(replycount);
+ }

  static void
  query_send(ns_client_t *client) {
  dns_statscounter_t counter;
+ replycount++;
  if (client->message->rcode == dns_rcode_noerror) {
  if (ISC_LIST_EMPTY(client->message->sections[DNS_SECTION_ANSWER])) {
  if (client->query.isreferral) {
***************
*** 3447,3453 ****
  query_error(client, result);
  return;
  }
!
  if (ns_g_server->log_queries)
  log_query(client);

--- 3458,3464 ----
  query_error(client, result);
  return;
  }
! querycount++;
  if (ns_g_server->log_queries)
  log_query(client);

diff -cr bind-9.3.0/bin/named/server.c bind-9.3.0_abel/bin/named/server.c
*** bind-9.3.0/bin/named/server.c Fri Jun 18 12:39:48 2004
--- bind-9.3.0_abel/bin/named/server.c Wed Oct 13 00:47:47 2004
***************
*** 3998,4003 ****
--- 3998,4005 ----
  n = snprintf((char *)isc_buffer_used(text),
       isc_buffer_availablelength(text),
       "number of zones: %u\n"
+      "number of query: %u\n"
+      "number of reply: %u\n"
       "debug level: %d\n"
       "xfers running: %u\n"
       "xfers deferred: %u\n"
***************
*** 4006,4012 ****
       "recursive clients: %d/%d\n"
       "tcp clients: %d/%d\n"
       "server is up and running",
!      zonecount, ns_g_debuglevel, xferrunning, xferdeferred,
       soaqueries, server->log_queries ? "ON" : "OFF",
       server->recursionquota.used, server->recursionquota.max,
       server->tcpquota.used, server->tcpquota.max);
--- 4008,4014 ----
       "recursive clients: %d/%d\n"
       "tcp clients: %d/%d\n"
       "server is up and running",
!      zonecount, get_query_count(), get_reply_count(),ns_g_debuglevel, xferrunning, xferdeferred,
       soaqueries, server->log_queries ? "ON" : "OFF",
       server->recursionquota.used, server->recursionquota.max,
       server->tcpquota.used, server->tcpquota.max);[/code:1:f7a85c68b4]
[b:f7a85c68b4]註:Patch 動作請自己做, patch -p1 < this_patch_file,本檔僅適合 9.3.0,沒空每版都寫出來[/b:f7a85c68b4]
以上的程式僅是在做 rdnc -s IP_addr status 時,可以帶出如下內容:
[root@log SIP]# rndc -s 211.72.210.251 status
[code:1:f7a85c68b4]number of zones: 1
number of query: 157
number of reply: 153
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
recursive clients: 0/1000
tcp clients: 0/100
server is up and running[/code:1:f7a85c68b4]
看到沒有,跟你的有什麼不同, 多了
[b:f7a85c68b4]number of query: 157
number of reply: 153[/b:f7a85c68b4]
兩欄,也就是我們加上去的,好了,你每一台機器都做了這樣的 patch 後
並做相同的 rndc.conf 的設定,就可以利用 rndc -s Server_IP status 取
得這樣的結果了,我們可以驗證看看數字到底對不對:

[code:1:f7a85c68b4]
#rndc -s Server_IP stats
# cat /var/named/named.stats
success 137
referral 0
nxrrset 6
nxdomain 10
recursion 142
failure 4
[/code:1:f7a85c68b4]
上面數字 success+nxrrset+nxdomain+failure=157 表示 dns 收到了
157 查詢,其中有 142 次做 recursion

不計算 failure 即為成功的查詢次數, 所以為 153

故程式的結果沒有問題 !!
我再寫一個小程式來做字串處理:
[code:1:f7a85c68b4]
#!/usr/bin/perl
open(II,"/usr/local/sbin/rndc -s $ARGV[0] status|");
while (<II>) {
  chomp;
  split(/: /,$_);
  print "$_[1]\n" if ($_[0] eq 'number of query' or $_[0] eq 'number of reply');
}
close(II);
[/code:1:f7a85c68b4]
Ex:filename 為 dns_flow.pl
./dns_flow.pl Server_IP
輸出結果為:
[code:1:f7a85c68b4]157
153
[/code:1:f7a85c68b4]

是不是變簡單了呢 !?
你若跑十台 DNS 服務,想來很多人會用 query log 來記 Query 量
這是最不好的方式,因為 Disk I/O 會很多
若你用 rndc stats 來做分折,是可以的,但資料滙整將是一個問題

改程式是終南捷徑(要會改就不是捷徑了)...
每部 DNS Server 再配置相同的 rndc.conf ,即可使用此一 rule
(不同也行,但就會變復雜了,相同的 rndc.conf 只要將一些 rndc
的設定copy 到別台機器即可)

利用 mrtg 來輸出結果:
[code:1:f7a85c68b4]
#  for UNIX
WorkDir: /www/html/mrtg
#  or for NT
# WorkDir: c:\mrtgdata

### Global Defaults

#  to get bits instead of bytes and graphs growing to the right
Options[_]: growright, noinfo

#---------------------------------------------------------------

Target[DNS_Server1]: `/home/abel/dns.pl 你的DNS_Server_IP`
MaxBytes[DNS_Server1]: 2500
Title[DNS_Server1]: A.DNS.TW (IPv6)
Legend1[DNS_Server1]: DNS查詢(次數/秒)
Legend2[DNS_Server1]: DNS回應(次數/秒)
LegendI[DNS_Server1]: DNS查詢
LegendO[DNS_Server1]: DNS回應
YLegend[DNS_Server1]: Q. per second
PageTop[DNS_Server1]: <h1>DNS_Server Query/Response</h1>
[/code:1:f7a85c68b4]
crontab 那些及 mrtg 設定細節就不再贅述

mrtg 結果:
http://211.72.210.251/dns/
[img:f7a85c68b4]http://211.72.210.251/dns/b-dns-week.png[/img:f7a85c68b4]

這次我就不寫 rrdtool 版本了,免得大家望文生畏,我也偷懶一下 :em03:
給阿骁兄的賀禮基本上 google 都是沒有或不足的,有興趣的人可好好研究
一下 :em06:

註: 我直接提供一個修改過的9.3.0版本給大家試試
http://211.72.210.251/bind-9.3.0.tar.gz
若不放心,請記得到 ftp://ftp.isc.org 下也抓一個 9.3.0
來做比較(diff -cr isc_dir abel_dir), 即可知我改了什麼

campoeagle 回复于：2004-10-13 10:53:55

深奥！

unixli 回复于：2004-10-13 11:20:57

有时间试试！

abel 回复于：2004-10-13 20:09:10

[code:1:4a3e27ba42]
+++ Statistics Dump +++ (1097653695) # rndc stats 的時間點
success 2764 #成功得到答案的次數
referral 0 #參考量,這個值是你回應 NS 的次數,也就是當你設成
#recursion=no 時,你?#93;有的答案你都會回應 . 的 NS 記錄
#這個NS回應即稱為 Referral,可以遞歸主機此值為0
nxrrset 15#nx 意即不存在(Not eXist),rrset 即記錄,不存在的記錄即無此名稱
nxdomain 55#不存在的網域名稱
recursion 16#遞歸次數,例如有人詢問 www.chinaunix.com 時,完全?#93;有 cache 狀況
#下,你會問 ./com/chinaunix.com 最後得到 www 結果,而此值只算一次
#也就是一次遞歸查詢,但實際查詢次數為3次去,3次回
failure 0#查詢失敗,也就是你送出了 Query,但 Server ?#93;有回應
--- Statistics Dump --- (1097653695)
[/code:1:4a3e27ba42]
所以,我們看 DNS 流量統計時:
Client <-------> DNS Server <--------> gTLD/ccTLD (./.com/.cn)

看的都是 Client 到 DNS 這一段,而較少看 DNS 到 TLD 這一段 (這一段 BIND8 可以做,但
很複雜,BIND 9 他不計算來來回回幾次)

Client<-----> DNS Server 流量計算,標準做法:
收到查詢量=success+referral+nxrrset+nxdomain+failure
送出的回應=success+referral+nxrrset+nxdomain

這是計算方法,但是你會發現,有點費事(其實也不會太費事),你對本機做 rndc stats 時
他們產生 named.stats 檔供你擷取,計算,算出數字後,畫成 mrtg 就不成什麼問題,但是
如果第有二台三台N 台 DNS 呢 ? rndc -s Server_IP stats , 這個 named.stats 是存
在遠端,這對你的處理來說會很費事,當然,你可以用 ssh/ftp/expect... 等去擷取,但無疑
是增加許多複雜度.

你要自己做,一定可以做的出來,需要任何 Patch,唯其工作及日後維護問題而以,我們可以
看到這個例子:
範例檔在這
[img:4a3e27ba42]http://211.72.210.251/named-query-hour.png[/img:4a3e27ba42]
[img:4a3e27ba42]http://211.72.210.251/named-query-day.png[/img:4a3e27ba42]
你可以將每個值都畫出來,但實際上較具意義的如上所說,唯查詢/回應的數字是我們要注意
的. 故使用 rndc status 對工作簡化有一定幫助:
利用 Patch 做出來的總合效果:
範例檔在這
日流量:
[img:4a3e27ba42]http://211.72.210.251/dns/TLD-day.png[/img:4a3e27ba42]
月流量:
[img:4a3e27ba42]http://211.72.210.251/dns/TLD-month.png[/img:4a3e27ba42]

我相信做法來看應該簡捷許多

阿骁回复于：2004-10-13 22:06:30

收到 abel 兄的第二份大礼，不过明天要出差一趟，周末才能回来，没时间消化啊!

风往南吹回复于：2004-10-14 09:57:20

实在太厉害了，打自内心佩服。这几份大礼真的是很有分量，得好好学习学习

skylove 回复于：2004-10-14 11:00:09

不错，以前一直用mrtg记录服务器的风扇转速，cpu使用，内存使用，网卡使用，以及ftp的使用情况。不过dns因为我们只提供有限的几个外部查询地址，所以流量一般不太大，所以就没用。另外根据我所知，一些邮件系统也是用它来记录。其实只要可以把数据整理成2维方式，都可以用mrtg来画图操作——不管用shell，perl，反正输入2维数据就行了。

顶一下，上面的分析过程那里很喜欢！

abel 回复于：2004-10-15 12:01:14

一般來說,二維的做法都很足夠了,但mrtg 的效率及資源的使用個人是較不
喜歡的,且有時我們需要做一個整體性比較時,幾張二維的圖不如整個合一張
,如此更容易了解彼此關係.

例
如上面看到的我提供的那張 mrtg 圖,其實這是一部 DNS 主機的流量而以
但我有 N 部要做,我如何知道總合狀況呢 ?

另外,像這張圖,基本上就是台灣這兩年來的DNS流量統計
(ccTLD 部份,.tw),只畫一台或是把七台畫成七張圖,都難以表現出來
"整體" 的概念:
[img:d205f782a5]/Article/UploadPic/2005-11/20051127151056937.png[/img:d205f782a5]

這兩年來,我們的 TTL 值都沒有變(這是一個很重要的前提),可以發現
.tw 的 DNS 查詢成長了三倍,不看一台而看整體,更有助於我們日後的
規畫.

skylove 回复于：2004-10-16 13:52:18

谢谢您的指点，受教了。

看来以后我画每个月的web流量访问图除了用awstat外，还可以用这个来分析每个月“总有那么几天”访问量特别高，or低的的出现时间段了。
然后利用这个分析出的时间段来进行维护等工作，就比较不影响用户了。

再次谢谢abel兄的指点！！

abel 回复于：2004-10-17 00:23:10

[quote:b22ea65f87="skylove"]谢谢您的指点，受教了。

看来以后我画每个月的web流量访问图除了用awstat外，还可以用这个来分析每个月“总有那么几天”访问量特别高，or低的的出现时间段了。
然后利用这个分析出的时间段来进行维护等工作，就?.........[/quote:b22ea65f87]
這個會不準,除非您將 TTL 設成0,才有意義,不然就設的很小很小,最好小於
15 秒,超過這個值.,大多數的 DNS Query 就不會問到您的 Server 了
因為都被外面的 Cache 了

skylove 兄有興趣,可以試試,將 TTL 值改變一下,以了解不同的 TTL 值對 DNS Query 的影響哦!
Ex: 您現在設為 86400 秒
做個 DNS 流量測試(最好做一星期),再改為 38400,再改為xxx, (每次 /2)
你就會知道,什麼 TTL 值對您來說會取得一個最佳的時間
(您會發現,若這個例子中,TTL 為 X 軸, Query 次數為 Y 軸,它會是一個曲線下降而不是直線下降)

skylove 回复于：2004-10-17 01:13:16

谢谢abel的提议，事实上或许那事件很有趣的事。

可惜的是我所在的高校地处西南，西南教育网网络中心的管理实在不太敢恭维——因此我们把大部分的服务都转到公网上去走中国电信的出口。惟独dns由于edu.cn类域名属于教育网专用，上级部门给予的授权ip地址是教育网段的。。。。若平时外面公网dns cache server能访问到我们的dns server则已是万幸了。。。断然不敢把ttl改得如此之小。。。

dns的query我是没机会做了，不过偶的web是用了cache的，正好用您指点的思路来证明一下cache的工作效率及使用cache的利/弊。文不如表，表不如图——得abel的指点，看来以后跟外行领导解释起来又方便了一些：）

david_hounew 回复于：2004-10-20 23:36:02

楼主,可以谈谈MRTG如何CONFIG吗??

abel 回复于：2004-10-21 03:15:40

幫一下,
不都寫在上面,知道 mrtg 怎接一個外部程式吧 !?

tma 回复于：2004-10-22 01:03:40

顶

gzaurora 回复于：2004-10-29 16:09:23

请教，rndc -s Server_IP stats 查询到的是dns收到的瞬间请求吗？但我尝试看过在四层交换机上面看连接数，但两种并不一致？而且比在四层上面看到的多很多，这是什么原因呢？thanks

abel 回复于：2004-10-29 16:13:46

rndc stats
看到是的運行以來的累計值
所以要再看 timestamp, 計算時間差

gzaurora 回复于：2004-10-29 16:59:57

[quote:bc06992da1="abel"]rndc stats
看到是的運行以來的累計值
所以要再看 timestamp, 計算時間差[/quote:bc06992da1]

请问，怎么看timestamp, 計算時間差？thanks

abel 回复于：2004-10-29 17:18:56

[code:1:329398ef68]+++ Statistics Dump +++ (1099041217)
success 252120
referral 0
nxrrset 6
nxdomain 4264
recursion 817
failure 34
--- Statistics Dump --- (1099041217)
+++ Statistics Dump +++ (1099041277)
success 252134
referral 0
nxrrset 6
nxdomain 4266
recursion 819
failure 34
--- Statistics Dump --- (1099041277)[/code:1:329398ef68]
1099041217 就是時間(ts1)
1099041277 就是時間(ts2)
ts2-ts1=60 (ts_range)
再將兩個 success/referral....加起來,但不計算 recursion,除以 ts_range , 就是你的 DNS 收到 Client 的每秒查詢量

gzaurora 回复于：2004-10-29 17:52:43

[quote:d9ac84a553="abel"]1099041217 就是時間(ts1)
1099041277 就是時間(ts2)
ts2-ts1=60 (ts_range)
再將兩個 success/referral....加起來,但不計算 recursion,除以 ts_range , 就是你的 DNS 收到 Client 的每秒查詢量[/quote:d9ac84a553]

:D 明白，thank you very much!

cpss 回复于：2004-12-12 19:08:14

首先感谢abel 带来了这么好的一个主意。在看了这篇帖子后，我马上就将我手上的dns全部变成了abel的修改版本，并通过rndc -s server status进行监控。
但我发现有个问题，abel 兄可能忽略了，那就是dns进程可能会重启，重启后通过rndc -s server status来看到的query和reply的数都被归0了，mrtg就不知道怎么运算了。从监控图上看，还以为是dns死了呢。说实话，当时确实吓我一跳。
于是我就自做主张重新写了个脚本，由于我对perl不熟，就用sh来写了。在这里贴出来，希望对大家有所帮助。
#cat dns_flow.sh
#!/usr/bin/sh
TMPDATAFILE="/var/named/.${1}.tmp"
RUN_1=0
query_old=0
reply_old=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"
fi

这时候mrtg的配置文件也要修改一下，表明采到的数据是absolute类型的。
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
.
.
.

cpss 回复于：2004-12-13 12:48:11

程序又升级了，我增加了一个所有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 回复于：2004-12-13 13:06:00

我的dns统计

我所有dns合计

我其中一台dns的统计

abel 回复于：2004-12-13 20:09:23

嗯...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 回复于：2004-12-15 08:41:51

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

附图

ns1xxx.net server

ns2.xxx.net　server

abel 回复于：2004-12-15 12:15:24

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

jsquan 回复于：2004-12-17 12:10:35

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

一、首先感谢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文件，此时会发现
系统中出现大量的如下信息：
[code:1:96e3e66918]Nov 25 19:55:22 ns2 named[50127]: client xxx.xxx.xxx.xxx(ip)#2441:
view external: no more recursive clients: quota reached[/code:1:96e3e66918]
上面这段代码，已经出现很久了，我想其他ns管理员也经常碰到。

针对这种情况，我就会修改named.conf，将recursive-clients 的值加大。
例如：
[code:1:96e3e66918]
recursive-clients 100000;[/code:1:96e3e66918]

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

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

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

cpss 回复于：2004-12-17 13:57:22

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

fuleru 回复于：2004-12-17 15:34:31

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

abel 回复于：2004-12-17 17:41:32

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

recursive-clients 設為多少意義應不大,預設好像是 1000
因為如 cpss 提到的,你的 query/response 並沒有很大,
我們的一台例子:
[img:9ae49b8041]http://log.twnic.net.tw/dns-sample.png[/img:9ae49b8041]
我個人認為你的問題應該先看:
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 的機器).

[quote:9ae49b8041]
1、我的DNS是ns1.xxx.net或ns2.xxx.net，我不知道用xxx.com
和xxx.net作ISP的域名服务器时，有什么不一样的地方？（第一问）
考虑到大陆的互联网用户，多数是查询的是.cn的域名，是不是使用
xxx.net.cn或xxx.com.cn作为域名服务器的域会更好呢？（第二问）
[/quote:9ae49b8041]
無所謂,因為這是給 user 用的,用什麼名稱都無關, user 的 resolver
是認 IP 的.

[quote:9ae49b8041]
2、关于查询数与回应数两线相距很远的问题，我曾经使用dnstop分析过。
我个人认为，某个window用户将我的ns1和ns2作为它的主备域名服务器，
但该window平台可能受病毒攻击过或是该计算机上有恶意攻击DNS服务器的
程序，从而导致查询数与回应数两线相距很远。即查询的正确率较低。
[/quote:9ae49b8041]
這個問題,若一般的 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 回复于：2004-12-18 14:21:30

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

1、
[code:1:c03bc53325]所以?#93;法回答你的問?#125;,我猜是 windows 對 v6 的支援不夠所致
但我無法證明,建議您到一些有論 v6 較深的論壇去問問,不然到我們這邊也可以
http://www.ipv6.org.tw [/code:1:c03bc53325]
你的建议是很好的，我对v6真可是一点也不通。只是工作还是不够专注。

2、
[code:1:c03bc53325]因為如 cpss 提到的,你的 query/response 並?#93;有很大, [/code:1:c03bc53325]
是的，Query/Response并不大，但的确ns1、ns2是chinanetcom即CNC
在南方某省的公网域名服务器。目前用户2万户左右。同时在线，我不清楚有多不少。

3、
[code:1:c03bc53325]1. 網路是否正常 ? Router/Switch/本機都要看, 看 Error 是否會太多 [/code:1:c03bc53325]
这个应该没问题。我先后在中电信、中网通，从事router/switch多年，对FreeBSD学习也有六年。

[code:1:c03bc53325]2. 同時間的流量是否有瓶頸,不見得是本機或現在的網路, 出口處也要多注意 [/code:1:c03bc53325]
我们网络是China169(CNCnet)中的一部分，由于China169跟Sprint-globalone之间的出国带宽比较拥挤。与ChinaNet也是拥挤严重。以下是从ns1到root-server的时延。内容较多，详见附件一。

[code:1:c03bc53325]3. 各設備的系統狀況是否正常(CPU/MEMORY/device..) [/code:1:c03bc53325]
这个没有问题。我的ns1和ns2是FreeBSD 4.8 releases平台。
1G Ram, 1*cpu 2.0 Ghz  我设置的swsap根本没有用到。如ns1信息。
详见附件二。

4、
[code:1:c03bc53325]我猜這是dns 代管主機,而不是像一般 ISP 給 user 用的 DNS Server[/code:1:c03bc53325]

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

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

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

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

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

[code:1:c03bc53325]
附件一：
%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
[/code:1:c03bc53325]

[code:1:c03bc53325]
附件二：
%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 NICE  SIZE    RES STATE    TIME   WCPU    CPU COMMAND
95497 bind       2   0   368M   368M select  41.6H  1.42%  1.42% named
97006 root      28   0  1872K  1104K RUN      0:00  2.07%  0.68% top
   73 root       2   0   940K   536K select  38:05  0.00%  0.00% syslogd
   84 root       2   0  3000K  1456K select   3:13  0.00%  0.00% sshd
   82 root      10   0  1016K   620K nanslp   1:21  0.00%  0.00% cron
   80 root       2   0  1088K   608K select   0:00  0.00%  0.00% inetd
96942 jsquan    28   0  5700K  2152K RUN      0:00  0.00%  0.00% sshd
96962 root      18   0  1308K   896K pause    0:00  0.00%  0.00% csh
96940 root       2   0  5700K  2024K sbwait   0:00  0.00%  0.00% sshd
96943 jsquan    18   0  1300K   892K pause    0:00  0.00%  0.00% csh
3659 root       3   0   944K   456K ttyin    0:00  0.00%  0.00% getty
3658 root       3   0   944K   456K ttyin    0:00  0.00%  0.00% getty
7769 root       3   0   944K   652K ttyin    0:00  0.00%  0.00% getty
  111 root       3   0   944K   420K ttyin    0:00  0.00%  0.00% getty
  108 root       3   0   944K   420K ttyin    0:00  0.00%  0.00% getty
  112 root       3   0   944K   420K ttyin    0:00  0.00%  0.00% getty
  113 root       3   0   944K   420K ttyin    0:00  0.00%  0.00% getty
  110 root       3   0   944K   420K ttyin    0:00  0.00%  0.00% getty
   23 root      18   0   208K    64K pause    0:00  0.00%  0.00% adjkerntz
[/code:1:c03bc53325][/code]

jsquan 回复于：2004-12-18 14:30:14

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

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

ns2.xxx.net Options[_]: growright, noinfo

ns1.xxx.netOptions[_]: growright, noinfo

jsquan 回复于：2004-12-20 09:58:19

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

ns1.xxx.net ( date:20041220) Options[_]: growright,bits

ns2.xxx.net ( date:20041220) Options[_]: growright,bits

abel 回复于：2004-12-21 15:59:18

Options[_]: growright,bits
不要 bits , 他會把數字 x8

對於您提到的幾個狀況,我目前也想不出來是什麼原因,
只能猜測是網路的瓶頸點,應該在那一磈造成了擁塞的狀況
bind 的 tarball 中 contrib 下附了一個叫 querypref 的程式
您可研究一下他的語法看

用一台 Server 開 query log, 記下來 user 查了什麼,
把 user 查的東西轉户 querypref 要用的 data format
(querypref 的目錄下文件有說明,很簡單即可完成,轉檔自己
寫一個小程式就可以了)

用 querypref 來發送 dns query, 並觀察 querypref report
mrtg report , 及其他網路或設備的狀況,以了解問題點在那裏
一般來說,ISP 的 IDC 試,單一 querypref 來送 , 可以到達每秒 1000 次
以上,您的狀況連一半都沒有是較人好奇的.您可在同一網段下再建一個
DNS 來試試(以免影響用戶)

有什麼結果大家可在討論看看

(我估記在 DNS Server 連外時, UDP timeout 會多,造成失敗)

coolgg 回复于：2004-12-21 23:10:51

to jsquan

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

平时负载发生很大变化除了病毒以及恶意攻击外，我认为还和某些设备（如缓存服务器、BRAS）动态改变首选dns有关。

某服务器一周负载

jsquan 回复于：2004-12-22 08:42:55

[quote:acab458dfb="coolgg"]to jsquan

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

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

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

1、Querylog　＆　Querypref (abel推荐的)

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

vias 回复于：2004-12-23 00:05:08

好贴！

jsquan 回复于：2004-12-23 09:24:08

相关贴子如下：
[code:1:3a95cbc2b1]请教关于dnstop和Query/respone比例
http://bbs.chinaunix.net/forum/viewtopic.php?t=430300&highlight=jsquan[/code:1:3a95cbc2b1]

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

[code:1:3a95cbc2b1]
一、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)

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

[/code:1:3a95cbc2b1]

skylove 回复于：2005-01-25 10:06:20

发现当每秒不到一次的时候...就没有记录咯....我这里经常是replay 0...真可怜

看来需要rrdtool出马了~~

[数据载入中...] [返回上一页] [打印] [收藏]

上一篇技术文章：一个疑问：为何某些门户网站直接输入IP地址却无法访问

下一篇技术文章：dns 感想之一