DNS計測・監視

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

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

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サーバの稼働状況とレスポンスを継続的に確認し、高可用性を確保します。
レコードの正確性の検証
A、AAAA、CNAME、MX、TXTなどのDNSレコードが、様々なリゾルバで意図どおりに正しく名前解決されているかを検証します。
DNS変更の伝播の追跡
DNSの変更が各地域やISPにどのくらいの速さで伝播するかを監視し、TTL設定や更新の有効性を確認します。
Geo-DNSの動作の分析
地域ごとにDNSレスポンスがどのように変化するかを確認し、CDNの設定、負荷分散、リージョンルーティングポリシーを検証します。
CNAMEチェーンの検証
過剰なCNAMEの多段参照や、壊れたCNAMEチェーンを検出し、名前解決の速度や信頼性への影響を特定します。

DNSテストの詳細設定

DNS計測・監視では、用途に合わせて以下の詳細設定が利用できます。

TLDネームサーバクエリのキャッシュ
トップレベルドメイン(TLD)サーバへのリクエストをキャッシュし、権威ネームサーバの探索に掛かる時間の影響を除外します。TLDから返されるNSレコードのリストは保存されますが、TLDへの問い合わせ時間はテスト結果に影響しません。
障害発生時のプライマリホストへのデバッグ実行
テストが失敗した場合に、プライマリホストに対してPing、Traceroute、DNS Traversalを自動的に実行し、原因の特定を支援します。
DNS再帰解決の無効化
再帰的な名前クエリでは、DNSサーバはクライアントに対して要求されたリソースレコードか、レコードが存在しない旨のエラーメッセージを返す必要があります。この設定を有効にすると、DNSサーバは別のサーバへのリファーを行いません。特定サーバのパフォーマンスを単独で監視する場合に有効です。
EDNSサブネット
サーバへのクエリにIPサブネット情報を含める事ができます。サーバはこの情報を使って、指定サブネットに近いIPアドレスに名前解決します。Geo-DNSの動作検証に有効です。
TCP/UDP プロトコルの選択
DNS計測はデフォルトではUDPを使用しますが、TCPによる計測も選択できます。DNSのUDPペイロードは通常512バイトが上限であり、DNSSECのレスポンスやIPv6アドレスが多数含まれる場合など、レスポンスサイズが512バイトを超える際にはTCPへのフォールバックが発生します。また、ファイアウォールやセキュリティポリシーでUDP/53がブロックされている環境では、TCPでの計測により実際の通信経路での名前解決の挙動を正確に把握できます。
最速RTTのネームサーバを優先
ラウンドトリップタイムが最も低いネームサーバを80%の割合で使用するよう設定します。実際のエンドユーザの名前解決に近い動作を再現します。
ネームサーバのホスト名取得方式
ネームサーバのホスト名取得に、BIND.HOSTNAMEとNSIDのいずれかを選択できます。BIND.HOSTNAMEはBINDの独自実装ですが、NSIDはRFC 5001で定義された標準的な識別子です。AWSのRoute53やCloudflareのように、多数のアノニマスなネームサーバインスタンスが分散稼働している環境では、外部から見ると同一のIPアドレスやホスト名に見えても、実際には異なるインスタンスがレスポンスを返している場合があります。NSIDを使用することで、どのインスタンスが応答しているかを特定でき、特定のインスタンスでのみ発生する遅延や障害の切り分けに有効です。
障害発生時に次のネームサーバへの試行
DNSクエリが失敗した際に、次のネームサーバに対してリトライします。デフォルトでは障害が発生したNSサーバでテストを失敗とし、即座に通知しますが、この設定を有効にするとエンドユーザの再帰リゾルバと同じ動作を模倣します。なお、この設定を有効にすると、NSサーバの問題検出が遅延する場合があります。
※ DNS Experienceテストでこの設定を有効にした場合、同一レベルで最大3つの異なるNSに対して、各1.5秒のタイムアウトで最大3回リトライします。サーバー障害（ServerFail）などのハードエラーの場合は次のネームサーバに移行せず、タイムアウト時のみ次のネームサーバに移行します。
MTUパスディスカバリの有効化
Tracerouteのパスにおけるマキシマム・トランスミッション・ユニット(MTU)データを収集します。追加監視としてTracerouteを設定している場合に有効です。
追加監視
同一の計測ノードから宛先へのTracerouteを追加で実行します。以下の追加監視に対応しています。
  • Traceroute Insession
  • Traceroute TCP
  • Traceroute ICMP
  • Traceroute UDP
  • Traceroute QUIC
  • Ping TCP
  • Ping ICMP
  • Ping UDP

計測メトリクス

DNS計測・監視では、以下のメトリクスを取得・分析します。

メトリクス説明
# Aレコード解決数テスト実行中に解決されたAレコードの個数。CNAMEチェーン追跡時の多段解決の深さを把握する際に使用します
# AAAAレコード解決数テスト実行中に解決されたAAAAレコードの個数
# CNAMEレコード解決数テスト実行中に解決されたCNAMEレコードの個数。多段CNAMEの段数確認に使用します
# NSレコード解決数テスト実行中に解決されたNSレコードの個数
計測回数指定期間内のテスト実行総数
テストエラー数失敗したテスト実行の総数。DNSエラー、接続障害、SSLエラー、レスポンスエラー、タイムアウトの各障害の合計
可用性テスト実行のうち、サーバに到達しテストが完了した割合。算出式: (テスト実行数 - テストエラー数) / テスト実行数
調整済み可用性手動でパージ（除外）した計測回を除いた上で算出する可用性。障害調査などで意図的に除外した計測を除いた正確なSLA算出に使用します
ダウンタイム率プライマリURLサーバが利用不可、到達不能、またはその他の障害が発生したテスト実行の割合。算出式: テストエラー数 / テスト実行数
Pingパケットロス率送信したPingパケットのうち、レスポンスが返らなかったパケットの割合
レスポンスタイム (ms)最初のリクエストから最後のレスポンスデータ受信までの合計時間
Ping往復時間 (ms)Pingパケットの送信からレスポンス受信までの平均時間
テスト時間 (ms)テスト実行の合計所要時間。Apdexスコアの算出に使用されます
Apdex事前に設定したレスポンスタイムの閾値を元に、「満足」「許容」「不満」の3段階でユーザ満足度を数値化するスコアリング指標。詳細は apdex.org を参照してください
満足率Apdexの「満足」閾値以内に完了したテスト実行の割合
許容率「満足」閾値を超えたが「不満」閾値以内に完了したテスト実行の割合
不満率「不満」閾値を超えたテスト実行の割合
Experience Scoreユーザ体験の総合的な品質を0〜100のスコアで表す複合指標

データ

散布図

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

累積分布関数

DNSの計測拠点別累積分布

DNS観測値詳細

DNS観測値詳細

アラート/レポート機能

アラート機能

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

レポート機能

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