Zeitplan für die DNSSEC Einführung

Die Vorgehensweise für die Einführung auf den eigenen DNS-Servern ist weitestgehend frei wählbar, wenn man den in unseren Anleitungen zum Signieren der Zonen auf dem autoritativen Server und der Durchführung von Keyrollovers beschriebenen Mindestzeitbedarf beachtet.

Der größte Zeitaufwand liegt darin, sich mit der grundlegenden Theorie von DNSSEC und den möglichen Fallstricken bekannt zu machen. Hier ist auch eine gewisse Erprobungsphase auf einem nicht-kritischen System mit einer Testdomain zu empfehlen.

Notwendige und empfohlene Schritte

Die folgenden Schritte müssen durchgeführt, beziehungsweise vorbereitet werden:

1. Registrar der auf DNSSEC umzustellenden Domain und DNSSEC unterstützen (und bekannt sein)
2. Verfahren zur Kommunikation des KSK an die Parentzone muss klar sein (web interface, email)
3. Testdomain zum üben registriert sein (unterhalb der TLD!)
4. Ist ein Monitoring vorhanden, in das DNSSEC-Checks eingebunden werden können?
5. Nameserver-Software muss (aktuelles) DNSSEC unterstützen (z.B. BIND >9.9, PowerDNS >4.x)
6. Schlüssel (ZSK und KSK) pro Domain erzeugt werden
7. Domain mit den ZSK und KSK auf dem autoritativen Nameserver signieren
8. TTL (gewöhnlich 86400 Sekunden, d.h. 1 Tag) der Caching resolver abwarten
9. Überprüfen mit DNSViz über externen Caching Resolver (z.B. Google/OARC):
   DNSSEC-Kette ohne DS zwar unvollständig, aber die Zone sollte als signiert erkannt werden
10. KSK an die Parentzone kommunizieren, die den DS RR setzt
11. TTL (86400 Sek) zur Propagierung in den Caching Resolvern abwarten
12. Überprüfen der vollständigen Kette der DNSSEC-Signierung (dig oder DNSViz)

Zeitplan-Illustration

Die Ausführung an einem bestimmten Wochentag ist natürlich nicht nötig, sondern hier nur exemplarisch zu sehen.

1.-3.:

Die ersten drei Punkte sind nicht systemadministrativer Natur, sollten aber weit genug im Voraus geklärt werden. Die zeitliche Verteilung ist nach Belieben, aber die einzelnen Fragestellungen können durchaus ~ 1 Tag zur Klärung benötigen. Daher kann es sein, dass dafür eine Woche benötigt wird.

4.+5.:

Der Softwarestand der Nameserver muss bekannt sein, und darauf geprüft werden, ob DNSSEC unterstützt wird, die DNS-Software den  aktuellen und kommenden  root-KSK beinhaltet.

Die theoretische Einarbeitung, eventuell auch Lesen umfangreicherer Dokumentation zu DNSSEC (z.B. "BIND DNSSEC Guide" von ISC), kann dann erfolgen. Der Aufwand hängt natürlich von der Tiefe der Einarbeitung ab, aber mit minimal 3-4 Tagen sollte man rechnen.

6.+7.:

Mit den erzeugten ZSK/KSK-Schlüsselpaaren (es wird jeweils ein eigenes ZSK/KSK-Paar pro Domain verwendet) kann dann die Zone in der Nameserver-Software signiert werden.

8.:

Wichtig ist nun vor dem nächsten Schritt die TTL der caching resolver, im allgemeinen ein Tag, d.h. 86400s, abzuwarten.

Insbesondere für die Umstellung der Live-Domains, Haupt- und Maildomains ist planvolles Vorgehen und die Einhaltung der durch die TTL-bedingten Wartezeiten wichtig.

9.:

Der Vollständigkeit halber kann man hier einmal die DNSSEC-Signierung mit DNSViz überprüfen. Es kann hilfreich sein, sich den Fall der DNSSEC-Signierung der Zone (schwarze Markierungen der Zone selbst, türkise Signierungspfeile), aber noch nicht gesetzten DS-Records zu veranschaulichen:

Wie man den schwarzen Pfeil sieht, ist die Delegation natürlich nicht sicher, aber das ist kein fataler Fehler eines unter Umständen kompromittierten DNSSEC. Validierende Resolver erhalten also kein SERVFAIL als Antwort, und die Zone bleibt trotzdem noch erreichbar.

10.:

Als letzten Schritt der Umstellung auf DNSSEC muss - nach Abwarten einer TTL(86400s/1 Tag) noch der zu der Zone zugehörige KSK an die Parentzone kommuniziert werden. Wie diese Kommunikation erfolgen kann, oder zwingend zu erfolgen hat, hängt vom Registrar ab, bei dem die Domain registriert ist.

Für die meisten Hochschulen und Universitäten ist der DFN e.V. Registrar. Wie hier die Übermittelung des DS-Eintrags per Email erfolgen soll, haben wir auf DS-"Upload"-Formate zum Parent über den DFN beschrieben.

11.:

Erst nach dem Abwarten einer weiteren TTL von einem Tag, da wir nur keinen Einfluß auf die Handhabung der minimal erlaubten TTL der caching resolver haben, ist die vollständige DNSSEC-Signierung inklusive sicheren Delegation von der Parentzone zur DNSSEC-signierten Zone auf unserem autoritativen Nameserver auch für alle Benutzer von caching resolvern sichtbar.

Damit ist der, durch die TTL-Latenz bedingte langwierige, Umstellung unserer Zone auf DNSSEC abgeschlossen. Im nachfolgenden Schritt wollen wir das überprüfen.

12.: Überprüfung der DNSSEC-signierten Zone

Eine erste Kommandozeilen-basierte Methode zur Überprüfung der DNSSEC-Signierung einer Zone, besteht darin die Zone mit dig abzufragen, und nach zu prüfen, ob der Resolver ein "AD" (Authenticated Data) Flag gesetzt hat. Hier wird am besten ein externer Resolver (z.B.: Googles 8.8.8.8) verwendet, um sicher zu stellen, dass man keine Antwort der eigenen Resolver erhält, die eventuell kürzere TTL-Caching-Zeiten haben:

dig ws04.ws.dnssec.bayern @8.8.8.8

Die Korrektheit der DNSSEC-Signierung kann auch mit DNSViz graphisch veranschaulicht werden:

Key rollovers üben

Die Einrichtung von DNSSEC für eine Zone mit neuen Schlüsseln ist nicht der schwierigste Teil der DNSSEC-Administration einer Zone. Kritischer und mit mehr Sorgfalt und Vorsicht zu behandeln sind die Durchführung von Rollovers.

Hier stellt der ZSK noch die einfachere Variante dar, die aufgrund der nicht notwendigen Kommunikation mit der Parentzone, von der "key manager"-Komponente der DNS-Software (z.B. in BIND "dnssec-keymgr" oder in Windows) übernommen werden kann.

ZSK rollover üben

Dies ist explizit ein auf die kürzest mögliche sinnvolle Pre publication/Post publication Zeit getrimmtes Beispiel.

KSK rollover üben

Dies ist explizit ein auf die kürzest mögliche sinnvolle Pre publication/Post publication Zeit getrimmtes Beispiel. Ein praxis-orientiertes Beispiel eines KSK rollovers ist auf dieser Doku-Seite.