DNSの遅延：DNSパフォーマンスのベストプラクティスとトラブルシューティングを理解する

DNSはインターネットにおいて最も重要な構成要素の一つであり、その動作はエンドユーザーエクスペリエンスの良し悪しを左右する重要な要素です。DNSの応答速度が極端に遅いと、ユーザーエクスペリエンスが悪化し、顧客がウェブサイトを読み込む前に離脱してしまう可能性があります。

この記事では、DNS解決の仕組みについて、エンドユーザーデバイスがDNSリクエストを送信してからユーザーが接続先のIPアドレスに返されるまでの転送時間について説明します。また、DNS解決時間に関する統計情報を共有し、遅延の原因となる要因や、さまざまなコンポーネントのパフォーマンスを測定する方法について解説します。最後に、DNSパフォーマンスを向上させ、優れたユーザーエクスペリエンスを提供するための推奨事項をいくつかご紹介します。

主要概念の要約

DNSルックアップ時間の定義	DNSルックアップ時間は、コンピュータがDNSレコードを要求してから、正しい応答を受け取るまでの時間を計測したものです。
DNSが遅いとはどういう意味ですか？	DNS応答が遅いとは、DNS解決にかかる時間が全体的に長くなり、ユーザーエクスペリエンスに悪影響を与える場合を指します。
DNSルックアップ時間に影響を与える要因	DNSルックアップ時間は、インターネット接続状況、サーバーからの遅延、設定の詳細、およびDNSサーバーのパフォーマンスによって異なります。
DNSの遅延問題のトラブルシューティング	DNSの応答速度が遅い場合は、ネットワーク遅延ツール（pingやtracerouteなど）とDNSパフォーマンステストツール（digやDNSPerfなど）を使用してトラブルシューティングを行ってください。
高速なDNSパフォーマンスを確保するためのベストプラクティス	高可用性を実現するためにCDNを使用し、ベンチマークとパフォーマンスチューニングを実施し、DNSのTTL値を増やし、CNAME（DNSエイリアス）を使用してください。

DNSルックアップ時間の定義

インターネットブラウザにウェブサイトのアドレスを入力すると、コンピュータはウェブサイトのコンテンツを取得する前に、そのウェブサイトのIPアドレスを見つける必要があります。アドレスを取得するために、コンピュータは設定済みのDNSサーバー（リゾルバ）にウェブサイトのアドレス解決を依頼します。DNSリゾルバは、トップレベルドメイン（TLD）サーバーをDNSルートサーバーに問い合わせる反復解決プロセスを開始し、続いてウェブサイトの権威DNSサーバーをTLDサーバーに要求します。最終的な要求はウェブサイト自体の権威DNSサーバーに送信され、IPアドレスがコンピュータに返されます。 

これらの各ステップには時間がかかり、それらをすべて合計すると、コンピュータが目的のウェブサイトコンテンツを取得するまでの合計解決時間になります。このDNS応答時間の速さが、ユーザーエクスペリエンスの良し悪しを左右します。

DNSの遅延の原因と影響

調査によると、ウェブサイトのパフォーマンス（特にDNS解決時間）は、顧客が特定のサイトにとどまるか、必要な情報やサービスを求めて競合他社のサイトに移動するかに大きな影響を与えることがわかっています。

Googleの市場調査 ウェブサイトのページ読み込み時間が1秒から3秒に増加すると、エンドユーザーの離脱確率は32%に増加し、5秒になると90%に上昇することが示されています。理想的には、DNSルックアップ時間は最大100ミリ秒、できれば50ミリ秒未満に抑えることで、良好なユーザーエクスペリエンスに貢献し、ウェブサイトのコンテンツがブラウザに読み込まれるまでの1～2秒の余裕が生まれます。以下のスナップショットは、 ウェブページテスト.org この図はcisco.comウェブサイトのパフォーマンスを示しています。DNSルックアップ時間は、ウェブサイトの接続遅延とページ読み込み時間に加算されます。ここでは2回のDNSルックアップが行われます。まずcisco.com（25ms）にアクセスし、次にwww.cisco.comにリダイレクトします（さらに33msかかります）。

上記の表は、ウェブページコンテンツ全体を読み込むために行われるさまざまなリクエストを（部分的に）示したものです。ページが使用可能な状態になるまでに6秒以上かかりましたが、これは理想的なベンチマークよりもはるかに長い時間です。次のセクションでは、DNSパフォーマンスを測定し、このパフォーマンスを改善する方法について説明します。 

