VPS ネットワークのプライベート DNS: 仕組みと必要になる場面

3 台目のサーバーを立ち上げ、各マシンが IP ではなく名前で互いに到達できるようにしたくて「private DNS VPS」と検索します。返ってきた 3 件の結果は互いに食い違っています。1 つは携帯の名前解決を暗号化する Android の設定。1 つはドメインのネームサーバーをブランド化する cPanel のガイド。もう 1 つはプライベートホストゾーンに関する AWS のドキュメントです。2026 年 7 月 20 日、 Cloudflare が Internal DNS を一般提供として公開しました そしてそれを「プライベート DNS と呼ばれることもある」と説明しました。つまりこの名称の衝突は、いまやインフラベンダーからも生じています。

この用語は意味が多すぎます。本記事ではまず異なる意味を切り分け、そのうえで VPS ネットワークの意味、つまりサーバー間通信のための内部 DNS ゾーンに焦点を当てます。読み終える頃には、必要なシステムを見分け、自分のサーバー群にプライベート DNS が必要かを判断し、よくある設計ミスを避けられるようになります。

要約

• 「プライベート DNS」は、互いに無関係な少なくとも 3 つのシステムを指します。サーバーネットワーク向けの内部 DNS ゾーン、Android の DNS-over-TLS 暗号化機能、そして cPanel のブランド化されたネームサーバーです。本記事はこの用語を 1 つ目の意味、つまり VPS ネットワーク向けの内部 DNS ゾーンとして使います。
• VPS のプライベート DNS ゾーンとは、ネットワーク単位に限定された内部の名前空間で、 db.internal.example.com のようなホスト名をプライベート IP に対応付けます。そのレコードはパブリック DNS には公開されません。
• IP が安定したサーバーが数台だけなら、 /etc/hosts で十分です。内部 DNS サーバーが価値を持つのは、サーバー台数が増えたとき、IP が頻繁に入れ替わるとき、あるいはサービスが確実な名前解決を必要とするときです。
• 本番の VPS ネットワークの多くでは、自分が所有するサブドメインを使ってください。たとえば internal.example.com。.internal 名前空間は、ネットワーク間の名前衝突、プライベート CA による証明書管理、DNSSEC の特別な扱いを受け入れられる隔離環境でのみ使ってください。mDNS が予約している .local は避けましょう。

本記事が扱わないこと

本記事はプライベート DNS の VPS ネットワーク的な意味に絞ります。無関係な一般消費者向けおよびホスティングブランド向けの用途は扱いません。

• スマートフォンで Android のプライベート DNS または DNS-over-TLS の設定を行うこと。
• ホスティングブランド向けに cPanel のプライベートネームサーバーを設定すること。
• BIND 9、Unbound、dnsmasq、CoreDNS の完全なインストール手順。本記事の実装はリファレンス程度にとどめ、手順ごとの設定までは踏み込みません。
• 1.1.1.1 や NextDNS のような一般消費者向けの暗号化リゾルバーについて、ネットワーク的な意味との区別を超えた内容。

「プライベート DNS」とは実際に何を指すのか

「プライベート DNS」は 1 つのシステムではありません。互いに無関係な少なくとも 3 つを指します。VPS や VPC ネットワーク内部で内部ホスト名を解決する、ネットワークに限定された DNS ゾーン。Android の DNS-over-TLS 暗号化機能。そして cPanel の独自ブランドの権威ネームサーバーです。本記事が扱うのは 1 つ目、サーバー同士が互いを見つけるために問い合わせる内部ゾーンです。さらに緩やかな 4 つ目の用法もあります。「プライベート」とうたって売られる暗号化されたパブリックリゾルバーです。

この 4 つの意味に共通するのは名前だけで、それ以外は何もありません。

Cloudflare による Internal DNS の一般提供 の発表は、1 つ目の意味に対応する現行のマネージド事例であり、この名称衝突が改めて目につくようになった理由の一つでもあります。インフラベンダーが launch 文書の中で「プライベート DNS」を内部 DNS の同義語として使い始めたからです。そこで説明されているシステム、すなわち Enterprise 顧客向けの Gateway Resolver と Internal Authoritative DNS の組み合わせは、あなたが VPS 群の上で自分で構築するものと同じカテゴリーであり、違いはマネージドかどうかだけです。

