DNSの名前解決が遅いときの対処法

DNSの名前解決は、気づかないほど速いのが本来の姿です。キャッシュ済みの応答なら通常は1桁から十数ミリ秒、キャッシュなしの完全な検索でも、数百ミリ秒を超えることはめったにありません。それより明らかに遅い場合、漠然とした全体的な遅さではなく、限られた特定の原因のどれかであることがほとんどです。

よくある原因

• 設定ミスまたは過負荷のリゾルバー。ISPの既定のリゾルバーの調子が悪いことは、思われているよりよくあります。1.1.1.1 や 8.8.8.8 のような公開の代替リゾルバーに切り替えるのは、単なる回避策ではなく、正当な診断の手順です。
• 長いCNAMEチェーン。リゾルバーが実際のA/AAAAレコードにたどり着くまでにたどる各ホップが遅延を加え、4、5ホップのチェーンになると、積み重なります。
• 非常に短いTTLのせいで、高速なキャッシュ済みの応答ではなく、頻繁な完全検索が強制される。素早い伝播には有効ですが、実際に必要な値よりはるかに短く設定すると、平均的な速度にとっては負担になります。
• リゾルバーと権威サーバーの間のネットワーク経路の問題。パケット損失、ルーティングの問題、近くにエニーキャストの拠点がないネームサーバーまでの地理的な距離など、DNSソフトウェアとはまったく無関係なものです。

DNSをほかの要因から切り分ける

DNSが本当にボトルネックなのかを知る最も確実な方法は、ページ全体の読み込みとは切り離して、検索だけを単独で測定することです。接続の確立、TLSのネゴシエーション、レスポンスのダウンロードとは別に計測した専用の検索を見れば、全体のレイテンシーのうち、DNSが占める割合が、もしあれば、正確に分かります。検索が常に1桁ミリ秒で返るのに、サイトの読み込みがそれでも遅く感じるなら、ボトルネックはDNSよりも下流にあり、これ以上DNSを調整しても改善しません。

思い込む前に、これを確認する価値があります。「サイトが遅い」という苦情の多くは、サーバーやサイトのコードとはまったく関係がないことが判明します。一方で、全体的な遅さに見えて、実はDNS固有の問題で、TTLやリゾルバーの変更で解決できるものも少なくありません。

エニーキャストリゾルバーが通常は速い理由

1.1.1.1 や 8.8.8.8 のような公開リゾルバーが、ISPの既定のリゾルバーより高速なのは、ソフトウェアが賢いからではなく、エニーキャストのおかげです。同じIPアドレスが世界中の数十か所の物理的な拠点から広告され、ネットワークのルーティングが、トポロジー上最も近い拠点へ、自動的にクエリを送ります。これに対して、ISP独自のリゾルバーは、1つ（またはごく少数）のデータセンターであることが多く、自分との位置関係によっては、実際にラウンドトリップが長くなります。リゾルバーの切り替えが、迷信ではなく正当な最初のトラブルシューティングの手順であるのも、このためです。それは気休めではなく、距離とルーティングという現実の物理的な違いに対処しているのです。

自分だけでなく、誰にとっても遅い場合

あるドメインが、1つだけでなく、複数の異なるネットワークやリゾルバーから遅く解決される場合、問題は「自分からリゾルバーまでの経路」から、「ドメイン自身の権威インフラ」に移っている可能性が高くなります。実際の訪問者の多くから長いネットワーク距離にある、エニーキャストではない単一の権威ネームサーバー、高負荷状態の権威サーバー、大きくて転送に時間がかかるDNSゾーンは、いずれもこの形で現れることがあります。これは、1回の検索よりも、複数のリゾルバーを使った一括比較のほうが診断に役立つケースです。どの観測地点でも一貫して遅いなら、途中のどこか1つのネットワークではなく、ドメイン自身のDNSプロバイダーという上流に原因があることを示しています。