Einführung von DNSSEC und DANE an der KU Eichstätt-Ingolstadt

Ein Erfahrungsbericht aus dem DNSSEC/DANE-Projekt des Bayerischen Forschungsministeriums beim Leibniz-Rechenzentrum

Die Katholische Universität Eichstätt-Ingolstadt ist als kirchliche Universität auch Mitglied im Bayerischen Hochschulnetz, und hat auch Ihr Interesse an der Einführung von DNSSEC ("Domain Name System Security Extensions")  zur Absicherung der Domain Nameserver und DANE ("DNS-based Authentication of Named Entities") zur TLS-Verifizierung des Mailverkehrs zwischen den Hochschulen bekundet. Das Bayerische Forschungsministerium unterstützt dies mit einem Projekt am Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften, das den beteiligten Hochschulen und Universitäten Hilfestellung in Form von Expertise und praktischer Unterstützung bietet.

DNS-Setup

Die Universität Eichstätt-Ingolstadt ist an zwei Standorten, in Eichstätt und Ingolstadt präsent. Dies erfordert einerseits die Bereitstellung von Diensten an zwei Standorten ist aber auch der ideale Ausgangspunkt, um Redundanz für essentielle Dienste, wie sie DNS darstellen, zu implementieren. Je ein autoritativer Nameserver sind daher am Standort Eichstätt und Ingolstadt, wobei der Nameserver in Ingolstadt als "Secondary" die Zonen des ersteren übernimmt.

Vorbereitung

Die autoritativen Nameserver wurden im Zuge der Umstellung durch neue Hardware Dell 310 Server ersetzt. Auf diesen wurde SLES12-SP3 mit einer etwas älteren BIND-Version (9.9.9-P1) installiert, da Debian 9, das eigentlich vorgesehen war, die neuen PERC SATA-Controller nicht unterstützte. Durch das modulare Konzept, das einen dedizierten DNSSEC-Nameserver, der als Signing Proxy die Schlüsselverwaltung und Signierung von Zonen übernimmt, war das aber kein großes Hindernis.

Die Anbindung an die öffentlichen autoritativen Nameserver ("Public Master" im Schema) erfolgt über einen standardisierten Zonen-Transfer. Das funktioniert nicht nur über verschiedene BIND-Versionen (9.11.3-2 auf Debian 9.4 und 9.9.9-P1 auf SLES 12) hinweg, sondern sogar mit unterschiedlicher Nameserver-Software (z.B. PowerDNS, Windows2016 Server usw.). Der zusätzliche Aufwand, für den Signing Proxy und die bestehende DNS-Verwaltung (über direktes Editieren der Zonen mit vim), zwei virtuelle VMWare Instanzen einzuführen, hat sich also hier schon gelohnt.

Die bisherige Umstellung wurde lange aufgrund der Vielfalt anderer Projekte und Aufgaben, die für den reibungslosen und zukunftsfähigen Betrieb der IT der KU unabdingbar sind, verschoben. Der Leiter der Abteilung IT-Infrastruktur und der Netzverantwortliche hatten bereits das durch das Leibniz-Rechenzentrum und dem Regionalen Rechenzentrum der Friedrich Alexander Universität Erlangen organisierte Angebot genutzt, sich in den im März 2017 veranstalteten Kurs "Einführung in DNSSEC und DANE" über die Theorie und praktische Einrichtung zu informieren.

Beratung

Die im Rahmen des Projekts erstellte Dokumentation mit Howtos und Anleitungen zur praktischen Einrichtung von DNSSEC mit gängiger Nameserver-Software bildeten dann die Grundlage, diese Kenntnisse aufzufrischen und zu vertiefen. Damit war sicher gestellt, dass die Umstellung effizient und vorausschauend erfolgen konnte.

Im Rahmen des Projekts bietet das LRZ auch an, dass einer der Projektmitarbeiter direkt vor Ort Hilfe bei der Umstellung leisten kann. Dieses Angebot wurde von der KU Eichstätt-Ingolstadt gerne angenommen, insbesondere um technische Details und Konzepte im direkten Gespräch zu klären.