DNSルックアップ時間に影響を与える要因

インターネット通信は、 TCP/IP参照モデル2台のホストまたはコンピュータが通信する場合、通信は一方のホストのアプリケーション層で開始されます。通信データはインターネット層（ネットワーク層とも呼ばれる）を通過し、インターネット経由で他方のホストに送信されます。受信側では、データは（逆の順序で）各層をたどり、アプリケーション層に到達します。アプリケーション層は通信を受信し、処理した後、応答を送信します。この応答データは、同じ層を逆方向にたどります。

コンピュータがDNS解決要求を開始すると、コンピュータ内のDNSクライアントアプリケーションがDNSクエリを作成します。このクエリはコンピュータのネットワークスタックを通過し、インターネット接続を介して送信され、指定されたDNSサーバーネットワークで受信され、DNSリゾルバアプリケーションに渡されます。リゾルバは前述の反復的な解決プロセスを実行し、要求元のクライアントにIPアドレスを返します。この階層化された通信の各ステップには時間がかかります。 

DNS解決時間全体に影響を与える重要な要素をいくつか挙げます。

• エンドユーザーのインターネット接続速度と混雑状況
• ユーザーとDNSサーバー間の地理的距離とネットワーク遅延
• 地理的な距離に関係なく、送信元と宛先間の経路が最適ではない。
• DNSサーバーのネットワークパフォーマンス、レイテンシ、および輻輳
• リゾルバとTLDおよび権威DNSサーバー間の地理的距離
• 受信リクエストを処理するためのDNSサーバーの計算リソース
• コンピューティングリソースとリクエスト数に基づいたDNSアプリケーションの最適化とチューニング

DNSの遅延問題のトラブルシューティング

あなたがオンラインショッピングのウェブサイトを持っているとしましょう。 exampleshop.com, あなたは（架空の）大手ホスティング会社からウェブホスティングとDNSサービスを取得しました。エンドユーザーのウェブブラウザに「このサイトにアクセスできません」といったエラーメッセージが表示されるというフィードバックを受けています。ウェブサイトとホスティングのパフォーマンスは良好に見えるため、これはウェブサイトのDNS解決に問題があるのではないかと疑っています。

DNS応答の遅延の原因を特定し、トラブルシューティングを行うためのツールは数多くあり、その多くは無料です。トラブルシューティングを行う際は、問題の原因を特定し、切り分けるために、体系的なアプローチを取ることをお勧めします。ネットワークスタックの異なるレベルに存在する様々なコンポーネントのために困難が生じる場合もありますが、考えられる原因を一つずつ排除していくことから始められます。

ネットワークパフォーマンスのテスト

