DNS計測・監視

DNSのレスポンスタイムを多角的に分析

DNSとは

DNS(Domain Name System)とは、WebサイトやEメールのアドレスに使われるドメイン名と、IPアドレスとの対応づけを管理するために使用されているシステムです。
人間に分かりやすいドメイン名を、機械が使うIPアドレスに変換してくれる、インターネットでの通信の起点となる大事なサービスと言えます。

DNS計測・監視とは

DNSが遅延すれば、全ての通信は遅延し、DNSに障害が発生すれば、全てのサービスは提供できなくなります。
DNSの性能と可用性の管理は、全ての企業にとって最重要事項です。
DNS計測・監視は、24時間365日、国内の主要な光回線や携帯会社の回線を介して、名前解決に掛かる時間をレベル別に計測し、ボトルネックを特定します。

ルートサーバからの階層毎のレスポンスタイムの確認

ルートサーバから、階層を追って名前解決していき、それぞれのレスポンスタイムを計測することで、どこのNSが遅延しているのかを明確にします。

どのNSがレスポンスを返しているかを確認

NSが冗長構成を取っている場合には、どのNSがレスポンスを返しているのかを明確にします。
DNSのレスポンスタイムが遅延している場合には、最寄りのNSではなく、遠いNSがレスポンスを返している場合もあります。

実装

ターゲットなるドメイン名を頂きます。
札幌、新潟、東京、名古屋、大阪、福岡の国内6都市から、定常的にDNS Lookupを実行して、各レベルのNSからのレスポンスタイムを計測・監視します。
複数のNSが存在する場合には、それぞれのNSのレスポンスタイムを計測します。

計測頻度は、1分、5分、15分からお選び頂きますが、15分が推奨です。

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のリゾルバに対して、名前解決のリクエストを送る事で、そのレスポンスと可用性を分析します。
例えば

• CloudflareとAPNICが運営する1.1.1.1、Googleが運営する8.8.8.8、IBM社などが共同運営するQuad9による9.9.9.9のようなPublic DNS
• ISPや携帯キャリアが提供しているDNS
• 企業内で利用している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まで存在しています。

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

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

データ

散布図

累積分布関数

DNS観測値詳細

アラート/レポート機能

アラート機能

エラー検知

DNSのエラーを検知した場合には、即座に、指定のメールアドレスにアラートメールを送信することが可能です。

遅延検知

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

レポート機能

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