Daher wurde der erste von drei Tagen auch dazu genutzt, im Schaubild und mit der Beantwortung von Fragen, die notwendige Sicherheit im Verständnis von DNSSEC bei allen an der KU Eichstätt-Ingolstadt mit dem Thema beauftragten Mitarbeitern zu festigen.

Die im folgenden beschriebenen technischen Änderungen wurden in gemeinsamer Abstimmung zwischen dem LRZ Projektmitarbeiter und den Verantwortlichen der KU vor Ort abgestimmt und umgesetzt.

DNSSEC

Auf den neuen Hardware-Nameservern war schon BIND9-9.11.3-2 aus den Backports-Quellen für Debian 9 "Stretch" installiert. Die Konfigurations- und Zonendateien der bestehenden Systeme wurden übernommen. Insgesamt verwaltet die KU Eichstätt-Ingolstadt rund 70 Zonen auf Ihren DNS-Servern. Davon sollten vorerst zwei Zonen, darunter die hauptsächlich genutzte Hauptzone ku.de, auf DNSSEC umgestellt werden. Der Rest sollte nach Bedarf dann selbst umgestellt werden.

Wie durch das Leibniz-Rechenzentrum empfohlen, und auch dort so verwendet, wird die Schlüsselverwaltung und DNSSEC-Signierung auf einem sogenannten "Signing Proxy" durchgeführt. Dieser übernimmt die unsignierten Zonendaten per Zonentransfer von einem als DNS-Verwalter, der sogenannte "Hidden Master", fungierenden Nameserver. Sowohl der Signing Proxy, als auch der DNS-Verwalter wurden auf VMWare als Virtuelle Maschine installiert. Da die physischen Server als einzige autoritativ sind, und vom öffentlichen Internet erreichbar sein müssen, können die beiden Virtuellen Maschinen auf internen IPs laufen, und abgesichert werden. So ist ein Zugriff auf die geheimen, privaten DNSSEC-Schlüssel erschwert.

Für Zonen, die nicht mit DNSSEC signiert werden sollen, kann der Signing Proxy umgangen werden. Hier ist auf dem Primary Public Master, der Hidden Master als "Master" eingetragen und der Zonentransfer geht direkt auf den Primary Public Master.

Die Einrichtung der DNSSEC-Signierung umfasste daher, die Konfigurationsdateien für BIND auf den beteiligten Nameserver-Systemen so einzurichten, dass die Master/Slave-Relationen und erlaubten Zonentransfer sicher gestellt sind:

Die weiteren definierten Secondary Nameserver am RRZE in Erlangen und beim DFN e.V., bleiben wie gehabt konfiguriert, und übernehmen die Zonen vom "Primary Public Master":

Auf DNSSEC umgestellt werden sollten die beiden Zonen ku.de und slaby-online.de. Zur DNSSEC-Signierung werden ein Key-Signing-Key-Paar (KSK), das die Delegation von der Parentzone auf die eigene Zone sicherstellt, und ein Zone-Signing-Key-Paar (ZSK), das die Einträge der Zone selbst signiert, benötigt.

Es wird empfohlen pro Zone je ein KSK und ZSK-Schlüsselpaar zu erzeugen. Dies wird auch so von dnssec-keygen der bind9utils, das die Schlüssel erzeugt, und nach den Zonennamen benennt, forciert. Als Schlüssel wurden jeweils 2048 Bit lange RSA-Schlüssel gewählt. Dies stellt einen guten Kompromiss aus Sicherheit auf der einen und Rechenaufwand und Signaturlänge auf der anderen Seite dar. Diese Schlüssellängen werden auch am LRZ verwendet.

Von der Verwendung ECDSA-Schlüssel mit elliptischen Kurven, die mit kürzeren Schlüssellängen (384 Bit) vergleichbare Sicherheit bei kürzeren Signaturlängen bieten, wurde vorerst abgesehen, da ECDSA erst zu späterer Zeit im DNSSEC-Standard definiert wurden, und nicht ausgeschlossen werden kann, dass Resolver mit alter Software damit nicht umgehen könnten. Es wurde empfohlen, diese llieber bei einer Testzone einzurichten, nachdem man sich über den aktuellen Stand der Unterstützung und Verbreitung informiert hat.

