DNSの名前解決について

DNSの名前解決とは、人が理解しやすいドメイン名を、通信に必要なIPアドレスなどの情報に変換する仕組みです。

たとえば、ユーザーがブラウザで example.com にアクセスするとき、コンピュータはその名前のまま通信しているわけではありません。

実際には、通信先を特定するために、93.184.216.34 のようなIPアドレスを調べています。

この「ドメイン名からIPアドレスなどを調べる処理」が、DNSの名前解決です。

DNSは Domain Name System の略で、インターネット上の名前情報を管理する分散型・階層型の仕組みです。

単なる「名前とIPアドレスの対応表」ではなく、Web、メール、各種認証、サービス連携など、さまざまな用途に使われています。

DNSの役割

DNSの代表的な役割は、ドメイン名に対して必要な情報を返すことです。

たとえば、次のような情報がDNSで管理されます。

• Webサイトの接続先IPアドレス
• メールの配送先サーバー
• そのドメインを管理しているネームサーバー
• SPF、DKIM、DMARCなどのメール認証情報
• 外部サービスのドメイン所有確認用情報

このようにDNSは、インターネット上で名前に関連する情報を配布するための基盤になっています。

名前解決で登場する主な要素

DNSの名前解決を理解するには、まず登場する役割を押さえることが重要です。

スタブリゾルバ

PCやスマートフォンなどの端末側にある、簡易的な問い合わせ機能です。

ブラウザやアプリがドメイン名を使うとき、まずOSの名前解決機構に問い合わせが渡されます。

この入口部分を一般にスタブリゾルバと呼びます。

スタブリゾルバは自分ですべてのDNSサーバーをたどるわけではなく、通常は設定されているDNSサーバーへ問い合わせを送ります。

再帰リゾルバ

利用者の代わりにDNS情報を調べてくれるサーバーです。

一般にユーザーが「DNSサーバー」として設定しているものは、この再帰リゾルバです。

たとえば、ISPのDNS、企業内DNS、パブリックDNSなどがこれにあたります。

代表例としては、Google Public DNS や Cloudflare DNS があります。

再帰リゾルバは、クライアントから「このドメイン名の情報を教えてほしい」と依頼されると、必要に応じて上位のDNSサーバーをたどりながら最終的な答えを集め、結果を返します。

ルートネームサーバー

DNS階層の最上位に位置するネームサーバー群です。

ここには、.com や .jp などのトップレベルドメインを管理するネームサーバー情報が登録されています。

ルートネームサーバー自身が個別のWebサイトのIPアドレスを全部持っているわけではありません。

役割は、どのトップレベルドメインをどこに聞けばよいかを示すことです。

TLDネームサーバー

TLDは Top Level Domain の略で、.com、.net、.org、.jp などを指します。

TLDネームサーバーは、その配下にあるドメインについて、どの権威ネームサーバーが管理しているかを返します。

たとえば example.com を調べる場合、.com のTLDネームサーバーは「example.com の正式情報はこの権威ネームサーバーが持っている」と案内します。

権威ネームサーバー

対象ドメインの正式なDNS情報を持っているサーバーです。

このサーバーが、そのドメインに関するAレコード、MXレコード、TXTレコードなどの元データを管理しています。

つまり、最終的な答えを持っているのは権威ネームサーバーです。

名前解決の基本的な流れ

ここでは、ブラウザで www.example.com にアクセスするケースを例に、名前解決の流れを見ていきます。

端末側で名前解決を開始する

ブラウザやアプリが www.example.com へ接続しようとすると、まずOSの名前解決機構に問い合わせが渡されます。

このとき、端末内ではローカルキャッシュ、hostsファイル、DNS問い合わせなどがOSや設定に応じて利用されます。

実際の参照順は環境により異なるため、常に同じ順番とは限りません。

再帰リゾルバへ問い合わせる

端末内で答えが得られなければ、設定されている再帰リゾルバへ問い合わせます。

ここで端末は、「www.example.com のIPアドレスを知りたい」という依頼を送ります。

通常、利用者はその先の詳細な問い合わせ手順を意識する必要はありません。

再帰リゾルバがルートネームサーバーを参照する

再帰リゾルバのキャッシュにも答えがなければ、ルートネームサーバーへ問い合わせます。

するとルートネームサーバーは、「.com の情報はこのTLDネームサーバー群が持っている」という情報を返します。

再帰リゾルバがTLDネームサーバーを参照する

次に再帰リゾルバは .com のTLDネームサーバーへ問い合わせます。

ここでは、example.com を管理している権威ネームサーバーの情報が返されます。

再帰リゾルバが権威ネームサーバーへ問い合わせる

