Einführung
DNS Antworten können signiert werden, damit man überprüfen kann, ob es sich um
eine richtige und vertrauenswürdige Antwort handelt. Die DNS Antworten werden
vom authoritativen DNS Server signiert. Die Schlüssel, welche die Antworten
signieren, werden von dem DNS Server eine Zone höher signiert. Über diese
Chain-of-Trust können Anwendungssoftware und DNS Resolver prüfen, ob eine
Antwort vertrauenswürdig ist oder nicht. Mit dem DNS Server bind
kann man
seine Zonen selber signiert anbieten. Ich zeige das am Beispiel der Domain
example.org
.
NSEC vs. NSEC3
Die Nichtexistenz einer Domain ( NXDOMAIN
) wird mittels eines NSEC Records
(Next SEcure Record) bewiesen. Fragt man einen Nameserver nach einer nicht
existierenden Domain, sagt dieser “diese Domain gibt es nicht, aber folgendes
ist die nächst gültige…”. So werden alle existierenden Domains in einer Art
Linked List verkettet. Damit ist es sehr einfach die ganze Zone durchzugehen und
so alle existierenden DNS Einträge zu bekommen. Das geht z. B. mit dem Tool
ldns-walk
. Bei der neueren Version NSEC3 geht das nicht mehr, da dort der
Eintrag mit einem Salt und mehreren Iterationen gehashed werden kann. Ein
Angreifer kann mit einer Rainbowtable die Hashes vorberechnen und so offline
probieren die Zone zu enumerieren, was sehr aufwändig ist (aber möglich).
Deshalb sollte man heutzutage NSEC3 und nicht mehr nur NSEC verwenden.
Key Signing Key (KSK) erstellen
Der Key Signing Key (KSK) benötigt man um sich seinen Zone Signing Key (ZSK) zu
signieren. Der eigene KSK wird von einer DNS Zone weiter oben signiert. Alle
folgenden Arbeiten werden im Verzeichnis /etc/bind
durchgeführt. So erstellt
man ein Key Signing Key:
dnssec-keygen -3 -a RSASHA512 -b 4096 -n ZONE -r /dev/urandom -f KSK example.org
-3
aktiviert NSEC3-a RSASHA512
Typ der Signatur-b 4096
Blockgrösse
Dabei entstehen folgende Dateien:
Kexample.org.+007+28736.key
: DNSKEY Record: Öffentlicher Schlüssel. Dient zum Verifizieren der ZSK Keys. Wird von der höheren Zone signiert.Kexample.org.+007+28736.private
: Privater Schlüssel zum Signieren des öffentlichen ZSK.
Der öffentliche Schlüssel beinhaltet einen DNSKEY Record:
Darin sind folgende Werte zu sehen:
257
: Bit7
und15
vomflags
Feld: Zone Signing Key (ZSK) und Secure Entry Point (SEP) wird zusammen zum Key Signing Key (KSK); Vgl. RFC4034 (Resource Records for the DNS Security Extensions): http://tools.ietf.org/html/rfc4034#section-2.3 und RFC3757 (Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag): http://www.ietf.org/rfc/rfc3757.txt.3
: Fix vom Protokoll definiert.10
: RSASHA512, Vgl. DNSSEC Algorithm Numbers von IANA: https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml. Es gibt ein RFC Proposal welches SHA2 Hashes für DNSSEC erlaubt: http://tools.ietf.org/html/rfc5702
Zone Signing Key (ZSK) erstellen
Der Zone Signing Key (ZSK) Schlüssel wird vom eigenen KSK signiert. Die ganze Zone wird mit diesem Schlüssel signiert. So erstellt man ein Zone Signing Key:
dnssec-keygen -3 -a NSEC3RSASHA1 -b 2048 -n ZONE -r /dev/urandom example.org
Dabei entstehen folgende Dateien:
Kexample.org.+007+60310.key
: Öffentlicher Schlüssel, DNSKEY Record. Dient zum Verifizieren der DNS AntwortenKexample.org.+007+60310.private
: Privater Schlüssel zum Signieren der Ressource Records
256
: Nur Bit7
vomflags
Feld: Zone Signing Key (ZSK)3
: Fix vom Protokoll definiert.10
: RSASHA512
Zone signieren
Die neuen öffentlichen Schlüssel bindet man im Zonenfile mit der $INCLUDE
Direktive ein:
Nebenbei ein Tipp für vi
Benutzer: Die Dateinamen holt man in vi
am
einfachsten mit mit :r!ls Kexample.org.*.key
.
Jetzt kann man die Zonen signieren. Dabei bekommt man eine neue Zone mit dem
Suffix .signed
.
-3
aktiviertNSEC3
und benötigt als Parameter einen Salt, welcher aus den ersten 16 Zeichen einer SHA1 gehashten Zufallszahl besteht. Es wird empfohlen bei jedem signieren einen neuen Hash zu generieren.-H
gibt an wieviele Iterationen für den Hash gemacht werden müssen. Empfehlungen dazu gibt es im RFC4641 (DNSSEC Operational Practices): http://www.ietf.org/rfc/rfc4641.txt-t
zeigt am Schluss eine Statistik an-o
gibt die Zone an- am Schluss gibt man das das Zonenfile an
Update (25.05.2021): Der im Best Current Practice Draft " Guidance for NSEC3 parameter settings" empfohlene Wert für die Anzahl Iterationen ist 0 und kein Salt ("-").
Falls man die Keys in einem anderen Verzeichnis hat, kann man dies mit -K
angeben.
Die neue Datei der signierten Zone heisst db.example.org.signed
und beinhaltet folgendes:
- Alle Ressource Records lexographisch (alphabetisch) sortiert.
- Nach jedem Ressource Record wird ein NSEC3 Record eingefügt, welcher auf den nächsten Ressource Record zeigt (gehashed).
- Alle Ressource Records (auch die neuen NSEC3 Records) haben ein
RRSIG
Record bekommen, welches die Signatur vom Record ist. Erstellt wurde diese Signatur mit dem ZSK.
Bei jeder Änderung in der Zone, muss diese neu signiert werden.
Die signierte Zone ist 30 Tage lang gültig und muss danach wieder erneut signiert werden. Mit -e YYYYMMDDHHMMSS
kann dnssec-signzone
eine eingene Endzeit angegeben werden.
DNSSEC in Bind aktivieren
In Bind kann man dnssec
in den globalen Optionen aktivieren:
Danach aktiviert man für die zu signierende Zone das neue Zonenfile mit dem Suffix .signed
:
Key beim Registrar eintragen
Jetzt muss man DNSSEC bei seinem Registrar aktivieren. Dies geschieht zum Beispiel online. Beim Aktivieren wird man nach dem richtigen KSK gefragt, was man gestätigen muss.
Die Zone höher muss die Delegation Signer Ressource Records (DS-RR) für die darunterliegende Zone eintragen. Sind die DS-RR eine Zone höher eingetragen, kann die Zone nun verifiziert werden. Die DS-RR werden zum erstellen der Chain-of-Trust benötigt.
Es dauert es je nach dem eine Weile bis man die DS-RR
sieht:
In den DS Records sieht man den KSK, welcher hier die ID 7127
trägt.
Auch der whois
Eintrag zeigt, dass DNSSEC aktiviert ist:
DNSSEC Testen
Jetzt können die Nameserver, welche die DNSSEC Validierung aktiviert haben, die Antworten für unsere Zonen validieren.
Die öffentlichen DNS Schlüssel (KSK und ZSK) können so abgerufen werden:
Zu jedem Record bekommt man jetzt ein RRSIG Record, welcher die Signatur darstellt. Dies kann mit der Option +dnssec
in dig
aktiviert werden:
In Firefox gibt es das Plugin DNSSEC Validator, welches einem den Status von DNSSEC der Domain einer Webseite anzeigt:
Es gibt auch Webseiten, welche einem die DNSSEC Konfiguration prüfen. Hier ein Beispiel vom DNSSEC-Debugger von Verisign Labs ( http://dnssec-debugger.verisignlabs.com):
Weitere Schritte/Ideen
- Einpflegen von
SSHFP
Records für SSH Public Keys - Einfplegen von PGP Key im DNS
- Einpflegen von
TLSA
Records für DANE Unterstützung (SSL Fingerprint im DNS) - Automatisches Signieren der Zonen bevor sie ungültig werden
- Resolver nutzen, welche ungültige DNSSEC Antworten ablehnen
- Automatisches Signieren von Zonen mit Dynamischen Updates
- Sich Gedanken machen, wie man die Schlüssel am einfachsten wechselt und den ZSK regelmässig wechseln.
- Signierte Zone in einem Monitoringtool eintragen, damit man bei Problemen benachrichtigt wird
Links, Quellen und weitere Informationen
- DNS absichern mit DNSSEC. Heise. 2010: http://www.heise.de/netze/artikel/Domain-Name-System-absichern-mit-DNSsec-903318.html?view=print
- DNS Security II: DNSSEC. SysAdmin Magazine. 2004: http://www.crypt.gen.nz/papers/dns_security_2.html
- Bind 9.7 - DNSSEC for Humans. ISC. 2010: http://ripe60.ripe.net/presentations/Damas-BIND_9.7_-_DNSSE_for_humans.pdf
- Pro DNS and Bind. Ron Aitchison. Apress. 2005. ISBN: 1-59059-494-0
- Take your DNSSEC with a grain of salt. Carsten Strotmann. 2012: http://info.menandmice.com/blog/bid/73645/Take-your-DNSSEC-with-a-grain-of-salt
- RFC3757: Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag: http://tools.ietf.org/html/rfc3757
- RFC4033: DNS Security Introduction and Requirements: http://tools.ietf.org/html/rfc4033
- RFC4034: Resource Records for the DNS Security Extensions: http://tools.ietf.org/html/rfc4034)
- RFC4035: Protocol Modifications for the DNS Security Extensions: http://tools.ietf.org/html/rfc4034
- RFC4641: DNSSEC Operational Practices: http://tools.ietf.org/html/rfc4641
- RFC 5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence: http://tools.ietf.org/html/rfc5155
- Manpage
dnssec-keygen(8)
- Manpage
dnssec-signzone(8)