Da durch 2x2 Schlüsseldateien (Public und Private DNSKEY jeweils für KSK und ZSK) allein pro Zone vier Dateien im Blick behalten werden müssen, und sich diese Anzahl bei der Durchführung von key rollovers noch weiter vervielfacht, werden die Schlüssel in Verzeichnissen pro Zone unter /var/bind/keys/<ZONENNAME> vorgehalten. Dieses Verzeichnis musste in den Zonenkonfigurationen angegeben werden, damit BIND die Schlüssel finden kann.

Die Optionen "inline-signing yes" und "auto-dnssec maintain" wurden für die zu signierenden Zonen in den Konfigurationsdateien für die jeweilige Zone angegeben - hier zeigen wir nur den Fall für die Zone ku.de. Der Hidden Master wurde so konfiguriert, dass der Transfer an den Signing Proxy und den Public Master (für die nicht zu signierenden Zonen) erlaubt ist.

zone ku.de {

	type master;

	file "/etc/bind/master/db.ku.de";

	allow-transfer { 10.10.10.2; 141.78.7.250; };

	also-notify { 10.10.10.2; };

}

Da der "Signing Proxy" nicht als autoritärer Nameserver offiziell in den NS-Einträgen der Zone auftaucht, muss dieser gesondert mit "also-notify" über Zonenänderungen in Kenntnis gesetzt werden, um dann wiederum den Zonentransfer, der durch allow-transfer erlaubt ist, zu initiieren.

Auf dem Signing Proxy wurde der "Hidden Master" als Master gesetzt und der Transfer nur an den "Primary Public Master" erlaubt.

zone ku.de {

	type slave;

	Masters { 10.10.10.1; };

	file "/etc/bind/slave/db.ku.de";

	# DNSSEC-Signierung dieser Zone

	key-directory "/var/bind/keys/ku.de";

	inline-signing yes;

	auto-dnssec maintain;

	ixfr-from-differences no;

	allow-transfer { 141.78.7.250; };

	also-notify { 141.78.7.250; };

}

Die Konfiguration des Public Master ist wie gewohnt, mit dem Unterschied, dass sowohl der Hidden Master für die unsignierten Zonen und der Signing Proxy für die signierten Zonen als Master eingetragen haben muss:

zone ku.de {

	type slave;

	Masters { 10.10.10.1; 10.10.10.2; };

	file "/etc/bind/slave/db.ku.de";

	allow-transfer { 10.10.10.3; 193.174.75.50; 193.174.75.58; 131.188.3.4; };

	also-notify { 10.10.10.3; 193.174.75.50; 193.174.75.58; 131.188.3.4; };

}

Da die anderen autoritativen Nameserver die Zonen vom Primary Public Master übernehmen, muss der Transfer an diese erlaubt sein.

Zuletzt wurden für die beiden Zonen entsprechende Key-Signing-Keys (KSKs) und Zone-Signing-Keys (ZSKs) erzeugt. Für die Zone slaby-online.de wurde auch zu Übungszwecken ein Standby-KSK erzeugt.

dnssec-keygen -a RSASHA256 -b 2048 -K /var/bind/keys/ku.de/ -n ZONE ku.de

dnssec-keygen -a RSASHA256 -b 2048 -K /var/bind/keys/ku.de/ -f KSK -n ZONE ku.de

dnssec-keygen -a RSASHA256 -b 2048 -K /var/bind/keys/slaby-online.de/ -n ZONE slaby-online.de

dnssec-keygen -a RSASHA256 -b 2048 -K /var/bind/keys/slaby-online.de/ -f KSK -n ZONE slaby-online.de

dnssec-keygen -a RSASHA256 -b 2048 -K /var/bind/keys/slaby-online.de/ -f KSK -n ZONE slaby-online.de

Aufgrund der noch relativen Unzuverlässigkeit des BIND-eigenen dnssec-keymgrs werden "key rollovers" bei Bedarf (ZSK rollover ca. alle 6 Monate und KSK rollover etwa alle zwei Jahre) per Hand durchgeführt werden. Für den KSK wird dies mit dem "Double Signature"-Verfahren und für den ZSK mit der "Pre-publication"-Methode erfolgen.

