DNSSEC

Das DNS-System ist der Grundpfeiler fast jeder Verbindung. Normalerweise wird eine Verbindung über den Namen eines Servers oder Dienstes Aufgebaut. Der Name ist aber nicht Routingfähig. Deshalb wird die (routingfähige) IP-Adresse über DNS ermittelt. Das DNS-Protokoll verwendet sehr kurze einfache Mitteilungen, die es mittels dem UDP-Protokoll versendet. Eine Anfrage wird unverschlüsselt und ohne Verbindung durch das Netz gesendet. Jeder, der die Mitteilung mitlesen kann (ein Abfangen im Sinne von: Den eigentlichen Empfänger vom Empfang ausschliessen ist nicht notwendig), ist in der Lage eine falsche Information als Antwort einzuspeisen. Damit wird erreicht, dass alle Clients, die den Sender der Anfrage kontaktieren eine falsche IP als Ziel erhalten.

Eine weitergehende Modifikation ist nicht mehr nötig. Schlimmer noch: Resultate von DNS-Anfragen werden in einen Cache geschrieben. Für wie lange dies zulässig ist, steht in der (möglicherweise gefälschten) Antwort. Eine solche Manipulation wird auch als DNS Cache Poisoning bezeichnet. Sie kann eigentlich nur verhindert werden durch DNSSEC.

DNSSEC ist ein System zur Absicherung von DNS-Anfragen und wurde bereits 1997 mit dem RFC Dokument 2065 aus der Taufe gehoben. Es ist in der Kategorie "Standards Track" (was so etwas wie ein niederer Adelstitel unter den RFC-Dokumenten ist) und wurde bereits mehrfach weiterentwickelt (unter anderen RFC2535, RFC3008, RFC3445 und so weiter). Die aktuellen Kerndokumente sind die Dokumente RFC4033, RFC4034, and RFC4035.

Bei DNSSEC wird jeder einzelne Eintrag mit einem privaten Schlüssel unterschrieben. Den zugehörigen öffentlichen Schlüssel erhält man von der jeweils nächst höheren Instanz einer Zone. Die Schlüssel der obersten Instanz sind jeweils im Betriebssystem (so dieses denn DNSSEC versteht) hinterlegt.

Clients können nun (müssen aber nicht) jede einzelne Zwischenanfrage überprüfen. Lassen sich die Signaturen bis hoch zu den Root-Signaturen prüfen, dann ist gewährleistet, dass der ganze Pfad von authorisierten Servern kommt.

Zu den üblichen Records wie zum Beispiel "A" (für die Auflösung von einem Namen zu einer IPv4-Adresse), "AAAA" (für die Auflösung von einem Namen zu einer IPv6-Adresse), "NS" (für die zuständigen DNS-Server) oder "MX" (für die zuständigen Mai-Server), kommen neu folgende Records hinzu:

Diese Records können eigentlich statisch berechnet und ins Zonenfile eingetragen werden. Diese Form des Unterhaltes ist aber sehr aufwändig und fehleranfällig. Die meisten DNS-Server erlauben es aber auch die Signaturen automatisch anzupassen. So muss sich der DNS-Administrator nicht um diese kümmern, sondern der DNS-Server legt diese automatisch an.

Bei DNSSEC wird jeder Record mit einem Schlüssel (Zone Signing Key oder kurz ZSK) unterschrieben. Dies geschieht mit dem RRSIG-Record. Der öffentliche Teil des Schlüssels (public KSK) wird mit einem DNSKEY-Record zur Verfügung gestellt. Eine Anfrage nach einem Record wird also mit dem Record selbst (A, CNAME oder was auch immer), dem Der signatur (RRSIG).

Falls der ZSK der Zone nicht bekannt ist kann er mittels DNSKEY erfragt werden. Der ZSK wird mit einem Key Signing Key (KSK) erneut unterschrieben (wieder mit einem RRSIG-Record). Warum zwei Schlüssel (einer für die Records (ZSK) und einen für die Zonenschlüssel (KSK)). Die Antwort ist einfach: Ein Schlüssel muss irgendwann ausgetauscht werden. Dies ist erheblich einfacher, wenn es sich um zwei Schlüssel handelt, die zu unterschiedlichen Zeitpunkten getauscht werden. Es erlaubt auch einen kürzeren ZSK zu verwenden, der häufiger ausgetauscht wird und so wiederum Bandbreite und Rechenleistung spart.

Der DNSKEY erlaubt es damit die Signatur zu überprüfen. Das Problem ist, dass nicht bekannt ist, ob der Schlüssel auch vertrauenswürdig ist. Damit dies überprüft werden kann, wird die nächst höhere Zone angefragt, was der richtige Hash-Wert des KSK ist (der Hash-Wert wurde verwendet um Bandbreite und Speicherplatz zu sparen).

Diese Antwort könnte natürlich auch gefälscht sein, weshalb sie ebenfalls unterschrieben wird mit dem zugehörigen KSK zur Zone. Folgerichtig muss auch dieser Schlüssel bei der nächst höheren Zone überprüft werden, bis die Root-Zone erreicht wird.

Ein DNSSEC-fähiger Client hat ein Set von vertrauenswürdigen Root-Schlüsseln bei sich auf der Festplatte. Damit kann die letzte Unterschrift und somit die Gültigkeit der ganzen Kette überprüft werden.

Die Implementation von DNSSEC ist relativ einfach. Als erstes müssen alle entsprechenden Zonen mit einem eigenen Schlüssel signiert werden. Wie das geschieht ist vom DNS-Server abhängig.

Folgende Links verweisen auf entsprechende HowTo’s oder Dokumentationen:

Wenn alle Zonen signiert sind, muss der öffentliche Schlüssel der darüber liegenden Domäne zur Signatur übergeben werden. Dies muss normalerweise beim Provider der entsprechenden Top-Level-Domäne gemacht werden und ist meistens ein automatisierter Prozess. Wird dieser Schritt weggelassen ist die ganze Signierung wertlos, weil die Signaturen nur einen Wert haben, wenn sie von ganz oben (der Root Zone) her überprüfbar sein müssen.

Es gibt mittlerweile einige Clients, die DNSSEC unterstützen. Die meisten haben die Unterstützung aber standardmässig ausgeschaltet. Clients, die DNSSEC unterstützen sind:

Clients, die derzeit (nur mit Bordmitteln) kein DNSSEC unterstützen oder deren Zustand nicht bekannt sind:

Bei allen Clients die keinen DNSSEC-Fähigen Resolver haben kann als alternative lokal ein DNS-Server installiert werden, der als Resolver im OS eingetragen wird (benötigt häufig Root-Rechte).

Die Frage stellt sich ob bei so schlechter Unterstützung durch die Clients es überhaupt Sinn macht DNSSEC zu unterstützen. Hierauf gibt es zwei Antworten: