新しいActive Directoryフォレストに名前を付ける-スプリットホライズンDNSが推奨されないのはなぜですか？

願わくば、Active Directoryフォレストに名前を付けるための推奨事項がすべてわかっていることを願っています。つまり、1つの文にまとめることができます。

既存の登録済みドメイン名のサブドメインを使用し、外部で使用されないものを選択します。 たとえば、hopelessn00b.comドメインを組み込み、登録する場合、内部ADフォレストの名前はinternal.hopelessn00b.comor ad.hopelessn00b.comまたはcorp.hopelessn00b.comです。

「偽の」TLDや単一ラベルのドメイン名の使用を避ける圧倒的に説得力のある理由がありますが、ルートドメイン（hopelessn00b.com）を私のドメイン名として使用し、corp.hopelessn00b.com代わりにサブドメインを使用するのを避ける同様の説得力のある理由を見つけるのに苦労しています。実際、内部から外部のWebサイトにアクセスするには、A nameDNSレコードが必要www.であり、ブラウザーでWebサイト名の前に入力する必要があるという唯一の正当性が あります。

だから、私は何が欠けていますか？ad.hopelessn00b.comActive Directoryフォレスト名として使用する方がはるかに優れているのはなぜhopelessn00b.comですか？

上司の男は、バック行商で、という名前の新しいADフォレストを作成するために私に行く先を与えた後-念のために、それはニーズが説得力のことを本当に私の雇用者のcorp.hopelessn00b'semployer.com社内ネットワークのために、彼は名前のADフォレストに固執したいですhopelessn00b'semployer.com（外部登録ドメインと同じ）。私は、いくつかの説得力のある理由、またはベストプラクティスがより良いオプションであるという理由を得られることを望んでいます。そのため、彼にそれを納得させます。瞬間。今、私たちの会社のために公共のウェブサイトにアクセスし、内部での「Microsoftのベストプラクティス」とは、それをカットされていないようだ、と私は本当に、本当に、本当にここに誰かを期待しては、より説得力のある何かをしています。

非常に多くの担当者がいました。貴重な私に来てください。

わかりました。したがって、Microsoftは、スプリットホライズンや、何度もリンクしているように作成されたTLDを使用すべきではないことを十分に文書化しています（私のブログをご覧ください！）。これにはいくつかの理由があります。

1. wwwあなたが先に指摘したことが問題。迷惑ですが、契約違反ではありません。

2. パブリックではなく、内部でもアクセス可能なすべての公開サーバーの重複レコードを維持する必要がありますwww。mail.hopelessnoob.com一般的な例です。理想的なシナリオでは、mail.hopelessnoob.comまたはなどの個別の境界ネットワークがありますpublicwebservice.hopelessnoob.com。内部インターフェイスおよび外部インターフェイスを備えたASAなどの一部の構成では、内部と内部のNATまたはスプリットホライズンDNSのいずれかが必要ですが、Webに面するリソースがヘアピンNAT境界の背後にない正当な境界ネットワークを持つ大規模な組織では-これにより、不要な作業が発生します。

3. このシナリオを想像してください-あなたはhopelessnoob.com内部的および外部的です。パートナーとなる会社が呼び出されexample.com、同じことを行います。ADと公的にアクセス可能なDNS名前空間で内部的に地平線を分割します。ここで、サイト間VPNを構成し、信頼のための内部認証がトンネルを通過する一方で、外部のパブリックリソースにアクセスしてインターネットを経由するようにします。信じられないほど複雑なポリシールーティングや内部DNSゾーンの独自のコピーを保持しないと、不可能に近い-これで、維持するDNSレコードの追加セットを作成できました。つまり、あなたの最後でヘアピニングに対処する必要がありますし、その目的、ポリシールーティング/ NAT、およびその他のあらゆる種類のトリック。（私は実際に、継承したADでこの状況にありました）。

4. DirectAccessを展開すると、名前解決ポリシーが大幅に簡素化されます。これは、他のスプリットトンネルVPNテクノロジーにも当てはまります。

これらのいくつかはエッジケースであり、いくつかはそうではありませんが、それらはすべて簡単に回避されます。あなたが最初からこれを行う能力を持っているなら、10年後にこれらの1つにぶつからないように、正しい方法でそれをするかもしれません。

この声明：「本当に、私が見つけることができる唯一の正当化は、内部から外部のWebサイトにアクセスするにはSRV DNSレコードが必要であり、ブラウザでWebサイト名の前にwww。と入力すること」は当てはまりません。

AD DNSサーバーにすべてのパブリックレコードのコピーを保持する必要があることを意味します。これは、特に適切に行わないと問題が発生する可能性があります。一部を見逃すなどです。誰かがftp.companyにアクセスする場合。 comですが、内部DNSでエイリアスを作成するのを忘れている（または適切に自動化していない）ため、社内の人々はパブリックFTPサイトにまったくアクセスできません。

これは、リンク先の質問でかなり具体化されています： Windows Active Directory命名のベストプラクティス？

DNSゾーンの複数のコピーを維持することが、永遠に正しく解決するのが簡単な問題であるなら、私はあなたがやりたいことができると思います。MSがそれを壊す何かを変更するまで。あなたは彼らの推奨事項に従うだけです。

今日は長い回答を作成するために担当者に十分気を配っていません...だから私はそれを短くします。

EvanとMarkが別の方法で納得させるまで、私は以前はsplit-dnで問題なく、何度も実装していました。正直に言って、それができないということではありません...できることであり、いくつかはそれでうまくいくかもしれません（オーバーヘッドとそれのために行われた仕事にもかかわらず）。

数年前に、それを使用しないことで固まった2つの特定のことがありました：

1. 質問で指摘したように、ドメイン名だけで内部ユーザーが外部Webサイトにアクセスできるようにすることはできません。それは、このような大したことだった理由を尋ねるが、我々はせずにブラウザにドメイン名のみを入力することを激怒になるだろう内部のユーザーだったしないwwwADドメインにドメインレコード対応しているため、実際のウェブサイトを立ち上げていないだろうとし、に到達するためのキャッチオールではありませんし、www内部的にすることはできません。
2. Exchangeの問題-Exchange AutoDiscoverは証明書の取得に失敗し、エラーが表示される場合があります。これは、内部と外部の両方で発生する可能性があります。これは、Exchange組織に "外部フォレストメールボックス"を作成し始めたときにさらに明らかになり、彼らは以前と同じ内部DNSを認識しませんでした。

お役に立てば幸いです。