名前解決とは？DNSの仕組み・正引き/逆引き・dig/nslookupでの確認方法を実装者向けに解説

名前解決（Name Resolution）とは、人が読める「www.example.com」のようなドメイン名と、通信で実際に使うIPアドレス（例：192.0.2.10）を相互に変換する処理を指します。ブラウザやアプリがサーバーへ接続する前段で必ず走る工程で、失敗すればページは1バイトも取得できません。この記事では、DNSの再帰問い合わせと権威サーバーの階層、正引きと逆引きの違い、OS側でhostsファイルとresolv.confがどの順で参照されるか、dig/nslookupでの確認手順、そしてクラウド環境での設計とキャッシュ起因のトラブルシュートまでを、実装者が手を動かせる粒度で整理します。

まとめ：名前解決の全体像と実装者がまず押さえる要点

名前解決は「ドメイン名 → IPアドレス」を求める正引きが主で、逆に「IPアドレス → ドメイン名」を求める逆引きも存在します。名前解決を担う中心的な仕組みがDNS（Domain Name System）で、世界中のサーバーが権威を分担する分散データベースとして動きます。

実装者の観点では、次の3点を分けて理解すると障害切り分けが速くなります。第一に、問い合わせを代行して答えを持ち帰るのがキャッシュDNSサーバー（フルサービスリゾルバ）で、正解の元データを保持するのが権威DNSサーバーです。第二に、OS内部ではDNSに問い合わせる前にhostsファイルなどローカルの解決手段を先に見ることがあり、この優先順位を知らないと「DNSを直したのに直らない」事態に陥ります。第三に、名前解決の結果はTTL（Time To Live）秒数だけ各所にキャッシュされ、レコードを変更しても即時には反映されません。以降の章で、この3点を順に掘り下げます。

ドメイン名とIPアドレスを相互変換する名前解決の基本構造と役割

名前解決が必要な理由とドメイン名・ホスト名・IPアドレスの関係

TCP/IP通信の宛先はIPアドレスですが、数字の羅列は人が覚えにくく、サーバー移設のたびに変わり得ます。そこで人が扱う識別子としてドメイン名を用い、実アドレスへの対応付けを名前解決に任せる設計が一般的です。これによりサーバーを別のIPへ移しても、DNSのレコードを書き換えるだけで利用者側の設定は変えずに済みます。名前の構造やホスト名との違いを厳密に押さえたい場合は、FQDNとは？ドメイン名・ホスト名との違いと書き方を実装者向けに解説で完全修飾ドメイン名の書式を確認してください。末尾ドット付きの「www.example.com.」がルートを起点とした絶対表記である点は、名前解決の挙動を読むうえで前提になります。

正引きと逆引きの違いと、逆引きが実務で必要になる具体的な場面

正引き（forward lookup）はドメイン名からIPアドレスを求める、日常のWebアクセスで走る解決です。対応するレコードはIPv4のAレコード、IPv6のAAAAレコードです。逆引き（reverse lookup）はIPアドレスからドメイン名を求める解決で、in-addr.arpa（IPv6はip6.arpa）という専用のドメイン空間とPTRレコードで表現します。逆引きが効くのは、メールサーバーの送信元検証（受信側が送信元IPの逆引き名と正引きの一致を確認する）や、アクセスログの読解といった場面です。逆引きが未設定のIPからのメールが弾かれる事例は珍しくなく、メール基盤を構築するなら正引きと逆引きの両方を整える前提で設計します。

DNSの再帰問い合わせと権威サーバー階層による名前解決の流れ

スタブリゾルバからルート・TLD・権威サーバーへの反復問い合わせ

ブラウザに組み込まれた最小限のクライアント（スタブリゾルバ）は、自力では答えを探さず、OSに設定されたキャッシュDNSサーバーへ「www.example.comのAレコードは？」と1回だけ問い合わせます。答えを探す反復（iterative）作業を肩代わりするのがキャッシュDNSサーバーです。手順は次の通りです。

1. キャッシュDNSサーバーがルートDNSサーバーへ問い合わせ、「.com」を管理するTLDサーバーの在処を教わる。
2. TLDサーバーへ問い合わせ、「example.com」を管理する権威DNSサーバーの在処（NSレコード）を教わる。
3. 権威DNSサーバーへ問い合わせ、目的のAレコード（IPアドレス）を受け取る。
4. 受け取った答えをTTLの秒数だけ自分のキャッシュに保存し、スタブリゾルバへ返す。

スタブリゾルバがキャッシュDNSサーバーに求めるのは「答えそのもの」で、これを再帰問い合わせ（recursive query）と呼びます。対してキャッシュDNSサーバーが各権威サーバーに投げるのは「次の担当を教えて」という反復問い合わせで、2種類は役割が違います。

