Benennen einer neuen Active Directory-Gesamtstruktur - Warum wird Split-Horizon-DNS nicht empfohlen?

23

Hoffentlich wissen wir alle, welche Empfehlungen für die Benennung einer Active Directory-Gesamtstruktur gelten , und sie sind recht einfach. Es kann nämlich in einem einzigen Satz zusammengefasst werden.

Verwenden Sie eine Unterdomäne eines vorhandenen, registrierten Domainnamens und wählen Sie eine aus, die nicht extern verwendet werden soll. Wenn ich beispielsweise die hopelessn00b.comDomäne einbinden und registrieren möchte, sollte meine interne AD-Gesamtstruktur internal.hopelessn00b.comoder ad.hopelessn00b.comoder heißen corp.hopelessn00b.com.

Es gibt überwiegend zwingende Gründe, die Verwendung von "gefälschten" tlds oder Single-Label-Domain-Namen zu vermeiden , aber es fällt mir schwer, ähnlich zwingende Gründe zu finden, um die Verwendung der Root-Domain ( hopelessn00b.com) als Domain-Namen zu vermeiden und corp.hopelessn00b.comstattdessen eine Subdomain wie zu verwenden . Wirklich, die einzige Rechtfertigung, die ich zu finden scheinen kann, ist, dass der Zugriff auf die externe Website von intern aus einen A nameDNS- Eintrag erfordert und www.in einem Browser vor dem Namen der Website eintippt , was für Probleme ziemlich "meh" ist.

Also, was fehle ich? Warum ist es so viel besser, den ad.hopelessn00b.comNamen meiner Active Directory-Gesamtstruktur zu übernehmen hopelessn00b.com?

Nur zur Veranschaulichung: Mein Arbeitgeber muss wirklich überzeugen - der Boss tritt zurück und nachdem er mir die Erlaubnis gegeben hat, eine neue AD-Gesamtstruktur mit dem Namen corp.hopelessn00b'semployer.comfür unser internes Netzwerk zu erstellen , möchte er sich an eine AD-Gesamtstruktur mit dem Namen hopelessn00b'semployer.com( das gleiche wie unsere extern registrierte Domain). Ich hoffe, dass ich einen überzeugenden Grund oder Gründe dafür finden kann, dass die beste Vorgehensweise die bessere Option ist, also kann ich ihn davon überzeugen ... denn es scheint einfacher zu sein, als den Zorn aufzugeben und / oder einen neuen Job zu finden, zumindest für der Moment. Gerade jetzt, „Microsoft Best Practices“ und intern die öffentliche Website für unser Unternehmen den Zugriff auf nicht scheinen zu schneiden, und ich bin wirklich , wirklich , wirklich jemand hier der Hoffnung hat etwas mehr überzeugen.

HopelessN00b
quelle
1
Kleinere Korrekturen - es wäre ein interner A-Datensatz erforderlich, kein SRV-Datensatz für www.
MDMarra
@ HopelessN00b - Mark ist genau richtig mit allem, was ich gesagt habe und mehr. Sein "Partner" -Szenario ist das Sahnehäubchen. Ich hatte nicht das "Vergnügen", in dieses Szenario mit Split-Horizon-DNS zu stoßen. Ich hätte gerade erwähnt, dass es Namensauflösungen in einem VPN zum Kotzen bringt, aber ich habe nicht speziell an DirectAccess gedacht.) Wenn mir etwas einfällt, werde ich es wegwerfen. Ich bin nur entsetzt über das Makework und das Fehlerpotential, das es erzeugt. Das allein ist Grund genug, es nicht zu tun. Am allermeisten ärgern mich immer noch Leute, die sagen, "große Unternehmen tun es, damit es in Ordnung ist" als Ausrede.
Evan Anderson

Antworten:

24

So viel Wiederholung zu haben. Komm zu mir, Schatz.

