DNS計測・監視

DNS計測・監視

DNSは、インターネットを利用した全ての通信の起点を担います。
DNSが遅延すれば、全ての通信は遅延し、DNSに障害が発生すれば、全てのサービスは提供できなくなります。
DNSの性能と可用性の管理は、全ての企業にとって最重要事項です。

目的

ルートサーバからの階層毎のレスポンスタイムの確認
ルートサーバから、階層を追って名前解決していき、それぞれのレスポンスタイムを計測することで、どこのNSが遅延しているのかを明確にします。
どのNSがレスポンスを返しているかを確認
NSが冗長構成を取っている場合には、どのNSがレスポンスを返しているのかを明確にします。
DNSのレスポンスタイムが遅延している場合には、最寄りのNSではなく、遠いNSがレスポンスを返している場合もあります。

実装

ターゲットなるホスト名、もしくはIPアドレスを頂きます。
札幌、東京、大阪、福岡の国内4都市から、定常的にTrace Routeを実行して、経路上のレイテンシとパケットロスを計測・監視します。

計測頻度で、パケットロスを検知する確率が変わります。
パケットロスの発生確率は、途中経路のネットワーク機器の品質や負荷に問題が無ければ、ポアソン分布に従います。
計測頻度は、1分、5分、15分からお選び頂きますが、1分が推奨です。

DNSを巡るパフォーマンスや可用性の問題

DNSのパフォーマンスや可用性についてのテストは幾つかの手法を組み合わせる必要があります。
DNSは、複数の組織・ネットワークに跨った分散データベースシステムであるため、遅延や障害が発生した際に、原因も多岐にわたって考えられるからです。

1. BGP監視
BGPでルーティングの障害が発生していないかどうかを確認する
2. Trace Route計測・監視
ネットワークで経路上のホップでパケットロスや遅延が発生していないかどうかを確認する
3. DNS Direct計測・監視
各回線業者が提供しているDNSのリゾルバの問題かどうかを切り分ける
4. DNS Experience計測・監視
各回線業者が提供しているDNSのリゾルバを使わずに、回線だけを使って再帰検索を行い、どのレベルで問題が生じているかを切り分ける
5. DNS Traversal計測・監視
各レベルのDNSサーバは、複数のホストから構成されている事が多い。各レベルにおいて、どのホストが遅延しているのか、接続障害が発生しているのかを切り分ける

DNSのテストの種別

DNS Direct計測・監視

DNS Direct計測・監視は、特定のDNSのリゾルバに対して、名前解決のリクエストを送る事で、そのレスポンスと可用性を分析します。
例えば

一般的には、この計測を他の計測と組み合わせて分析をします。

DNS Experience計測・監視

DNS Experience計測・監視は、ネットワーク回線だけ、指定の計測ノードのものを使い、DNSのリゾルバは内部で独自のものを使い、キャッシュが無い状態で、名前解決のリクエストを送る事で、そのレスポンスと可用性を分析します。

ISPやキャリアのDNSの問題なのか、自社のDNSの問題なのか

例えば、DNSの名前解決で時間が掛かっている事を検出した時に、それが、ISPやキャリアが提供しているリゾルバの性能遅延なのか、そもそも、自社のDNSの遅延なのかの判別が難しいでしょう。
そのような時に、以下のように問題を切り分けます。

  1. DNS Direct計測・監視で、対象となるISPやキャリアのリゾルバでの名前解決時間を計測
  2. DNS Experience計測・監視で、対象となるISPやキャリアでの名前解決時間を、計測ノード内部で稼働しているリゾルバを使って計測
  3. 双方の値を比較してみて、DNS Direct計測・監視の値の分布が大きければ、ISPやキャリアのリゾルバの性能の問題、逆であれば、各レベルでのNSの性能の問題

クラウドコンピューティングのプラットフォームのDNSの問題

また、AWSのようなクラウドコンピューティングのプラットフォームを利用し、Route53のように複数のNSが冗長化のために展開されている場合、どのNSがレスポンスを返したのかを確認する必要があります。
DNS Experience計測・監視は、DNS Direct計測・監視では見えてこない、リゾルバの背後のプロセスとボトルネックを明らかにします。

CDNのDNSの問題