さらに再帰リゾルバは、返された権威ネームサーバーへ問い合わせます。

たとえば「www.example.com のAレコードは何か」と問い合わせ、その結果としてIPアドレスを受け取ります。

再帰リゾルバが端末へ返答する

再帰リゾルバは取得した答えを一定時間キャッシュし、その結果を端末へ返します。

端末はその情報を使って接続先を特定し、以降の通信を開始します。

再帰問い合わせと反復問い合わせ

DNSでは、問い合わせの形として「再帰問い合わせ」と「反復問い合わせ」を区別して考えると理解しやすくなります。

再帰問い合わせ

端末が再帰リゾルバに対して、「途中の処理も含めて最終的な答えを返してほしい」と依頼する形式です。

利用者のPCやスマホは通常、ルートやTLDを自分でたどりません。

その役割を再帰リゾルバに任せています。

反復問い合わせ

再帰リゾルバがルートネームサーバーやTLDネームサーバーなどに順番に問い合わせていく形式です。

たとえばルートネームサーバーは最終回答そのものを返すのではなく、「次はここに聞いてください」という案内を返します。

再帰リゾルバはその案内をもとに、次のサーバーへ進みます。

DNSレコードの種類

DNSでは、名前解決に関わる情報が「レコード」という形で管理されています。

WebアクセスではAレコードやAAAAレコードが中心ですが、それ以外にも重要な種類が多くあります。

Aレコード

ホスト名に対してIPv4アドレスを対応づけるレコードです。

例としては、www.example.com に対して 192.0.2.10 を返すような設定です。

AAAAレコード

ホスト名に対してIPv6アドレスを対応づけるレコードです。

IPv6環境ではこちらが使われます。

CNAMEレコード

あるホスト名を、別の正規ホスト名の別名として定義するレコードです。

たとえば www.example.com を service.vendor.net の別名として設定する、といった使い方をします。

ただしCNAMEには制約があります。

特に、標準的なDNSではゾーン頂点にCNAMEを置くことはできません。

そのため、DNS事業者によってはALIAS、ANAME、CNAME flattening などの独自機能で似た動作を実現することがあります。

MXレコード

メールの配送先サーバーを示すレコードです。

example.com 宛のメールをどのメールサーバーへ届けるべきかを定義します。

NSレコード

そのゾーンを管理している権威ネームサーバーを示すレコードです。

DNSの委任関係を成り立たせるうえで重要です。

TXTレコード

テキスト情報を保持するレコードです。

現在では、SPF、DKIM、DMARC、ドメイン所有確認などで広く使われています。

SOAレコード

ゾーンの基本情報を持つレコードです。

シリアル番号、更新間隔、管理者情報などが含まれます。

PTRレコード

IPアドレスからホスト名を逆引きするときに使うレコードです。

キャッシュとTTL

DNS運用で非常に重要なのがキャッシュです。

DNSは毎回ルートからすべてをたどるわけではなく、取得した結果を一定時間保存して再利用します。

キャッシュの役割

キャッシュがあることで、名前解決は高速化され、上位DNSサーバーへの負荷も減ります。

逆に言えば、DNS変更後に古い情報が残る原因にもなります。

TTLとは何か

TTLは Time To Live の略で、そのレコードを何秒間キャッシュしてよいかを示す値です。

たとえばTTLが300なら5分、3600なら1時間、86400なら24時間という意味になります。

TTLが長いと問い合わせ回数は減りますが、設定変更が反映されるまで時間がかかりやすくなります。

TTLが短いと変更は反映されやすくなりますが、問い合わせ回数は増えます。

DNSの「伝播」について

実務では「DNSが伝播するまで待つ」とよく言われますが、技術的には、世界中に順番に設定が配布されるというより、各再帰リゾルバや端末のキャッシュが古い情報から新しい情報へ切り替わっていくと考えるほうが正確です。

このため、ある環境では新しい設定が見えていても、別の環境ではまだ古い情報が返ることがあります。

権威DNSと再帰DNSの違い

この2つは混同されやすいですが、役割は明確に異なります。

権威DNS

権威DNSは、そのドメインの正式なDNS情報を持つ側です。

いわば元データの管理者です。

再帰DNS

再帰DNSは、利用者の代わりに情報を調べて返す側です。

通常、端末が問い合わせる相手はこちらです。

簡単にいえば、権威DNSは「正式な答えを持つサーバー」、再帰DNSは「答えを調べて利用者に渡すサーバー」です。

正引きと逆引き

正引き

ドメイン名からIPアドレスを調べることです。

Webサイトへアクセスするときによく使われる通常の名前解決はこちらです。