キャッシュDNSサーバーと権威DNSサーバーの役割分担と設計原則

この2種は同居させず分離するのが基本設計です。権威DNSサーバーは自ドメインの正解データ（ゾーン）を配る役で、外部の不特定多数からの再帰要求には応じない設定にします。再帰を誰にでも許すと、DNSを踏み台にした増幅型のDDoSに悪用されるためです。キャッシュDNSサーバーは社内やISP利用者など、範囲を絞った利用者からの再帰要求に応じる役に徹します。両者の性質を対比すると次の通りです。

この分離を崩すと運用が破綻します。権威サーバーに再帰を混ぜない、キャッシュサーバーは外部に開かない。この2点はどんな規模でも守る設計原則です。

OSが名前解決する順序とhosts・resolv.confの優先度

hostsファイルとDNSの参照順を決めるnsswitchの仕組み

アプリがDNSへ問い合わせる前に、OSはローカルの解決手段を先に見ることがあります。LinuxやmacOSでは/etc/nsswitch.confのhosts:行が参照順を決め、多くの環境でfiles dns、つまり/etc/hostsを先に見てからDNSへ向かう設定です。/etc/hostsに該当ドメインの行があれば、DNSには一切問い合わせずその値が使われます。ステージング環境で本番ドメインを検証IPへ向けたいときはhostsに一時的な行を書く手が有効ですが、消し忘れると「DNSは正しいのに特定端末だけ古いIPへ繋がる」障害の原因になります。名前解決がおかしいと感じたら、まずhostsを疑うのが実装者の初手です。

resolv.confとsystemd-resolvedによる問い合わせ先の決定

DNSへ問い合わせる際の宛先（キャッシュDNSサーバーのアドレス）と検索ドメインは、Unix系では/etc/resolv.confのnameserver行とsearch行で決まります。現在のLinuxディストリビューションはsystemd-resolvedが仲介し、/etc/resolv.confが127.0.0.53を指すスタブになっているケースが増えました。その場合の実際の上流DNSは、resolvectl statusで確認する形です。nameserverの値はDHCPで自動配布されるのが一般的で、社内DNSやクラウドの内部リゾルバが配られます。この配布の仕組みはDHCPとは？IPアドレス自動割り当ての仕組みを実装者向けに解説で整理しました。手動で固定したい場合はDHCPクライアントやNetworkManagerの設定側で指定し、/etc/resolv.confを直接編集しても自動生成で上書きされる点に注意します。

dig・nslookupで名前解決を確認する手順とTTLの読み方

digを使った正引き・逆引き・権威応答の確認コマンドと読み方

名前解決の調査はdigが第一候補です（Windowsは標準のnslookup、またはdigの導入版）。よく使う形は次の通りです。

• dig www.example.com A +noall +answer：正引きのAレコードだけを簡潔に表示。
• dig -x 192.0.2.10：逆引き（PTR）を確認。
• dig www.example.com @8.8.8.8：問い合わせ先のキャッシュDNSサーバーを明示して切り分け。
• dig example.com NS +trace：ルートから権威までの反復問い合わせを段階表示。

digの応答にはヘッダのステータスが載り、NOERRORは正常、NXDOMAINは「その名前は存在しない」、SERVFAILは「解決の途中で失敗（権威応答不能やDNSSEC検証失敗など）」を意味します。この3語を読み分けるだけで、設定ミスなのか、そもそも名前が無いのか、上流の障害なのかを切り分けられます。

ANSWER SECTIONのTTLとキャッシュ残存時間の見積もり

digの回答行の左側に出る数値がTTL（秒）です。例えばwww.example.com. 300 IN A 192.0.2.10ならTTLは300秒で、キャッシュDNSサーバーはこの答えを最大5分保持します。同じ問い合わせを繰り返すとTTLが刻々と減っていき、これはキャッシュに載っている証拠です。レコードを変更する前にTTLを短く（例：300秒）しておくと切り替えが速く反映され、変更完了後に元へ戻す運用が定石です。逆引きやメール関連のPTR・MXも同じくTTLで支配されるため、DNS切り替え作業はTTLの経過を待つ時間設計とセットで組みます。

クラウド環境での名前解決の設計とセキュリティ確保の実務ポイント

VPC内部の名前解決とRoute 53などマネージドDNSの設計

クラウドでは名前解決の層が二重になります。VPC内部ではプロバイダが用意する内部リゾルバ（AWSならVPC+2のアドレス、いわゆるAmazon提供DNS）がEC2のプライベートホスト名やプライベートホストゾーンを解決し、外部ドメインはRoute 53などの権威DNSがインターネットへ公開します。設計時に判断が要るのは、内部専用の名前をプライベートホストゾーンで閉じるか、外部にも同名を公開するか（スプリットビュー）です。オンプレミスとクラウドをVPN/専用線で繋ぐハイブリッド構成では、Route 53 Resolverのインバウンド/アウトバウンドエンドポイントで社内DNSとクラウドDNSの問い合わせを相互に転送する設計が必要になります。こうしたVPCのDNS設計やハイブリッド構成の名前解決は初期の切り分けが難しく、要件に合わせた設計から任せたい場合は一創のインフラ構築（AWS/GCP/Azure）でご相談ください。名前が解決されるかどうかは可用性そのものに直結するため、冗長化とあわせて初期設計で固めます。