例えば、CDNのAkamaiのように、CNAME方式で利用している場合には、CNAMEがCNAMEを参照するCNAME Chain(多段CNAME)によって、再帰的名前解決は7段に及びます。
当然ながら、DNSの名前解決は、基本的に、大きなオーバーヘッドを持ちます。
それが、ISPやキャリア、地方都市の場所によって、大きく名前解決時間のバラツキを生じさせる事に繋がります。

DNS Traversal計測・監視

DNS Traversal計測・監視は、その都市のそのISPやキャリアでDNSの名前解決を行った際の権威DNSサーバのパフォーマンスを確認できるため、DNSの問題のトラブルシューティングに役立ちます。
レスポンスタイムの構成要素で、サーバレスポンスやその他の指標に変化がなく、DNSの時間だけが遅延した場合、DNSが正常であるかどうかを確認する必要があります。

まずは、Instant Testで利用可能なDNS Traversal計測を実行します。
このツールは、以下の順序でDNSルート全体を照会するので、各サーバのレスポンスと応答時間を調べることができます。

  1. ルートサーバ
  2. GTLDサーバ
  3. NSサーバ

各レベルにおいて、そのレベルの各サーバに問い合わせを行い、その応答と応答時間を記録します。
GTLDサーバに到達すると、テストは各サーバに対して5パケットの ping を実行します。
テストがいずれかのNS サーバに接続できなかった場合 (システムがエラーを受信した、接続できなかった、 Ping 送信中にパケットロスが発生したなどの可能性があります)、テストは最初に失敗したサーバへのTrace Routeを1回実行します。

最後に、サーバのホスト名を取得するために、HOSTNAME.BINDレコードのNSサーバーの最終レベルにクエリを実行します。
※ この結果を取得するためには、DNSサーバがHOSTNAME.BINDのエントリを持つように設定されていなければなりません。

このテストがどのように機能するかを理解するために、以下に DNS Traversal計測のサンプルを示します。
spelldata.co.jpの名前解決をするためのDNS Traversalテストを東京のUSENの光回線上で実行します。
すると、189msと書かれているのは、全てのネームサーバのレスポンスを合計した時間{(2+2+2+8+8+3+3+153)+(4+4)}です。

レベル1では、ルートサーバ、権威ネームサーバ、追加レコードのすべてを表示し、続いて各DNSサーバにテストクエリを実行し、その応答と応答時間を記録しています。
JPトップレベルドメイン名のゾーン(jpゾーン)を管理する権威サーバ(権威DNSサーバ)は、a.dns.jp~h.dns.jpまで存在しています。

サーバ名運用組織
a.dns.jp株式会社日本レジストリサービス(JPRS)
b.dns.jp一般社団法人日本ネットワークインフォメーションセンター(JPNIC)
c.dns.jp株式会社日本レジストリサービス(JPRS)
d.dns.jp株式会社インターネットイニシアティブ(IIJ)
e.dns.jpWIDEプロジェクト
f.dns.jp国立情報学研究所(NII)
g.dns.jp株式会社日本レジストリサービス(JPRS)
h.dns.jp株式会社日本レジストリサービス(JPRS)

UDPレベルで問題が発生しているかどうかを確認するためにpingが実行されます。
この結果を見ると、h.dns.jpが153msと他の権威サーバより大きく遅延している事が分かります。

Level1のデータ

レベル2では、権威ネームサーバの応答と応答時間を記録しています。
spelldata.co.jpの権威サーバは、jonah.ns.cloudflare.comと、zoe.ns.cloudflare.comの2つです。
いずれも、4msでレスポンスを返しているものの、jonah.ns.cloudflare.comは、パケットロスが5回中1回生じている事が分かります。

Level2のデータ

データ

散布図

DNSの計測拠点別→レベル別散布図

累積分布関数

DNSの計測拠点別累積分布

DNS観測値詳細

DNS観測値詳細

アラート/レポート機能

アラート機能

エラー検知
DNSのエラーを検知した場合には、即座に、指定のメールアドレスにアラートメールを送信することが可能です。
遅延検知
DNSのレスポンスタイムの閾値を設定し、その値を超えた観測値を計測した場合には、即座に指定のアドレスにアラートメールを送信することが可能です。

レポート機能

日次で、DNSのレスポンスタイムについて、グラフ化したレポートを指定のメールアドレスに送信することが可能です。

お問い合わせフォーム

本サービスのご相談やお見積り、事例についてなど、お気軽にお問い合わせ下さい。

➡ サービス、製品に関するお問い合わせ