DirectAccess zerstört DNSSEC
Ich hatte gerade im Lab mit DirectAccess gespielt. Da bietet es sich an, auch mal zu schauen, was passiert, wenn DNSSEC dazu kommt. Das Ergebnis ist eine faustdicke Überraschung.
Neue Zone
Als ersten lege ich eine neue Zone sec.adatum.com mit DNSSEC an. Das ist einfach: Einfach an der Zone im Kontextmenü DNSSEC auswählen. Es bietet sich an, die Trust Anchors innerhalb der Domain gleich mit zu verteilen.
Diese Zone bekommt einen WWW Eintrag, der auf den Webserver im Lab verweist. Und das tut dann auch.
Die Antwort besteht aus drei Teilen:
PS dns> Resolve-DnsName -DnssecOk -Name www.sec.adatum.com
Name Type TTL Section NameHost
---- ---- --- ------- --------
www.sec.adatum.com CNAME 3600 Answer www.adatum.com
Name : www.sec.adatum.com
QueryType : RRSIG
TTL : 3600
Section : Answer
TypeCovered : CNAME
Algorithm : 8
LabelCount : 4
OriginalTtl : 3600
Expiration : 5/19/2017 3:41:34 PM
Signed : 5/19/2017 8:41:34 AM
Signer : sec.adatum.com
Signature : {39, 75, 194, 190...}
Name : www.adatum.com
QueryType : A
TTL : 3600
Section : Answer
IP4Address : 172.16.0.10Auch auf dem Client, der irgendwo remote steht, tut es anstandslos. Hier gibt es aber nur zwei Teile in der Antwort:
PS client> Resolve-DnsName -DnssecOk -Name www.sec.adatum.com Name Type TTL Section NameHost ---- ---- --- ------- -------- www.sec.adatum.com CNAME 600 Answer www.adatum.com Name : www.adatum.com QueryType : AAAA TTL : 600 Section : Answer IP6Address : fd68:d6bf:56b6:7777::ac10:a
Man sieht schön die Wirkung von DNS64 und das Ergebnis überzeugt:
Pinging www.adatum.com [fd68:d6bf:56b6:7777::ac10:a] with 32 bytes of data: Reply from fd68:d6bf:56b6:7777::ac10:a: time=1ms Reply from fd68:d6bf:56b6:7777::ac10:a: time=1ms
Allerdings wurde keine DNSSEC Validierung durchgeführt, wie man an dem Fehlen der RRSIG Antwort bemerkt haben könnte.
Validierung
Die Validierung von DNSSEC kann man per Gruppenrichtlinie erzwingen.
Technisch gesehen wird hier per Policy Based DNS, die Validierung pro Domain eingefordert. Die Trust-Anchors wurden ja schon verteilt.
Nach Verteilung der Gruppenrichtlinie auf den Client stellt sich die Situation ganz anders dar:
PS client> Resolve-DnsName -DnssecOk -Name www.sec.adatum.com Resolve-DnsName : www.sec.adatum.com : Unsecured DNS packet
Konsequenterweise funktioniert dann auch nichts mehr:
C:\> ping www.sec.adatum.com Ping request could not find host www.sec.adatum.com. Please check the name and try again.
DNSSEC hat also erfolgreich DNS64 erkannt und die Modifikation verhindert!
Und IPv6?
Nehmen wir einen IPv6 Host im lokalen Netz an:
PS dns> Resolve-DnsName -DnssecOk -Name test.sec.adatum.com -type aaaa
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
test.sec.adatum.com AAAA 3600 Answer 2001:db8::1
Name : test.sec.adatum.com
QueryType : RRSIG
TTL : 3600
Section : Answer
TypeCovered : AAAA
Algorithm : 8
LabelCount : 4
OriginalTtl : 3600
Expiration : 5/19/2017 4:02:43 PM
Signed : 5/19/2017 9:02:43 AM
Signer : sec.adatum.com
Signature : {162, 99, 191, 91...}Die Antwort besteht aus zwei Teilen, dem AAAA und dem RRSIG. Das tut. Nun zur Sicherheit noch einen nicht existierenden Namen.
PS dns> Resolve-DnsName -DnssecOk -Name test3.sec.adatum.com Resolve-DnsName : test3.sec.adatum.com : DNS name does not exist
Aber tut es auch auf dem Client? Schließlich muss ja keine Umschreibung durch DNS64 stattfinden.
PS client> Resolve-DnsName -DnssecOk -Name test.sec.adatum.com
Huch? Das tut nicht? Es fehlt auch komplett eine Antwort! Ist das denn von DNSSEC bestätigt?
PS client> Resolve-DnsName -DnssecOk -Name test3.sec.adatum.com Resolve-DnsName : test3.sec.adatum.com : Unsecured DNS packet
Nein, der DirectAccess-Resolver macht DNSSEC kaputt.
Richtig kaputt.