DNS の仕組み

ブラウザにドメイン名を入力しても、コンピュータはその名前を直接使ってインターネット上にデータを送ることはできません。ルーターは単語を理解せず、数値の IP アドレスに基づいてパケットを転送します。

たとえば、google.com を入力すると、最終的には 142.250.190.14 のようなアドレスに解決されます。その IP アドレスが、グローバルネットワーク上の目的のサーバーを識別します。

変換システムがなければ、すべてのユーザーが利用するサービスごとに IP アドレスを覚えなければなりません。これはインターネット規模では明らかに現実的ではありません。

Domain Name System (DNS) は、インターネットの分散型電話帳のような役割を果たします。人間が読める名前を機械が読める IP アドレスに対応付けることで、通信を実際に開始できるようにします。

ブラウザに URL を入力しても、システムはすぐに HTTP リクエストを送信できません。まず、そのリクエストを どこに 送るのかを知る必要があります。

DNS 解決は、最初に行われるネットワーク処理です。ブラウザは「このドメイン名に対応する IP アドレスは何か？」と問い合わせます。IP アドレスを受け取って初めて、システムは宛先サーバーとの TCP ハンドシェイクを開始できます。

流れは厳密です:
DNS → TCP 接続 → HTTP リクエスト → サーバー応答

DNS が失敗すると、処理全体はすぐに停止します。接続試行も、暗号化のネゴシエーションも、アプリケーション層の通信も行われません。DNS は、リクエストライフサイクルの他のすべてを可能にするゲートキーパーです。

ドメイン名を要求すると、ブラウザはすぐにグローバルな DNS インフラに接続するわけではありません。まず、ローカルの情報源を確認します:

1. ブラウザのキャッシュ
2. オペレーティングシステムのキャッシュ
3. ルーターのキャッシュ

キャッシュされた結果が存在しない場合、その要求は通常、ISP が運用するか、8.8.8.8 のような公開プロバイダーが提供する 再帰 DNS リゾルバ に送られます。

その後、リゾルバは階層的なルックアップを実行します:

• Root サーバー に「.com はどこで見つけられますか?」と尋ねます。
• Root は、適切な TLD (Top-Level Domain) サーバー のアドレスを返します。
• リゾルバは TLD サーバーに「example.com はどこですか?」と尋ねます。
• TLD は、そのドメインの 権威ネームサーバー を返します。
• リゾルバは権威サーバーに実際の IP アドレスを問い合わせます。

権威サーバーが IP を返すと、リゾルバはそれをクライアントに返し、将来の利用のためにキャッシュに保存します。

この一連の処理は通常ミリ秒単位で完了しますが、構造としては、1 つのドメイン名を解決するために、複数のグローバルに分散したサーバーが連携しています。

もしドメインの検索のたびに毎回ルートサーバー、TLDサーバー、権威サーバーへ問い合わせる必要があるなら、DNSはすぐに世界規模のボトルネックになってしまいます。

これを防ぐために、DNSレスポンスはブラウザ、オペレーティングシステム、ルーター、再帰リゾルバーなど複数の場所でキャッシュされます。ドメインが一度解決されると、その結果は一時的に保存され、次回以降のリクエストでは完全な再帰的な処理を省略できます。

各DNSレコードには、秒単位で測定される TTL (Time To Live) の値が含まれています。TTLは、権威ソースから更新し直すまで、そのレコードをどれくらい保持してよいかをリゾルバーに伝えます。

TTLが短いと、ドメイン所有者はIPアドレスをより素早く変更できます。一方、TTLが長いとパフォーマンスが向上し、DNSトラフィックが減ります。TTLは、柔軟性と効率のバランスです。

キャッシュがあるからこそ、DNS解決は通常、基盤となるシステムが世界中に分散していても、ほぼ瞬時に感じられます。

DNS は、名前を 1 つの IP に変換するだけではありません。さまざまなサービスがどのように動作するべきかを定義する、構造化されたレコードを保存します。

A レコード は、ドメイン名を IPv4 アドレスに対応付けます（例: example.com → 93.184.216.34）。
AAAA レコード は、IPv6 アドレスに対して同じ役割を果たします。

CNAME (Canonical Name) レコード はエイリアスを作成します。IP アドレスに直接向けるのではなく、あるドメイン名を別のドメイン名に向けます。これは、サービスが外部プラットフォームでホストされている場合によく使われます。

MX (Mail Exchange) レコード は、そのドメインのメールを処理する責任があるメールサーバーを指定します。バックアップ用メールサーバーをサポートするために優先度の値も含まれます。

これらの基本的なレコードタイプを理解すると、Web サイトがどのように名前解決されるか、エイリアスがどのように機能するか、そして DNS を通じてメールのルーティングがどのように制御されるかが分かります。

1つの Web サイトが 1台のサーバーだけでホストされることは、ほとんどありません。トラフィックの多いサービスでは、パフォーマンスと信頼性のために、複数の地域にまたがって複数のサーバーを運用します。

DNS は、1つのドメインを複数の A または AAAA レコード に関連付けることで、基本的な負荷分散を可能にします。リゾルバがそのドメインを問い合わせると、異なる IP アドレスが交互の順序で返されることがあります。これを round-robin DNS と呼びます。

より高度な構成では geo-based DNS を使用します。これは、リゾルバがユーザーのおおよその位置に基づいて IP アドレスを返す仕組みです。たとえば、ヨーロッパのユーザーは、北米のデータセンターではなくヨーロッパのデータセンターへ誘導されることがあります。

DNS ベースのロードバランシングは、アプリケーション層のロードバランサーと比べると比較的シンプルですが、世界規模でスケーラブルであり、接続が確立される前に動作します。

そのため DNS は、単なる名前解決以上の役割を持ちます。パフォーマンス、可用性、トラフィック分散に、インターネット規模で影響を与えることができます。

DNS は、インターネットのリクエストライフサイクルにおける入口です。ここで失敗すると、その後の処理はすべて自動的に失敗します。

一般的な失敗シナリオには次のようなものがあります:

• recursive resolver が利用できない、または設定が誤っている。
• authoritative name server が停止している。
• DNS レコードが最近変更されたが、まだ完全に伝播していない。
• TTL が切れており、新しい問い合わせでも有効な応答を取得できない。
• ドメイン自体の設定が誤っている、または存在しなくなっている。

ユーザーの視点では、DNS の失敗は通常、“DNS_PROBE_FINISHED_NXDOMAIN” や “Server not found.” のようなメッセージとして表示されます。これらのエラーは、TCP のハンドシェイクや TLS のネゴシエーションが始まる前に発生します。

DNS は接続確立の前に動作するため、DNS が失敗するとアプリケーション層の通信はすべてブロックされます。システムは、見つけられない相手には接続できません。