DNS

通信の相手は IP アドレスで指定しますが、人は www.example.com のような名前で覚えます。名前から IP アドレスを引くのが DNS (Domain Name System) です。名前を引く作業を名前解決と呼び、ほとんどの通信はこの名前解決から始まります。設計の判断に関わるのは TTL です。答えは TTL の秒数だけ各地のキャッシュに残るので、DNS の値を書き換えても、TTL が切れるまで古い値を返すリゾルバが残ります。

ドメイン名は右から読む

ドメイン名はドットで区切った階層です。右端ほど上の階層で、いちばん上をルートと呼びます。ルートのすぐ下が com や jp などの TLD (トップレベルドメイン) です。その下の example.com は、登録した組織が中身を管理します。

上の階層が下の階層の管理を任せることを委任と呼びます。ルートは「.com のことは .com のサーバーに聞いて」と答え、.com は「example.com のことは example.com のサーバーに聞いて」と答えます。名前の最終的な答えを持つサーバーを、権威サーバー (権威 DNS サーバー) と呼びます。

名前解決はリゾルバが代わりに聞いて回る

端末が自分でルートから順に聞くわけではありません。端末はリゾルバ (キャッシュ DNS サーバー) に 1 回だけ質問し、リゾルバが階層を上から順にたどって答えを端末に返します。リゾルバは自宅のルーターやプロバイダ、会社のネットワークが用意しています。DNS の問い合わせには主に UDP の 53 番ポートを使い、大きな応答は TCP の 53 番で送ります。

リゾルバは、ルートの答え (.com のサーバーの場所) も TLD の答えもキャッシュします。そのため、同じ example.com の別の名前を引くときは、権威サーバーに 1 回聞くだけで済みます。ルートサーバーは a から m までの 13 の名前があり、それぞれ世界中の多数の拠点から同じアドレスで応答しています。

TTL はキャッシュしてよい秒数

権威サーバーは、答えに TTL (Time To Live) を付けて返します。TTL が 300 なら、リゾルバはその答えを 300 秒間キャッシュし、その間は誰に聞かれても権威サーバーに問い合わせずに返します。

TTL の長さは、速さと切り替えやすさの取り引きです。長くすると問い合わせが減り、名前解決も速くなりますが、IP アドレスを変えても古い値が長く残ります。サーバーの移行で DNS を切り替える予定があるなら、数日前に TTL を短くしておき、切り替えが終わってから長く戻します。

下のシミュレーターで、キャッシュが空のときと残っているとき、TTL が切れたあとの問い合わせの回数を比べてください。

主なレコード

DNS に登録する 1 件 1 件をレコードと呼び、種類ごとに役割が決まっています。

CNAME は、同じ名前に別のレコードを置けません。ゾーンの頂点 (example.com そのもの) には NS などが必ずあるので、頂点を CNAME にすることはできません。

Google Cloud の DNS

Cloud DNS は Google Cloud のマネージドな権威サーバーです。インターネットに公開する公開ゾーンと、指定した VPC ネットワークの中からだけ引ける限定公開ゾーンを作れます。オンプレミスの DNS との間で問い合わせを転送する転送ゾーンもあり、ハイブリッド構成の名前解決に使います。詳細は VPC の設計 で扱います。

Compute Engine の VM は、メタデータサーバー (169.254.169.254) をリゾルバとして使います。同じ VPC の VM は VM名.ゾーン.c.プロジェクトID.internal という内部 DNS 名で引けるので、IP アドレスを直接書かずに済みます。

試してみる

dig は DNS に問い合わせるコマンドで、macOS と多くの Linux に入っています。次のコマンドを 2 回続けて実行し、2 列目の TTL が減っていくことを確かめます。減っていれば、リゾルバのキャッシュから答えが返っています。

dig +noall +answer www.google.com

+trace を付けると、リゾルバを使わずに自分でルートから順にたどります。ルート、com. の TLD、google.com. の権威サーバーの順に、応答したサーバーの名前が出ます。

dig +trace www.google.com