--- title: "プライベートDNSとは？内部名前解決の仕組み・Route 53プライベートホストゾーン・設計を実装者向けに解説" url: "https://www.issoh.co.jp/tech/details/14678/" published: 2026-07-14 updated: 2026-10-04 categories: ["AWS"] publisher: "株式会社一創" --- # プライベートDNSとは？内部名前解決の仕組み・Route 53プライベートホストゾーン・設計を実装者向けに解説 プライベートDNSとは、特定のネットワーク（クラウドのVPCや社内LAN）の中だけで有効な、外部には公開しないDNSによる名前解決の仕組みを指します。内部専用のドメイン名とプライベートIPアドレスを紐付け、その問い合わせには内側からしか応答しないため、サーバー構成をインターネットへ晒さずに「名前でつなぐ」運用が可能です。なお、Androidの端末設定にある「プライベートDNS」は暗号化通信（DNS over TLS）を指す別概念で、本記事が扱うクラウド/社内基盤の内部DNSとは対象が違います。この記事では、パブリックDNSとの違い、Route 53プライベートホストゾーンをはじめとするクラウドでの実装、オンプレミスとクラウドをまたぐハイブリッド構成の名前解決、そして導入の判断基準と落とし穴までを、実装者が手を動かせる粒度で整理します。 ## まとめ：プライベートDNSの全体像と実装者がまず押さえる要点 プライベートDNSは「内部限定の名前解決」です。インターネット全体へ公開するパブリックDNSと対になる概念で、解決の答え（レコード）が届くスコープを社内やVPCの内側に閉じる点が本質です。基礎となる名前解決そのものの機構は[名前解決とは？DNSの仕組み・正引き/逆引き・dig/nslookupでの確認を実装者向けに解説](https://www.issoh.co.jp/tech/details/13556/)で前提を押さえてください。プライベートDNSはその名前解決を、外に出さない範囲で運用する一形態にあたります。 実装者の観点では、次の3点を分けて理解すると設計と障害切り分けが速くなります。第一に、レコードが有効な範囲（スコープ）です。クラウドではVPC単位、オンプレミスでは社内DNSの管理ドメイン単位で「どこから引けるか」が決まります。第二に、同じドメイン名を内部と外部で別々の答えに向けるスプリットホライズン（スプリットビュー）の設計です。第三に、オンプレミスとクラウドを相互に引き合わせるための条件付きフォワーディング（DNS転送）です。以降の章で、この3点を順に掘り下げます。 ## プライベートDNS（内部DNS）の基本と公開DNSとの違いを理解する ### 内部ドメイン名での接続・IP変更への強さと内部構成を秘匿できる利点 プライベートDNSが返すのは、社内やVPCの内側でしか通用しないドメイン名と、プライベートIPアドレスの対応です。たとえば`db.internal.example`という内部専用の名前を`10.0.1.20`というプライベートIPへ向ける、といった使い方をします。このレコードは内側からの問い合わせにしか応答せず、インターネット側のキャッシュDNSサーバーからは引けません。返されるアドレスがプライベートIPである点は前提として押さえておくべきで、グローバルIPとプライベートIPの使い分けは[グローバルIPとは？プライベートIPとの違い・確認方法を実装者向けに解説](https://www.issoh.co.jp/tech/details/13463/)で整理しています。内部の名前が外部から解決できないのは制約ではなく、構成情報を秘匿するための設計そのものです。 ### クラウド/社内基盤の内部DNSと「スマホのプライベートDNS」設定の用語差 検索でよく混同されるのが、Android端末の「設定 → ネットワーク → プライベートDNS」という項目です。こちらはDNS over TLS（DoT）で問い合わせ経路を暗号化する機能で、どのDNSサーバーへ引くかを暗号化して指定するものです。DoTと対になる方式は[DNS over HTTPSとは](https://www.issoh.co.jp/tech/details/16239/)で解説しています。本記事のプライベートDNS（内部DNS／プライベートホストゾーン）は、レコードの公開範囲を内側に閉じる仕組みで、暗号化の話とは目的が異なります。用語が同じでも、端末の通信秘匿を指すのか、インフラ側の内部名前解決を指すのかで文脈が分かれる点を最初に切り分けておくと迷いません。以降は後者、インフラ側の内部DNSに絞って解説します。 ## プライベートDNSを内部ネットワークで使う理由と代表的な利用場面 ### 内部ドメイン名での接続がIP変更に強く、内部構成の秘匿にもつながる理由 プライベートIPを直接コードや設定に書き込むと、サーバー入れ替えやスケール変更のたびに全箇所を書き換える羽目になります。内部の名前でつないでおけば、IPが変わってもプライベートDNSのレコードを1か所書き換えるだけで追従できるのが強みです。加えて、内部ドメイン名は外部に公開されないため、どのホストがどんな役割かという構成情報をインターネットへ晒さずに運用できます。名前の付け方（ホスト名とドメイン名の構造）を整えておくと運用が読みやすくなり、その書式は[FQDNとは？ドメイン名・ホスト名との違いと書き方を実装者向けに解説](https://www.issoh.co.jp/tech/details/13365/)で確認できます。内部専用ゾーンには`.internal`や自社管理の実在ドメインのサブドメインを当て、外部の公開ドメインと名前空間を分けて設計するのが定石です。 ### マイクロサービスのサービス検出やオンプレからのクラウド移行での利用場面 プライベートDNSが効くのは、まずマイクロサービス間の接続です。サービスをIPではなく名前で呼び合えば、コンテナの入れ替えやオートスケールでIPが変わっても呼び出し側は影響を受けません。次にデータベースや内部APIなど、外部へ出す必要のないエンドポイントの提供に向きます。さらに、オンプレミスからクラウドへ移行する局面で、既存の社内名前解決の名残を保ちながら段階移行する土台にもなります。パブリックDNSとプライベートDNSの違いを対比すると次の通りです。 | 観点 | パブリックDNS（公開DNS） | プライベートDNS（内部DNS） | | ------- | ---------------------- | ----------------------- | | 解決できる範囲 | インターネット全体 | 関連付けたVPCや社内ネットワークの内側のみ | | 返すアドレス | 主にグローバルIP | 主にプライベートIP | | 主な用途 | Webサイトや公開サービスの公開 | 内部サービス接続・サービス検出 | | 構成情報の露出 | レコードは外部から参照可能 | 外部からは参照できず秘匿される | | 代表的な実装 | Route 53公開ゾーン、各社の権威DNS | Route 53プライベートゾーン、社内DNS | 公開が要る名前はパブリック側、内部で閉じたい名前はプライベート側と、役割で置き場所を分ける。これが名前空間を破綻させないための基本線です。 ## クラウドでのプライベートDNS実装とスプリットホライズン設計 ### VPCの内部リゾルバとプライベートホストゾーンの関係と前提となる設定 クラウドでは、VPCごとに用意される内部リゾルバがプライベートDNSの入口になります。AWSの場合、VPCのCIDR先頭から数えた特定アドレス（いわゆるVPC+2、Amazon提供DNS）が内部リゾルバの実体です。この内部リゾルバが、EC2のプライベートホスト名や、後述するプライベートホストゾーンのレコードを解決します。プライベートホストゾーンは、1つまたは複数のVPCに関連付けるゾーンで、そこに登録したドメインは関連付けたVPCの内側からのみ引けます。実装時に前提となるのが、VPCのDNS属性（enableDnsSupportとenableDnsHostnames）の有効化です。これらが無効だと内部リゾルバが機能せず、ホスト名の解決が通りません。GCPなら[Cloud DNSのプライベートゾーン](https://www.issoh.co.jp/tech/details/15679/)、AzureならAzure Private DNSゾーンが同じ役割を担い、いずれも仮想ネットワークへゾーンをリンクして初めて内部から引ける形になります。 ### 同名の内外分離を実現するスプリットホライズン設計の考え方と注意点 同じ`api.example.com`という名前を、社内からはプライベートIPへ、社外からはグローバルIPへ解決させたい場面があります。これを実現するのがスプリットホライズン（スプリットビュー）です。同名のプライベートホストゾーンと公開ゾーンを併存させ、問い合わせ元がVPC内かどうかで返す答えを変えます。ここで注意すべきは優先順位で、あるVPCに同名のプライベートゾーンを関連付けると、そのVPC内からの問い合わせはプライベート側が優先され、公開ゾーンのレコードは見えなくなります。内部から一部のサブドメインだけ公開側へ通したい場合は、プライベートゾーン側にも該当レコードを明示的に持たせておく前提です。こうしたVPCのDNS設計やスプリットホライズンの切り分けは初期の設計判断が難しく、要件に合わせて任せたい場合は[一創のインフラ構築（AWS/GCP/Azure）](https://www.issoh.co.jp/service/system/aws/)でご相談ください。名前が引けるかどうかは可用性そのものに直結するため、冗長化とあわせて初期設計で固めます。 ## オンプレミスとクラウドをまたぐハイブリッド構成での名前解決の設計 ### 条件付きフォワーディングで社内DNSとクラウドDNSを相互につなぐ設計 VPNや専用線でオンプレミスとクラウドを接続したハイブリッド構成では、双方が相手側の内部名前を引けるようにする転送設計が要ります。基本形は条件付きフォワーディング（conditional forwarding）です。「このドメイン宛ての問い合わせだけを、指定した相手のDNSへ転送する」というルールを両側に置きます。たとえば社内DNSには`*.aws.example`宛てをクラウド側へ転送する設定を、クラウド側には`*.corp.example`宛てをオンプレDNSへ転送する設定を入れ、名前空間ごとに問い合わせ先を振り分けます。全問い合わせを無条件に転送すると外部解決まで巻き込んで遅延や障害の温床になるため、対象ドメインを絞るのが原則です。 ### Route 53 Resolverのインバウンド/アウトバウンドエンドポイントの役割 AWSでこの転送を担うのが、Route 53 Resolverの2種類のエンドポイント（インバウンド/アウトバウンド）になります。インバウンドエンドポイントは、オンプレDNSからクラウド内の名前を引くための入口（オンプレ→クラウド方向の受け口）です。対してアウトバウンドエンドポイントは、VPC内から特定ドメインをオンプレDNSへ転送するための出口（クラウド→オンプレ方向）です。両者とアウトバウンド側の転送ルールを組み合わせて、どのドメインをどちらへ流すかを定義します。エンドポイントはENI単位の時間課金で、最小構成でも1本あたり月180ドルを超えるため、費用の内訳は[Route 53の料金を実額で計算する：ホストゾーン・クエリ・Resolver・ドメイン代の月額](https://www.issoh.co.jp/tech/details/18072/)で確認してください。なお、内部リゾルバの問い合わせ先はDHCPで各インスタンスへ配布されるのが基本です。この配布の仕組みは[DHCPとは？IPアドレス自動割り当ての仕組みを実装者向けに解説](https://www.issoh.co.jp/tech/details/13461/)で整理しました。転送設計を変えたのに反映されないときは、まずインスタンス側が参照しているリゾルバのアドレスが想定通りかを確認します。 ## プライベートDNS導入の判断基準と実装でつまずく代表的な落とし穴 ### プライベートDNSを採用すべき条件と、あえて見送ってよい小規模の場面 判断の軸ははっきりしています。内部サービス同士を名前で疎結合につなぎたい、IP変更やスケールに設定を追随させたい、内部構成を外部へ晒したくない——この3条件のいずれかに当てはまるなら、プライベートDNSは採用してよい設計です。とくにVPCをまたぐ接続やマイクロサービス構成では、名前解決を内部で持つ効果が大きく出ます。一方で、単一VPC内にホストが数台しかなく、IPもほぼ固定で当面スケールしない小規模構成なら、プライベートホストゾーンを立てずにクラウド既定の内部ホスト名で足りる場面もあるでしょう。ゾーンを増やすほど「どのゾーンにどのレコードがあるか」の管理コストが積み上がるため、名前で疎結合にする利益が管理の手間を上回るかで採否を決めます。 ### VPCのDNS属性の有効化・名前空間の衝突・TTLでつまずく代表例 実装で頻出する落とし穴は主に3つです。第一に、前述のVPCのDNS属性（enableDnsSupport/enableDnsHostnames）の有効化漏れで、これを忘れるとプライベートホストゾーンを作っても内部から引けません。第二に、名前空間の衝突です。既存の公開ドメインと同名のプライベートゾーンを不用意に関連付けると、そのVPCからは公開側のレコードが見えなくなり、意図せず内部向けの答えだけが返ります。第三に、TTL（キャッシュの保持時間）の見落としで、レコードを変更しても各リゾルバのキャッシュが切れるまで古い答えが残ります。切り替え作業の前にTTLを短く設定し、伝播を待ってから変更する運用が定石です。この3点を設計時のチェックリストに入れておくと、公開後の名前解決トラブルの多くを未然に防げます。 ## よくある質問 プライベートDNSの実務でつまずきやすい点を、5つの質問に絞って答えます。 ### プライベートDNSとパブリックDNSの違いは何ですか？ 解決の答えが届く範囲が違います。パブリックDNSはインターネット全体から引けて主にグローバルIPを返し、公開サービスの名前解決に用いる仕組みです。対してプライベートDNSは、関連付けたVPCや社内ネットワークの内側からのみ引けて、主にプライベートIPを返します。レコードが外部から参照できるか否かが本質的な差で、内部構成を秘匿したい名前はプライベート側へ置きます。 ### スマホの「プライベートDNS」設定と同じものですか？ 別物です。Android等の端末設定にある「プライベートDNS」はDNS over TLSによる問い合わせ経路の暗号化機能で、どのDNSへ引くかを暗号化して指定するものです。本記事のプライベートDNS（内部DNS／プライベートホストゾーン）は、レコードの公開範囲を内側に閉じるインフラ側の仕組みで、目的が異なります。用語は同じでも文脈が分かれる点に注意してください。 ### プライベートホストゾーンはインターネットから見えますか？ 見えません。プライベートホストゾーンのレコードは、関連付けたVPCの内部リゾルバ経由でしか解決できず、外部のキャッシュDNSサーバーからは参照できません。これはアクセス制御の副産物ではなく仕様で、内部専用の名前とプライベートIPを外部へ露出させないための設計です。外部公開が要る名前は、別途パブリックの公開ゾーンに登録します。 ### オンプレの社内DNSとクラウドのプライベートDNSは連携できますか？ できます。VPNや専用線で両ネットワークを接続したうえで、条件付きフォワーディングにより双方向にDNS問い合わせを転送する形です。AWSならRoute 53 Resolverのインバウンド/アウトバウンドエンドポイントと転送ルールで、社内DNS宛てとクラウドDNS宛ての問い合わせを名前空間ごとに振り分けます。全問い合わせを無条件転送せず、対象ドメインを絞るのが安定運用の原則です。 ### 同じドメイン名を内部と外部で使い分けできますか？ スプリットホライズン（スプリットビュー）で実現できます。同名のプライベートホストゾーンと公開ゾーンを併存させ、VPC内からの問い合わせにはプライベート側、外部からの問い合わせには公開側の答えを返す構成です。ただしVPC内では同名のプライベート側が優先され公開側のレコードが隠れるため、内部からも公開側の値が要るサブドメインは、プライベートゾーンにも明示的にレコードを持たせる必要があります。 ## 関連記事 - [名前解決とは？DNSの仕組み・正引き/逆引き・dig/nslookupでの確認を実装者向けに解説](https://www.issoh.co.jp/tech/details/13556/)：プライベートDNSの土台となる名前解決の機構（再帰問い合わせ・権威サーバー・確認コマンド）を押さえられます。 - [グローバルIPとは？プライベートIPとの違い・確認方法を実装者向けに解説](https://www.issoh.co.jp/tech/details/13463/)：プライベートDNSが返すプライベートIPと、公開向けグローバルIPの使い分けを整理できます。 - [DHCPとは？IPアドレス自動割り当ての仕組みを実装者向けに解説](https://www.issoh.co.jp/tech/details/13461/)：内部リゾルバのアドレスがどう各ホストへ配布されるかを補完します。 - [FQDNとは？ドメイン名・ホスト名との違いと書き方を実装者向けに解説](https://www.issoh.co.jp/tech/details/13365/)：内部専用ゾーンで使うドメイン名・ホスト名の正確な構造を確認できます。 - [クラウドとは？AWSとは何かを仕組み・料金・移行の判断まで事業者向けに解説](https://www.issoh.co.jp/column/details/13421/)：プライベートDNSが載るVPC/クラウド基盤の全体像を俯瞰できます。 --- 出典: [プライベートDNSとは？内部名前解決の仕組み・Route 53プライベートホストゾーン・設計を実装者向けに解説]()（株式会社一創）