この記事の目的：DNSを「名前をIPアドレスへ変換する仕組み」という一文だけで終わらせず、実際の障害調査でどのように切り分けるかを理解します。
DNSは名前と通信先を結びつける
ブラウザーへドメイン名を入力したとき、端末はDNSを使って通信先情報を取得します。DNSが正常でなければ、インターネット回線自体が生きていても「サイトが開かない」と見えることがあります。メール配送でもMX、送信認証ではTXTなどDNSは重要な役割を持ちます。
代表的なレコード
| A | ホスト名をIPv4アドレスへ対応付ける |
|---|---|
| AAAA | IPv6アドレスへ対応付ける |
| CNAME | 別の名前を参照する別名 |
| MX | メールを受け取るサーバーを示す |
| TXT | SPFやドメイン確認など文字列情報に使われる |
障害時の切り分け
まず「すべてのサイトが開かない」のか「特定ドメインだけか」を分けます。次にIPレベルの通信が成立するか、DNS問い合わせが応答するかを確認します。IPアドレスでは到達できるのに名前だけ解決できない場合、DNSを優先して調査できます。
ただしDNSサーバーを8.8.8.8などへ変更して直ったからといって、恒久的な原因が確定したとは限りません。ルーターのDNS中継、VPN、社内DNS、端末キャッシュなどを確認します。
TTLと変更反映
DNSにはキャッシュがあります。レコードを変更しても、TTLや各リゾルバーのキャッシュにより旧情報が一定時間残ることがあります。「DNS変更が反映されない」ときは、権威DNS上の値と利用端末から見える値を分けて確認します。
メール障害との関係
MXが誤れば受信に影響し、SPF・DKIM・DMARC用のDNS情報が誤ればメール認証へ影響します。Webサイトが正常だからDNS全体が正常とは限りません。用途ごとのレコードを確認します。
避けたい対処
- 原因確認なしにDNSサーバーを変更する
- TTLを無視して変更直後に失敗と判断する
- Web用Aレコード変更時にメール関連レコードまで削除する
- DNS管理会社とWebホスティング会社を同一だと思い込む
専門調査では何を見るか
端末が参照しているDNS、DHCPで配布された値、権威DNS、委任、レコード種別、TTL、DNSSECの有無、VPNやセキュリティ製品の名前解決経路を確認します。障害点を端末、LAN、リゾルバー、権威DNSへ分離することが重要です。
参考資料
端末・ルーター・外部DNSを分けて確認する
家庭や小規模事業所では、端末がルーターをDNSとして参照し、ルーターが上流DNSへ問い合わせる構成があります。端末設定だけでなく、DHCPで何が配布されているか、ルーターがどのDNSを参照しているかを確認すると障害点を分離できます。社内サーバーやActive Directoryを利用する環境では、外部DNSへ直接変更すると社内名が解決できなくなることもあるため注意が必要です。
DNSキャッシュを理解する
端末、ブラウザー、OS、ルーター、リゾルバーなど複数段階にキャッシュが存在する場合があります。変更確認では「権威DNSには新しい値があるか」「利用しているリゾルバーは何を返すか」「端末に古い情報が残っていないか」を分けます。これにより、反映待ちと設定ミスを混同しにくくなります。