このセクションの要点： 「プライベート DNS」と呼ばれる主なシステムに共通するのはラベルであって、機能ではありません。設定ガイドに従う前に、どの意味なのかを見極めてください。

プライベート DNS は VPS ネットワークでどう機能するのか

VPS のプライベート DNS ゾーンとは、サーバー側で使うよう設定したリゾルバーが提供する、ネットワーク単位に限定された名前空間です。これは db.internal.example.com のような内部ホスト名を、自分が管理する範囲のプライベート IP に対応付けます。これらのレコードはパブリック DNS には公開されません。ただしクエリ自体は、リゾルバーに届くまでにプライベートトンネルやマネージドの DNS コントロールプレーンを通ることがあります。この分離こそがプライベート DNS とパブリック DNS の違いの核心です。プロトコルは同じでも、ゾーンの可視範囲とアクセス範囲が違います。

働きを担うのは 3 つの部分です。権威サーバーまたはゾーンのソースが内部ゾーンとそのレコードを保持します。リゾルバーがサーバーから送られたクエリに応答します。そしてゾーンの A レコードと AAAA レコードが内部ホスト名をプライベートアドレスに対応付けるため、 app.internal.example.com はアプリケーション層に解決され、 db.internal.example.com はデータベースに解決されます。他のレコード種別はエイリアスやサービス情報を提供できます。ゾーンとリゾルバーの経路が正しく設定されていれば、リゾルバーは内部クエリをパブリック DNS のルートへ送らず、ローカルで応答します。

クラウド各社はこれをマシン単位ではなくネットワーク単位に限定しており、参考になるモデルです。 AWS Route 53 のプライベートホストゾーン が機能するのは、VPC で enableDnsHostnames と enableDnsSupport の両方が true になっている場合だけで、リゾルバーは関連付けたどの VPC に対してもプライベートゾーンから応答します。 Google Cloud のプライベートゾーン は許可された VPC ネットワークに限定され、 標準の VPC 名前解決順序 では、送信サーバーポリシーが経路を変えない限り、パブリック DNS より先に参照されます。これらはプラットフォームのチュートリアルではなく、パターンの例として読んでください。自分で運用する内部 DNS サーバーも同じ発想で、自身の VPS 上で動かすだけの違いです。

ゾーンをパブリック DNS の外に置くのは、仕事の半分にすぎません。DNS サービスをプライベートインターフェースにバインドするか、UDP と TCP のポート 53 を自分のプライベートネットワークまたは VPN に限定してください。再帰サービスをパブリックインターネットに公開してはいけません。 オープンリゾルバーは DNS 増幅攻撃に悪用されうる.

プライベートゾーンもパブリックゾーンも、DNS レコードとキャッシュの仕組みは同じです。レコードには TTL があり、キャッシュするリゾルバーは通常その TTL が切れるまで応答を再利用します。ただしリゾルバー固有の設定によって実効的なキャッシュ時間は変わりえます。この挙動については、ドメインを VPS に向ける当社のガイドで扱っており、 DNS の伝播と TTL の基礎ここでは改めて説明しません。

VPS ネットワークに本当にプライベート DNS が必要になるのはいつか

2 台か 3 台の固定サーバーであれば、 /etc/hosts で十分です。内部 DNS サーバーが価値を持つのは、サーバー台数が増えたとき、IP が定期的に変わるとき、あるいはアプリケーションが確実なサービスディスカバリーを必要とするときです。本当のきっかけは運用上の複雑さであって、決まったサーバー台数ではありません。

/etc/hosts は、あらゆる Linux マシンにすでに存在する、ホスト名と IP の静的な対応表です。デーモンもゾーンファイルも不要ですが、古くなったり食い違ったりしたコピーは現実の障害要因になります。各サーバーのプライベート IP をこのファイルに追加し、コピーを同期しておけば、マシン同士が名前で見つけ合えます。小規模で安定した構成ならこれが正解であり、代わりに BIND 9 を持ち出すのは、何の得もないまま保守対象のデーモンを一つ増やすだけです。