名前解決を狙う代表的な攻撃とDNSSECによる信頼性確保の要点

名前解決は「正しいIPが返る」ことに全面的に依存するため、答えを偽装されると被害が大きくなります。代表がキャッシュポイズニング（DNSキャッシュ汚染）で、キャッシュDNSサーバーに偽のレコードを覚え込ませ、利用者を偽サイトへ誘導します。対策として応答の正当性を電子署名で検証するのがDNSSECで、権威側でゾーンに署名し、キャッシュ側で検証する仕組みです。導入手順と検証の流れはDNSSECとは？DNSの安全性を守る仕組みと導入手順を解説で扱っています。加えて、社内向けには問い合わせ先を信頼できるキャッシュDNSサーバーに限定し、外部の見知らぬリゾルバをresolv.confに書かない運用も、名前解決の信頼性を保つ基本線です。

よくある質問

名前解決の実務でつまずきやすい点を、5つの質問に絞って答えます。

名前解決とDNSは同じ意味ですか？

厳密には別です。名前解決は「名前とアドレスを相互変換する処理」という目的を指す言葉で、DNSはそれを実現する代表的な仕組み（分散データベースとプロトコル）です。名前解決の手段はDNSだけではなく、/etc/hostsによる静的な解決や、社内LAN向けのmDNS/NetBIOSなども含みます。日常ではほぼDNSによる名前解決を指しますが、hostsが優先されて「DNSを通らない名前解決」が起きる点は区別して理解すると障害調査で役立ちます。

正引きと逆引きは何が違いますか？

正引きはドメイン名からIPアドレスを求める解決で、Web閲覧など日常の通信で使います（A/AAAAレコード）。逆引きはIPアドレスからドメイン名を求める解決で、in-addr.arpaのPTRレコードを使います。逆引きはメール送信元の検証やログ解析で用いられ、未設定だとメールが受信側で弾かれることがあります。正引きが引ければ通信はできますが、メール基盤では逆引きも整えるのが前提です。

名前解決ができないとき、まず何を確認すべきですか？

切り分けの順序は、(1)/etc/hostsに該当行が残っていないか、(2)resolv.conf（またはresolvectl status）の問い合わせ先が正しいか、(3)dig 対象ドメイン @上流DNSで上流が答えるか、の3段です。digのステータスがNXDOMAINなら名前自体が無い、SERVFAILなら上流やDNSSEC検証の失敗、応答なしならネットワーク到達性やファイアウォールを疑います。この順で見ると原因の層を素早く特定できます。

DNSレコードを変えたのに反映されないのはなぜですか？

各所のキャッシュにTTLの秒数だけ古い答えが残るためです。digの回答行のTTL値が保持時間で、これがゼロになるまで新しい値は配られません。切り替え作業の前にTTLを短く（例：300秒）設定し、伝播を待ってから変更し、完了後に戻すのが定石です。加えてブラウザやOSのローカルキャッシュも残るため、端末側でのキャッシュクリアも合わせて確認します。

hostsファイルとDNSはどちらが優先されますか？

多くのOSではhostsが先です。Linux/macOSでは/etc/nsswitch.confのhosts:行がfiles dnsとなっていれば、/etc/hostsを先に見て、該当行があればDNSに問い合わせません。検証用にhostsへ書いた行を消し忘れると特定端末だけ挙動が変わるため、名前解決の不整合を感じたら最初にhostsを確認します。

関連記事

• FQDNとは？ドメイン名・ホスト名との違いと書き方を実装者向けに解説：名前解決の対象となる「名前」の正確な構造（ホスト名＋ドメイン名）を押さえられます。
• DHCPとは？IPアドレス自動割り当ての仕組みを実装者向けに解説：名前解決の問い合わせ先（DNSサーバーアドレス）がどう配布されるかを補完します。
• グローバルIPとは？プライベートIPとの違い・確認方法を実装者向けに解説：名前解決が返すIPアドレスの種類と公開範囲の前提を整理できます。
• NATとは？仕組み・NAPTとの違いからクラウド実装まで実装者向けに解説：内部アドレスと外部アドレスの変換が名前解決の設計にどう絡むかを補います。
• DNSSECとは？DNSの安全性を守る仕組みと導入手順を解説：名前解決の答えを偽装から守るための検証の仕組みを深掘りできます。