--- title: "名前解決とは？DNSの仕組み・正引き/逆引き・dig/nslookupでの確認方法を実装者向けに解説" url: "https://www.issoh.co.jp/tech/details/13556/" published: 2026-07-12 updated: 2026-09-16 categories: ["インフラ・クラウド"] publisher: "株式会社一創" --- # 名前解決とは？DNSの仕組み・正引き/逆引き・dig/nslookupでの確認方法を実装者向けに解説 名前解決（Name Resolution）とは、人が読める「www.example.com」のようなドメイン名と、通信で実際に使うIPアドレス（例：192.0.2.10）を相互に変換する処理を指します。ブラウザやアプリがサーバーへ接続する前段で必ず走る工程で、失敗すればページは1バイトも取得できません。この記事では、DNSの再帰問い合わせと権威サーバーの階層、正引きと逆引きの違い、hostsとresolv.confの参照順、dig/nslookupでの確認手順、失敗時の切り分け、クラウドでの設計までを、コピーして実行できるコマンドつきで整理します。数値はRFCと公式ドキュメントで確かめました。 ## まとめ：名前解決の全体像と実装者がまず押さえる要点 名前解決は「ドメイン名からIPアドレス」を求める正引きが主で、逆に「IPアドレスからドメイン名」を求める逆引きもあります。これを担う中心的な仕組みがDNS（Domain Name System）で、世界中のサーバーが権威を分担する分散データベースとして動きます。設計の土台は[RFC 1034](https://www.rfc-editor.org/rfc/rfc1034.html)と[RFC 1035](https://www.rfc-editor.org/rfc/rfc1035.html)で、階層構造と委任という考え方は現在も変わっていません。 実装者の観点では、次の3点を分けて理解すると障害切り分けが速くなります。第一に、問い合わせを代行して答えを持ち帰るのがキャッシュDNSサーバー（フルサービスリゾルバ）で、正解の元データを保持するのが権威DNSサーバーです。第二に、OSはDNSより先にhostsなどローカルの解決手段を見ることがあり、この優先順位を知らないと「DNSを直したのに直らない」事態に陥ります。第三に、結果はTTL（Time To Live）秒数だけ各所にキャッシュされるため、レコードを変更しても即時には反映されません。 ## ドメイン名とIPアドレスを相互変換する名前解決の基本構造と役割 ### 名前解決が必要な理由とドメイン名・ホスト名・IPアドレスの関係 TCP/IP通信の宛先はIPアドレスですが、数字の羅列は人が覚えにくく、サーバー移設のたびに変わり得ます。そこで人が扱う識別子としてドメイン名を用い、実アドレスへの対応付けを名前解決に任せる設計が一般的です。サーバーを別のIPへ移してもDNSのレコードを書き換えるだけで済みます。名前の構造やホスト名との違いは[FQDNとは？ドメイン名・ホスト名との違いと書き方を実装者向けに解説](https://www.issoh.co.jp/tech/details/13365/)で確認してください。末尾ドット付きの「www.example.com.」がルート起点の絶対表記である点は、挙動を読む前提になります。 名前空間の最上位にあるルートゾーンを預かるのがルートDNSサーバーです。[IANAのRoot Servers一覧](https://www.iana.org/domains/root/servers)のとおり、aからmまでの13ラベルにIPv4とIPv6のアドレスが割り当てられています。13は物理台数ではなくラベル数で、実体はエニーキャストで分散配置されています。 ### 正引きと逆引きの違いと、逆引きが実務で必要になる具体的な場面 正引き（forward lookup）はドメイン名からIPアドレスを求める、日常のWebアクセスで走る解決です。対応するレコードはIPv4のAレコード、IPv6のAAAAレコードになります（Aレコードの書き方やCNAMEとの使い分けは[Aレコードとは？IPv4アドレスへの対応付けとAAAA/CNAMEとの違い・書き方・digでの確認を実装者向けに解説](https://www.issoh.co.jp/tech/details/14679/)で整理しています）。逆引き（reverse lookup）はIPアドレスからドメイン名を求める解決で、in-addr.arpa（IPv6はip6.arpa）という専用のドメイン空間とPTRレコードで表現します。IPv4なら4オクテットを逆順に並べてin-addr.arpaを付ける組み立て方がRFC 1035の3.5節に規定されています。 逆引きが効くのは、メールサーバーの送信元検証や、アクセスログの読解といった場面です。未設定のIPからのメールが弾かれる事例は珍しくなく、メール基盤なら正引きと逆引きの両方を整える前提で設計します。PTRとAの不一致など踏みやすい誤りは[RFC 1912（Common DNS Operational and Configuration Errors）](https://www.rfc-editor.org/rfc/rfc1912.html)にまとまっています。名前解決が返すIPがグローバルかプライベートかで公開範囲の前提も変わるため、その区別は[グローバルIPとは？プライベートIPとの違い・確認方法を実装者向けに解説](https://www.issoh.co.jp/tech/details/13463/)で押さえておくと設計判断がぶれません。 ## 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種類はそれぞれ異なる役割の問い合わせです。この委任の連鎖は、[BIND 9 Manual Pages](https://bind9.readthedocs.io/en/latest/manpages.html)が説明するdigの`+trace`で実際にたどれます。ルートからの委任経路を追う動きのため、どの段で止まっているかが画面に出ます。 ### キャッシュDNSサーバーと権威DNSサーバーの役割分担と設計原則 この2種は同居させず分離するのが基本設計です。権威DNSサーバーは自ドメインの正解データ（ゾーン）を配る役で、外部の不特定多数からの再帰要求には応じない設定にします。再帰を誰にでも許すと、DNSを踏み台にした増幅型のDDoSに悪用されるためです。 | 観点 | キャッシュDNSサーバー（フルサービスリゾルバ） | 権威DNSサーバー | | -------- | ------------------------ | ------------------ | | 持つデータ | 他サーバーから得た答えの一時キャッシュ | 自ドメインの正解ゾーン | | 応じる問い合わせ | 再帰問い合わせ（範囲を絞った利用者向け） | 反復問い合わせ（自ゾーンの応答のみ） | | 代表的な実装 | Unbound、BIND、dnsmasq | BIND、NSD、Route 53 | | 公開範囲 | 内部・契約利用者に限定 | インターネット全体に公開 | 権威サーバーに再帰を混ぜない、キャッシュサーバーは外部に開かない。この2点はどんな規模でも守る設計原則です。自前で立てる実装はBINDが代表格で、[ISCのBIND配布ページ](https://www.isc.org/bind/)では9.20系がCurrent Stable（Extended Support Version）として案内されています（2026年9月時点）。応答サイズの前提も設計に影響する要素です。UDPで運ぶDNSメッセージは元来512オクテットに制限されていましたが、[RFC 6891（EDNS(0)）](https://www.rfc-editor.org/rfc/rfc6891.html)が最大ペイロードサイズを互いに通知する仕組みを定め、出発点として4096オクテットを挙げています。途中経路が大きなUDP応答を落とすと、名前解決は「時々失敗する」形で表面化します。 ## hostsとresolv.confを読んでOSの名前解決順を確かめる ### nsswitch.confのhosts行で参照順を確かめる手順 アプリがDNSへ問い合わせる前に、OSはローカルの解決手段を先に見ることがあります。LinuxやmacOSでは**/etc/nsswitch.conf**の`hosts:`行が参照順を決め、多くの環境で`files dns`、つまり**/etc/hosts**を先に見てからDNSへ向かう設定です。書式は[nsswitch.conf(5)のマニュアル](https://man7.org/linux/man-pages/man5/nsswitch.conf.5.html)に定義があり、`files`はローカルファイル、`dns`はDNSを指します。検証用にhostsへ一時的な行を書く手は有効ですが、消し忘れると「特定端末だけ古いIPへ繋がる」障害の原因になります。 ``` # nsswitch の参照順を見る（多くの環境では files dns） grep '^hosts:' /etc/nsswitch.conf # hosts に残骸が無いか（コメント行と空行を除いて表示） grep -v '^#' /etc/hosts | grep -v '^$' # nsswitch を通した実際の解決結果（hosts が効けばここに出る） getent ahosts www.example.com ``` `getent`はdigと違ってDNSへ直接聞かず、OSの名前解決の仕組み（nsswitch）をそのまま通します。digでは正しいIPが返るのに`getent`では別のIPが出るなら、その差分はhostsやmDNSなどDNS以外の経路が生んでいます。 ### resolvectl statusで実際の上流DNSを突き止める手順 DNSへ問い合わせる宛先と検索ドメインは、Unix系では**/etc/resolv.conf**の`nameserver`行と`search`行で決まります。書式と上限（`nameserver`は最大3つまで参照されるなど）は[resolv.conf(5)のマニュアル](https://man7.org/linux/man-pages/man5/resolv.conf.5.html)に明記されています。現在のLinuxはsystemd-resolvedが仲介し、**/etc/resolv.conf**が`127.0.0.53`を指すスタブになっている構成が増えました。その場合の実際の上流DNSは[resolvectl(1)](https://man7.org/linux/man-pages/man1/resolvectl.1.html)で確認します。 ``` # 現在の resolv.conf（127.0.0.53 ならスタブ経由） cat /etc/resolv.conf # 実際の上流DNS・検索ドメインをリンク単位で見る resolvectl status # 端末側のキャッシュだけを捨てて再確認する sudo resolvectl flush-caches resolvectl query www.example.com ``` `resolvectl status`は上流DNSをインターフェース単位で並べるため、VPN接続時にどちら側のDNSが勝っているかまで読み取れます。`nameserver`の値はDHCPで自動配布されるのが一般的で、社内DNSやクラウドの内部リゾルバが配られます。この配布の仕組みは[DHCPとは？IPアドレス自動割り当ての仕組みを実装者向けに解説](https://www.issoh.co.jp/tech/details/13461/)で整理しました。手動で固定するならDHCPクライアントやNetworkManagerの設定側で指定します。**/etc/resolv.conf**を直接編集しても自動生成で上書きされる点に注意してください。 ## digとnslookupを実行して名前解決とTTLを確認する手順 ### digで正引き・逆引き・権威応答を確認するコマンドと出力の読み方 名前解決の調査はdigが第一候補です（Windowsは標準のnslookup、またはdigの導入版）。よく使う形を並べました。 ``` # 正引き（Aレコードだけを簡潔に表示） dig www.example.com A +noall +answer # 逆引き（PTRレコードを確認） dig -x 192.0.2.10 +noall +answer # 問い合わせ先のキャッシュDNSを明示して切り分ける dig www.example.com @8.8.8.8 # ルートから権威までの委任を段階表示する dig example.com NS +trace # Windows の nslookup で問い合わせ先を指定する nslookup www.example.com 8.8.8.8 ``` `+noall +answer`は、名前・レコード種別・TTL・値だけの短い出力にする組み合わせで、BIND 9のマニュアルでも定番として案内されています。`-x`はIPv4でもIPv6でも逆引き名へ自動変換するため、in-addr.arpaを手で組み立てる必要はありません。Windows標準のnslookupのオプションは[Microsoftのコマンドリファレンス](https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/nslookup)にまとまっています。 ### ANSWER SECTIONのTTLとキャッシュ残存時間の見積もり digの回答行の左側に出る数値がTTL（秒）です。出力は次の形になります。 ``` ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; status: NOERROR, id: 42015 ;; ANSWER SECTION: www.example.com. 300 IN A 192.0.2.10 ;; Query time: 12 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) ``` この例ならTTLは300秒で、キャッシュDNSサーバーはこの答えを最大5分保持します。同じ問い合わせでTTLが減っていくなら、それはキャッシュに載っている証拠です。TTLの取り得る値は[RFC 2181の8節](https://www.rfc-editor.org/rfc/rfc2181.html)で0から2147483647までの符号なし数値と定められ、最上位ビットが立った値は0として扱うべきとされています。リゾルバが上限で丸める自由も同節が認めるため、極端に長いTTLは期待どおりに保持されるとは限りません。 レコードを変更する前にTTLを短く（例：300秒）しておくと切り替えが速く反映され、変更完了後に元へ戻す運用が定石です。PTRやMXも同じくTTLに支配されるため、DNS切り替えはTTLの経過を待つ時間設計とセットで組みます。 ## 名前解決に失敗したときの切り分け手順と応答ステータス別の対処 ### hostsの消し忘れとキャッシュ残存をコマンドで切り分ける手順 「名前解決できない」という申告は、原因の層がまったく違うものが同じ言葉で報告されます。digのステータスを起点にすると、見る場所を絞り込めます。 | ステータス | 返ってきた意味 | 次に見る場所 | | -------- | ------------ | ----------- | | NOERROR | 名前は存在し応答も正常 | 返ったIPと接続経路 | | NXDOMAIN | その名前自体が存在しない | ゾーンのレコードと綴り | | SERVFAIL | 解決の途中で失敗した | 上流とDNSSEC検証 | | REFUSED | 問い合わせを拒否された | 再帰を許す範囲の設定 | | 応答なし | そもそも届いていない | 53番ポートと経路 | 切り分けは「OS側」「キャッシュ側」「権威側」の順に降りると最短です。次の4手を上から実行してください。 ``` # 1. OS側: hosts や mDNS が割り込んでいないか getent ahosts www.example.com # 2. キャッシュ側: 上流に直接聞いてステータスだけ見る dig www.example.com @1.1.1.1 +noall +comments # 3. 権威側: 権威に直接聞いてキャッシュの遅れと切り分ける dig www.example.com @ns1.example.com +norecurse +noall +answer # 4. DNSSEC 検証を外して SERVFAIL の出所を見る dig www.example.com +cd +noall +comments ``` 手順2と手順3で答えが食い違うなら、権威は新しい値を配っているのにキャッシュが古い状態なので、TTLの経過を待つか捨てる判断になります。手順4の`+cd`（Checking Disabled）を付けたときだけNOERRORが返るなら、SERVFAILの正体はDNSSEC検証の失敗です。NOERRORなのに繋がらないなら原因は経路やポート側にあり、アドレス変換が絡む構成では[NATとは？仕組み・NAPTとの違いからクラウド実装まで実装者向けに解説](https://www.issoh.co.jp/tech/details/13552/)まで追います。 ## クラウドとKubernetesで名前解決を設計するときの判断基準 ### VPC内部の名前解決とRoute 53などマネージドDNSの設計 クラウドでは名前解決の層が二重になります。VPC内部は内部リゾルバがプライベートホスト名を解決し、外部ドメインはRoute 53などの権威DNSが公開を受け持つ形です。AWSの内部リゾルバの居場所は[Understanding Amazon DNS](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html)に明記があり、リンクローカルの169.254.169.253（IPv6はfd00:ec2::253）と、VPCのプライマリIPv4 CIDRの先頭に2を足したアドレスで到達します。CIDRが10.0.0.0/16なら10.0.0.2が内部リゾルバです。VPC属性はenableDnsSupportが既定でtrue、enableDnsHostnamesが既定でfalse（デフォルトVPCを除く）で、プライベートホストゾーンを使うなら両方をtrueにする条件も同ページに書かれています。 見落としやすいのが上限値です。同ページのDNS quotasには、リンクローカル宛て全体で1ENIあたり毎秒1024パケットという上限があり、Resolverへの問い合わせにIMDSやNTPの要求も合算され、引き上げできないと明記されています。1台に多数のコンテナを詰めて問い合わせが集中すると、「たまにDNSが引けない」形で表面化します。内部専用の名前を外部へ出さずに閉じる設計は[プライベートDNSとは？内部名前解決の仕組み・Route 53プライベートホストゾーン・設計を実装者向けに解説](https://www.issoh.co.jp/tech/details/14678/)で解説しました。VPCのDNS設計やオンプレミスとのハイブリッド構成を要件から任せたい場合は[一創のインフラ構築（AWS/GCP/Azure）](https://www.issoh.co.jp/service/system/aws/)でご相談ください。 ### Podのresolv.confとndots:5が招く問い合わせ増の対処 Kubernetesでも同様に、kubeletがPodごとにresolv.confを生成します。[DNS for Services and Pods](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)の例では、`search`行に自Namespaceのsvc.cluster.local・svc.cluster.local・cluster.localの3つ、`options`行に`ndots:5`が書き込まれる構成です。ndots:5は「ドットが5個未満の名前はsearchドメインを順に付けて試す」指定なので、`api.example.com`のような外部名でも展開を全部空振りしてから絶対名で引き直します。1回の解決でクラスタ内DNSへの問い合わせが数倍に膨らむのはこのためです。 対処は2つあります。外部ドメインを引くPodでは末尾ドット付きの絶対名（`api.example.com.`）で呼ぶか、PodSpecの`dnsConfig`で`ndots`を2程度まで下げる方法です。DNSポリシーもClusterFirst・ClusterFirstWithHostNet・Default・Noneから選べるため、クラスタ内名を引かないワークロードなら方針ごと変えられます。クラスタ内DNSの実装とCorefileの設計は[CoreDNSとは？Kubernetesの名前解決の仕組みとCorefile設計を解説](https://www.issoh.co.jp/tech/details/15771/)で扱っています。 ## 名前解決を狙う攻撃に備える設定手順とDNSSEC導入の判断基準 ### 名前解決を狙う代表的な攻撃とDNSSECによる信頼性確保の要点 名前解決は「正しいIPが返る」前提に依存するため、答えを偽装されると被害が大きくなります。代表がキャッシュポイズニング（DNSキャッシュ汚染）で、キャッシュDNSサーバーに偽のレコードを覚え込ませ、利用者を偽サイトへ誘導する攻撃です。対策として応答の正当性を電子署名で検証するのがDNSSECで、権威側でゾーンに署名し、キャッシュ側で検証する仕組みです。現行仕様群は[RFC 9364（DNS Security Extensions (DNSSEC)）](https://www.rfc-editor.org/rfc/rfc9364.html)にBCPとしてまとまっており、どのRFCが現役かを確かめる起点になります。導入手順と検証の流れは[DNSSECとは？DNSの安全性を守る仕組みと導入手順を解説](https://www.issoh.co.jp/tech/details/10518/)で扱っています。 社内向けには問い合わせ先を信頼できるキャッシュDNSサーバーに限定し、見知らぬリゾルバをresolv.confに書かない運用も基本線になります。経路そのものを暗号化する選択肢は[DNS over HTTPS（DoH）の仕組みと設定](https://www.issoh.co.jp/tech/details/16239/)で整理しています。DNSSECは応答の真正性、DoHは経路の盗聴と改ざんを防ぐ仕組みで、守る対象が違うため排他ではありません。 ### digでDNSSEC検証済み応答（adフラグ）を確かめる手順 リゾルバが実際に検証しているかは、ヘッダのadフラグ（Authenticated Data）で確かめられます。 ``` # ad フラグが立てば「検証済み」の応答 dig example.com A +dnssec +noall +comments +answer # 署名レコード（RRSIG）が返っているかを見る dig example.com RRSIG +noall +answer ``` 1つ目で`flags: qr rd ra ad;`のようにadが並べば、リゾルバが署名チェーンをたどって検証を通しています。adが立たないのに2つ目でRRSIGが返るなら、ゾーンは署名済みだが手元のリゾルバが検証していない状態です。判断基準は単純で、金銭や認証情報が流れるドメイン（決済・ログイン・メール受信）は署名する側に回り、社内の検証用ゾーンは運用負荷との兼ね合いで見送ります。鍵の更新（ロールオーバー）を止めると署名切れでドメイン全体が引けなくなるため、署名するなら自動更新まで含めて設計します。 ## よくある質問 実務でつまずく点を5問に絞って答えます。 ### 名前解決とDNSは同じ意味ですか？ 厳密には別です。名前解決は「名前とアドレスを相互変換する処理」という目的で、DNSはそれを実現する代表的な仕組み（分散データベースとプロトコル）を指します。名前解決の手段はDNSだけではなく、**/etc/hosts**による静的な解決や、社内LAN向けのmDNS/NetBIOSなども対象です。hostsが優先されて「DNSを通らない名前解決」が起きる点を区別しておくと障害調査で役立ちます。 ### 正引きと逆引きは何が違いますか？ 正引きはドメイン名からIPアドレスを求める解決で、Web閲覧など日常の通信で使います（A/AAAAレコード）。逆引きはIPアドレスからドメイン名を求める解決で、in-addr.arpaのPTRレコードを使い、`dig -x 192.0.2.10`で確認できます。未設定だとメールが受信側で弾かれることがあるため、メール基盤では両方を整えるのが前提になります。 ### 名前解決ができないとき、まず何を確認すべきですか？ 切り分けの順序は、(1)**/etc/hosts**に該当行が残っていないか（`getent ahosts`で確認）、(2)`resolvectl status`で問い合わせ先が正しいか、(3)`dig 対象ドメイン @上流DNS`で上流が答えるか、の3段です。digのステータスがNXDOMAINなら名前自体が無い、SERVFAILなら上流やDNSSEC検証の失敗、応答なしならネットワーク到達性を疑います。 ### DNSレコードを変えたのに反映されないのはなぜですか？ 各所のキャッシュにTTLの秒数だけ古い答えが残るためです。digの回答行のTTL値が保持時間で、これがゼロになるまで新しい値は配られません。切り替え作業の前にTTLを短く（例：300秒）設定し、伝播を待ってから変更し、完了後に戻すのが定石になります。端末側は`resolvectl flush-caches`でクリアし、権威側との食い違いは`+norecurse`で権威へ直接聞くと確定できます。 ### hostsファイルとDNSはどちらが優先されますか？ 多くのOSではhostsが先です。Linux/macOSでは**/etc/nsswitch.conf**の`hosts:`行が`files dns`となっていれば、**/etc/hosts**を先に見て、該当行があればDNSに問い合わせません。この参照順はnsswitch.conf(5)が定める書式そのままなので、順序を入れ替えれば挙動も変わります。検証用の行を消し忘れると特定端末だけ挙動が変わる点に注意してください。 ## 関連記事 - [FQDNとは？ドメイン名・ホスト名との違いと書き方を実装者向けに解説](https://www.issoh.co.jp/tech/details/13365/)：名前の構造。 - [DHCPとは？IPアドレス自動割り当ての仕組みを実装者向けに解説](https://www.issoh.co.jp/tech/details/13461/)：DNSアドレスの配布。 - [グローバルIPとは？プライベートIPとの違い・確認方法を実装者向けに解説](https://www.issoh.co.jp/tech/details/13463/)：返るIPの公開範囲。 - [NATとは？仕組み・NAPTとの違いからクラウド実装まで実装者向けに解説](https://www.issoh.co.jp/tech/details/13552/)：アドレス変換の絡み。 - [DNSSECとは？DNSの安全性を守る仕組みと導入手順を解説](https://www.issoh.co.jp/tech/details/10518/)：偽装から守る検証の仕組み。 --- 出典: [名前解決とは？DNSの仕組み・正引き/逆引き・dig/nslookupでの確認方法を実装者向けに解説]()（株式会社一創）