speer 19 Geschrieben 6. November Melden Teilen Geschrieben 6. November Guten Abend an alle, bei uns stehen AD seitig Änderungen an und die wollte ich in meiner kleinen AD-Testumgebung erstmals nachstellen. Bei der DNS Forwardzone steh ich gerade im Wald. Meine AD Domäne heisst: example.local Im DNS ist die Forward-Zone: example.local vorhanden. Dort ist aktuell ein Eintrag eines Server nach dem domain -join enthalten (server.example.local). Nun zum eigentlichen Verständnisproblem. Füge ich einen Alias mit Namen: abc.server.example.local in die Forwardzone example.local hinzu, dann funktioniert die Namensauflösung wie gewohnt, keine Fehlermeldungen. Meine Kollegen haben bisher immer eine separate Forward-Zone eingerichtet und dort die A bzw. CNAME eingetragen. Hat obiges schon immer mit jeder Windows Server Version funktioniert? Zitieren Link zu diesem Kommentar
NorbertFe 2.032 Geschrieben 6. November Melden Teilen Geschrieben 6. November Ja das hat afair schon immer so funktioniert. Ist ja eigentlich auch logisch. Denn ob ich eine Zone alias.example.local nach dem Server frage oder ob ich einen host Server.alias in der Zone example.local suche ist erstmal egal. Den Unterschied zwischen Zone und Host/alias kann man für dieses einfache Beispiel mal vernachlässigen. Zitieren Link zu diesem Kommentar
cj_berlin 1.313 Geschrieben 7. November Melden Teilen Geschrieben 7. November (bearbeitet) Moin, je nachdem, wofür der Alias benötigt wird, gibt es sehr wohl einen Unterschied - insbesondere, wenn Zertifikate im Spiel sind. Ich rufe app.myapps.domain.de, welche auf server.domain.de läuft. wenn das ganze als A record namens app in der Zone myapps.domain.de abgebildet ist, ruft der Client app.myapps.domain.de auf wenn das ganze als CNAME record abgebildet ist, der auf server.domain.de zeigt, wird server.domain.de aufgerufen (nicht immer - aber bspw. Outlook, auch die meisten Browser) Wenn also auf dem Server ein Zertifikat präsentiert wird, das nur app.myapps.domain.de im SAN hat, wird CNAME möglicherweise nicht funktionieren und vice versa. bearbeitet 7. November von cj_berlin Zitieren Link zu diesem Kommentar
toao 4 Geschrieben 7. November Melden Teilen Geschrieben 7. November (bearbeitet) 16 hours ago, speer said: Meine Kollegen haben bisher immer eine separate Forward-Zone eingerichtet und dort die A bzw. CNAME eingetragen. Hi, ohne mehr Informationen über den jeweiligen Zweck (use case) zu haben, lehne ich mich mal aus dem Fenster..., einige der separat erstellten Forward-Lookup Zonen bei euch hören sich nach "overkill" an. 1-2 Gründe für das Anlegen einer separaten Forward-Lookup Zone könnten sein: - Delegierung der Administration der DNS RR - "Dynamic updates" Konfiguration für die separate Zone muss angepasst werden und etwaige andere Gründe. Funktional ist es sicherlich bei Euch mit den separaten ForwardLookupZonen (sonst würde bestimmt schon jemand meckern :D), nur wäre ein gewisser "Standard" zu definieren schon hilfreich um einen "unnötigen" Wulst and ForwardLookupZonen zu verhindern als auch eventuell durch (versehentlich) verkehrte Konfigurationen der einzelnen ForwardLookupZonen, sich mögliche Probleme ins Haus zu holen. Gruß, toao Ps.: Denke bitte bei CNAME DNS RR an den Kerberos Kontext (richtigen SPN zu registrieren). bearbeitet 7. November von toao Zitieren Link zu diesem Kommentar
speer 19 Geschrieben 15. November Autor Melden Teilen Geschrieben 15. November Hallo zusammen, vielen Dank für die ausführlichen Antworten. Muss auf meine Todo Liste das Thema DNS aufnehmen. :) Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.