web-dev-qa-db-ja.com

ローカルでレコードが見つからない場合に再帰するように権限のあるDNSサーバーを構成できますか？

うまくいけば、これは可能です。

質問

特定のドメインに対して権限のあるDNSサーバーを構成して、レコードがローカルで見つからない場合に「フォールバック」してフォワーダー/ルートヒントを介して再帰することは可能ですか？

シナリオ

具体的なシナリオを示すために、ドメインpoorlyplanned.comの内部Active DirectoryでバックアップされたDNSサーバー（10.10.10.10）によって提供されるプライベート（内部）ネットワークを想像してみてください。

hostgroupA.poorlyplanned.comのようなレコードを照会する内部クライアントは、ローカルの内部DNSサーバー（10.10.10.10）から回答を取得します。他のドメインの内部クライアントからのクエリは、フォワーダー/ルートヒントを使用して内部DNSサーバー（10.10.10.10）を介して再帰的に解決されます。

さらに、IP 1.2.3.4などのパブリックDNSサーバー（実際には大規模で高可用性の負荷分散サーバー）があり、同じドメイン名poorlyplanned.comに対して権限があります。

レコードを照会する外部クライアントは、解決のために1.2.3.4のパブリックDNSサーバーに直接アクセスします。たとえば、webserverX.poorlyplanned.comのパブリッククエリは、パブリックDNSサーバー1.2.3.4から直接解決され、たとえば50.51.52.53をクライアントに返します。私が直接解決したと言うとき、私はNSレコードがパブリックDNSサーバーを指し、クエリがnot内部サーバーを経由していることを意味します（パブリックではありません）とにかくアクセス可能）。

内部DNSには、パブリックに解決できるように意図されていないpoorlyplanned.comのプライベートDNSレコードが入力されますが、外部DNSには、パブリックに解決できるはずのパブリックDNSレコード（同じドメインの）が入力されます。

これまでのところ、かなり標準的なDNSのものですが、おそらく理想的ではありません。

問題

内部クライアントは、webserverx.poorlyplanned.comのようなパブリックDNSレコードを解決できません。これらのレコードは、内部DNSサーバーで定義されていないためです。内部DNSサーバーは同じpoorlyplanned.comドメインに対して権限があるため、権限のあるDNSサーバーが通常行うように、内部レコードのみを確​​認した後、単に「DNSレコードが見つかりません」という結果を返します。

パブリックDNSサーバーはサードパーティによって管理されており、頻繁にチャーンが発生するため、ボールを落とさずに内部DNSサーバーに重複するレコードセットを手動で維持することは非常に困難です。

回避策として、（内部DNSサーバーを補完するために）外部DNSサーバーを指すクライアント側DNSルックアップサーバーエントリを追加しようとしましたが、両方とも権限があり、クライアントはその後を試行しないため、機能しません。結果とともに戻ってきたら、リストにあるサーバー。

スプリットブレインまたは水平構成は、両方のサーバーに同じDNSレコードが含まれていて、IPが異なるだけであるか、ゾーンファイルを共有できるため、実行できません。

ただし、魅力的に機能するレコードがローカルで見つからない場合に、フォワーダー/ルートヒントを介して内部DNSサーバーを再帰的に解決することが可能である場合。しかし、どのように？

内部ドメインが元々int.poorlyplanned.comのようなサブドメインオフセットで構成されていた場合、問題はないことを理解しています。残念ながら、すでに展開されているリソースと関連するサイトの規模は、そのような変更を禁じています。

確かにこれはユニークな問題ではありませんか？

私は自分自身を十分に明確に表現したことを願っています-明確にするのを手伝うことができるかどうか私に知らせてください。

読んでくれてありがとう！

domain-name-systemactive-directorywindows-server-2016internal-dnssplit-dns
3
Jaans

これは確かに固有の問題ではありません。私の頭のてっぺんから、一般的に採用されている2つの「解決策」があります。

  • パブリックに利用可能にする必要があるレコードのエントリを両方のDNSインフラストラクチャに手動でコピーします。これは、公的にホストされているサービスの場合のみであることに注意してください。 VPSインスタンス。内部でホストされるapp.example.comは外部でパブリックIPアドレスを必要としますが、おそらく内部でプライベートIPアドレスを必要とします。自動化が誇大宣伝になっているので、両方の場所でこれらのパブリックIPアドレスを頻繁に変更する必要がある場合は、これを自動化することを検討する必要があります。現在のDNSホスティングプロバイダーが良くない場合（品質が悪いか、自動化のためのAPIがない場合）、単に別のプロバイダーに切り替えることができます。
  • 内部で別のドメインを使用します。 example.comを所有していて、パブリックサーバーがこのドメインを使用している場合。 www.example.comおよびmail.example.comの場合、Windows Active Directoryを使用している場合は内部ネットワークでad.example.comを使用でき、comp.example.comまたは任意のものを使用できます。内部リソースはこの名前空間に存在し、パブリックリソース（例：www.example.com）はパブリックDNSプロバイダーに転送されます。このように、DNSエントリを複製する必要はありません。

両方のソリューションには賛否両論があり、他のソリューションが存在する可能性があります。

データベースに回答が見つからない場合、クエリを転送するように権限のあるDNSサーバーを構成することはできません。 「権威」とは、ゾーンに関するすべてを知っていることを意味します。特定のフォワーダーを構成できます。例：

zone "example.com" {
   type master;
   file "...";
};
zone "www.example.com" {
   type forward;
   forwarders { 203.0.113.53; };
};
zone "mail.example.com" {
   type forward;
   forwarders { 203.0.113.53; };
};
3
Tommiie

外部DNSがBINDを使用している場合次の構成ファイルは、問題を解決する方法の単なる例です。

acl localnet { 1.2.3.4/24; }; <---- this is the range of your public ip addresses
view internal {
     match-clients { localnet; };

     allow-recursion { any; };

     zone "myzone.example" {
          type master;
          file "external.db.myzone.example"; <--- in this file put all your internal and external records
                                                  even if they have local ip addresses
     };

     };
}; 
view external {
     match-clients { any; };

     allow-recursion { any; };

     zone "myzone.example" {
          type master;
          file "internal.db.myzone.example"; <--- in this file put all just your external records
     };

     };
}; 
};
0
Soulimane Mammar