DNSSEC: Knot-Resolver für den Rollover des Root-Keys vorbereiten

Wir fassen im Folgenden zusammen, wie der Resolver Knot den aktuellen Vertrauensanker der Root-DNS-Zone selbstständig lädt und erläutern, was zu tun ist, wenn das nicht klappt.

Der Knot DNS Resolver, kurz knotr, ist ein noch junger, validierender Resolver, den CZ.NIC, der Betreiber der tschechischen Top-Level-Domain .cz, entwickelt. Knotr steckt unter anderem im Open-Source-Router Turris Omnia, der ebenfalls von CZ.NIC stammt. Wie man den Vertrauensanker beim DNS-Resolver PowerDNS aktuallisiert haben wir in einem separaten Beitrag beschrieben. Im Artikel Schlüsseldienst – Handreichungen für den Key-Rollover der Root-Zone beschreiben wir, warum der Schlüsselwechsel erforderlich ist, weshalb viele Nutzer betroffen sind, wenn DNS-Resolver den Schlüssel nicht aktualisieren und wie Administratoren den Schlüsselwechsel für die gängigen Resolver überwachen und notfalls per Hand sicherstellen können.

knotr gehört zu den Resolvern, die den Vertrauensanker, den Key Signing Key der DNS-Root-Zone (KSK), selbstständig gemäß dem RFC 5011 aktualisieren können, sodass man den Vorgang im Idealfall lediglich prüfen muss. Die Automatik funktioniert aber nur, wenn man in knotr, respektive dem Daemonprozess namens kresd die Validierung eingeschaltet hat – dann lädt er den aktuellen Vertrauensanker der Root-DNS-Zone selbstständig von der IANA-Webseite (TLS abgesichert mittels Zertifikat-Pinning). Er speichert die Datei entweder im Pfad, den man beim Start des Resolvers auf der Kommandozeile angegeben hat oder im Pfad, der in der Konfigurationsdatei steht. Mehr dazu finden Sie in der knotr-Dokumentation.

Vertrauensanker finden

Startet man kresd über die Kommandozeile und aktiviert die Validierung, prüft der Daemon zunächst, ob er im angegebenen Pfad einen Vertrauensanker finden kann:

kresd -c /etc/knotr.conf -k /etc/knotr/root.keys -q

Wenn er keinen Root-Key finden kann, versucht er ihn zu laden. Die zugehörigen Meldungen sehen so aus:

[ ta ] keyfile '/etc/knotr-root.keys': doesn't exist, bootstrapping
[ ta ] Root trust anchors bootstrapped over https with pinned certificate.
You may want to verify them manually, as described on:
https://data.iana.org/root-anchors/old/draft-icann-dnssec-trust-anchor.html#sigs

Der Key Signing Key der Root-DNS-Zone liegt im Standard-Format für DNS-Zonendateien vor (mehr dazu finden Sie im RFC 1035):

. 172800 DNSKEY 257 3 8 AwEAAagAI[...]xA+Uk1ihz0= ; Valid: ; KeyTag:19036

Auf Turris-Omnia-Routern findet kresd den Vertrauensanker in der Datei /etc/root.keys.

Wenn der Vertrauensanker am richtigen Platz liegt, kümmert sich knotr selbst darum, den Vertrauensanker aktuell zu halten (gemäß RFC 5011). Sobald er in der Root-DNS-Zone einen neuen Key findet, lädt er ihn selbstständig. Er aktiviert ihn als neuen Vertrauensanker aber erst, wenn die Hold-Down-Time verstrichen ist – das heißt, wenn der Key 30 Tage lang ununterbrochen in der DNS-Root-Zone vorgelegen hat. Das ist ein Sicherheitspuffer des RFC 5011, der verhindern soll, dass Angreifer ihren eigenen Key über die DNS-Root-Zone verbreiten. Dazu müssten sie die Root-Zone mindestens 30 Tage lang unter ihrer Kontrolle halten. Der neue KSK wird voraussichtlich am 11. Juli 2017 in der Root-DNS-Zone publiziert.

Zugriffsrechte beschränken

Zu beachten ist, dass man die Zugriffsrechte auf den Vertrauensanker in der Konfigurationsdatei trust_anchors.config auf "nur-lesen" stellen kann. Das ist notwendig, wenn die Datei auf einem nichtbeschreibbaren Laufwerk liegt. Ist der Resolver so konfiguriert, kann knotr den Vertrauensanker nicht automatisch erneuern. Dann müssen Sie die Datei, respektive das Laufwerk vor dem 11. Oktober 2017 manuell aktualisieren, denn ab diesem Datum wird die DNS-Root-Zone mit dem neuen KSK-Schlüssel signiert.

Ein Weg dazu besteht darin, das DNS-Analyseprogramm dig zu verwenden. Wie das geht, beschreiben die Entwickler in der knotr-Dokumentation im Abschnitt zur DNSSEC-Konfiguration. (dz)