Signing Proxy mit OpenDNSSEC
Am RRZE wurde DNSSEC wie schon am LRZ mit dem Aufsetzen eines dedizierten "Signing Proxy"-Server eingeführt. Jedoch wurde für diesen nicht BIND verwendet, sondern das speziell für DNSSEC entwickelte Tool OpenDNSSEC. Die Vorteile eines Signing Proxy sind bereits auf der Seite über den Signing Proxy mit BIND erläutert. Auf den ersten Blick erscheint es natürlich sinnvoll einen BIND als Signing Proxy zu verwenden. Das Know-How ist bereits auf Grund der vorhandenen Nameserver verfügbar. Anders sieht es jedoch aus, wenn eine Institution gar keinen BIND einsetzt. Nach aktuellem Stand ist nämlich ein OpenDNSSEC-Proxy viel leichter zu bedienen und auch mächtiger als die Lösung mit BIND, wenn es um das Schlüsselmanagement geht. Seine Fähigkeiten machen ihn sogar interessant in Umgebungen, in denen BIND schon eingesetzt wird. So ist es auch am RRZE gewesen. Allgemein gilt jedoch, dass beide Lösungen Open-Source sind und aktiv weiterentwickelt werden. In Zukunft kann es also leicht zu einem Kopf an Kopf Rennen kommen. Schon seit der Entscheidung des RRZE auf OpenDNSSEC zu setzen, hat beispielsweise der BIND durchaus entscheidend beim Schlüsselmanagement zugelegt.
Im Folgenden nun eine Übersicht der Vorteile und Besonderheiten, die OpenDNSSEC im Vergleich zum BIND auszeichnen:
- Konzentration auf die wesentliche Funktion, nämlich das Signieren von Zonen, die lokal auf der Platte liegen, oder per Zonentransfer durchgeleitet werden (Signing Proxy). Kein vollwertiger Nameserver und schon gar kein Alleskönner wie BIND.
- Übernimmt komplettes Schlüsselmanagement soweit es automatisierbar ist. ZSK-Rollover wird beispielsweise komplett übernommen. KSK-Rollover bereitet es vor und informiert Benutzer, dass Eintragen des DS in die Parent-Zone manuell vorgenommen werden muss. Manueller Eingriff ist natürlich trotzdem möglich, beispielsweise bei einem Emergency-Rollover. Weiter unten auf dieser Seite finden sich Beispiele für das Schlüsselmanagement.
- Schlüssel und Kryptographiefunktionen werden mit Hilfe eines Hardware Security Modules (HSM) gar nicht von OpenDNSSEC selbst durchgeführt. Eine klar definierte Schnittstelle (PKCS#11) zu einem Modul in Hardware erschwert Angriffe von außen. Alternativ kann aber SoftHSM, das ebenfalls im Umfeld von OpenDNSSEC entwickelt wird, eine dedizierte Hardware-Lösung durch Software ersetzten. Mit Hilfe von p11-kit oder PKCS11-Proxy kann die PKCS#11-Schnittstelle sogar über Netzwerk geführt werden. Die privaten Schlüssel können so auf einem Hochsicherheitsserver gelagert werden.
- OpenDNSSEC besteht aus zwei getrennten Daemons:
- ods-signerd übernimmt das Signieren der Zonen und fungiert auch als Komponente für die notwendigen Zonentransfers.
- ods-enforcerd kümmert sich um die Einhaltung der Policies, die für die Zonen definiert wurden (kryptografische Eigenschaften der Schlüssel, Rollover der Schlüssel; Key and Signing Policy, KASP).
- Die Policies können sehr flexibel konfiguriert und dann den jeweiligen Zonen zugeordnet werden. Auch die Verwendung von Shared Keys, also eines Schlüssels für mehrere Zonen, ist möglich.
Dokumentation
Die Dokumentation zu OpenDNSSEC ist in einem Wiki zu finden. Dort gibt es einen Quick start guide, der durch eine einfache Installation führt.
Ein ähnlicher Guide im PDF-Format ist schon etwas älter.
Die Doku im Wiki ist sehr ausführlich, dennoch übersichtlich und jeweils auf eine konkrete Version von OpenDNSSEC bezogen. Deshalb verzichte ich hier auf weitere Ausführungen und verweise auf das Wiki.
Besonders empfohlen sei natürlich noch die Übersicht im Wiki (OpenDNSSEC 2.0).
Beispiele Schlüsselmanagement
Zentrales Tool des Schlüsselmanagements ist ods-ksmutil. Hier ein paar Bedienbeispiele.
Wann finden die nächsten Rollover statt?
# ods-ksmutil rollover list Rollovers: Zone: Keytype: Rollover expected: rrze.de KSK 2017-07-04 08:55:22 rrze.de ZSK 2017-06-25 10:40:53 uni-erlangen.de KSK 2017-09-20 12:25:05 uni-erlangen.de ZSK 2017-06-25 10:40:53 fau.de ZSK 2017-04-09 12:34:17 fau.de KSK 2017-09-20 12:23:35
Eine ausführliche Liste der Schlüssel gibt es natürlich auch:
# ods-ksmutil key list --verbose Keys: Zone: Keytype: State: Date of next transition (to): Size: Algorithm: CKA_ID: Repository: Keytag: rrze.de KSK active 2017-07-04 08:55:22 (retire) 2048 8 d72db97ffa53e2e1fe4b95ba5f5187a5 PKCS11Proxy 3569 rrze.de ZSK retire 2017-04-10 23:40:53 (dead) 1024 8 709e448cce522a9ac5757435629083e1 PKCS11Proxy 18006 rrze.de ZSK active 2017-06-25 10:40:53 (retire) 1024 8 ba7e8a7cba4106757db22b39373626ab PKCS11Proxy 7851 uni-erlangen.de KSK active 2017-09-20 12:25:05 (retire) 2048 8 2debeb08dc076fd91d0be899bea888c0 PKCS11Proxy 23492 uni-erlangen.de ZSK retire 2017-04-10 23:40:53 (dead) 1024 8 d683619c02d32be4273862cc0dde5aa9 PKCS11Proxy 43849 uni-erlangen.de ZSK active 2017-06-25 10:40:53 (retire) 1024 8 e267e9373cc6367b5d2c67b54a3c6fdc PKCS11Proxy 44605 fau.de KSK active 2017-09-20 12:23:35 (retire) 2048 8 f070edc92db001349c8b85c659b3f85e PKCS11Proxy 11405 fau.de ZSK active 2017-04-09 12:34:17 (retire) 1024 8 bb3cece4742f2b1099d167be0dc9d9ec PKCS11Proxy 7563
Man sieht gut, dass rrze.de und uni-erlangen.de gerade einen Rollover durchgeführt haben und die alten Schlüssel deshalb noch da sind. fau.de wird demnächst dran sein. Das läuft alles automatisch.
KSK-Rollover stehen auch an, die laufen dann natürlich nur teilautomatisch.
Schlüssel werden in der Regel von OpenDNSSEC selbst mit Hilfe des HSM erstellt. Also muss man sie aus dem System exportieren. Notwendig ist das natürlich beim KSK:
# ods-ksmutil key export
;active KSK DNSKEY record:
rrze.de. 3600 IN DNSKEY 257 3 8 AwEAAbvRXsKVXz1EA3kuKIepTQMxMRVwP7o58RHWaASujPolbVZ0vYiR1KqVJ3zJ9C/rGipMJ0ySmRjL1Oek12jvMxdI2Rd0RcfBxjgxx2FnI1xH07yIMENHBjBhfOjptaugPJTaRQXMfvoxotVddZUTOrnVR7gC9oaSXcrV+DZHbRljBDxWLLqVn/46eLcsaeV+Z2+XsHtvsUDmsdRFQcZf9bK0NdtRTS6CiFwfJ6m0htl3J+NODx9txePNFmV5OeSigsECC79d+mrOZeDJnMDDp/DrZXD27lmj5nuQBQCIuZSaqFRaxAMdNtK5t/BvrNy+hz4WUWs3KFKRjJf0H6Hhm00= ;{id = 3569 (ksk), size = 2048b}
;active KSK DNSKEY record:
uni-erlangen.de. 3600 IN DNSKEY 257 3 8 AwEAAdHvAedSHev13g2VYYcHccZ6xuPHr9OJeDLhLRsz7UkVYj3vRw+1fnxNf4Uv0Sl2KnCXukJ0TbvtZ0L8t34YWIuJMbpqO4bDt4kodvgPqZ7hkwUdABaYRGFaB7Zkdi56zmH673ModPjbyR+AUcmiWqqyRiumDimcaY2AOTz1j41QAgAZ3E6rVG4u+xob8FhYBwZMZNyYaYf0m60Yd3GwFfVM1SJ4DyyEMjZe5XAUGlasnCKU8SS6AWn5q9I1LTjlyOSoa1RH/rNiLWEqaeKsrp3lNZFqJkKkJFH5ZGPdVYyIOJc8cbrnUIiMEpo4PqPWWma6pA7fs87G0yqQe4iRU7c= ;{id = 23492 (ksk), size = 2048b}
;active KSK DNSKEY record:
fau.de. 3600 IN DNSKEY 257 3 8 AwEAAbr0XKFdaY43V05ukD6F77A0+6DchTTwlYEh8Tz+k5wiU2yYoOUJykVGSpHNpeS+JCkrLxuP0ihoxbkyWXN52prcyFvVrCM55oGqcCouTFv2JOdzyZVafSRl7F7PJC+eAL+tmWqG/Q973LYrL/Mcy/wxDuD05puhUeVNR6YdD2zage0kifZ96kdwOPAUzcLW8NSAHy+cN+S+LwrEZ1Q4NYCQJQgcE5Ei5QyHgY1/lEjUFDZj2vv8+cYUveWk79QOHlUwvAPJv4lKKam/j0Okchb29d8z4TkoTUVT1KQz+/owQ5pOpqkeljY+cc2ILzRH+Z4MTQuf0GfW4Zc2GnE4zkM= ;{id = 11405 (ksk), size = 2048b}
Oder falls man für das Eintragen in der Parent-Zone die DS-Records braucht:
# ods-ksmutil key export --ds ;active KSK DS record (SHA1): rrze.de. 3600 IN DS 3569 8 1 d354a5ae86df5238ab1f0c5aa7c4e8e355839aed ;active KSK DS record (SHA256): rrze.de. 3600 IN DS 3569 8 2 251d8878c2e45b2fd660e89d96f4d6ade2fd7305e382120ec208dce14bf4c5ff ;active KSK DS record (SHA1): uni-erlangen.de. 3600 IN DS 23492 8 1 bf0ee87670419c2664ae9bc471f6e1610cc423f1 ;active KSK DS record (SHA256): uni-erlangen.de. 3600 IN DS 23492 8 2 08e4d7e3638ed3de71c303255576d6b59b1a0cb2d15b518afaf4ce9099beebd9 ;active KSK DS record (SHA1): fau.de. 3600 IN DS 11405 8 1 f0e81e530ceb5721caff86cb464245252b2f1cf7 ;active KSK DS record (SHA256): fau.de. 3600 IN DS 11405 8 2 000258c3296d7020018f978363d98a4712ff0321ed21a64a25b8cd8603648857
Logdateien
Die beiden Daemons von OpenDNSSEC schreiben Logdateien und man kann ihnen daher mit den üblichen Methoden des Betriebssystems auf die Finger schauen. Beispielsweise unter Ubuntu mit:
# journalctl _SYSTEMD_UNIT=opendnssec-signer.service # journalctl _SYSTEMD_UNIT=opendnssec-enforcer.service # journalctl -f -u opendnssec-*.service
Typische Einträge im Log des ods-signerd beim Update einer Zone:
Apr 04 09:33:07 ods-signerd: [xfrd] zone uni-erlangen.de request udp/ixfr=40018124 to 10.27.27.10 Apr 04 09:33:07 ods-signerd: [xfrd] zone uni-erlangen.de received too short udp reply from 10.27.27.10, retry tcp Apr 04 09:33:07 ods-signerd: [xfrd] zone uni-erlangen.de request tcp/ixfr=40018124 to 10.27.27.10 Apr 04 09:33:10 ods-signerd: [xfrd] zone uni-erlangen.de transfer done [notify acquired 1491291187, serial on disk 40018125, notify serial 40018125] Apr 04 09:33:45 ods-signerd: [STATS] uni-erlangen.de 1491291194 RR[count=91 time=5(sec)] NSEC3[count=109 time=0(sec)] RRSIG[new=6375 reused=410123 time=18(sec) avg=354(sig/sec)] TOTAL[time=35(sec)]
Interessant am Rande: 40018124 ist die alte Serial vom Hidden Primary. 40018125 ist die aktuelle. OpenDNSSEC ist bei uns so konfiguriert, dass die signierten Zonen die Epochensekunden als Serial haben. Hier 1491291194.
Ab und an wird übrigens das übliche Resigning von RRs durchgeführt. Da gibt es dann jedes Mal einen STATS Eintrag. Außerdem schaut OpenDNSSEC natürlich auch nach, ob sich die Serial vielleicht ohne Notify erhöht hat.