Transitschutz: DNSSEC und DANE auf Linux-Servern konfigurieren
Seite 3: TLSA-Record publizieren
Damit ein Client das Zertifikat eines Servers per DANE prüfen kannˇ[2], braucht er als Fingerabdruck den SHA256-Hash des Zertifikats. Diesen Hash bekommt er von seinem DNS-Resolver, der ihn aus dem vom Upstream-DNS-Server gelieferten TLSA-Record holt. Den TLSA-Record holt sich der Client mit einer DNS-Anfrage wie _25._tcp.mail.example.org. Dabei wird dem Servernamen die Portnummer 25 für SMTP und das Transportprotokoll (TCP) vorangestellt.
Neuere DNS-Server können bereits mit dem TLSA-Record umgehen. Bei vielen älteren Servern können Sie ihn in der Standard-Notation für unbekannte DNS-Records eintragen (RFC 3597). Windows Server 2012(R2) nutzt den TLSA-Record leider noch nicht. Den SHA256-Hash erzeugen Sie aus dem unterschriebenen Zertifikat:
openssl x509 -in /etc/ssl/example.org.crt -outform DER | openssl sha256
Die Ausgabe des Befehls sieht beispielsweise so aus:
(stdin)= 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1
Der TLSA-Record enthält drei Flags, die seine Verwendung kennzeichnen. Das erste, die TLSA Certificate Usage, bekommt den Wert 3, der ein dediziertes Server-Zertifikat beschreibt (DANE-EE Domain-issued certificate). Der folgende Selector 0 kennzeichnet ein komplettes Zertifikat, im Unterschied zu einer "SubjectPublicKeyInfo"-Datenstruktur. Der Matching Type 1 zeigt an, dass die folgenden Daten der SHA256-Fingerabdruck des Zertifikats sind. 0 steht für das komplette Zertifikat, 2 für einen SHA512-Hash. Damit sieht der in die DNS-Zone für example.org einzutragende TLSA-Record so aus:
_25._tcp.mail.example.org. IN TLSA 3 0 1 ( 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1 )
Entsprechend gehen Sie für den Webserver vor. Arbeitserleichterung bieten ein Online-Generator oder die Tools hash-slinger und ldns-dane. Letzteres lässt sich besonders einfach nutzen. Es holt das Zertifikat direkt vom Server und erzeugt den TLSA-Record:
ldns-dane create www.example.org 443
Der Befehl liefert eine Ausgabe wie diese:
_443._tcp.www.example.org. 3600 IN TLSA 3 0 18cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1
DNS-Zone signieren
Der TLS-Schutz per DANE funktioniert nur dann sicher, wenn DNS-Server und -Resolver auch DNSSEC benutzen. Sonst könnte ein Angreifer falsche TLSA-Hashes injizieren. Zum DNSSEC-Ertüchtigen von Resolvern liefert der Artikel Namen-Checker – DNSSEC für Clients und Client-Netze einrichten Hinweise.
Die meisten DNS-Server beherrschen inzwischen DNSSEC. Das folgende Beispiel einer DNSSEC-Signierung gilt für BIND 9.9.0, hernach kurz BIND. Alternativen sind etwa NSD, PowerDNS, Knot, Yadifa und Bundy. Um die Verwaltung von DNSSEC-Schlüsseln und den periodischen Schlüsseltausch (Key-Rollover) kann sich OpenDNSSEC kümmern.
DNSSEC erzwingt, dass autoritative DNS-Server (DNS-Zonen) und DNS-Resolver (Dienste zur Namensauflösung für Clients) auf getrennten Systemen laufen: Ein autoritativer Server kann nicht seine eigenen DNS-Daten per DNSSEC prüfen. Bei autoritativen Antworten ist nämlich in der Antwort das AA-Flag gesetzt (AA = autoritative Antwort), bei DNSSEC-validierten DNS-Antworten jedoch das AD-Flag (AD = authentisierte Daten). Die Flags schließen sich aber gegenseitig aus.
Stellen Sie zunächst mit Zonecheck, DNSCheck oder Zonemaster sicher, dass Ihre DNS-Zone fehlerfrei ist. Sonst kann die DNSSEC-Signierung oder -Validierung fehlschlagen, auch wenn die Zone bisher funktioniert hat.