OK, also ist es von Microsoft ziemlich gut dokumentiert, dass Sie nicht Split-Horizon oder eine erfundene TLD verwenden sollten, wie Sie sie oft verlinkt haben (rufen Sie meinen Blog auf!). Dafür gibt es einige Gründe.

  1. Das wwwProblem, auf das Sie oben hingewiesen haben. Ärgerlich, aber kein Deal Breaker.

  2. Sie müssen doppelte Datensätze für alle öffentlich zugänglichen Server führen, auf die nicht nur intern zugegriffen werden kann www. mail.hopelessnoob.comist ein gängiges Beispiel. In einem idealen Szenario hätten Sie ein separates Umkreisnetzwerk für Dinge wie mail.hopelessnoob.comoder publicwebservice.hopelessnoob.com. Bei einigen Konfigurationen wie ein ASA mit internen und externen Schnittstellen , müssen Sie entweder von innen nach außen nach innen NAT oder Split-Horizon DNS ohnehin aber für größere Organisationen mit einem berechtigten Perimeter - Netzwerk , wo Sie Ihre Web - gerichteten Ressourcen sind nicht hinter einer NAT - Hairpin Grenze - Dies verursacht unnötige Arbeit.

  3. Stellen Sie sich dieses Szenario vor - Sie sind hopelessnoob.comintern und extern. Sie haben ein Unternehmen, mit dem Sie eine Partnerschaft eingehen, example.comund sie tun dasselbe - sie teilen den Horizont intern mit ihrem AD und mit ihrem öffentlich zugänglichen DNS-Namespace auf. Jetzt konfigurieren Sie ein Standort-zu-Standort-VPN und möchten, dass die interne Authentifizierung für die Vertrauensstellung den Tunnel durchquert und gleichzeitig Zugriff auf ihre externen öffentlichen Ressourcen hat, um über das Internet zu kommunizieren. Es ist so gut wie unmöglich, ohne unglaublich kompliziertes Richtlinienrouting oder das Speichern einer eigenen Kopie der internen DNS-Zone. Jetzt haben Sie einen zusätzlichen Satz von DNS-Einträgen erstellt, die verwaltet werden sollen. Also musst du dich an deinem Ende mit Haarnadeln beschäftigen undihr Ende, Policy Routing / NAT und alle Arten von anderen Tricks. (Ich war tatsächlich in dieser Situation mit einer AD, die ich geerbt habe).

  4. Wenn Sie jemals DirectAccess bereitstellen , werden Ihre Richtlinien zur Namensauflösung drastisch vereinfacht - dies gilt wahrscheinlich auch für andere VPN-Technologien mit geteiltem Tunnel.

Einige davon sind Randfälle, andere nicht, aber alle lassen sich leicht vermeiden. Wenn Sie die Fähigkeit haben, dies von Anfang an zu tun, sollten Sie es genauso gut richtig machen, damit Sie in einem Jahrzehnt nicht auf eine davon stoßen.

MDMarra
quelle
1
Großartige Soße. Ich denke 3 und 4 könnten den Deal besiegeln ... aber ich werde es offen lassen, um zu sehen, ob jemand etwas anderes hat. Und ermutige hoffentlich mehr Kostbarkeiten auf deinem Weg. Zwei positive Stimmen für diese Antwort sind ziemlich schwach ... komm schon, Leute. Benötigt murrende Upvotes!
HopelessN00b
2
+1 - Ich liebe es. Kämpfe weiter.
Evan Anderson
8

Diese Aussage: "Wirklich, die einzige Rechtfertigung, die ich zu finden scheinen kann, ist, dass der Zugriff auf die externe Website von intern aus einen SRV-DNS-Eintrag erfordert und die Eingabe von www. Vor dem Namen der Website in einem Browser" nicht wahr ist.

