LASSIC Media らしくメディア
DNSの仕組み｜名前解決の流れとレコード
「サーバを移転したのに、なぜか一部の利用者にはしばらく古いサイトが表示され続ける」「ドメインの設定変更をベンダーに依頼したら、反映まで時間がかかると言われた」——IT事業部でWebサイトやシステムの運用に関わっていると、こうした場面でDNSという言葉に行き当たることがあるのではないでしょうか。DNSは、インターネット上の通信を裏側で支える基盤的な仕組みで、ふだんは意識されないものの、設定を誤るとサイトやメールが丸ごと届かなくなることもある重要な存在です。しかし目に見えないため、発注者やPMにとっては実態のつかみにくい領域になりがちでしょう。その仕組みを大まかにでも理解しておくと、移転やドメイン変更の段取り、障害時の切り分け、ベンダーへの依頼内容の確認がしやすくなります。本記事では、特定サービスの設定手順ではなく、DNSとはそもそも何を指すのか、名前解決はどのような流れで行われるのか、どんなレコードがあり、運用で何に気をつけるべきかを、発注・運用の視点から順に整理します。用語をすべて覚える必要はありませんが、「名前から住所を調べる仕組み」という勘所をつかんでおくと、ベンダーとの会話の解像度が変わってくるはずです。
DNSとは何か
DNS（Domain Name System）とは、「example.jp」のような人間に読みやすいドメイン名を、コンピュータが通信に使う「192.0.2.1」のようなIPアドレスへ変換する仕組みです。この変換のことを名前解決と呼びます。人にとってはドメイン名のほうが覚えやすい一方、機械どうしの通信では数字で表されたIPアドレスが必要になります。その橋渡しをするのがDNSの役割です。
身近なたとえで言えば、電話帳に近いものと考えると分かりやすいでしょう。相手の名前は覚えていても電話番号までは覚えていないとき、電話帳で名前を引いて番号を調べます。DNSも同じように、ドメイン名という「名前」から、IPアドレスという「番号」を調べて教えてくれる仕組みです。ブラウザにドメイン名を入力すると、その裏側では、目的のサーバへたどり着くために、まずDNSへの問い合わせが行われています。
この仕組みがあるおかげで、私たちはIPアドレスを意識せずにドメイン名だけでサイトへアクセスできます。また、サーバを引っ越してIPアドレスが変わっても、DNSの設定を書き換えれば、利用者は同じドメイン名のままアクセスし続けられます。ドメイン名とIPアドレスを切り離して管理できる点も、DNSがもたらす利点といえるでしょう。次の図は、ブラウザがドメイン名を入力してからIPアドレスを得るまでの流れを、単純化して示したものです。
この記事のポイント
- DNSとは、ドメイン名をIPアドレスへ変換する「名前解決」の仕組みで、電話帳のように名前から番号を調べる役割を担います。
- 名前解決はリゾルバがルート・TLD・権威サーバの順にたどって行われ、結果は一定時間キャッシュされます。
- A・CNAME・MX・NSなどのレコードで設定し、TTLの理解と移転時の事前調整、冗長化が運用の要点になります。
名前解決の流れ
ドメイン名からIPアドレスを調べる名前解決は、複数のDNSサーバが役割を分担して行われます。実際の問い合わせを担うのが「DNSリゾルバ」（キャッシュサーバとも呼ばれます）で、利用者に代わって各サーバへ順に問い合わせ、答えをまとめて返してくれる案内役です。おおまかな流れは次のようになります。
- ブラウザがドメイン名にアクセスしようとし、DNSリゾルバへ「このドメインのIPアドレスは？」と問い合わせる。
- リゾルバはまずルートDNSサーバへ尋ね、「.jp」などのトップレベルドメインを担当するTLDサーバの場所を教わる。
- 続いてTLDサーバへ尋ね、そのドメインを実際に管理する権威DNSサーバの場所を教わる。
- 最後に権威DNSサーバへ尋ね、目的のIPアドレスを受け取る。
- リゾルバは得たIPアドレスをブラウザへ返し、ブラウザはそのアドレスのサーバへ接続する。
このように、DNSは世界規模の階層構造になっており、役割を分担することで膨大な数のドメインを扱えるようになっています。一見すると問い合わせの回数が多く手間がかかりそうですが、一度調べた結果はリゾルバがしばらく保持（キャッシュ）するため、同じドメインへの二度目以降のアクセスでは、この長い道のりをたどらずに素早く応答できるのです。私たちがドメイン名を入力してからページが表示されるまでの短い時間の裏で、こうしたやり取りが行われていると考えると、仕組みの全体像がつかみやすくなります。
なお、DNSリゾルバには、通信事業者が提供するものや、社内に設置するもの、公開されているパブリックなものなど、いくつかの種類があります。ふだん家庭や職場で使う端末は、接続先のネットワークが指定するリゾルバを自動的に利用していることが多く、利用者が意識する場面はほとんどないでしょう。一方で企業のシステムでは、どのリゾルバを使うか、社内向けの名前をどう解決するかといった設計が必要になる場合もあります。本記事では細部には立ち入りませんが、「問い合わせを代行してくれる案内役がいる」という点を押さえておけば十分です。
主なDNSレコードの種類
DNSの設定は「レコード」という単位で管理されます。レコードとは、ドメインに対して「この名前はこのIPアドレス」「メールはこのサーバへ」といった対応づけを記述したものです。種類ごとに役割が決まっており、代表的なものを表に整理しました。すべてを覚える必要はありませんが、ベンダーとのやり取りで名前が出てきたときに、何を指すのか見当がつく程度に把握しておくと役立ちます。
| レコード | 役割 |
|---|---|
| Aレコード | ドメイン名をIPv4アドレスに対応づけます。もっとも基本的なレコードで、Webサーバの指定などに使われます。 |
| AAAAレコード | ドメイン名をIPv6アドレスに対応づけます。役割はAレコードと同じで、対象がIPv6である点が異なります。 |
| CNAMEレコード | あるドメイン名を別のドメイン名の別名として指し示します。参照先の変更を一箇所で済ませたい場合などに使われます。 |
| MXレコード | そのドメイン宛のメールを、どのメールサーバへ届けるかを指定します。メールの送受信に欠かせません。 |
| NSレコード | そのドメインを管理する権威DNSサーバを指定します。ドメインの管理をどこに委ねるかを示す土台のレコードです。 |
| TXTレコード | 任意の文字情報を登録します。ドメインの所有確認や、メールのなりすまし対策（SPFなど）の設定に用いられます。 |
設定変更でよく話題にのぼるのがAレコードとMXレコードです。サーバ移転ではAレコードの向き先を新しいIPアドレスへ変更しますし、メール周りの不具合ではMXレコードやTXTレコードの設定が関わることが少なくありません。どのレコードを触るとどこに影響が及ぶのかを、ベンダーと共有しておくと、変更作業の見通しが立てやすくなります。
これらのレコードは、DNSサービスの管理画面から追加・変更できるのが一般的です。ただし一つのレコードの書き換えが、Webの表示やメールの到達といった広い範囲に影響することもあります。変更の前には現在の設定を控えておき、作業は影響の小さい時間帯に行うといった慎重さが求められるでしょう。
TTLとキャッシュ ― 変更が反映されるまで
DNSを理解するうえで欠かせないのが、TTL（Time To Live）とキャッシュの関係です。前述のとおり、名前解決の結果はリゾルバに一定時間キャッシュされます。その「一定時間」をどれくらいにするかを決めているのがTTLで、レコードごとに秒単位で設定されているのです。TTLが3600秒であれば、一度調べた結果は約1時間そのまま使い回され、その間は元のレコードを変更しても、キャッシュを持っているリゾルバには新しい値が伝わりません。
この性質が、冒頭で触れた「サーバを移転したのに一部の利用者に古いサイトが表示され続ける」という現象の正体です。IPアドレスを変更しても、古い値をキャッシュしているリゾルバでは、TTLが切れるまで前のサーバを参照し続けます。世界中のリゾルバでキャッシュが一斉に切れるわけではないため、切り替わりには時間差が生じ、この移り変わりの期間を「伝播（反映）にかかる時間」と表現することがあります。
そこで、サーバ移転やドメイン変更をあらかじめ計画できる場合は、作業の数日前にTTLを短い値へ下げておく、という段取りがよく採られます。TTLを短くしておけば、切り替え時に古いキャッシュが早く消え、新しい設定への移行がスムーズになるでしょう。移転が終わって安定したら、TTLを元の長さに戻して問い合わせの負荷を抑えます。「変更はすぐには反映されない」「事前のTTL調整が段取りの鍵になる」という2点は、発注側としても押さえておきたいところです。
発注・運用で意識したい観点
DNSは一度設定すると当たり前に動き続けるため、ふだんは意識されにくいものの、いざ止まるとサイトもメールも到達しなくなる、影響範囲の大きい仕組みです。発注や運用の立場から押さえておきたい観点を挙げておきます。
第一に、移転・変更時の段取りです。前章のとおり、TTLの事前調整と切り替えのタイミングが、ダウンタイムや表示の乱れを抑える鍵になります。作業計画を立てる際は、いつTTLを下げ、いつ切り替え、いつ元に戻すのかという時系列を、ベンダーと共有しておくとよいでしょう。第二に、冗長化です。ドメインを管理する権威DNSサーバが一台だけだと、そこが停止したときに名前解決ができなくなり、サイト全体へアクセスできなくなります。複数台の構成にしておくことで、一部が停止しても名前解決を続けられます。提案された構成で、この冗長性が確保されているかは確認しておきたい点です。
第三に、なりすましや改ざんへの備えです。DNSの応答が偽られると、正規のドメイン名でありながら別のサーバへ誘導されてしまうおそれがあります。これを防ぐ技術としてDNSSEC（応答が正規のものかを検証する仕組み）があり、取り扱う情報の重要度に応じて導入が検討されます。第四に、監視です。名前解決が正しく行えているか、レコードが意図せず変更されていないかを継続的に把握できるようにしておくと、障害やトラブルの予兆に早く気づけるでしょう。障害が起きたときに「サイトが見られない」原因がサーバ側なのかDNS側なのかを切り分けられるよう、DNSも監視対象に含めておくと復旧が早まります。なお本記事は特定サービスの設定手順ではなく、DNSという仕組みの考え方と運用で押さえたい観点に焦点を当てているものです。個別の設定を詰める段階では、利用するDNSサービスの公式ドキュメントや、実績のあるベンダーへの確認が別途必要になります。
まとめ
- DNSとは、ドメイン名をIPアドレスへ変換する「名前解決」の仕組みで、電話帳のように名前から番号を調べる役割を担います。
- 名前解決はリゾルバがルート・TLD・権威サーバの順にたどって行われ、結果は一定時間キャッシュされて二度目以降を高速化します。
- 設定はA・AAAA・CNAME・MX・NS・TXTなどのレコード単位で管理し、移転ではAレコード、メールではMX・TXTがよく関わります。
- TTLはキャッシュの保持時間を決め、変更は即時には反映されないため、移転前のTTL短縮が段取りの鍵になります。
- 運用では、移転時の段取り、権威サーバの冗長化、なりすまし対策（DNSSEC）、監視といった観点を押さえておくと安定します。
- 本記事は特定サービスの設定手順ではなく、DNSという仕組みの考え方と運用の観点の整理を狙いとしています。
よくある質問
DNSの設定を変更したのに、すぐ反映されないのはなぜですか。
名前解決の結果が、世界中のDNSリゾルバに一定時間キャッシュされているためです。キャッシュの保持時間はレコードごとのTTLで決まり、その時間が切れるまでは古い値が使われ続けます。リゾルバによってキャッシュの切れるタイミングがずれるため、切り替わりには時間差が生じるのです。あらかじめ計画できる変更であれば、作業の数日前にTTLを短く設定しておくと、反映が早まりトラブルを抑えやすくなります。
AレコードとCNAMEレコードは、どう使い分けるのですか。
Aレコードはドメイン名をIPアドレスに直接対応づけるもので、CNAMEレコードはドメイン名を別のドメイン名の別名として指し示すものです。参照先のサーバが変わる可能性があり、変更を一箇所で吸収したい場合はCNAMEが便利です。一方、対象を直接IPアドレスで指定したい場合はAレコードを使います。用途や運用のしやすさによって使い分けるもので、どちらが優れているという関係ではありません。設定時には、CNAME特有の制約もあるため、ベンダーと確認しておくとよいでしょう。
DNSが止まると、どのような影響がありますか。
名前解決ができなくなるため、ドメイン名でアクセスするサイトやサービスに到達できなくなります。Webサイトの表示だけでなく、メールの送受信にも影響が及ぶことがあります。サーバ自体は動いていても、名前解決ができなければ利用者はたどり着けないため、影響範囲は広くなりがちです。こうした事態に備え、権威DNSサーバを複数台にする冗長化や、名前解決の状態を監視する仕組みが重要になります。
ドメインの管理会社を変更する際、何に気をつければよいですか。
移管の前に、現在設定されているレコード（A・MX・TXTなど）をすべて洗い出し、移管先でも同じ内容を用意しておくことが大切です。設定の抜けがあると、サイトの表示やメールの到達に支障が出ることがあります。あわせて、切り替え時の影響を抑えるためにTTLを事前に短くしておく、移管のタイミングを利用の少ない時間帯に合わせる、といった段取りも検討します。移管手続きには反映までの時間も伴うため、余裕をもった計画を立てるとよいでしょう。
著者：テレリモ総研編集部 鈴木 亮佑
LASSICでは、国内ニアショア開発体制を活かし、DNSを含むインフラの設計・運用から、サーバ移転やドメイン変更の段取り、冗長化・DNSSEC・監視体制の整備までを一貫して支援する体制です。移転時の到達不良や、メールだけ届かないといった切り分けの難しい不具合の調査についてもご相談いただけます。要件定義の段階から実装、テスト、リリース後の運用・保守まで、工程を分けずに任せられる点も強みでしょう。設定変更の段取りに迷う段階からでも、ご相談ください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