Nameserver-Migration

Eine zusätzliche Herausforderung lag noch darin, dass die neuen Public Master bisher noch nicht die Funktion der bestehenden Nameserver übernommen hatten. Nach Einrichtung der Konfiguration mit dem "Signing Proxy" und der Verifikation der korrekten Zonentransfers konnten diese aber im laufenden Betrieb umgestellt werden.

Die beiden neuen Dell PowerEdge R310-Server bekamen per DHCP einfach die IPs und Hostnamen der bisherigen Systeme zugewiesen. Mit nur minimalen Ausfall war damit das bestehende Nameserversystem mit den bestehenden unsignierten Zonen migriert. Dank der nahtlosen Integration über den Signing Proxy konnten die zu umstellenden Zonen dann transparent und selektiv mit DNSSEC signiert werden.

Nachdem die beiden Zonen selbst mit DNSSEC mit den erstellten Schlüsseln signiert wurden, dies geschieht über den Signing Proxy durch Verwendung des "inline-signing yes"-Parameters automatisch, mussten eine typische TTL der Caching resolver, d.h. 1 Tag, abgewartet werden, um sicher zu stellen, dass die signierte Zone auch in die Caching Resolver propagiert. Dies konnte am nächsten Tag mit DNSViz überprüft werden. Hier sind in der ku.de-Zone dann schon die DNSKEYs und Signaturen sichtbar, die Zone aber aufgrund der fehlenden Delegation (noch kein DS-Eintrag in der Parentzone .de) noch als unsicher, also mit schwarzen Umrandungen, markiert.

Kommunikation des KSK an den DFN

Nachdem sicher gestellt wurde, dass die signierte Zone in die Caching resolver propagiert wurde, konnte der Hash der jeweils für die beiden Zonen erstellten KSKs an den DFN, bei dem die ku.de-Zone registriert wurde, mitgeteilt werden. Der DFN wünscht dies in einer standardisierten Email zu erhalten. Diese wurde an hostmaster@dfn.de Mittwoch mittag versendet.

Nach einigen Stunden wurde der KSK durch den DFN im DS-Eintrag der .de-Zone eingetragen, und die vollständige DNSSEC-Signierung inklusive der sicheren Delegation über den DS-Eintrag konnte mit DNSViz.net für die ku.de-Domäne überprüft werden:

DANE und TLSA-Einträge

Im SMTP-Postausgangsserver, der unter Postfix läuft, wurden die Optionen zur Verifikation der Server-TLS-Zertifikate mit DANE gemäß RFC6698 aktiviert. Hier ist zu beachten, dass Postfix einen validierenden Resolver benutzt, auf dem wir in BIND die Option "dnssec-validation auto" gesetzt haben.

smtp_dns_support_level = dnssec

smtp_tls_security_level = dane

Die Verifikation von TLS-Zertifikaten beim Versand an Mailserver, die in der Zone, in der sich der Mailserver befindet, einen TLSA-Eintrag haben, und dessen Zone, sowie die zugehörige MX-Zone DNSSEC-signiert sind, kann im Postfix-Log gesehen werden, sofern das Logging zeitweise mit

smtp_tls_loglevel = 3

hoch gestellt wird.

Da der Emailempfang der Katholischen Universität Eichstätt-Ingolstadt über die Posteingangsserver des DFN gehandhabt wird, und die dfn.de-Zone, und die sich darunter befindlichen Zonen, des DFN e.V. aktuell noch nicht mit DNSSEC signiert ist, kann hier derzeit noch kein RFC6698-konformer TLSA-Eintrag für die Serverzertifikate hinterlegt werden. Sobald der DFN e.V. die mx.srv.dfn.de-Zone, in der sich die Mailserver

befinden, mit DNSSEC vollständig, d.h. auch die übergeordneten Zonen srv.dfn.de und dfn.de, signiert haben wird, kann man hier entsprechende TLSA-Einträge mit ldns-tlsa, hash-slinger oder online erstellen und in der Zone eintragen.