新しいActive Directoryフォレストに名前を付ける-スプリットホライズンDNSが推奨されないのはなぜですか？
うまくいけば 、私たちは すべて知っているActive Directoryフォレストの命名に関する推奨事項 であり、それらは非常に単純です。つまり、1文にまとめることができます。
既存の登録済みドメイン名のサブドメインを使用し、外部で使用されないものを選択します。 たとえば、hopelessn00b.comドメインを組み込んで登録すると、内部ADフォレストの名前はinternal.hopelessn00b.comまたはad.hopelessn00b.comまたはcorp.hopelessn00b.comにする必要があります。
"fake" tlds または single-label domain names の使用を避けるために圧倒的に説得力のある理由がありますが、ルートの使用を避けるために同様に説得力のある理由を見つけるのに苦労していますドメイン（hopelessn00b.com）をドメイン名として使用し、代わりにcorp.hopelessn00b.comなどのサブドメインを使用します。本当に、私が見つけたように思える唯一の正当化は、内部から外部Webサイトにアクセスするには、A name DNSレコードを必要とし、ブラウザでWebサイト名の前にwww.を入力する必要があるということです。問題に関する限り。
では、何が欠けているのですか？ ad.hopelessn00b.comよりもhopelessn00b.comをActive Directoryフォレスト名として使用する方がはるかに優れているのはなぜですか？
記録のためだけに、説得力を必要とするのは本当に私の雇用主です-ボスマンは逆行しており、私に内部ネットワーク用にcorp.hopelessn00b'semployer.comという名前の新しいADフォレストを作成することを許可した後、彼は固執したいと考えていますhopelessn00b'semployer.comという名前のADフォレスト（外部登録ドメインと同じ）。ベストプラクティスがより良い選択肢であるという説得力のある理由が得られることを願っています。そのため、彼にそれを納得させることができます...怒りをやめて、新しい仕事を見つけるよりも、少なくとも瞬間。現時点では、「Microsoftのベストプラクティス」と社内のパブリックWebサイトへのアクセスはそれを削減しているようには見えません。私はreally、really、reallyここに誰かが何かを持っていることを願ってより説得力があります。
非常に多くの担当者が必要でした。 貴重な場所に来てください。
わかりましたので、分割ホライズンや、何度もリンクしているように構成されたTLD（私のブログに叫びましょう！）を使用するべきではないことが、Microsoftによってかなり文書化されています。これにはいくつかの理由があります。
上記で指摘した
wwwの問題。迷惑ですが、取引ブレーカーではありません。wwwだけでなく、内部からもアクセス可能なall公開サーバーの重複レコードを維持することを強制します。mail.hopelessnoob.comは一般的な例です。理想的なシナリオでは、mail.hopelessnoob.comやpublicwebservice.hopelessnoob.comのようなもののために、別の境界ネットワークを用意します。 内部インターフェイスと外部インターフェイスを備えたASAのように の構成では、inside-inside NATまたはsplit-horizon DNSanywayしかし、正当な境界ネットワークを使用し、Webに接続するリソースがヘアピンの背後にない大規模な組織の場合NAT境界-これにより、不要な作業が発生します。このシナリオを想像してみてください-あなたは内部および外部の
hopelessnoob.comです。提携している企業がexample.comと呼ばれている場合、それらは同じことを行います。つまり、ADと、パブリックにアクセス可能なDNS名前空間を使用して、内部的にホライズンを分割します。次に、サイト間VPNを構成し、外部のパブリックリソースにアクセスしてインターネット経由でアクセスしながら、信頼の内部認証がトンネルを通過するようにします。信じられないほど複雑なポリシールーティングや、内部DNSゾーンの独自のコピーを保持しないと、これはほぼ不可能です。これで、維持するDNSレコードの追加セットが作成されました。したがって、あなたはあなたの終わりでヘアピニングとそれらの終わり、ポリシールーティング/ NAT、および他のあらゆる種類のトリックに対処する必要があります。 （私は実際に私が受け継いだADでこの状況にありました）。DirectAccess を展開する場合、名前解決ポリシーが大幅に簡略化されます。これは、他のスプリットトンネルVPNテクノロジーでも同様です。
これらの一部はEdgeケースですが、一部はそうではありませんが、すべて簡単に回避されます。最初からこれを行う能力がある場合は、10年以内にこれらのいずれにも遭遇しないように、正しい方法で行うこともできます。
このステートメント：「本当に、私が見つけることができる唯一の正当化は、内部から外部WebサイトにアクセスするにはSRV DNSレコードが必要であり、ブラウザでWebサイト名の前にwww。と入力することです」というのは正しくありません。
これは、AD DNSサーバーに公開レコードのallのコピーを保持する必要があることを意味します。これを行わないと、特に問題が発生する可能性があります。適切に-一部を逃すなど。誰かがftp.company.comにアクセスしたいが、内部DNSにエイリアスを作成するのを忘れた場合（または適切に自動化しなかった場合）、社内の人々はパブリックFTPにアクセスできません。まったくサイト。
これは、あなたがリンクした質問でかなりうまく具体化されています： Windows Active Directory命名のベストプラクティス？
DNSゾーンの複数のコピーを維持することが、永遠に正しく解決するのが簡単な問題である場合、私はあなたが望むことをできると思います。 MSがそれを壊す何かを変えるまで。あなたはできますただ彼らの推奨に従います。
今日は長い回答を作成するのに担当者のことは気にしていません...それで私はそれを短くしておきます。
以前はsplit-dnsで問題なく、エヴァンとマークが別の方法で私を説得するまで何度もそれを実装していました。正直言って、それができないということではありません...それは可能であり、いくつかはそれでうまくいくかもしれません（オーバーヘッドとそのために行われる作業にもかかわらず）。
それを使用しないことを固めた2つの特定の事柄が私のために数年前に思い付きました：
- 質問で指摘したように、ドメイン名だけで内部ユーザーに外部Webサイトへのアクセスを許可することはできません。なぜそれがそんなに大したことだったのかと聞かないでください。ただし、ドメインレコードだけなので、
wwwなしでドメイン名だけをブラウザに入力しても実際のウェブサイトは表示されないという内部ユーザーがいますADドメインに対応し、wwwに到達するための包括的なものではなく、内部で行うことはできません。 - Exchangeの問題-Exchange AutoDiscoverが証明書の取得に失敗し、エラーが表示される場合があります。これは内部的にも外部的にも起こり得ます。これは、Exchange組織に「外部フォレストメールボックス」を導入したときにさらに明白になり、彼らが持っていたのと同じ内部DNSを表示しませんでした。
お役に立てば幸いです。