この方法は 3 つの場面で立ち行かなくなります。サーバーを頻繁に追加・削除する場合、静的ファイルをすべてのホストで一致させ続けることが手作業の重荷になります。オートスケーリングや再構築、事業者側の再割り当てによって IP が変わる場合、ファイルは黙ったまま古くなります。そしてコンテナや隔離されたランタイムがホストのエントリを引き継がない場合、この対応付けは万能ではなくなります。このいずれか一つでも当てはまれば、それが本当のきっかけです。サーバー台数だけでは大まかな目安にすぎず、実際のシグナルではありません。

このセクションの要点： きっかけは運用上の変動であって、サーバー台数ではありません。まったく変化のない 10 台構成なら /etc/hostsで済みますが、毎晩作り直される 3 台構成ではおそらくそうはいきません。

どの DNS サーバーを動かすべきか: BIND 9、Unbound、dnsmasq、CoreDNS

自分の構成の形に合わせて選びます。dnsmasq は軽量な DNS を求め、必要なら同じデーモンから DHCP も欲しい小規模ネットワークに向きます。Unbound は無駄のない検証付き再帰リゾルバーで、小さなローカルゾーンにも応答できます。BIND 9 は最も広い設定面を持ち、権威・再帰の両面で幅広い機能を備えます。CoreDNS は DNS がサービスディスカバリーの一部となっているコンテナや Kubernetes 環境に適しています。

選び方の理屈は短いものです。hosts 形式のファイルに支えられた小さなリゾルバーが必要な場合、あるいはすでに DHCP のリースを配っている場合、dnsmasq は可動部を一つ減らしてくれます。主に必要なのが、外部へ転送しつつ小さな内部ゾーンに応答する検証付きリゾルバーであれば、Unbound は BIND 9 をまるごと展開せずにその狭い機能セットを提供します。完全な権威制御と委任、そして午前 3 時に頼れる最大の文書量が必要なら、設定面が広いにもかかわらず BIND 9 が手堅い選択です。DNS がすでにコンテナや Kubernetes のサービスディスカバリー基盤の一部になっているなら、CoreDNS はその場に無理なく収まります。目安は、自分の構成の形をカバーできる最小のものを動かすことです。

本番環境の構成では、単一の DNS インスタンスをすべての内部名への唯一の経路にしてはいけません。ゾーンに応答できる 少なくとも 2 つの DNS インスタンス を動かし、可能なら別々の障害ドメインに配置し、クライアントが両方に到達できるよう設定してください。そうしなければ、たった一度の DNS 障害で健全なサービスが停止しているように見えてしまいます。

内部ドメインの命名はどうするか: .internal、.local、それともサブドメインか

本番の VPS ネットワークの多くでは、自分が所有するサブドメインを使ってください。たとえば internal.example.com。.internal 名前空間は、ネットワーク間の名前衝突、プライベート CA による証明書管理、DNSSEC の特別な扱いを受け入れられる隔離環境でのみ使ってください。mDNS が予約している .local は避けましょう。

.local の問題は具体的です。 RFC 6762 は .local で終わる名前に Multicast DNS 向けの特別な扱いを与えています。そのため同じサフィックスを使うユニキャストの BIND 9 や Unbound のゾーンは、Apple 製デバイスをはじめとする mDNS 対応システム上の mDNS の挙動と衝突する可能性があります。クライアントごとの回避策に頼るより、別の名前空間を使ってください。

プロのヒント: .local の内部ゾーンを引き継いだのなら、それは技術的負債として扱ってください。クライアントによっては .local のクエリをユニキャストの DNS サーバーではなく mDNS へ送るため、クライアント依存の、あるいは断続的に見える障害が起きることがあります。

