DNS

DNSとは

DNS(Domain Name System)は、人間が覚えやすいドメイン名(example.com)を、機械が使うIPアドレス(192.0.2.1)へ変換する仕組みです。インターネットの電話帳とよく例えられます。

ブラウザ「example.com のIPアドレスは?」
DNS    「192.0.2.1 です」
ブラウザ → 192.0.2.1 へ [[HTTP]] リクエストを送る

初学者向けポイント

• 世界中のDNSサーバーが階層構造で分担している(ルート → .com → example.com)
• 一度調べた結果はキャッシュされる。TTL(有効期限)が切れるまで再利用
• 「サイトにつながらない」原因の定番。dig や nslookup コマンドで調査できる

名前解決の道のり

「example.com のIPアドレスは?」に答えているのは1台のサーバーではありません。実際には端末に代わってキャッシュDNSサーバー(フルサービスリゾルバ)が階層をたどります。

1. ルートサーバー         「.com のことは .com の担当者に聞いて」
2. .com のサーバー        「example.com のことは ns1.example.com に聞いて」
3. example.com の権威サーバー 「192.0.2.1 です」

このキャッシュDNSサーバーは、自宅なら回線事業者のもの、社内なら社内に立てたもの、公開のもの(8.8.8.8 や 1.1.1.1 など)を明示的に指定することもあります。どれを使うかを端末が自分で決めているわけではなく、多くの場合は接続時に自動で配られた値です。「自分の端末だけ名前解決に失敗する」ときは、まずこの問い合わせ先の設定を疑うと早く片が付きます。

一方、ドメインの持ち主が実際に値を書き込むのは、最後に答えた権威サーバーです。ホスティング事業者やクラウドの管理画面で「Aレコードを追加」する操作は、この権威サーバーの内容を書き換えています。設定する場所と、答えを持っている場所は別という点が、初学者がまず混乱するところです。

主なレコードタイプ

TTLとキャッシュのハマりどころ

DNS の変更が「すぐ反映されない」のは、途中のキャッシュDNSサーバーが前の答えを TTL の間そのまま返し続けるためです。TTL が 86400秒(1日)なら、最悪1日は古いIPアドレスへ案内され続けます。ここを知らずに移転作業を始めると、原因不明の「一部の人だけ古いサイトが見える」状態に陥ります。

• サーバーを引っ越す予定があるなら、切り替えの数日前に対象レコードの TTL を短くしておく(例: 300秒)。切り替えが終わってから元の値に戻す
• 自分の環境で新しい値が見えても、他人の環境ではまだ古いことがある。「自分では直った」を全体の完了と判断しない
• 「そのレコードは存在しない」という答えもキャッシュされる(ネガティブキャッシュ)。レコードを作る前にアクセスしてしまうと、作った後もしばらく失敗が続く

そのため、切り替え期間中は新旧どちらのサーバーにアクセスが来ても壊れないようにしておくのが安全です。

DNSを軸に広げる地図

DNS は単独で完結せず、「名前を引く仕組み」と「引いた名前で何をするか」の両側に伸びています。次に読む記事は、目的別に次の4つの方向で選べます。

名前を引く動作を分解する

DNS の問い合わせは、[[IPアドレスとサブネット]] で決まる住所の、53番という [[ポート番号]] 宛に送られます。運び方は [[UDP]] で、小さな問い合わせと答えが1往復で済むためです(応答が大きい場合などは TCP が使われます)。返る住所は IPv4 だけとは限らず、[[IPv6]] のアドレスは AAAA レコードとして登録されます。そして問い合わせ先そのものを端末へ配っているのが [[DHCP]] です。これらを読むと、抽象的だった「名前解決」が具体的な1往復の通信として見えてきます。

名前で「どこへ届けるか」を決める

DNS が返すのは Web サーバーの住所だけではありません。メールの宛先サーバーは MX レコードで決まり([[メールの仕組み(SMTP・POP3・IMAP)]])、[[CDN]] は利用者ごとに最寄りのエッジサーバーの住所を返すことで配信を速くしています。同じIPアドレスを世界中の複数拠点で共有し最寄りの1台へ届けるエニーキャストは、公開DNSサーバーやCDNを支える方式です([[ユニキャスト・ブロードキャスト・マルチキャスト]])。自分のサイトを実際に公開するまでの手順は [[ホスティングとレンタルサーバー]] にまとまっています。

ドメインを名乗る側の責任

ドメインを持つと、「本当にその持ち主か」を示す作業が付いてきます。[[電子証明書とPKI]] の DV 証明書は、指定されたレコードをそのドメインに追加できるかどうか(あるいは指定のファイルをそのサイトに置けるかどうか)で管理権を確認します。裏を返せば、証明書が保証するのはドメインの持ち主であることまでです。よく似た綴りのドメインを取得して鍵マーク付きの偽サイトを立てる手口があり、その見分け方と組織としての備えは [[フィッシング対策]] が扱っています。

つながらないときに調べる

「IPアドレス直打ちなら開くのに、ドメイン名だと開かない」は DNS を疑う典型的なサインです。どの順番で何を確認すれば原因を絞り込めるかは [[ネットワーク診断コマンド]] にまとまっています。

関連技術とのつながり

• [[TCP/IP]] — DNSで得たIPアドレスを使って通信する
• [[HTTP]] — DNSの名前解決の後に始まる通信
• [[クラウドコンピューティング]] — 独自ドメインでの公開時にDNS設定が必要

Q: ドメインの持ち主がAレコードなどの値を実際に書き込むのはどのサーバー?
- [ ] ルートサーバー
- [ ] 利用者が使っているキャッシュDNSサーバー
- [x] そのドメインの権威サーバー
解説: 値の正本を持つのは権威サーバーです。ルートや.comのサーバーは「次はどこに聞くか」を教える役で、キャッシュDNSサーバーは答えを代理で調べて一時的に保持します。

Q: 数日後にサーバーを移転する予定があるとき、DNS側で事前にしておくとよいことはどれ?
- [x] 対象レコードのTTLを短くしておく
- [ ] 対象レコードのTTLを長くしておく
- [ ] 移転が終わるまでレコードを削除しておく
解説: TTLが長いとキャッシュDNSサーバーが古い答えを返し続けます。切り替えの数日前にTTLを短くしておき、切り替え後に元へ戻すのが定番です。

Q: レコードを作る前にそのドメインへアクセスしてしまうと、作った後もしばらく失敗が続くことがあるのはなぜ?
- [ ] 一度失敗したドメインは権威サーバーから削除されるため
- [x] 「存在しない」という答えもキャッシュされるため
- [ ] TTLが切れるまで新しいレコードを登録できないため
解説: ネガティブキャッシュと呼ばれる挙動で、「レコードが無い」という結果も一定時間キャッシュされます。先にアクセスせず、レコードを用意してから確認するのが安全です。