4
Alte Domain - bedingte DNS-Weiterleitung
Hallochen Gemeinde,
historisch wurden - den damaligen Microsft-Empfehlungen folgend - die Domains firma.de (extern) und firma.local (intern) eingerichtet, wobei die interne Domain zugleich das FQDN-Suffix des internen Active Directory war. Bei der Vorbereitung / dem Test der Systemumstellung von Windows auf Linux zeigte sich, dass der Samba-DC (mit bind_dlz) gewisse Probleme mit der TLD local hat. Unter anderem deswegen, aber nicht nur wurde die interne Domain (/ das AD) in eine Namensvariante transformiert, die einigermaßen "sicher" verspricht, in absehbarer Zeit nicht in eine vergleichbare Situation wie bei der TLD local zu geraten. Jedenfalls zeigte sich während der Transformation, dass das unterschiedliche Konzept der Definition für bedingte Weiterleitungen zwischen Windows-DC und Bind ebenfalls gewisse Tücken / Zickigkeiten provoziert.
Egal wie, wurde zwischenzeitlich gewiss, dass es gelegentlich hilfreich ist, wenn DNS-Anfragen zur alten internen Domain noch aufgelöst werden könnten, z.B. beim Öffnen von alten Dateien hinsichtlich enthaltener Verknüpfungen. Freilich wäre dafür per CName-Eintrag eine Zuweisung auf die neue Domain ausreichend, insbesondere weil gerade die anzusprechenden Linux-Server lediglich von der alten auf die neue Domain "umgehangen" wurden. Dadurch würde außerdem die eigentliche IP-Zuordnung weiterhin nur in der Zone der aktuellen Domain erfolgen.
Der erste Gedanke wäre natürlich über den RSAT-DNS-Manager einfach eine Forward-Zone für die alte Domain anzulegen. CName-Verweise wären somit keine große Sache. Dann könnte Bind aber wieder zickig reagieren, weil wieder eine Domain mit der TLD local gehostet wird.
Über die hosts-Datei sind keine CName-Verweise möglich, weil das nicht deren Gestaltungsansatz ist.
Wenn ich mich recht erinnere, kann bei Bind die local-Problematik durch die Deaktivierung von mDNS "beseitigt" werden. Während das bewusst für die AD-DNS-Server bisher ausgeschlossen wurde, um zukunftsoffen zu bleiben, kann das bei einem isolierten DNS-Server für die alte Domain durchaus realisiert werden.
Demnach wäre an eine bedingte Weiterleitung für diese alte Domain auf einen isolierten DNS-Server zu denken. Würde zudem der Ansatz von CName-Verweisen gewählt, würde das nach meinem Verständnis wohl eine "Rück(weiter)verweisung" an die anfragenden AD-DNS-Server auslösen.
Übrigens würde eine interne Auflösung ein Routing der DNS-Anfragen zur alten Domain an externe DNS-Server unterbinden, was ebenfalls ein gewünschter (Neben)Effekt ist.
Fragen:
Wie löse ich am besten die Problematik, wenn ich die direkte Auflösung der alten local-Domain auf den AD-DNS-Servern vermeiden möchte / muss? Ist der Weg über einen isolierten DNS-Server und CName-Verweisen ein sinnvoller Ansatz oder gibt es bessere / alternative Lösungsansätze?
Mit welchen (Seiten-)Effekten muss ich rechnen, wenn der isolierte DNS-Server lediglich CName-Verweise auf die aktuelle Domain bereithält?
Vielen Dank für Euren Input im Voraus und viele Grüße
HansDampf06
historisch wurden - den damaligen Microsft-Empfehlungen folgend - die Domains firma.de (extern) und firma.local (intern) eingerichtet, wobei die interne Domain zugleich das FQDN-Suffix des internen Active Directory war. Bei der Vorbereitung / dem Test der Systemumstellung von Windows auf Linux zeigte sich, dass der Samba-DC (mit bind_dlz) gewisse Probleme mit der TLD local hat. Unter anderem deswegen, aber nicht nur wurde die interne Domain (/ das AD) in eine Namensvariante transformiert, die einigermaßen "sicher" verspricht, in absehbarer Zeit nicht in eine vergleichbare Situation wie bei der TLD local zu geraten. Jedenfalls zeigte sich während der Transformation, dass das unterschiedliche Konzept der Definition für bedingte Weiterleitungen zwischen Windows-DC und Bind ebenfalls gewisse Tücken / Zickigkeiten provoziert.
Egal wie, wurde zwischenzeitlich gewiss, dass es gelegentlich hilfreich ist, wenn DNS-Anfragen zur alten internen Domain noch aufgelöst werden könnten, z.B. beim Öffnen von alten Dateien hinsichtlich enthaltener Verknüpfungen. Freilich wäre dafür per CName-Eintrag eine Zuweisung auf die neue Domain ausreichend, insbesondere weil gerade die anzusprechenden Linux-Server lediglich von der alten auf die neue Domain "umgehangen" wurden. Dadurch würde außerdem die eigentliche IP-Zuordnung weiterhin nur in der Zone der aktuellen Domain erfolgen.
Der erste Gedanke wäre natürlich über den RSAT-DNS-Manager einfach eine Forward-Zone für die alte Domain anzulegen. CName-Verweise wären somit keine große Sache. Dann könnte Bind aber wieder zickig reagieren, weil wieder eine Domain mit der TLD local gehostet wird.
Über die hosts-Datei sind keine CName-Verweise möglich, weil das nicht deren Gestaltungsansatz ist.
Wenn ich mich recht erinnere, kann bei Bind die local-Problematik durch die Deaktivierung von mDNS "beseitigt" werden. Während das bewusst für die AD-DNS-Server bisher ausgeschlossen wurde, um zukunftsoffen zu bleiben, kann das bei einem isolierten DNS-Server für die alte Domain durchaus realisiert werden.
Demnach wäre an eine bedingte Weiterleitung für diese alte Domain auf einen isolierten DNS-Server zu denken. Würde zudem der Ansatz von CName-Verweisen gewählt, würde das nach meinem Verständnis wohl eine "Rück(weiter)verweisung" an die anfragenden AD-DNS-Server auslösen.
Übrigens würde eine interne Auflösung ein Routing der DNS-Anfragen zur alten Domain an externe DNS-Server unterbinden, was ebenfalls ein gewünschter (Neben)Effekt ist.
Fragen:
Wie löse ich am besten die Problematik, wenn ich die direkte Auflösung der alten local-Domain auf den AD-DNS-Servern vermeiden möchte / muss? Ist der Weg über einen isolierten DNS-Server und CName-Verweisen ein sinnvoller Ansatz oder gibt es bessere / alternative Lösungsansätze?
Mit welchen (Seiten-)Effekten muss ich rechnen, wenn der isolierte DNS-Server lediglich CName-Verweise auf die aktuelle Domain bereithält?
Vielen Dank für Euren Input im Voraus und viele Grüße
HansDampf06
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 4238178454
Url: https://administrator.de/contentid/4238178454
Printed on: April 27, 2024 at 18:04 o'clock
4 Comments
Latest comment
Moin,
Gruß,
Dani
Unter anderem deswegen, aber nicht nur wurde die interne Domain (/ das AD) in eine Namensvariante transformiert, die einigermaßen "sicher" verspricht, in absehbarer Zeit nicht in eine vergleichbare Situation wie bei der TLD local zu geraten.
Ich empfehle euch auf jeden Fall eine .de Domain dafür zunehmen. Hierbei ist nur noch unterscheiden, ob firma.de in Verbindung mit Split-DNS eingerichtet wird oder eine 0815 Domain die nicht direkt im Zusammenhang mit der Firma steht. Damit bist du langfristig auf der sicheren Seite. Unbedingt in dem Prozess auch das Thema Markenschutz denken.Jedenfalls zeigte sich während der Transformation, dass das unterschiedliche Konzept der Definition für bedingte Weiterleitungen zwischen Windows-DC und Bind ebenfalls gewisse Tücken / Zickigkeiten provoziert.
Die da wären?Demnach wäre an eine bedingte Weiterleitung für diese alte Domain auf einen isolierten DNS-Server zu denken. Würde zudem der Ansatz von CName-Verweisen gewählt, würde das nach meinem Verständnis wohl eine "Rück(weiter)verweisung" an die anfragenden AD-DNS-Server auslösen.
Klingt erst mal gut, aber der Teufel liegt im Detail. Geht es ausschließlich um Webserver, so ist der Ansatz grundsätzlich umsetzbar. Evtl. müssen noch die SSL-Zertifikate neu ausgestellt werden. Wenn es aber um Dienste wir SMB, Exchange, etc. geht wirst du nicht weit kommen. Da müssten nämlich noch die Service Pincial Names (SPNs) der Computerobjekte erweitert werden. Um welche Art von Dienste geht es?Wie löse ich am besten die Problematik, wenn ich die direkte Auflösung der alten local-Domain auf den AD-DNS-Servern vermeiden möchte / muss?
Was möchtest du damit erreichen, was der autoritive ad-integrierte DNS-Server nicht kann?!Gruß,
Dani
Zitat von @Dani:
Um die Aufteilung / Differenzierung zwischen externer und interner Domain geht es mir mit meiner Frage nicht, so dass Split-DNS für mich keine Rolle spielt. Ebenso will ich das weite Feld, ob eine offizielle TLD (wie .de & Co.) für die interne Domain genutzt werden sollte oder nicht, hier nicht weiter betreten.Unter anderem deswegen, aber nicht nur wurde die interne Domain (/ das AD) in eine Namensvariante transformiert, die einigermaßen "sicher" verspricht, in absehbarer Zeit nicht in eine vergleichbare Situation wie bei der TLD local zu geraten.
Ich empfehle euch auf jeden Fall eine .de Domain dafür zunehmen. Hierbei ist nur noch unterscheiden, ob firma.de in Verbindung mit Split-DNS eingerichtet wird oder eine 0815 Domain die nicht direkt im Zusammenhang mit der Firma steht. Damit bist du langfristig auf der sicheren Seite. Unbedingt in dem Prozess auch das Thema Markenschutz denken.Jedenfalls zeigte sich während der Transformation, dass das unterschiedliche Konzept der Definition für bedingte Weiterleitungen zwischen Windows-DC und Bind ebenfalls gewisse Tücken / Zickigkeiten provoziert.
Die da wären?Demnach wäre an eine bedingte Weiterleitung für diese alte Domain auf einen isolierten DNS-Server zu denken. Würde zudem der Ansatz von CName-Verweisen gewählt, würde das nach meinem Verständnis wohl eine "Rück(weiter)verweisung" an die anfragenden AD-DNS-Server auslösen.
Klingt erst mal gut, aber der Teufel liegt im Detail. Geht es ausschließlich um Webserver, so ist der Ansatz grundsätzlich umsetzbar. Evtl. müssen noch die SSL-Zertifikate neu ausgestellt werden. Wenn es aber um Dienste wir SMB, Exchange, etc. geht wirst du nicht weit kommen. Da müssten nämlich noch die Service Pincial Names (SPNs) der Computerobjekte erweitert werden. Um welche Art von Dienste geht es?Überdies kommen ausschließlich Clients/Server, die Member der neuen Domain oder ohnehin nicht domänengebunden sind, in Betracht, eine DNS-Auflösung der alten Domain anzufragen. In den meisten Fällen würde der CName-Verweis zu nichts anderem führen, als wenn der alte Link auf den aktuellen FQDN in der neuen Domain verweisen würde.
Sofern alte Links lediglich auf den Hostnamen und nicht auf den FQDN lauten, wird das bereits durch geeignete CName-Einträge in der neuen Domain abgefangen, falls der betreffende Host nicht mehr aktiv sein sollte. Relevant für die hiesige Fragestellung sind also nur diejenigen Links, bei denen der FQDN der alten Domain verwendet wurde.
Wie löse ich am besten die Problematik, wenn ich die direkte Auflösung der alten local-Domain auf den AD-DNS-Servern vermeiden möchte / muss?
Was möchtest du damit erreichen, was der autoritive ad-integrierte DNS-Server nicht kann?!Freilich könnte dieser DNS-Server anstatt - wie angedacht - auf einem dedizierten Linux-Server als Forwarder in der Firewall(/Router) platziert werden, der lediglich die alte local-Domain selbst hostet und alles weitere an externe DNS-Server weiterleitet. Die AD-DNS-Server hätten dann nur noch einen einzigen Forwarder-Eintrag, nämlich die Firewall - alle anderen Forwarder-Einträge würden somit ausschließlich auf der Firewall gepflegt werden. Indes ist der Themenkomplex Firewall(/Router) ein zukünftiges Projekt ... Daher ist derzeit offen, ob dort DNS-Server-Fähigkeiten integriert werden würden.
Der alternative Weg über die Firewall setzt natürlich voraus, dass nicht wieder Bind als DNS-Programm zum Zuge kommt und sich dann dieselbe mDNS-local-Problematik stellen würde, wenn mDNS auf der Firewall nicht deaktiviert werden soll.
Gerade deswegen erscheint mir der angedachte Ansatz, einen internen dedizierten DNS-Server zu verwenden, der nur die alte Domain hostet, als sinnvoll. Die leidige mDNS-local-Problematik lässt sich dort gezielt und sicher ausschalten und die Firewall(/Router) wird nicht mit zusätzlichen Aufgaben belegt.
Ich weiß: Es gibt durchaus Design-Empfehlungen, die die Firewall(/Router) als zentralen Forwarder vorsehen, auf den die internen AD-DNS-Server ausschließlich referenzieren. Bei der bisherigen Design-Abwägung ist dieser Ansatz hier jedenfalls nicht befürwortet worden.
Viele Grüße
HansDampf06
PS: Vielleicht noch einmal zum besseren Verständnis anders formuliert:
Wie würde der isolierte DNS-Server eine DNS-Anfrage, die er von einem AD-DNS-Server bekommt, überhaupt beantworten, wenn er den passenden CName-Eintrag in der alten Domain gefunden hat? Würde er die DNS-Anfrage lediglich direkt mit dem Ergebnis aus dem CName-Eintrag beantworten oder würde er - davon gehe ich aus - nunmehr die Anfrage an den dazu passenden DNS-Server weiterleiten?
Kann die bedingte Weiterleitung einer DNS-Anfrage zur alten Domain auf einen isolierten DNS-Server zu ungewollten Effekten führen, wenn in der Zone der alten Domain die dortigen CName-Einträge wiederum auf die neue Domain verweisen und somit auf dem isolierten DNS-Server zu einer Weiterleitung an die anfragenden AD-DNS-Server mit der Zone der neuen Domain führen?
Könnten das unliebsame Schleifeneffekte sein? Ich würde das eher verneinen.
Ist das aus etwaigen Sicherheitsüberlegungen heraus ein "riskantes" Design?
Gibt es andere Überlegungen, die ein solches Design fraglich erscheinen lassen?
Gäbe es alternative Ansätze? Mir würde als Alternative eigentlich nur der bereits erwähnte Firewall-Ansatz einfallen.
Wie würde der isolierte DNS-Server eine DNS-Anfrage, die er von einem AD-DNS-Server bekommt, überhaupt beantworten, wenn er den passenden CName-Eintrag in der alten Domain gefunden hat? Würde er die DNS-Anfrage lediglich direkt mit dem Ergebnis aus dem CName-Eintrag beantworten oder würde er - davon gehe ich aus - nunmehr die Anfrage an den dazu passenden DNS-Server weiterleiten?
Kann die bedingte Weiterleitung einer DNS-Anfrage zur alten Domain auf einen isolierten DNS-Server zu ungewollten Effekten führen, wenn in der Zone der alten Domain die dortigen CName-Einträge wiederum auf die neue Domain verweisen und somit auf dem isolierten DNS-Server zu einer Weiterleitung an die anfragenden AD-DNS-Server mit der Zone der neuen Domain führen?
Könnten das unliebsame Schleifeneffekte sein? Ich würde das eher verneinen.
Ist das aus etwaigen Sicherheitsüberlegungen heraus ein "riskantes" Design?
Gibt es andere Überlegungen, die ein solches Design fraglich erscheinen lassen?
Gäbe es alternative Ansätze? Mir würde als Alternative eigentlich nur der bereits erwähnte Firewall-Ansatz einfallen.
Moin,
wir haben deine Kommentare in den letzten Wochen mehfach gelesen. Leider können wir deinen Ausführungen und damit verbundenen Fragen nach wie vor leider nicht folgen - sowohl logisch (was ist wo wie gegeben) als auch inhaltlich (was ist das Ziel).
Da auch niemand anders bis dato geantwortet hat und du weiterhin Antworten möchtest, schlage ich vor, dass du das Vorhaben nochmals umformulierst bzw. besser umschreibst.
Gruß,
Dani
wir haben deine Kommentare in den letzten Wochen mehfach gelesen. Leider können wir deinen Ausführungen und damit verbundenen Fragen nach wie vor leider nicht folgen - sowohl logisch (was ist wo wie gegeben) als auch inhaltlich (was ist das Ziel).
Da auch niemand anders bis dato geantwortet hat und du weiterhin Antworten möchtest, schlage ich vor, dass du das Vorhaben nochmals umformulierst bzw. besser umschreibst.
Gruß,
Dani