以下のテストではLinuxマシンを使用します。まず、ネットワークのパフォーマンスに問題がないかテストすることから始めます。最も基本的なテストは、 ping 小さなメッセージを送信するコマンド（エコーリクエスト) マシンから宛先へ送信し、応答を待ちます (エコー応答応答が受信された場合、pingはメッセージが返ってくるまでの時間を示します。そうでない場合は、タイムアウトメッセージが表示されます。 

ここでは、Big Hosting Co.のDNSサーバーに3つのメッセージを送信し、平均約28ミリ秒の応答時間でパケットロスなしの応答を得ました。

$ ping -c 3 ns1.bighosting.co
PING  (192.168.53.10) 56(84) bytes of data.
64 bytes from ns1.bighosting.co (192.168.53.10): icmp_seq=1 ttl=57 time=28.3 ms
64 bytes from ns1.bighosting.co (192.168.53.10): icmp_seq=2 ttl=57 time=28.1 ms
64 bytes from ns1.bighosting.co (192.168.53.10): icmp_seq=3 ttl=57 time=27.6 ms

---  ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 27.644/27.989/28.256/0.255 ms

世界中からウェブサイトにアクセスする顧客がいることを覚えておいてください。Looking-glassサービスを使用して同じテストを実行できます。Looking-glassは、サービスプロバイダーの視点からネットワークテストやルーティング情報の検索を実行するためのさまざまなツールを提供する公開サービスです。多くの大手プロバイダーがLooking-glassサービスを提供しており、以下の方法で簡単に見つけることができます。 ピアリングDB一つの選択肢は https://lg.he.net Hurricane Electric の製品を使用すると、グローバル ネットワークの多くの場所からネットワーク コマンドを使用できます。 traceroute コマンド。pingはエンドツーエンドの統計情報を提供するのに対し、tracerouteは送信元と宛先間の各ネットワークホップをより詳細に可視化します。 

$ traceroute -n ns1.bighosting.co
traceroute to ns1.bighosting.co (192.168.53.10), 30 hops max, 60 byte packets
 1  10.10.100.1  7.991 ms  4.466 ms  4.427 ms
 2  10.10.175.242  9.600 ms  9.566 ms  9.529 ms
 3  172.16.11.149  12.094 ms  12.061 ms  12.027 ms
 4  172.16.165.42  12.024 ms  11.989 ms  11.955 ms
 5  172.16.165.41  11.888 ms  11.851 ms  11.818 ms
 6  172.16.200.49  13.070 ms  8.537 ms  8.451 ms
 7  192.168.65.67  15.398 ms  19.377 ms 19.276 ms
 8  192.168.53.10  27.185 ms  25.042 ms 24.715 ms

pingとtracerouteを使用して、異なる間隔で複数回の測定を行うことで、さまざまな時点でのネットワークパフォーマンスを把握できます。結果に異常な遅延やパケットロスが見られる場合は、ネットワークの問題をさらに詳しく調査する必要があります。ネットワークパフォーマンスが正常であれば、アプリケーション層のトラブルシューティングに進むことができます。 

DNSアプリケーションのパフォーマンスをテストする

DNSアプリケーションの応答をテストするためのツールの1つは、コマンドラインユーティリティです。 digdigは「Domain Information Groper」の略です。digを使用すると、DNSクエリの解決を実行し、ドメインが正しいレコードに解決されていることを確認できます。digは、TTL値や応答時間など、回答とともに詳細な情報も提供します。 

DNS応答テスト

以下の例では、ns1.bighosting.co にクエリを送信して exampleshop.com の IP アドレスを解決します (出力は簡潔にするために一部省略しています)。

$ dig exampleshop.com @ns1.bighosting.co

;; QUESTION SECTION:
;exampleshop.com.			IN	A

;; ANSWER SECTION:
exampleshop.com.		305	IN	A	192.168.90.100

;; Query time: 34 msec

まず、Aレコードの正しいアドレスを受信して​​いることを確認します。次に、応答時間を確認します。この場合は34ミリ秒です。応答時間は、ネットワーク遅延28ミリ秒（上記でテストしたとおり）に対して適切です。この応答に100ミリ秒以上かかる場合は、DNSサーバーのパフォーマンスを調べる必要があります（これについては後述します）。また、digを使用して、マシンがリゾルバとして動作し、レコードのエンドツーエンドのDNS解決を実行するようにシミュレートすることもできます。 +トレース このオプションでは、各ステップの応答時間を含む完全な反復フローが表示されます（ただし、以下の出力は一部省略されています）。

$ dig exampleshop.com +trace

;; global options: +cmd
.			308838	IN	NS	a.root-servers.net.
.			308838	IN	NS	g.root-servers.net.
.			308838	IN	NS	f.root-servers.net.


;; Received 811 bytes from 127.0.0.53#53(127.0.0.53) in 1 ms

com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.

;; Received 1169 bytes from 198.97.190.53#53(h.root-servers.net) in 38 ms

exampleshop.com.		172800	IN	NS	ns1.bighosting.co.
exampleshop.com.		172800	IN	NS	ns2.bighosting.co.

;; Received 773 bytes from 192.48.79.30#53(j.gtld-servers.net) in 199 ms

exampleshop.com.		600	IN	A	192.168.90.100
exampleshop.com.		1800	IN	NS	ns2.bighosting.co.
exampleshop.com.		1800	IN	NS	ns1.bighosting.co.
;; Received 268 bytes from 192.168.53.10#53(ns1.bighosting.co) in 47 ms

ここで名前解決を完了するまでの合計時間は約285ミリ秒です。この時間には、テストマシンから各DNSサーバーまでのネットワーク遅延と、各サーバーの処理時間が含まれます。権威DNSサーバーからより多くのネットワークホップを経由するクライアントの場合、名前解決時間は長くなります。

エンドユーザーの応答時間を改善するため、DNSキャッシュリゾルバやその他のネットワークキャッシュツールには、DNSリゾルバ内にキャッシュメカニズムが組み込まれています。リゾルバは、完全な反復処理を再度実行する必要がないため、キャッシュされたレコードを非常に迅速に返します。

世界各地のマシンにアクセスできる場合は、digコマンドを使用して、さまざまなネットワークからドメインのDNS応答を測定し、エンドユーザーが経験する遅延を把握することができます。

DNSサーバーのパフォーマンスベンチマーク

もう一つの便利なオープンソースツールは DNSPerfDNSPerfとLinuxマシンを使用すれば、複数のDNSクライアントからのトラフィックをシミュレートすることで、権威DNSサーバーのベンチマークテストを行うことができます。DNSサーバーに大量のクエリを送信することで、トラフィック処理能力の上限を測定できます。そして、これらのベンチマーク結果に基づいて、アプリケーションの設定やサーバーリソースを微調整することが可能です。

次の例では、ns1.bighosting.co サーバーが 30 秒間に 100 クエリ (QPS) を処理できるかどうかをテストします。 

実行するDNSクエリを定義するテスト入力ファイルを作成します。

exampleshop.com	A
exampleshop.com	AAAA
exampleshop.com	MX
exampleshop.com	NS

次に、上記で作成したファイル（出力は省略）を入力として指定し、dnsperfベンチマークを開始します。

$ dnsperf -d inputfile -s ns1.bighosting.co -l 30 -Q 100

[Status] Testing complete (time limit)

Statistics:

  Queries sent:         3000
  Queries completed:    3000 (100.00%)
  Queries lost:         0 (0.00%)

  Response codes:       NOERROR 3000 (100.00%)
  Average packet size:  request 29, response 137
  Run time (s):         30.000116
  Queries per second:   99.999613

  Average Latency (s):  0.006252 (min 0.002663, max 0.126665)
  Latency StdDev (s):   0.006760

ベンチマーク結果では、この負荷条件下でのDNSサーバーのパフォーマンスが詳細に示されます。出力統計情報には、DNSによって処理されたクエリ数と失われたクエリ数、応答の平均レイテンシ、およびエラーが返されたかどうかが表示されます。スレッド数、QPS、およびテスト期間を増やすことで、対象のDNSサーバーの上限をテストし、さまざまな条件下でのサーバーのパフォーマンスを確認できます。

これらのネットワークおよびDNSテストユーティリティは、特定の時点での可視性は高いものの、それだけでは十分ではありません。ネットワークとアプリケーションのパフォーマンス履歴を保存し、継続的な可視性を確保するためには、ネットワークおよびアプリケーション監視プラットフォームの利用を強くお勧めします。 

LogicMonitorのインターネットパフォーマンス監視ソリューション、 キャッチポイントこのプラットフォームは、完全なDNS可観測性を提供します。バックボーンネットワークとラストマイルネットワークに複数の監視ノードが配置されています。エンドユーザーの視点からDNS測定を実行します。予期しないレコード変更をアラートで通知し、DNSインフラストラクチャとの間の遅延、パケット損失、往復時間を正確に測定することで、DNSレコードの整合性を確保し、真のエンドユーザーエクスペリエンスを実現します。 

高速なDNSパフォーマンスを確保するためのベストプラクティス

以下は、DNSのパフォーマンスを本来あるべき状態に維持するための重要な推奨事項です。

CDNアーキテクチャを備えたDNSプロバイダーを使用する

サービスプロバイダーを選ぶ際には、必ず事前に調査を行い、最低限の稼働時間とパフォーマンス基準を満たすプロバイダーを絞り込むことが重要です。アプリケーションの重要度によっては、2つの異なるプロバイダーを利用することを検討すべきでしょう。なぜなら、DNSがダウンすると、すべてのアプリケーションとサービスが停止し、重大な経済的損失につながる可能性があるからです。

DNSプロバイダーを選択する際に推奨される基準には、以下のようなものがあります。

• 地理的に分散されたDNSサーバー/リゾルバーノードの数。
• 可用性の保証と、プロバイダーが使用するフェイルオーバーメカニズム。主要なプロバイダーのほとんどは、世界中のデータセンター間でエニーキャストを使用し、世界各地での遅延を最小限に抑え、データセンター間での自動フェイルオーバーを実現しています。 
• プロバイダーによるサービス稼働時間、品質、および遅延に関する保証。
• 既存顧客からのフィードバック。

また、次のようなサードパーティの監視サービスを利用することもできます。 DNSPerfさまざまなサービスプロバイダーの比較統計を取得するため。

自己管理型DNSを検討する

DNSサービスのもう一つの選択肢は、自社で導入・管理するDNSサーバーを使用することです。必要な技術スキルがあり、サービスをより細かく制御したい場合は、独自のDNSサーバーを導入することもできます。その場合は、以下のベストプラクティスを参考にしてください。

• 2台以上のサーバーを異なる地理的地域に展開する。
• サーバーは、自社管理のデータセンター、またはクラウド上でホストされるインフラストラクチャに展開します。
• クラウド環境への導入を検討する場合は、実績があり評価の高いクラウドサービスプロバイダーを選んでDNSサーバーをデプロイしてください。
• デプロイ後、nslookup/digコマンドを使用して、すべてのDNSサーバーが正しいDNSレコードで応答していることを確認してください。
• 本番稼働を開始する前に、ベンチマークツールを使用して、DNSサーバーが想定されるトラフィックを処理できることを確認してください。
• テスト結果に基づいて、サーバーの設定を微調整し、仕様を変更してください。

キャッシュの効果を高めるために、DNSのTTL値を増やす。

DNSレコードには、有効期限（TTL）値が設定されます。TTL値は、レコードがDNSリゾルバのキャッシュに保持される期間を決定します。TTL値が長いほどキャッシュの効果が大きくなり、エンドユーザーへのDNS応答が速くなります。

DNSエイリアスまたはCNAMEフラット化の使用

DNSレコードの一般的な慣習の一つは、複数のレコードが同じアドレスを指すようにすることです。例えば、次のような場合が考えられます。 exampleshop.com (NAIST) と www.exampleshop.com 同じ Web サイトを指すようにするため。そのためには、A レコードを次のように設定します。 exampleshop.com と定義する www.exampleshop.com CNAMEレコードである。ユーザーが開こうとすると www.exampleshop.com、 その結果、DNSルックアップが2回発生します。1回目はCNAMEレコードを取得し、2回目は実際のIPアドレスを取得します。したがって、DNSレコードの取得にかかる時間が2倍になります。

現在、多くのDNSアプリケーションとDNSプロバイダは、ALIASレコードまたはCNAMEの「フラット化」をサポートしています。これは、レコードをALIAS（www.exampleshop.com）として定義し、別の名前（exampleshop.com）を指すように設定した場合、www.exampleshop.comへのクエリが届いた際に、DNSサーバーがALIASのAレコードを検索し、IPアドレスを1回のクエリでクライアントに返すという仕組みです。これにより、二重検索を行うことなくCNAMEの利点を享受できます。 

しかし、これには潜在的な欠点があります。クライアント側のDNSリゾルバが、このタイプのレコードを認識しない古いBIND DNSソフトウェアを使用している場合、ドメイン全体のDNSクエリが完全に失敗する可能性があります。 

ウェブサイトのコードでDNSプリフェッチを使用する

現代のウェブサイトのほとんどは動的で、さまざまなソース（画像、動画、フォントなど）からコンテンツを取得します。各ソースのDNSルックアップには時間がかかり、ウェブページの読み込みが遅れることになります。 

ウェブサイト開発者として、ウェブページの HEAD 要素に小さなコードスニペットを追加することで、ユーザーがリンクを開いたり表示したりする前に、リストされているすべての外部ウェブサイトの DNS 解決を実行させることができます。この機能は DNS プリフェッチと呼ばれ、 ほぼすべての主要ブラウザでサポートされています以下は、 Mozilla開発者向けウェブサイト 外部フォントURLのDNSプリフェッチを追加するため。

<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link rel="dns-prefetch" href="https://fonts.googleapis.com/" />
    <!-- and all other head elements -->
  </head>
  <body>
    <!-- your page content -->
  </body>
</html>

主要概念の要約

DNSのパフォーマンスは、ウェブサイト全体のパフォーマンスとユーザーエクスペリエンスの質を左右する重要な要素です。この記事では、DNSルックアップ時間、DNS応答が遅くなる原因、およびパフォーマンス低下につながる要因について考察しました。

DNSのパフォーマンス低下のトラブルシューティングには、pingやtracerouteを使用してネットワークパフォーマンスをテストしたり、digを使用して個々のDNS応答をテストしたり、DNSPerfを使用してDNSサーバーの高負荷テストを実行したりする方法があります。これらのテストを異なる間隔で実行することで、サーバーのパフォーマンスをさまざまな時間帯で確認できます。

良好なDNSパフォーマンスを確保するためのベストプラクティスとしては、CDNをサポートするプロバイダの利用、セルフマネージドDNSの検討、DNS TTLパラメータの増加、CNAMEフラット化またはDNSプリフェッチの利用などが挙げられます。これらのアプローチを組み合わせることで、DNSの遅延問題を解消し、収益性の向上に繋げることができます。