Seite 2: Eine Hierarchie statt Inseln

Inhaltsverzeichnis

Entwickler, die in der Internet Engineering Task Force zusammenarbeiten, haben daher Lösungsvorschläge entwickelt, die diese Konzeptschwächen beseitigen können. Sie setzen auf DNS Security Extensions (DNSSEC). DNSSEC ist eine Erweiterung des Domain Name System, die DNS-Daten kryptografisch gegen Fälschungen absichert und die Quelle der DNS-Daten authentisiert.

Das Domain Name System ist ein weltweit verteilter hierarchisch organisierter Verzeichnisdienst, der den Namensraum des Internet verwaltet und die Domainnamen zu IP-Adressen auflöst. Der Namensraum besteht aus unabhängig verwalteten Zonen. DNSSEC verknüpft die einzelnen Zonen zu Vertrauensketten (Chains of Trust).

Dabei enthält die oben in der Hierarchie angesiedelte Zone die signierten Hashes der öffentlichen Schlüssel der darunterliegenden Zonen, sie sind als authentisch markiert. Damit können Clients prüfen, ob die Schlüssel der darunterliegenden Zonen korrekt sind. Das Prinzip setzt sich auf jeder darunterliegenden Hierarchiestufe fort: Die übergeordnete Zone signiert und publiziert die Hashes der direkt untergeordneten, also delegierten Zonen.

DNSSEC-Vertrauensketten

Ein DNSSEC-Client oder Resolver, der eine per DNSSEC abgesicherte DNS-Antwort erhält, prüft zunächst, ob die Information unverfälscht ist. Dazu vergleicht er den in der DNS-Antwort mitgeschickten Hash-Wert mit dem selbst berechneten. Sind beide gleich, prüft er die gesamte Signaturkette aufwärts, indem er jede einzelne Signatur gegenrechnet; er folgt so der Vertrauenskette bis zum in der Konfiguration hinterlegten Schlüssel hinauf (Trust Anchor).

Dies ist in der letzten Instanz, wenn keine Schlüssel der unteren Hierarchiestufen hinterlegt wurden, der IANA-Root-Key. Dieser Schlüssel lässt sich durch Gegenrechnen der Signatur prüfen; er hat ja keine übergeordnete Instanz, also auch keine Signatur. Daher prüft ein Administrator einen solchen Key vor der Einrichtung manuell, etwa indem er von der IANA veröffentlichte Hashes gegenrechnet.

Diese, schon ansehnlich gewachsene Infrastruktur lässt sich auch zum Verteilen von ganz anderen Daten als den DNSSEC-spezifischen nutzen. Dafür gibt es die DANE-Protokollfamilie (DNS-Based Authentication of Named Entities). Solche Erweiterungen sind möglich, weil sich in Zonen nicht nur IP-Adressen, sondern auch andere Informationen speichern lassen; für jeden Datentyp gibt es eigene Spezifikationen (Resource Records, RR).

DANE/TLSA ist eine erste Anwendung, die auf DNSSEC aufsetzt. Damit validieren SMTP-Mail-Server ihre TLS-Zertifikate gegenseitig (Transport Layer Security). Die Zuordnung zwischen TLS-Zertifikat und Domain übernimmt der Verwalter der jeweiligen Domain – vereinfacht gesagt, trägt er dafür in die entsprechende Zonen-Datei einen TLSA RR ein. Die Technik ist bereits im Einsatz, weltweit gibt es inzwischen etliche SMTP-Server, die mittels DANE/TLSA gegenseitig ihre Authentizität feststellen.

Dieses Konzept lässt sich leicht erweitern, um eine Mail-Adresse an einen Benutzerschlüssel zu binden. DANE/SMIMEA und DANE/OPENPGPKEY legen fest, wie S/MIME-Fingerprints (Hashes) und OpenPGP-Schlüssel im DNSSEC hinterlegt werden. Auf ganz ähnliche Art publiziert man auch SSH- oder IPSec-VPN-Schlüssel im DNSSEC.