Der Hauptschlüssel des Internets wird gewechselt

So, Leute: Es wird ernst. Die Root-Zone ist schon eine ganze Weile signiert und man soll auch dort mal die Schlüssel wechseln. Das ist nicht einfach, weil alle Betreiber rekursiver Resolver daran mitwirken müssen.

Es gibt drei Typen von Betroffenen:

  • Der Resolver macht kein DNSSEC, dann vergesst es.
  • Der Resolver validiert DNSSEC und es interessiert Euch nicht, dann plant einen Paniktag ein.
  • Der Resolver validiert DNSSEC und ihr wollt Panik vermeiden, dann lest und testet.

Worum geht's?

Fragt man die Root-Nameserver nach ihrem Schlüsselmaterial so gibt es folgende Antwort:

;; QUESTION SECTION:
;.                      IN DNSKEY

;; ANSWER SECTION:
.                       DNSKEY  257 3 8 (
                                AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO
                                ...
                                9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
                                ) ; key id = 20326
.                       DNSKEY  257 3 8 (
                                AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
                                ...
                                LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
                                ) ; key id = 19036
.                       DNSKEY  256 3 8 (
                                AwEAAYvxrQOOujKdZz+37P+oL4l7e35/0diH/mZITGjl
                                ...
                                jpi+V7pgh0o1KYXZgDUbiA1s9oLAL1KLSdmoIYM=
                                ) ; key id = 15768
.                       RRSIG   DNSKEY 8 0 172800 20170831000000 (
                                20170810000000 19036 .
                                D2D0oJblRe/C86Eti+vOLIHll7hvI9mN/O6S9gZqKvN2
                                ...
                                fkMFPGKWv4Gi1BlE+r+a9FDFz4ypjwdbvA== )

Die Root-Zone hat also aktuell drei Schlüssel:

  • Einen Arbeitsschlüssel (key id = 15768) und
  • zwei  Hauptschlüssel von denen Ihr bisher den mit der ID 19036 auf der Platte habt.
  • Der Schlüssel mit der ID 20326 ist neu.

Zum 11. Oktober 2017 wird die Root-Zone mit dem neuen Schlüssel unterschrieben. Dann müsst Ihr den neuen Key auf der Platte haben, sonst fällt bei Euch DNS komplett aus.

Ich habe das selbst schon mal hinbekommen, als am 26.12. mir die Signaturen der Nameserver-Records meiner Test-Root ausliefen. Ein Remote-Zugriff klappte nicht mehr, weil die SSH die IPs nicht nachschlagen konnte, die einzelnen Geräte in Panik die Dienste neu starteten und diese schon beim Start keine Gegenstelle mehr erreichen konnten (IPs nachschlagen ging nicht mehr) und sich instantan wieder beendeten.

Manuell konnte ich an der Konsole des rekursiven Nameserver den Fehler beheben. Nach einer frostigen Fahrradtour in die Firma. Ich habe geschwitzt!

Was ist zu tun?

Eure Software sollte also erkennen, dass es einen neuen Schlüssel gibt und den auf die Platte legen.

Nehmen wir an, es sei unbound. Dann findet ihr eine Datei /etc/unbound/root.key (o.ä.)

; autotrust trust anchor file
;;id: . 1
;;last_queried: 1502962961 ;;Thu Aug 17 11:42:41 2017
;;last_success: 1502962961 ;;Thu Aug 17 11:42:41 2017
;;next_probe_time: 1503005390 ;;Thu Aug 17 23:29:50 2017
;;query_failed: 0
;;query_interval: 43200
;;retry_time: 8640
.       172800  IN      DNSKEY  257 3 8 AwEAAaz/t...V74bU= ;{id = 20326 (ksk), size = 2048b}
   ;;state=2 [  VALID  ] ;;count=0 ;;lastchange=1502399011 ;;Thu Aug 10 23:03:31 2017
.       3696    IN      DNSKEY  257 3 8 AwEAAagA...ihz0= ;{id = 19036 (ksk), size = 2048b}
   ;;state=2 [  VALID  ] ;;count=0 ;;lastchange=1291045951 ;;Mon Nov 29 16:52:31 2010

Diese Datei enthält bereits beide Schlüssel und alles ist gut(TM).

Hat man dagegen unbound irgendwann mal aufgesetzt und nie richtig eingerichtet, so schaut die Datei so aus:

;;id: . 1
;;last_queried: 1414101618 ;;Fri Oct 24 00:00:18 2014
;;last_success: 1414101618 ;;Fri Oct 24 00:00:18 2014
;;next_probe_time: 1414143412 ;;Fri Oct 24 11:36:52 2014
;;query_failed: 0
;;query_interval: 43200
;;retry_time: 8640
.       86390   IN      DNSKEY  257 3 8 AwEAA...k1ihz0= ;{id = 19036 (ksk), size = 2048b}
   ;;state=2 [  VALID  ] ;;count=0 ;;lastchange=1291283901 ;;Thu Dec  2 10:58:21 2010sdf 

Wie fixed man das?

Zuerst einmal sollte unbound wissen, dass er die Datei selbst aktualisieren soll:

$ fgrep root.key /etc/unbound/unbound.conf
 auto-trust-anchor-file: "/etc/unbound/root.key"

Klar soweit?

Wenn auch das nicht hilft, kann es sein, dass die Datei nicht die notwendigen Rechte hat.

-rw-r--r-- 1 root root 758 Okt 24  2014 /etc/unbound/root.key
-rw-r--r-- 1 unbound unbound 1250 2017-08-17 11:42 /etc/unbound/root.key 

Das ist doch wohl deutlich, oder? Und natürlich leicht zu fixen.

Und andere Resolver-Software? Im Kern geht es um RFC 5011 Unterstützung. Die findet man bei Bind und anderer Software.

Achja, bitte schaut doch mal nach den Kundensystemen, von denen ihr wisst oder ahnt.

Post a comment

Verwandter Inhalt