Dies bedeutet, dass Sie eine Kopie aller Ihrer öffentlichen Datensätze auf Ihren AD DNS-Servern aufbewahren müssen, was zu Problemen führen kann, insbesondere wenn Sie dies nicht ordnungsgemäß tun - einige verpassen usw. Wenn jemand zu ftp.company wechseln möchte. com, aber Sie haben vergessen, den Alias ​​im internen DNS zu erstellen (oder ihn nicht richtig automatisiert). Interne Benutzer können die öffentliche FTP-Site überhaupt nicht erreichen.

Dies ist in der Frage, mit der Sie in Verbindung gebracht haben, ziemlich ausführlich dargestellt: Best Practices für die Benennung von Windows Active Directory?

Wenn die Beibehaltung mehrerer Kopien Ihrer DNS-Zonen für immer ein Problem ist, das Sie leicht richtig lösen können, können Sie vermutlich tun, was Sie möchten. Bis MS etwas ändert, das es bricht. Sie könnten einfach ihren Empfehlungen folgen.

mfinni
quelle
Guter Punkt. Natürlich haben wir solche öffentlichen Dienste nicht und lagern unser Webhosting aus, also ... nicht sicher, wie wichtig das sein wird, aber ich kann es der Liste hinzufügen. Vielen Dank.
HopelessN00b
1
Während ich bearbeitete, spiegelt die Art und Weise, wie die öffentliche Internetidentität Ihres Unternehmens heute verwendet wird, möglicherweise nicht genau wider, wie sie in 5 Jahren verwendet wird.
Mfinni
Ja, zukunftssicher ... noch eine gute. Ich wünschte, ich könnte dir noch +1 geben. :)
HopelessN00b
5

Der Reiseleiter ist mir nicht wichtig genug, um heute eine lange Antwort zu erstellen ... also werde ich mich kurz fassen.

Ich war mit Split-DNS in Ordnung und habe es mehrmals implementiert, bis Evan und Mark mich davon überzeugt haben. Es ist ehrlich gesagt NICHT so, dass es nicht gemacht werden kann ... es kann, und einige könnten damit gut zurechtkommen (trotz des Overheads und der dafür geleisteten Arbeit).

Für mich sind vor Jahren zwei spezifische Dinge aufgetaucht, die sich verfestigt haben, ohne sie zu benutzen:

  1. Wie Sie in Ihrer Frage ausgeführt haben, können Sie internen Benutzern nicht erlauben, nur über den Domainnamen auf Ihre externe Website zuzugreifen. Fragen Sie nicht, warum das so eine große Sache war, aber wir hatten interne Benutzer, die sich darüber ärgerten, dass die Eingabe nur des Domainnamens in einen Browser ohne wwwdie eigentliche Website nicht auftauchen würde, da der Domain-Eintrag der AD-Domain und entspricht ist kein Allheilmittel, um dorthin zu gelangen wwwund KANN NICHT intern sein.
  2. Exchange-Probleme - Exchange AutoDiscover kann die Zertifikate möglicherweise nicht abrufen und führt zu einem Fehler. Dies kann sowohl intern als auch extern geschehen. Dies wurde noch deutlicher, als in unserer Exchange-Organisation "Externe Gesamtstruktur-Postfächer" eingerichtet wurden, die nicht das gleiche interne DNS wie wir hatten.

Hoffentlich hilft das.

Der Reiniger
quelle
1
Heh heh ... Irgendwann werden @MDMarra und ich dich genauso denken lassen wie wir.
Evan Anderson
2
Widerstand ist zwecklos ... Ihre AD wird in eine Subdomain Ihrer primären Domain aufgenommen!
Ward - Reinstate Monica
Nebenbei habe ich das WWW-Problem umgangen, indem ich IIS auf allen Domänencontrollern installiert und eine ASP-Umleitungsseite für das WWW erstellt habe. Dies funktioniert eigentlich ziemlich gut, trotz der etwas leichtfertigen Verwendung von IIS.
Cscracker