ICANN の理事会は .internal を恒久的に予約しました 。2024 年 7 月、先行する SSAC の勧告を受けて、パブリック DNS ルートでの委任から外されました。その配下の名前は設計上、グローバル DNS では解決されません。これにはトレードオフが伴います。.internal の名前はグローバルに一意ではなく、パブリック認証局が証明書を発行することも想定されておらず、グローバルなトラストアンカーに依拠して DNSSEC 検証を行うリゾルバーは解決に失敗します。.internal で HTTPS が必要なら、プライベート CA の運用を見込んでおいてください。

ここでは 2 つのことを区別してください。ICANN の予約は確定事項です。それとは別に、 有効な Internet-Draft である draft-davies-internal-tld-06が 2026 年 5 月 6 日に公開され、この名前空間を文書化し、RFC 1918 のプライベートアドレスと比較しています。これはあくまで作業中の Internet-Draft であって、公開された RFC ではありません。したがって .internal は IETF の標準ではなく、ICANN が予約した私用トップレベルドメインとして説明してください。

多くの VPS 構成では、自分が管理するドメインのサブドメインを使うのが、より安全な既定の選択です。 ISC はサブドメイン階層を推奨しています。たとえば自分のドメインの内部向けサブドメインを使うほうが、同じ親ゾーンについて内部用と公開用に分かれた不完全な版を二重に維持するよりよい、ということです。これは好みの問題ではありません。次節で述べる障害を防ぐためです。

このセクションの要点： 名前空間の決定は長く残ります。自分が管理するサブドメインは、グローバルな一意性を保ち、パブリック PKI とも噛み合うため、多くの本番環境で既定の選択になります。隔離されたプライベート名前空間のほうが適していて、DNSSEC・証明書・名前衝突のトレードオフを受け入れられる場合には .internal を使ってください。

スプリットホライズン DNS と、それを壊す落とし穴

スプリットホライズン DNS は、同じホスト名に対して問い合わせ元によって異なる答えを返します。内部にはプライベート IP、外部にはパブリック IP です。これが最もよく壊れるのは、同一ドメインでの NXDOMAIN の罠、意図したビューを迂回する別のリゾルバー、そして期待した上流に届かないコンテナの DNS 経路によるものです。正しく機能させられるかは、一つではなく三つのことに同時にかかっています。

NXDOMAIN の罠は、まさに ISC が直接警告している障害です。内部サーバーが親ドメインに対して権威を持っているのに、そのゾーンの内部版に www ホストのようなパブリックレコードが含まれていない場合、その名前を問い合わせた内部クライアントは、パブリックゾーンには存在するにもかかわらず NXDOMAIN を受け取ります。内部ゾーンは権威を持っているため、親ドメインについてパブリック DNS へフォールバックしないからです。命名の節で述べたサブドメイン階層方式が ISC の推す設計である理由は、まさにここにあります。

プロのヒント: 同一ドメインでのスプリットホライズン構成にサーバーを向ける前に、ネットワーク内部からそのドメインのよく知られたパブリック名を引いて試してください。外部では問題なく解決する名前に NXDOMAIN が返るなら、それがこの罠の特徴です。

見落としやすい落とし穴があと 3 つあります。ホストやコンテナに設定された別のリゾルバーが、この切り分けを迂回することがあります。リゾルバーの実装によっては、タイムアウト後に問い合わせたり並行して問い合わせたりするため、答えがぶれることもあります。Docker の既定ブリッジ上のコンテナは起動時にホストの DNS 設定のコピーを受け取りますが、カスタムネットワーク上のコンテナは Docker の組み込みリゾルバー 127.0.0.11に問い合わせます。そのリゾルバーは外部の名前解決を、ホストまたはコンテナに設定された DNS サーバーへ転送します。したがって split-DNS の挙動は、コンテナ自身のリゾルバー設定ファイルだけでなく、Docker とホストの設定に左右されます。内部サービスが次のようなリバースプロキシの背後にある場合、 Nginx プロキシマネージャー要求されたホスト名を証明書がカバーしていない場合や、発行元の CA をクライアントが信頼していない場合には、証明書の検証が失敗することがあります。内部で別の証明書を使うこと自体は誤りではありません。これらは設定の隙間であって、ツールの不具合ではありません。