逆引き

IPアドレスからホスト名を調べることです。

PTRレコードを使います。

メールサーバー運用では逆引き設定が重要になる場面があります。

hostsファイルとの違い

hostsファイルは、端末側で名前とIPアドレスの対応を手動で定義する仕組みです。

たとえば、特定のドメインを一時的に別のサーバーへ向けたい場合や、開発環境で確認したい場合に使われます。

ただしhostsファイルは端末ごとの設定であり、DNSのようにネットワーク全体へ公開される仕組みではありません。

本番運用で恒常的に使うものではなく、主にテストや一時対応向きです。

名前解決が失敗する主な原因

DNSで名前解決がうまくいかない原因はいくつかあります。

まず考えられるのは、AレコードやCNAMEなど、必要なレコードそのものが未設定であるケースです。

また、権威ネームサーバー側の設定ミスや、親ゾーンと子ゾーンの委任不整合が起きている場合もあります。

さらに、設定は正しくても再帰リゾルバや端末に古いキャッシュが残っていて、変更後の情報がまだ見えていないこともあります。

そのほか、DNSSECの署名不整合、IPv6関連の不備、ファイアウォールによる通信制限なども原因になります。

DNSで使われる通信

DNSは一般に UDP 53番ポート を使って通信します。

ただしそれだけではありません。

応答が切り詰められた場合、DNSSECなどで応答サイズが大きくなる場合、ゾーン転送を行う場合などには TCP 53番ポート も使われます。

このため、DNSの疎通確認ではUDPだけでなくTCPも必要になることがあります。

DNSSECとは何か

DNSSECは、DNS応答が改ざんされていないことを検証するための仕組みです。

電子署名を使って、返ってきたDNS情報が正しい権威側から来たものであることを確認します。

ただしDNSSECは、DNS通信そのものを暗号化する仕組みではありません。

あくまで、応答の真正性と完全性を検証するためのものです。

DoHとDoT

近年では、DNS通信を暗号化する手段として DoH と DoT も使われています。

DoH

DoHは DNS over HTTPS のことで、HTTPS通信の中でDNS問い合わせを行う方式です。

DoT

DoTは DNS over TLS のことで、TLSを使ってDNS通信を暗号化する方式です。

これらは盗聴や改ざんのリスクを下げるのに有効ですが、DNSSECとは役割が異なります。

DNSSECは「応答の正当性確認」、DoHやDoTは「通信経路の暗号化」と整理すると分かりやすいです。

WebアクセスとDNSの関係

Webサイトへアクセスするとき、DNSは最初の重要なステップの一つです。

一般的な流れは次のようになります。

まずURLからホスト名を取り出し、そのホスト名をDNSで解決します。

次に、得られた接続先情報をもとにサーバーへ接続し、HTTPSであればTLSハンドシェイクを行い、その後HTTP通信が始まります。

つまり、DNSはWeb表示全体の入口ではありますが、それだけでページ表示が完結するわけではありません。

実務で特に重要なポイント

Web運用やマーケティングの現場では、DNSの知識がそのままトラブル対応や設定作業に直結します。

特に重要なのは、Aレコード、CNAME、MX、TXTの違いを理解しておくことです。

Webサイトの向き先変更、サブドメイン設定、外部SaaSとの連携、広告計測ツールや検索エンジン向けの認証、メール配信設定など、実務ではDNS設定が頻繁に関わります。

また、TTLの意味を理解していないと、設定変更後に「反映されない」と誤解しやすくなります。

さらに、Aレコードの変更よりもNSの変更のほうが影響が大きく、事故時の切り分けも難しくなりやすい点は押さえておきたいところです。

まとめ

DNSの名前解決とは、ドメイン名をIPアドレスなどの通信情報へ変換する仕組みです。

その処理には、スタブリゾルバ、再帰リゾルバ、ルートネームサーバー、TLDネームサーバー、権威ネームサーバーが関わっています。

流れとしては、端末が再帰リゾルバへ問い合わせ、再帰リゾルバが必要に応じて階層をたどり、最終的に権威ネームサーバーから正式な答えを取得して返します。

この過程ではキャッシュが重要な役割を担い、TTLが反映速度や問い合わせ効率に大きく影響します。

また、DNSはAレコードだけで成り立っているわけではなく、MX、TXT、NS、SOA、PTRなど多くのレコードが用途ごとに使い分けられています。

Web運用、メール運用、認証設定、SaaS連携などを安定して行うためには、DNSの基本構造を理解しておくことが非常に重要です。

以上、DNSの名前解決についてでした。

最後までお読みいただき、ありがとうございました。