はじめに
先週の記事では、Cloudflare でドメインを購入する方法について話しました。今回は、ブラウザにドメインを入力してから、実際にサーバーへ接続するまでに何が起きているのかを解説します。それでは始めましょう。
このブログを例に挙げます：https://blog.clarkliu.com。実際にサーバーへ接続する前に、以下のステップを経ることになります。
ステップ 1 — ブラウザのキャッシュを確認する
以前に同じサイトを訪問したことがあれば、ブラウザや OS がその結果をキャッシュしています。次回アクセス時はそのキャッシュを使うため、DNS の問い合わせを省略してサーバーに直接接続できます。
ステップ 2 — Recursive Resolver に問い合わせる（ISP または 8.8.8.8）
キャッシュがない場合、ブラウザは Recursive Resolver に処理を委ねます。Recursive Resolver の役割は、あなたの代わりに各サーバーへ問い合わせを繰り返し、最終的に必要な IP アドレスを取得して返すことです。デフォルトでは ISP（例：台湾であれば中華電信など）が提供する Recursive Resolver が使われますが、Google の 8.8.8.8 や Cloudflare の 1.1.1.1 などのパブリック DNS に変更することもできます。
ステップ 3 — Recursive Resolver が Root Name Server に問い合わせる
Recursive Resolver はまず最上位の Root Name Server に問い合わせます。世界には 13 セットの Root Name Server が存在し、適切な TLD（Top-Level Domain）Name Server の場所を教える役割を担っています。
TLD Name Server は、.com・.org・.jp・.tw などのトップレベルドメインごとに存在し、そのドメイン配下の情報を管理しています。
ステップ 4 — Recursive Resolver が TLD Name Server に問い合わせる
TLD Name Server に問い合わせると、対象ドメインの Authoritative Name Server の IP アドレスが返ってきます。
Authoritative Name Server は、そのドメインの DNS 管理を担っているサービスが運営しています。AWS Route 53 を使っていれば Route 53 が、Cloudflare を使っていれば Cloudflare の DNS サーバーが Authoritative NS となります。
ステップ 5 — Recursive Resolver が Authoritative Name Server に問い合わせる
Authoritative Name Server にはそのドメインの実際の DNS レコードが保存されています。たとえばドメインを Cloudflare で管理している場合、Cloudflare の Authoritative NS がサーバーの最終的な IP アドレスを返します。
ステップ 6 — 結果がブラウザに返され、キャッシュされる
Recursive Resolver が IP アドレスをブラウザに返し、ブラウザはサーバーへ直接接続します。取得した結果はキャッシュされ、次回以降の問い合わせが高速化されます。
以下の図で全体の流れを確認できます：
上記の例は、Cloudflare でドメインを購入し、DNS も Cloudflare で管理している最もシンプルなケースです。
実際にはより複雑になることもあります。たとえば、ドメインは Cloudflare で購入しつつ DNS の管理は AWS Route 53 で行っている場合、Cloudflare の NS を経由した後に Route 53 へと問い合わせが続きます。そのような構成を理解するためにも、DNS レコードの種類を把握しておくことが重要です。
DNS レコードの種類
DNS にはさまざまなレコードタイプがあります。代表的なものを一覧にまとめました：
| レコードタイプ | 役割 | 例 | 補足 |
|---|---|---|---|
| A | ドメイン → IPv4 | yoursite.com -> 104.21.1.1 | 最も一般的 |
| AAAA | ドメイン → IPv6 | yoursite.com -> 2606:4700::... | A レコードの IPv6 版 |
| CNAME | エイリアス → 別ドメイン | www -> yoursite.com | IP に直接は指定不可 |
| MX | メールサーバー | yoursite.com -> mail.google.com | メール受信に使用 |
| TXT | テキスト情報 | SPF / DKIM / ドメイン認証 | 多くの SaaS サービスで利用 |
| NS | DNS 管理者の指定 | ns1.cloudflare.com | 「このドメインはここに聞いて」 |
| SOA | DNS ゾーンの管理情報 | serial、refresh など | DNS 同期の基準となる重要な情報 |
| SRV | サービスの場所情報 | _sip._tcp.example.com | SIP・Minecraft・K8s などで使用 |
本記事と特に関連が深いのは A レコードと NS レコードです。A レコードは最終的な IP を決定し、NS レコードは Authoritative Server の場所を決定します。
キャッシュと TTL
このフル解決チェーンを毎回リクエストのたびに実行していたら、非常に遅くなってしまいます。そこで登場するのが TTL（Time To Live） です。各 DNS レコードには TTL 値（秒単位）が設定されており、キャッシュの有効期限を表しています。TTL が切れるまでは再問い合わせが発生しません。
DNS では複数のキャッシュ層を活用して、フルの問い合わせ回数を減らしています：
- Recursive Resolver のキャッシュ — 最も重要。TTL が切れるまで Authoritative NS に再問い合わせしない
- OS のキャッシュ — TTL 切れまたは再起動時にクリアされる
- ブラウザのキャッシュ — TTL 切れまたはブラウザを閉じるとクリアされる
まとめ
DNS は内部的にはかなり複雑ですが、この記事で少しでも仕組みがつかめたなら嬉しいです。今週はここまで、また来週お会いしましょう！