7
DNSSec im Windows Netzwerk
Hallo Leute,
DNSSec ist ein Thema, was ich schon seit Wochen/Monaten/Jahren vor mich her schiebe.
Jetzt bin ich mal so weit gekommen und habe eine kleine Testinstallation zusammengestellt. Um es so nah wie möglich an unseren internen Strukturen zu testen, habe ich einen Windows Server 2012R2 Domänencontroller (natürlich inkl. DNS) installiert.
Es gibt ein paar Anleitungen im Netz, die einem die grundlegende Implementierung von DNSSec in Windows-DNS-Servern erläutern.
Kurz Zusammengefasst:
1) In den Optionen "DNSSEC-Überprüfung für Remoteantworten aktivieren" gesetzt
2) dnscmd.exe /RetrieveRootTrustAnchors /f ausgeführt
3) Interne-Zone "test.local" signiert.
4) Zumindest intern Läuft alles rund
über das BIND-Tools "Dig" konnte ich feststellen, dass intern alle Anfragen über DNSSec abgewickelt werden. Auch Anfragen an Internetadressen z.B. "google.de" o.ä. funktionieren über DNSSec (In diesem Fall nutzt der Domänencontroller die DNS-Stammhinweise bzw. DNS-Root-Server)
Zum Problem:
Dieses Testsystem möchte ich jetzt näher an unsere produktive Struktur bringen und habe diverse bedingte Weiterleitungen hinzugefügt, die wir im Betrieb benötigen (Beispiel: Produktiv sind wir per VPN an ein Rechenzentrum angebunden. Über die bedingte Weiterleitung "rechenzentrum.intern" lösen wir IPs des Rechenzentrums auf).
Noch dazu verwenden unsere produktiven DNS-Server unsere Sophos-UTM als Resolver. Alle DNS-Anfragen werden also an die UTM geschickt und nicht, wie im Testsystem, direkt über die Root-Server aufgelöst.
In dieser Konstellation kann ich demnach keine Anfragen mehr nach "Außen" senden. Alle DNS-Anfragen, außer interne die lokale Domäne test.local, werden mit einem "Server Fail" quittiert. Nachweislich haben weder die DNS-Server des Rechenzentrums, noch die Sophos-UTM DNSSec aktiviert. Wenn ich in den Serveroptionen die DNSSEC-Überprüfung wieder deaktiviere, klappt alles. Mein Testsystem unterhält sich demnach nur mit "DNSSec-Servern" - normalerweise sollte doch ein Fallback auf "normales DNS" durchgeführt werden, wenn der jeweilige Server kein DNSSec unterstützt, oder habe ich (bzw. Microsoft) da was falsch verstanden?
DNSSec ist ein Thema, was ich schon seit Wochen/Monaten/Jahren vor mich her schiebe.
Jetzt bin ich mal so weit gekommen und habe eine kleine Testinstallation zusammengestellt. Um es so nah wie möglich an unseren internen Strukturen zu testen, habe ich einen Windows Server 2012R2 Domänencontroller (natürlich inkl. DNS) installiert.
Es gibt ein paar Anleitungen im Netz, die einem die grundlegende Implementierung von DNSSec in Windows-DNS-Servern erläutern.
Kurz Zusammengefasst:
1) In den Optionen "DNSSEC-Überprüfung für Remoteantworten aktivieren" gesetzt
2) dnscmd.exe /RetrieveRootTrustAnchors /f ausgeführt
3) Interne-Zone "test.local" signiert.
4) Zumindest intern Läuft alles rund
über das BIND-Tools "Dig" konnte ich feststellen, dass intern alle Anfragen über DNSSec abgewickelt werden. Auch Anfragen an Internetadressen z.B. "google.de" o.ä. funktionieren über DNSSec (In diesem Fall nutzt der Domänencontroller die DNS-Stammhinweise bzw. DNS-Root-Server)
Zum Problem:
Dieses Testsystem möchte ich jetzt näher an unsere produktive Struktur bringen und habe diverse bedingte Weiterleitungen hinzugefügt, die wir im Betrieb benötigen (Beispiel: Produktiv sind wir per VPN an ein Rechenzentrum angebunden. Über die bedingte Weiterleitung "rechenzentrum.intern" lösen wir IPs des Rechenzentrums auf).
Noch dazu verwenden unsere produktiven DNS-Server unsere Sophos-UTM als Resolver. Alle DNS-Anfragen werden also an die UTM geschickt und nicht, wie im Testsystem, direkt über die Root-Server aufgelöst.
In dieser Konstellation kann ich demnach keine Anfragen mehr nach "Außen" senden. Alle DNS-Anfragen, außer interne die lokale Domäne test.local, werden mit einem "Server Fail" quittiert. Nachweislich haben weder die DNS-Server des Rechenzentrums, noch die Sophos-UTM DNSSec aktiviert. Wenn ich in den Serveroptionen die DNSSEC-Überprüfung wieder deaktiviere, klappt alles. Mein Testsystem unterhält sich demnach nur mit "DNSSec-Servern" - normalerweise sollte doch ein Fallback auf "normales DNS" durchgeführt werden, wenn der jeweilige Server kein DNSSec unterstützt, oder habe ich (bzw. Microsoft) da was falsch verstanden?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 427269
Url: https://administrator.de/forum/dnssec-im-windows-netzwerk-427269.html
Ausgedruckt am: 22.12.2024 um 07:12 Uhr
7 Kommentare
Neuester Kommentar
Moin,
Du kannst ganz einfach eine Gegenprobe machen. Zuerst führe eine Abfrage per Powershell auf einen FQDN durch:
Die Abfrage wird einen Fehler ausgeben.
Lösche die bedingte Weiterleitung für rz.intra und lege diese als Forward-Zone im DNS-Server an. Anschließend noch 2-3 A-Einträge als Referenz. Wiederhole anschließend die Abfrabe nochmals. Als Ergebnis erhältest du die IP-Adresse.
Gruß,
Dani
P.S. Das nächste Problem
Noch dazu verwenden unsere produktiven DNS-Server unsere Sophos-UTM als Resolver. Alle DNS-Anfragen werden also an die UTM geschickt und nicht, wie im Testsystem, direkt über die Root-Server aufgelöst.
Könnte das hier für dich zutreffen?In dieser Konstellation kann ich demnach keine Anfragen mehr nach "Außen" senden. Alle DNS-Anfragen, außer interne die lokale Domäne test.local, werden mit einem "Server Fail" quittiert.
Das Problem von (Conditional) Forwards mit DNSSEC ist, dass TLDs wie .local oder .intra nicht existent sind. Ich habe allerdings das passende RFC noch nicht gefunden.Du kannst ganz einfach eine Gegenprobe machen. Zuerst führe eine Abfrage per Powershell auf einen FQDN durch:
resolve-dnsname meldeportal.rechenzentrum.intra -Server 127.0.0.1 -DnssecOkLösche die bedingte Weiterleitung für rz.intra und lege diese als Forward-Zone im DNS-Server an. Anschließend noch 2-3 A-Einträge als Referenz. Wiederhole anschließend die Abfrabe nochmals. Als Ergebnis erhältest du die IP-Adresse.
Gruß,
Dani
P.S. Das nächste Problem
Zitat von @Dani:
Moin,
Moin,
Noch dazu verwenden unsere produktiven DNS-Server unsere Sophos-UTM als Resolver. Alle DNS-Anfragen werden also an die UTM geschickt und nicht, wie im Testsystem, direkt über die Root-Server aufgelöst.
Könnte das hier für dich zutreffen?Zumindest teilweise...wenn ich es richtig verstanden habe geht es im Artikel um spezielle Domains. Bei uns geht gar nichts...zumindest habe ich 5-6 Abfragen gemacht die mit "Server fail" quittiert wurden.
In dieser Konstellation kann ich demnach keine Anfragen mehr nach "Außen" senden. Alle DNS-Anfragen, außer interne die lokale Domäne test.local, werden mit einem "Server Fail" quittiert.
Das Problem von (Conditional) Forwards mit DNSSEC ist, dass TLDs wie .local oder .intra nicht existent sind. Ich habe allerdings das passende RFC noch nicht gefunden.Das heißt, dass die "Chain of Trust" nicht hergestellt werden kann oder wie muss ich das verstehen? Im Prinzip ist DNSSec im "privaten/internen" Bereich nicht durchführbar?
Man sieht es ja relativ schön per Wireshark:
Nr.: 10 + 11 stellt die normale Anfrage inkl. Antwort dar. Bei der restlichen UDP-Kommunikation versucht er die Chain of Trust aufzubauen...schlägt natürlich fehl weil er ja schon in Zeile 13 gesagt bekommt "local kenn ich nicht". Die Parent-Zone von .local ist <Root>. Demnach müsste mir die IANA meinen DNSKEY signieren um die Chain of Trust nicht zu durchbrechen. Verstehe ich das richtig?
Aber warum macht der Server überhaupt die DNSSec validierung? In der ersten Abfrage müsste er doch schon checken, ob die Zone überhaupt validiert werden kann - das ist hier nicht der Fall, weil in die angefragte Zone nicht über DNSSec abgesichert wurde.
Du kannst ganz einfach eine Gegenprobe machen. Zuerst führe eine Abfrage per Powershell auf einen FQDN durch:
Die Abfrage wird einen Fehler ausgeben.
Lösche die bedingte Weiterleitung für rz.intra und lege diese als Forward-Zone im DNS-Server an. Anschließend noch 2-3 A-Einträge als Referenz. Wiederhole anschließend die Abfrabe nochmals. Als Ergebnis erhältest du die IP-Adresse.
resolve-dnsname meldeportal.rechenzentrum.intra -Server 127.0.0.1 -DnssecOkLösche die bedingte Weiterleitung für rz.intra und lege diese als Forward-Zone im DNS-Server an. Anschließend noch 2-3 A-Einträge als Referenz. Wiederhole anschließend die Abfrabe nochmals. Als Ergebnis erhältest du die IP-Adresse.
Ähm, soll das jetzt einfach das Problem verdeutlichen bzw. beweisen oder stellt das eine, für dich, machbare Lösung dar? Wenn ich eine Forward-Zone anlege muss ich diese ja auch selbst pflegen...das will ich ja eher nicht, wenn sich mal Adressen ändern oder irgendwas dazu kommt...
Gruß Zurück
Moin,
Alternativ nicht die IP-Adresse von Sophos eintragen sondern direkt zum Beispiel Google oder Quad9, welche beide DNSSEC inzwischen unterstützen. Das empfehle ich dir sowieso, damit die Kette durchgängig mit DNSSEC gesichert ist. Sonst macht es fast keinen Sinn.
a) um primäre DNS-Zonen im LAN geht, welche selbst verwalten werden.
b) bedingte Weiterleitungen gibt, welche evtl. inoffzielle TLDs nutzen.
c) Alle Komponenten im LAN mit DNSSEC klar kommen.
Gruß,
Dani
P.S. Wir sammeln seit knapp 10 Monaten alle Probleme und Auffälligkeiten. Einiges konnten wir selbst herausfinden, manches ist nach wie vor unklar. Am Ende wird es ein dickes Ticket beim Hersteller. Die Umsetzung ist für uns auf Ende Jahr angesetzt. Mal schauen, ob's klappt.
Bei uns geht gar nichts...zumindest habe ich 5-6 Abfragen gemacht die mit "Server fail" quittiert wurden.
Das Community Forum und KB von Sophos sind beim Thema DNSSEC nicht wirklich hilfreich. Dort habe ich leider nur Aussagen wie nicht unterstützt, Frage unbeantwortet oder den Beitrag oben gefunden. Hilfe für Kunden sieht anders aus. Ich kanns auch bei uns leider nicht nachstellen, weil wir inzwischen nichts mehr von Sophos haben. Am Besten Support Ticket eröffnen und hoffen, einen kompetenten Techniker zu bekommen.Alternativ nicht die IP-Adresse von Sophos eintragen sondern direkt zum Beispiel Google oder Quad9, welche beide DNSSEC inzwischen unterstützen. Das empfehle ich dir sowieso, damit die Kette durchgängig mit DNSSEC gesichert ist. Sonst macht es fast keinen Sinn.
Im Prinzip ist DNSSec im "privaten/internen" Bereich nicht durchführbar?
Doch, natürlich. Man muss unserer Tests/Recherchen nach unterscheiden, ob esa) um primäre DNS-Zonen im LAN geht, welche selbst verwalten werden.
b) bedingte Weiterleitungen gibt, welche evtl. inoffzielle TLDs nutzen.
c) Alle Komponenten im LAN mit DNSSEC klar kommen.
Die Parent-Zone von .local ist <Root>. Demnach müsste mir die IANA meinen DNSKEY signieren um die Chain of Trust nicht zu durchbrechen. Verstehe ich das richtig?
Äh Joa. Was wahrscheinlich nicht passieren wird. Denn die TLD .local ist z.B. offziell für Multicast DNS Themen vorgesehen.Aber warum macht der Server überhaupt die DNSSec validierung?
Gute Frage. Wir haben bis dato die Theorie, dass der Microsoft DNS-Server in der Art der Weiterleitung unterscheidet. Du kannst temporär testweiße die DNS-Server der Zone für die bedingte Weiterleitung als Weiterleitung des DNS-Servers eintragen. Natürlich nicht vergessen, die bedingte Weiterleitung zu löschen. Dann klappt die DNS-Auflösung in Richtung RZ auch mit aktivierten DNSSEC.Ähm, soll das jetzt einfach das Problem verdeutlichen bzw. beweisen oder stellt das eine, für dich, machbare Lösung dar?
Es soll dir auf einfachen Wege zeigen, wie Microsoft bzw. der DNS-Server unterscheidet. Ob es für dich eine Lösung ist, weiß ich nicht. Für uns war es defintiv Keine. das will ich ja eher nicht, wenn sich mal Adressen ändern oder irgendwas dazu kommt...
Wenn du Outbound Firewalling betreibst, müsstest du sowieso jede Änderung einer IP-Adresse auf der Firewall konfiguieren. Gruß,
Dani
P.S. Wir sammeln seit knapp 10 Monaten alle Probleme und Auffälligkeiten. Einiges konnten wir selbst herausfinden, manches ist nach wie vor unklar. Am Ende wird es ein dickes Ticket beim Hersteller. Die Umsetzung ist für uns auf Ende Jahr angesetzt. Mal schauen, ob's klappt.
Zitat von @Dani:
Moin,
Moin,
Bei uns geht gar nichts...zumindest habe ich 5-6 Abfragen gemacht die mit "Server fail" quittiert wurden.
Das Community Forum und KB von Sophos sind beim Thema DNSSEC nicht wirklich hilfreich. Dort habe ich leider nur Aussagen wie nicht unterstützt, Frage unbeantwortet oder den Beitrag oben gefunden. Hilfe für Kunden sieht anders aus. Ich kanns auch bei uns leider nicht nachstellen, weil wir inzwischen nichts mehr von Sophos haben. Am Besten Support Ticket eröffnen und hoffen, einen kompetenten Techniker zu bekommen.Das habe ich auch schon gemerkt...
Alternativ nicht die IP-Adresse von Sophos eintragen sondern direkt zum Beispiel Google oder Quad9, welche beide DNSSEC inzwischen unterstützen. Das empfehle ich dir sowieso, damit die Kette durchgängig mit DNSSEC gesichert ist. Sonst macht es fast keinen Sinn.
Mhm...naja wir haben uns irgendwann mal gesagt: "alles über das Sicherheitsgateway nach außen leiten - dafür ist's gekauft worden"...Es ist auch laut Sophos Best Practice (logischerweise) alles über deren Appliance ablaufen zu lassen...
Im Prinzip ist DNSSec im "privaten/internen" Bereich nicht durchführbar?
Doch, natürlich. Man muss unserer Tests/Recherchen nach unterscheiden, ob esa) um primäre DNS-Zonen im LAN geht, welche selbst verwalten werden.
b) bedingte Weiterleitungen gibt, welche evtl. inoffzielle TLDs nutzen.
c) Alle Komponenten im LAN mit DNSSEC klar kommen.
Irgendwie ist das ein ziemlicher Mix aus doofen Abhängigkeiten. Einzeln gesehen funktionieren die jeweiligen Lösungen der Hersteller ganz gut, aber im Zusammenspiel wiederum nicht! Das mit den bedingten Weiterleitungen wird man ja im Prinzip nur in den Griff bekommen, wenn komplett auf inoffizielle TLDs verzichtet wird. Ist man also Besitzer von "unternehmen.de" müsste man beispielsweise für die interne Active Directory die Zone intern.unternehmen.de verwenden. Der Domainanbieter (z.B. 1und1) müsste dann ja auch noch zusätzlich den internen DNSKEY signieren und in der Zone "unternehmen.de" veröffentlichen, damit dort auch wieder die Chain-of-Trust eingehalten werden kann. Das muss dann ja auf der ganzen Welt so praktiziert werden...so würden auch die internen, bedingten Weiterleitungen mit DNSSec abgesichert werden - ziemlich viel Aufwand wie ich finde inkl. zusätzlicher Abhängigkeiten die nicht im eigenen Einflussbereich liegen.
Wie oben angesprochen wollen wir den ausgehenden Verkehr über die Sophos abfackeln. Trotzdem bin ich deinem Rat gefolgt und lasse über die normalen Stammhinweise auflösen. Wie erwartet funktioniert die Auflösung von Adressen im Internet einwandfrei (Die bedingten Weiterleitungen bringen logischerweise immer noch Fehler). Soweit so gut...Allerdings macht es jetzt nur Sinn, wenn möglichst alle Geräte DNSSec verwenden. Windows macht es uns leicht -> GPO für die interne Domain erstellt und fertig.
Weiterhin macht aber die Sophos wieder "Stress": Aktiviere ich jetzt auch die DNSSec-Validierung auf der Sophos, schlägt der SSO der Proxy-Komponente fehl. Die Sophos bekommt keine validen Information von der internen AD, da die DNS-Auflösung hier mit der Fehlermeldung "broken chain of trust" verworfen wird. Ich gehe jetzt einfach davon aus, dass die Sophos signierte Informationen von den internen DNS-Servern erhält, diese aber nicht validieren kann, weil die interne Domäne ebenfalls eine inoffizielle TLD im Namen trägt, sodass die Chain-of-Trust nicht aufgebaut werden kann.
Testweise habe ich die Signatur der internen Zone wieder entfernt, sodass unsere DNS-Server für die eigene Zone keine DNSSec-Signaturen ausliefern. Das Problem mit der Sophos besteht weiter -> "broken chain of trust" obwohl eigentlich von den internen Servern nichts signiertes mehr ankommen kann - wieso das?!
Die Parent-Zone von .local ist <Root>. Demnach müsste mir die IANA meinen DNSKEY signieren um die Chain of Trust nicht zu durchbrechen. Verstehe ich das richtig?
Äh Joa. Was wahrscheinlich nicht passieren wird. Denn die TLD .local ist z.B. offziell für Multicast DNS Themen vorgesehen.Denke ich auch
...Aber warum macht der Server überhaupt die DNSSec validierung?
Gute Frage. Wir haben bis dato die Theorie, dass der Microsoft DNS-Server in der Art der Weiterleitung unterscheidet. Du kannst temporär testweiße die DNS-Server der Zone für die bedingte Weiterleitung als Weiterleitung des DNS-Servers eintragen. Natürlich nicht vergessen, die bedingte Weiterleitung zu löschen. Dann klappt die DNS-Auflösung in Richtung RZ auch mit aktivierten DNSSEC.siehe oben...
---
Zusammengefasst empfinde ich die Einführung von durchgehendem DNSSec aufgrund von mangelnder Unterstützung seitens der Hersteller als extrem schwierig (siehe beispielsweise die unverständlichen Validierungsversuche von bedingten Weiterleitungen, obwohl nachweislich kein DNSSec von den anzufragenden Servern bereitgestellt wird)
Moin,
Es geht euch wohl darum, keine großen Forwards zu haben sondern so viel wie möglich auf dem Gerät zu terminieren.
Ich bin gespannt, ob sich noch weitere Kollegen finden lassen, die sich mit dem Thema auseinandersetzen.
Gruß,
Dani
Mhm...naja wir haben uns irgendwann mal gesagt: "alles über das Sicherheitsgateway nach außen leiten - dafür ist's gekauft worden"...Es ist auch laut Sophos Best Practice (logischerweise) alles über deren Appliance ablaufen zu lassen...
Es läuft nach wie vor über das SGW. Es geht euch wohl darum, keine großen Forwards zu haben sondern so viel wie möglich auf dem Gerät zu terminieren.Das mit den bedingten Weiterleitungen wird man ja im Prinzip nur in den Griff bekommen, wenn komplett auf inoffizielle TLDs verzichtet wird.
Unter den Vorraussetzungen wie du sie hast - Ja. Was sich natürlich mit Windows Server 2016 oder 2019 diesbezüglich geändert hat, weiß ich nicht. Da wir bis dato auch Windows Server 2012R2 nutzen. Da kann evtl. jemand anders was dazu sagen. Ist man also Besitzer von "unternehmen.de" müsste man beispielsweise für die interne Active Directory die Zone intern.unternehmen.de verwenden. Der Domainanbieter (z.B. 1und1) müsste dann ja auch noch zusätzlich den internen DNSKEY signieren und in der Zone "unternehmen.de" veröffentlichen, damit dort auch wieder die Chain-of-Trust eingehalten werden kann.
Da kann ich dir nicht ganz folgen. Warum müsste der Hoster der Domain unternehmen.de die Zone "intern" signieren?so würden auch die internen, bedingten Weiterleitungen mit DNSSec abgesichert werden
Jap, ist aber nicht unbedingt notwendig. Wir haben viele bedingte Weiterleitungen für zone1.de, zone2.de, etc... welche alle nicht über DNSSEC verfügen. Die Abfrage von unseren Windows DNS-Servern mit aktivierten DNSSEC funktioniert problemlos.Allerdings macht es jetzt nur Sinn, wenn möglichst alle Geräte DNSSec verwenden. Windows macht es uns leicht -> GPO für die interne Domain erstellt und fertig.
Kann man so machen. Allerdings würde ich bei solchen Eingriffen in eine elementarwichtigen Funktion wie DNS klein anfangen und langsam ausrollen. Nicht das es ungeahnten Folgen kommt, welche die tägliche Arbeit unmöglich machen.Die Sophos bekommt keine validen Information von der internen AD, da die DNS-Auflösung hier mit der Fehlermeldung "broken chain of trust" verworfen wird. Ich gehe jetzt einfach davon aus, dass die Sophos signierte Informationen von den internen DNS-Servern erhält, diese aber nicht validieren kann, weil die interne Domäne ebenfalls eine inoffizielle TLD im Namen trägt, sodass die Chain-of-Trust nicht aufgebaut werden kann.
Deine Erklärung klingt auf Anhieb logisch. Ich vermute allerdings, dass die Sophos gar nicht weiß, dass sie das Schlüsselmaterial bei deinem DNS-Server abrufen soll. Thema authoritative Nameserver.Das Problem mit der Sophos besteht weiter -> "broken chain of trust" obwohl eigentlich von den internen Servern nichts signiertes mehr ankommen kann - wieso das?!
Wir haben inzwischen gelernt, nach eine Änderung am Windows DNS-Server den Dienst auf jeden Fall einmal neu starten. Irgendwie verschluckt sich der Dienst manchmal...Ich bin gespannt, ob sich noch weitere Kollegen finden lassen, die sich mit dem Thema auseinandersetzen.
Gruß,
Dani
Zitat von @Dani:
Moin,
Es geht euch wohl darum, keine großen Forwards zu haben sondern so viel wie möglich auf dem Gerät zu terminieren.
Moin,
Mhm...naja wir haben uns irgendwann mal gesagt: "alles über das Sicherheitsgateway nach außen leiten - dafür ist's gekauft worden"...Es ist auch laut Sophos Best Practice (logischerweise) alles über deren Appliance ablaufen zu lassen...
Es läuft nach wie vor über das SGW. Es geht euch wohl darum, keine großen Forwards zu haben sondern so viel wie möglich auf dem Gerät zu terminieren.Jap, so ist es...
Ist man also Besitzer von "unternehmen.de" müsste man beispielsweise für die interne Active Directory die Zone intern.unternehmen.de verwenden. Der Domainanbieter (z.B. 1und1) müsste dann ja auch noch zusätzlich den internen DNSKEY signieren und in der Zone "unternehmen.de" veröffentlichen, damit dort auch wieder die Chain-of-Trust eingehalten werden kann.
Da kann ich dir nicht ganz folgen. Warum müsste der Hoster der Domain unternehmen.de die Zone "intern" signieren?Naja die Verifizierung der Domains geht ja von "oben nach unten". Eine Parent-Domain validiert den DNSKey der Child-Domain. In den DS-Records wird ja immer der jeweilige DNSKey-Hash der Child-Domain mit dem jeweiligen DNSKey der Parent-Domain signiert.
Dementsprechend baut sich die Chain of Trust so auf: Root-Zone->.de-Zone-> unternehmen-Zone-> intern-Zone. Wenn die anfragenden DNS-Server auf Höhe der Unternehmen-Zone keine DS-Records mehr finden, ist die Vertrauenskette ja unterbrochen, weil der DNSKey in der intern.unternehmen.de nicht mehr gegen den Eintrag in der Parent-Domain gegengeprüft werden kann. Deshalb muss der Hoster der Unternehmen-Zone auch den DNSKey der Child-Domain in einem DS-Record verifizieren. Dazu muss er den Hash des DNSKey von der untergeordneten Zone-Intern mit seinem privaten Schlüssel signieren und in einen DS-Record packen (Wenn ich falsch liege bitte verbessern
:-P).Dieser ganze Chain-of-Trust-Kram wurde ja ins leben gerufen, damit die Schlüsselverwaltung vereinfacht wird. Dadurch ist man ja nur noch auf die öffentlichen Schlüssel der Root-Zone angewiesen und nur noch diese müssen aktiv Verteilt werden. Ansonsten müssten ja für jede Zone erst einmal Schlüssel ausgetauscht werden...geschweige denn aktuell gehalten werden.
so würden auch die internen, bedingten Weiterleitungen mit DNSSec abgesichert werden
Jap, ist aber nicht unbedingt notwendig. Wir haben viele bedingte Weiterleitungen für zone1.de, zone2.de, etc... welche alle nicht über DNSSEC verfügen. Die Abfrage von unseren Windows DNS-Servern mit aktivierten DNSSEC funktioniert problemlos.Okay, also wie gesagt bei uns funktionieren die bedingten Weiterleitungen nicht. Ob es an den inoffiziellen TLDs liegt weiß ich nicht...ein versuch mit offiziellen TLDs könnte ich ja mal ausprobieren wobei ich auch da wenig Chancen sehe. Wenn ich eine interne Domain "intern.de" abfragen will, kommt er ja auch irgendwann mit der Verifikation nicht mehr weiter...
Die Sophos bekommt keine validen Information von der internen AD, da die DNS-Auflösung hier mit der Fehlermeldung "broken chain of trust" verworfen wird. Ich gehe jetzt einfach davon aus, dass die Sophos signierte Informationen von den internen DNS-Servern erhält, diese aber nicht validieren kann, weil die interne Domäne ebenfalls eine inoffizielle TLD im Namen trägt, sodass die Chain-of-Trust nicht aufgebaut werden kann.
Deine Erklärung klingt auf Anhieb logisch. Ich vermute allerdings, dass die Sophos gar nicht weiß, dass sie das Schlüsselmaterial bei deinem DNS-Server abrufen soll. Thema authoritative Nameserver.Auch hier: Sophos als Hersteller hat sich bisher wahrscheinlich einfach mit dem Thema DNSSec nicht wirklich auseinander gesetzt.
Das Problem mit der Sophos besteht weiter -> "broken chain of trust" obwohl eigentlich von den internen Servern nichts signiertes mehr ankommen kann - wieso das?!
Wir haben inzwischen gelernt, nach eine Änderung am Windows DNS-Server den Dienst auf jeden Fall einmal neu starten. Irgendwie verschluckt sich der Dienst manchmal...Ich bin gespannt, ob sich noch weitere Kollegen finden lassen, die sich mit dem Thema auseinandersetzen.
Ich werde mich zwar weiterhin ein wenig mit dem Thema auseinandersetzen aber die Einführung rückt für mich in weite Ferne. Irgendwie ist die ganze Sache bisher nicht recht praxistauglich. Mir sind diverse Problemchen aufgefallen, die den Einsatz uninteressant machen, solange sich die Hersteller der Geräte und Software nicht mit dem Thema auseinandersetzen. Noch dazu bin ich mir nicht sicher, ob der Sicherheitsgewinn in Relation zum Aufwand wirklich lohnenswert ist.
Achja und irgendwie interessiert DNSSec wohl keinen. Man findet zwar hier und da einen Artikel über DNSSec und auch mal ein Forenbeitrag (die aber alle etwas älter sind), aber die breite Masse hat sich wohl noch nicht mit dem Thema auseinander gesetzt.
Gruß,
Dani
Gruß zurück und Dankeschön!
Moin,
Gruß,
Dani
Irgendwie ist die ganze Sache bisher nicht recht praxistauglich. Mir sind diverse Problemchen aufgefallen, die den Einsatz uninteressant machen, solange sich die Hersteller der Geräte und Software nicht mit dem Thema auseinandersetzen.
möchtest du diese mit uns noch teilen? Gerne auch per PN. Gruß,
Dani
