ドメイン名がWebサイトにつながる仕組み：DNSの基本と実務チェック
Webサイトにアクセスするとき、ブラウザは example.com のようなドメイン名をそのまま見に行っているわけではありません。裏側では DNSがドメイン名をIPアドレスに変換し、ブラウザが目的のサーバーへ接続できる状態を作っています。
Web制作やサーバー運用では、この仕組みを知っているだけで「サイトが表示されない」「メールだけ届かない」「サーバー移転後に一部の人だけ古い画面が出る」といったトラブルを切り分けやすくなります。
この記事では、DNSの基本をWebサイト運用でよく使う範囲に絞って整理します。
- DNSは、ドメイン名と接続先情報を対応させる仕組み
- Web表示では主に
A、AAAA、CNAMEレコードを見る - メールでは
MX、送信元認証ではTXTレコードが関係する - 設定変更後すぐ反映されない主因は、TTLとキャッシュ
- 確認には
nslookup、dig、オンラインDNS確認ツールを使う
DNSは「名前」から「接続先」を引く仕組み
DNSは、ドメイン名をサーバーの住所にあたるIPアドレスへ変換する仕組みです。
たとえばブラウザで https://example.com/ を開くと、概ね次の順番で処理が進みます。
- ブラウザやOSが、
example.comの接続先をDNSに問い合わせる - DNSが
93.184.216.34のようなIPアドレスを返す - ブラウザがそのIPアドレスのサーバーへ接続する
- サーバーがHTMLや画像などを返し、ページが表示される
ここで重要なのは、DNSはWebページそのものを配信しているわけではないことです。DNSが担当するのは、あくまで「その名前なら、どこへ行けばよいか」を案内する部分です。
ここがポイント: DNSの設定ミスは、Webサーバーが正常でも「そもそも正しいサーバーへ到達できない」状態を作ります。
実務で見るDNSレコードはまず5種類でよい
DNSには多くのレコード種別がありますが、Web制作やWordPress運用の初期段階で頻繁に見るものは限られます。
| レコード | 主な役割 | 実務で出る場面 |
|---|---|---|
| A | ドメイン名をIPv4アドレスへ向ける | WebサーバーのIPを指定する |
| AAAA | ドメイン名をIPv6アドレスへ向ける | IPv6対応サーバーへ向ける |
| CNAME | 別のドメイン名を別名として参照する | `www` や外部サービス連携で使う |
| MX | メール配送先のサーバーを指定する | 独自ドメインメールを使う |
| TXT | 文字列情報を登録する | SPF、DKIM、DMARC、所有権確認で使う |
Webサイト表示で見るのはA・AAAA・CNAME
Webサイトの表示先を決めるときは、まず A レコードを確認します。IPv6を使う環境では AAAA も関係します。
入力例として、DNS管理画面では次のような設定になります。
種類: A
名前: @
値: 203.0.113.10
TTL: 3600
この例では、ルートドメインを 203.0.113.10 というIPv4アドレスへ向けています。@ はDNS管理サービスによって意味が少し異なることがありますが、多くの場合は example.com 自体を指します。
www.example.com を同じサイトへ向ける場合は、次のように CNAME を使うことがあります。
種類: CNAME
名前: www
値: example.com.
TTL: 3600
末尾のドットは「完全なドメイン名」を示す表記です。管理画面によっては自動補完されるため、入力時に必要かどうかはサービスの説明を確認してください。
メールや認証ではMX・TXTが出てくる
Webサイトだけを移転したつもりでも、DNS全体を触るとメールに影響することがあります。特に MX レコードは、メールの配送先を決めるための設定です。
たとえば、WebサーバーはレンタルサーバーA、メールはGoogle WorkspaceやMicrosoft 365のような外部サービス、という構成では、Web用の A レコードとメール用の MX レコードを分けて管理します。
TXT レコードは、メールのなりすまし対策や外部サービスの所有権確認でよく使われます。例としてSPFでは、送信を許可するメールサーバー情報を文字列として登録します。
ドメインが表示されるまでの流れ
ドメイン名がWebサイトにつながるまでには、複数のDNSサーバーが関わります。
細部をすべて覚える必要はありません。実務では、次の4つの役割を押さえると切り分けしやすくなります。
1. ブラウザやOSのキャッシュ
一度調べたDNS情報は、ブラウザやOSに一時保存されることがあります。これにより毎回DNSへ問い合わせずに済みますが、設定変更直後は古い情報を見続ける原因にもなります。
「自分のPCだけ古いサイトが出る」という場合、ブラウザキャッシュだけでなくDNSキャッシュも疑います。
2. リゾルバー
リゾルバーは、利用者の代わりにDNS情報を探しに行くDNSサーバーです。家庭や会社のネットワーク、プロバイダー、Google Public DNS、Cloudflare DNSなどが使われることがあります。
同じドメインでも、利用しているリゾルバーによって反映タイミングが違って見えることがあります。
3. 権威DNSサーバー
権威DNSサーバーは、そのドメインの正しいDNSレコードを持つサーバーです。DNS管理画面で変更した内容は、最終的にはこの権威DNSサーバーの情報として参照されます。
独自ドメインの管理では、「ドメイン登録サービス」と「DNS管理サービス」が同じとは限りません。サーバー会社を変えても、ネームサーバーが古いDNS管理先を向いたままだと、新しい管理画面で設定しても効きません。
4. Webサーバー
DNSで正しいIPアドレスへ到達しても、Webサーバー側の設定が合っていなければサイトは表示されません。
たとえば、DNSは新サーバーへ向いているのに、サーバー側に対象ドメインのバーチャルホスト設定がない場合、別サイトや初期ページが表示されることがあります。
DNS確認の基本コマンド
DNSの確認では、管理画面を見るだけでなく、外からどう解決されているかをコマンドで確認します。
ここではWindows、macOS、Linuxで使いやすい例を示します。実行環境によってコマンドの有無や出力は少し変わります。
nslookupでAレコードを確認する
nslookup はWindows、macOS、Linuxで比較的使いやすいDNS確認コマンドです。
nslookup example.com
出力例は次のようになります。
Name: example.com
Address: 93.184.216.34
見るべきポイントは Address です。ここに期待するサーバーのIPアドレスが出ていれば、少なくともその環境からはドメイン名がそのIPへ解決されています。
特定のDNSサーバーに問い合わせたい場合は、次のように指定できます。
nslookup example.com 8.8.8.8
これにより、Google Public DNSから見た結果を確認できます。社内ネットワークと外部DNSで結果が違う場合、キャッシュや社内DNSの設定差が疑えます。
digでレコード種別を指定する
macOSやLinuxでは dig が便利です。Windowsでも別途導入すれば使えます。
dig example.com A
CNAMEを確認する場合は次のようにします。
dig www.example.com CNAME
短い出力だけ見たいときは +short を付けます。
dig example.com A +short
出力例です。
93.184.216.34
dig はDNSトラブルの調査でよく使われます。A、AAAA、MX、TXT のように種類を指定できるため、Web表示とメール設定を分けて確認しやすいのが利点です。
よくあるDNSトラブルと原因
DNSのトラブルは、見た目が似ていても原因が違います。まず「どこまで名前解決できているか」を分けて考えるのが近道です。
サイトが表示されない
よくある原因は次の通りです。
AレコードのIPアドレスが間違っている- ネームサーバーが古いDNS管理先を向いている
wwwあり・なしの片方しか設定していない- Webサーバー側に対象ドメインの設定がない
- SSL証明書がまだ発行・適用されていない
DNSだけでなく、Webサーバー設定やSSL設定も一緒に確認します。DNSで正しいIPが返っているなら、次はサーバー側の設定を見る、という順番です。
一部の人だけ古いサイトが見える
この場合は、TTLとキャッシュが関係していることが多いです。
TTLは、DNS情報をどのくらいの時間キャッシュしてよいかを示す値です。たとえばTTLが 3600 なら、目安として3600秒、つまり1時間キャッシュされます。
サーバー移転前にTTLを短くしておくと、切り替え後の反映待ちを短くしやすくなります。ただし、すべての環境で完全に同じタイミングで切り替わるとは限りません。
メールだけ届かない
Webサイトは表示されるのにメールだけ届かない場合、MX レコードを確認します。
特に次の変更時は注意が必要です。
- レンタルサーバーを変更した
- DNS管理先を移した
- ドメインメールを外部サービスへ移した
- SPFやDKIMのTXTレコードを追加・変更した
Web用の A レコードだけを見て「DNSは合っている」と判断すると、メール側の問題を見落とします。
NG例と改善例
DNS設定でつまずきやすいのは、1つのレコードだけを見て全体を判断してしまうことです。
NG例: wwwだけ設定してルートドメインを忘れる
www.example.com -> example.com
example.com -> 未設定
この状態では、www.example.com は表示できても、example.com が表示できないことがあります。
改善するなら、ルートドメインと www の両方を意図して設定します。
example.com A 203.0.113.10
www.example.com CNAME example.com.
NG例: DNS管理画面を間違える
ドメイン登録サービス、レンタルサーバー、CDN、メールサービスが別々の場合、どこでDNSを管理しているか分かりにくくなります。
改善するには、まず現在のネームサーバーを確認します。
nslookup -type=NS example.com
出力されたネームサーバーが、実際に編集しているDNS管理サービスと一致しているかを見ます。ここが違う場合、変更している画面そのものが効いていない可能性があります。
実務で確認するチェックリスト
DNS変更前後は、作業内容を小さく分けて確認すると事故を減らせます。
変更前に見ること:
- 現在のネームサーバー
- 現在の
A、AAAA、CNAMEレコード - メール利用がある場合の
MX、TXTレコード - TTLの値
- 変更後に向けたいサーバーIPや外部サービスの指定値
変更後に見ること:
example.comとwww.example.comの両方が意図通りかhttpからhttpsへの遷移が想定通りか- メール送受信に影響が出ていないか
- 複数のDNSリゾルバーで同じ結果が返るか
- サーバー側に対象ドメインの設定があるか
DNSは一度に多くの値を変えると、原因の切り分けが難しくなります。Web表示だけを変えるなら、メール関連レコードは触らない。DNS管理先を移すなら、既存レコードを移行前に控える。この2点だけでも失敗はかなり減ります。
関連ツールと使い分け
DNS確認には複数の手段があります。目的ごとに使い分けると、調査が速くなります。
| 方法 | 向いている確認 | 注意点 |
|---|---|---|
| DNS管理画面 | 設定値そのものの確認 | 現在使われているDNS管理先とは限らない |
| nslookup | 手元環境からの名前解決確認 | 詳細調査にはやや情報が少ない |
| dig | レコード種別ごとの詳細確認 | 環境によっては導入が必要 |
| オンラインDNS確認ツール | 複数地域・複数DNSからの反映確認 | 表示結果の更新タイミングに差がある |
| サーバー管理画面 | ドメイン追加、SSL、Webルート確認 | DNSが正しくてもサーバー側設定が必要 |
初心者が最初に見るなら、DNS管理画面と nslookup の組み合わせで十分です。反映差やCNAME、MX、TXTまで追う段階になったら dig を使うと調査しやすくなります。
次に見るべきポイント
DNSの基本で大事なのは、用語を暗記することではありません。ドメイン名、DNSレコード、サーバー設定を別々の層として見ることです。
サイトが表示されないときは、次の順で確認します。
- ネームサーバーは正しい管理先を向いているか
A、AAAA、CNAMEは期待する値か- TTLやキャッシュで古い情報を見ていないか
- Webサーバー側に対象ドメインとSSLの設定があるか
- メール利用がある場合、
MXとTXTを壊していないか
サーバー移転や外部サービス連携では、DNSだけを見ても、サーバーだけを見ても足りません。次に作業するときは、変更前のDNSレコードを控え、変更後にコマンドで外から確認するところまでをセットにすると、原因を追える状態を残せます。