リモートのクライアントも同じ障害に遭遇することがあります。 セルフホストの VPN が DNS クエリを意図した内部リゾルバーへ配布・経路づけしていない場合です。

セキュリティの側面もあります。内部ホスト名やプライベート IP がパブリック DNS のレコードに漏れ出せば、内部の命名・アドレス設計の一部を、問い合わせた誰にでもさらすことになります。スプリットホライズンが存在する理由の一つは、その見取り図を内部にとどめることであり、設定を誤ったパブリックゾーンはそれを静かに台無しにします。

このセクションの要点： スプリットホライズンの失敗は設定上の罠であって、ツールの欠陥ではありません。正しく動くかどうかは、命名の規律、各クライアントが実際にどのリゾルバーへ問い合わせているかの把握、そしてゾーンの適切な範囲設定にかかっており、たった一つの設定項目で決まるものではありません。

読む

ドメインをVPSにポイントする方法：クイックガイド

まとめ: 適切なプライベート DNS 設計を選ぶ

これで、自分が言う「プライベート DNS」がどのシステムを指すのかを見分けられるはずです。VPS のネットワークにおいては、それは内部 DNS ゾーンであって、Android の DNS-over-TLS 設定でも、ブランド化された権威ネームサーバーでもありません。構成が小さく安定しているなら、 /etc/hosts は十分に筋の通った選択です。そうでないなら、自分が所有するサブドメインを既定の名前空間とし、構成に見合う最小の DNS サーバーを選び、アクセス、冗長性、内部ゾーンとパブリックゾーンの範囲を明示的に決めておいてください。.internal は、隔離された名前空間のほうが適していて、証明書・DNSSEC・名前衝突のトレードオフを受け入れられる場合にだけ使いましょう。

よくある質問

Android のプライベート DNS は、VPS 上のプライベート DNS サーバーと同じものですか

いいえ。Android のプライベート DNS は、デバイスの名前解決を通信経路上で保護する DNS-over-TLS 機能です（ポート 853 でのクエリ暗号化、Android 9 で追加）。一方、VPS 上のプライベート DNS サーバーは、ネットワーク全体で内部ホスト名をプライベート IP に解決します。前者はクエリを暗号化し、後者は内部の名前空間を作ります。両者はまったく別の問題を解決するものです。

プライベート DNS とパブリック DNS の違いは何ですか

プライベート DNS は、特定のネットワーク、VPN、クラウド環境にいる許可されたクライアントだけにゾーンを提供します。パブリック DNS は、インターネット上のリゾルバーが問い合わせられるレコードを公開します。どちらも同じ DNS レコード種別とキャッシュの仕組みを使います。違いは、そのゾーンに誰が到達できるか、そしてレコードがどこから見えるかです。

プライベート DNS と暗号化 DNS の違いは何ですか

DoT や DoH のような暗号化 DNS プロトコルは、DNS クエリを通信経路上で保護します。ネットワーク的な意味でのプライベート DNS は、内部名のためにネットワーク単位の名前空間を作ります。暗号化はクエリの通り方を変え、プライベートゾーンはどんな名前が存在し誰がそれを解決できるかを変えるのです。

.internal を内部ホスト名に使っても安全ですか

はい、ただし条件付きです。ICANN は 2024 年 7 月に .internal をパブリックな委任から恒久的に除外したので、プライベートリゾルバー上で提供できます。ただし、グローバルに一意ではなく、パブリック認証局が証明書を発行することも想定されておらず、グローバルなトラストアンカーに依拠する DNSSEC の検証器では解決できません。本番の VPS ネットワークの多くでは、自分が所有するサブドメインのほうが安全な既定の選択です。

プライベート DNS のレコードは、パブリック DNS と同じ TTL とキャッシュを使いますか

はい。プライベートゾーンもパブリックゾーンも、同じ TTL ベースのキャッシュの仕組みを使います。レコードには TTL があり、キャッシュするリゾルバーは通常その値が切れるまで応答を再利用します。とはいえ、リゾルバー固有の設定によって実効的なキャッシュ時間は変わりえます。詳しい仕組みは DNS の伝播と TTL の挙動 をご覧ください。