WHMまたはSSH経由で1か月あたりのDNSクエリ数を確認してください。

出来ますか？DNSサーバーと実際にポイントされているサーバーを完全に制御できます。Ultra DNSに移行するため、現在取得しているDNSクエリの数に関心がありますが、1か月に取得する可能性のあるクエリの数を知る必要があります。

これは理解することは可能ですか？追跡を開始する前にサービスを開始する必要がありますか？またはシェルを使用してデータにアクセスしますか？

AndyNが言うように、ここでの答えは：

sudo rndc stats

これを実行すると（named.confファイルで構成されている場合）、Bindは統計情報を構成された統計ファイルにダンプします。

/etc/bind/named.conf.*ファイルで次の行を確認する必要があります。

 [ statistics-file "path_name"; ]

（Ubuntuではnamed.conf.options、パスはです/var/run/named/named.stats）

あなたの質問から、スケーリングの目的でおおよそのDNSクエリ数を知る必要があるようです。ファイルからこれの大まかなアイデアを得ることができるはずです。

sudo rndc statsを実行する

次に、適切な時間（数時間？数日？）の後で、再度実行します。

統計ファイルには、次のように表示されます（これは、自分のホームDNSサーバーからのものです。これは、キャッシュリゾルバであり、信頼できます）。

大量の情報についてのお詫び...最初の行の数値は「エポック時間」（1970-1-1 00:00 UTCからの秒数）です。これを使用すると、ある「rndc stats」から次の「rndc stats」までの時間の違いと、リクエストの異なる数を計算できます（着信「QUERY」と発信合計（A + NS + SOA + PTRを確認する必要があります） + TXT + AAAA）。

+++ Statistics Dump +++ (1275999954)
++ Incoming Requests ++
                432 QUERY
++ Incoming Queries ++
                 306 A
                   2 NS
                   4 SOA
                  45 PTR
                   5 TXT
                  70 AAAA
++ Outgoing Queries ++
[View: default]
                 523 A
                   4 NS
                   4 SOA
                  42 PTR
                   9 TXT
                 330 AAAA
[View: _bind]
++ Name Server Statistics ++
                 432 IPv4 requests received
                 431 responses sent
                 259 queries resulted in successful answer
                  96 queries resulted in authoritative answer
                 335 queries resulted in non authoritative answer
                  39 queries resulted in nxrrset
                 133 queries resulted in NXDOMAIN
                 238 queries caused recursion
                   1 duplicate queries received
++ Zone Maintenance Statistics ++
++ Resolver Statistics ++
[Common]
[View: default]
                 849 IPv4 queries sent
                  63 IPv6 queries sent
                 841 IPv4 responses received
                  67 NXDOMAIN received
                   2 FORMERR received
                   2 EDNS(0) query failures
                 123 query retries
                   5 query timeouts
                 118 IPv4 NS address fetches
                 118 IPv6 NS address fetches
                   1 IPv4 NS address fetch failed
                  90 IPv6 NS address fetch failed
                  13 queries with RTT < 10ms
                 549 queries with RTT 10-100ms
                 279 queries with RTT 100-500ms
[View: _bind]
++ Cache DB RRsets ++
[View: default]
                 366 A
                  87 NS
                   9 CNAME
                   1 PTR
                  97 AAAA
                  20 RRSIG
                  15 NSEC
                   4 !AAAA
                   1 NXDOMAIN
[View: _bind]
++ Socket I/O Statistics ++
                 852 UDP/IPv4 sockets opened
                  64 UDP/IPv6 sockets opened
                   3 TCP/IPv4 sockets opened
                   2 TCP/IPv6 sockets opened
                 850 UDP/IPv4 sockets closed
                  63 UDP/IPv6 sockets closed
                 123 TCP/IPv4 sockets closed
                   1 UDP/IPv4 socket bind failures
                  63 UDP/IPv6 socket connect failures
                 849 UDP/IPv4 connections established
                 124 TCP/IPv4 connections accepted
                  63 UDP/IPv6 send errors
                   3 UDP/IPv4 recv errors
++ Per Zone Query Statistics ++
--- Statistics Dump --- (1275999954)

コマンド「rndc stats」は、BIND DNSの最新バージョンで動作するはずです。

DistroWatchによると、CentOS 5.5にはBind 9.3.4-P1が付属しています。OPは、「rpm -qa | grep bind」を使用してコマンドラインからこれを確認できます。

AndyNの "rndc stats"（たまたまBINDを実行した場合）とkaerastの "dnstop"は良いアドバイスです。DNS統計の非常に包括的なパッケージであるDSCを追加します。

最初のステップは、DNSサーバーソフトウェアがこれをネイティブに処理できるかどうかを確認することです。おそらく、他の場所で分析できるログファイルを出力することによります。ネットワークトラフィックを監視することにより作成されたDNSクエリのトップライクな出力を提供するDnstopを使用できない場合。上位のリクエスト、上位のリクエスター、クエリの種類に関する統計だけでなく、合計で行われたリクエストの数も表示されます。

別の方法として、Ntopを使用してネットワークトラフィックを一般的に測定します。Dnstopと同じ詳細な正確な出力は得られませんが、表示されているDNSトラフィックの量に関するアイデアが得られ、他のキャパシティプランニングに役立つ可能性がある他のトラフィックの量も測定されます。

警告：サーバーがビジーの場合、これによりいくつかの巨大なログが生成されます。スペースに注意してください。

まず/etc/named.confで「クエリ」チャネルを有効にしてログを取得します。簡潔な例：

logging {
  channel queries_channel {
        file "/var/log/named/queries.log" versions 5 size 500m;
        print-time yes;
  };
  category queries { queries_channel; }
}

5つのバージョン（ローテーションされたログ）を500 MBに保つ方法に注意してください-必要に応じて調整して、必要なデータ量をキャプチャしてください。ログを取得したので、Googleは「クエリ統計をバインド」して、問題の数を見つけるためのニーズに最適なツールまたはソフトウェアを見つけます。BIND v8とv9の両方の形式をサポートしていることがわかっているものの1つは、http：//www.logreport.org/です。

万が一NagiosまたはCactiがインストールされている場合は、DNSサーバーをグラフ化する多数のチェックがあります。これには、リクエスト数、レートなどが含まれます。DNSサーバーを監視するためだけにこれらをインストールする価値はありませんが、すでにそれを持っている場合その後、どちらかはかなり良いオプションです。