Technic Blog

Technik BlogDNS Security Extensions - Teil II

15. März 2017 Stefan Lauer

DNSSEC - Ein Verfahren zur Gewährleistung der Authentizität und Integrität von DNS Zonen-Daten

Durch die Verwendung von DNSSEC werden alle in einer DNS Zone befindlichen Einträge auf den authoritativen Nameservern digital signiert. Vergleichbar mit der digitalen Signatur in einer E-Mail kann so von den DNS Resolvern sichergestellt werden, das die für eine DNS Abfrage erhaltenen Ergebnisse echt und unverfälscht sind.

Nameserver Architektur

Nameserver Architektur mit Configuration Master

Alle weiteren Konfigurationen und Beispiele im Artikel beziehen sich auf diese Nameserver Architektur.
Alle Konfigurationen werden auf dem Configuration Master gemacht und von dort auf den Hidden Master übertragen.
Auf dem Hidden Master werden die zum Signieren verwendeten Schlüssel verwaltet und die Zonen signiert.
Configuration Master und Hidden Master sind durch Firewalls geschützt und nicht öffentlich zugänglich. Dadurch ist sichergestellt, dass die zum Signieren der Zonen verwendeten Schlüssel gegen Angriffe geschützt sind und das das DNSSEC Konzept nicht durch Sicherheitslücken im Betriebssystem oder in der Nameserver Software gefährdet wird.
Die Zonen werden dann vom Hidden Master auf den Primary Master übertragen.

Die Secondary Nameserver bekommen die Zonen vom Primary Nameserver. Der Primary Nameserver und die Seconday Nameserver sind Slave Nameserver. Sie sind öffentlich erreichbar und die für die Domains eingetragenen authoritativen Nameserver.

Aktivierung von DNSSEC

Bei allen signierten Zonen gibt es 2 Schlüssel (KSK und ZSK). Der KSK (Key Signing Key) dient dazu, im Zonefile die public Keys der zum Signieren einer Zone verwendeten Schlüssel zu signieren (die public Keys sind in der Zone hinterlegt als DNSKEY Records). Der Hashwert des public Keys des KSK muss auch bei dem Verantwortlichen für die Parent Zone hinterlegt werden (für .de ist das z.B. die DENIC, für .com ist das verisign), um eine sogenannte "Chain of Trust" von den Root DNS Server ausgehend bis zu den authoritativen Nameservern der Zone zu bilden. Die "Chain of Trust" wird weiter unten im Blog genauer erläutert.
Der ZSK (Zone Signing Key) dient dazu die Zone selbst (alle andere Ressource Records einer Zone) zu signieren.

Zu jedem in der Zone befindlichen Ressource Record gibt es nach dem Aktivieren von DNSSEC einen zusätzlich RRSIG Record, welcher den mit dem public Key des ZSK oder dem public Key des KSK signierten Hashwert des entsprechenden Ressource Records enthält.

Netplace hat angefangen DNSSEC bei den eigenen Domains netplace.de und netplace.com zu aktivieren, um Erfahrungen zu sammeln, ob und welche Probleme im Praxisbetrieb bei einer Domain mit aktiven DNSSEC auftreten. Aktuell wird kein KSK Rollover durchgeführt (Rollover=tunusmäßiger Austausch eines der zum Signieren verwendeten Schlüssel (aus Sicherheitsgründen)). Das heißt, nach dem Signieren der Zonen ist der initiale KSK unbegrenzt gültig. Deshalb wurde der KSK mit der größtmöglichen Keysize von 4096 Bit erzeugt.
Da der KSK einer Zone auch bei der Parent Zone hinterlegt werden muss, kann es hierbei vor allem beim Key Rollover zu Problemen kommen, da jede Parent Zone ihre eigene Schnittstelle und ihre eigenen Regularien hat. Es gäbe ein von der IETF beschriebenes Verfahren, welches dem Betreiber eines Nameservers erlauben würde, den zur Parent Zone zu übertragenen Hashwert des public Key des KSK mittels spezieller Records direkt in der DNS Zone einer Domain abzulegen. Die verantwortliche Parent Zone könnte sich diese Records dann per "Pull" automatisiert holen. Das würde die Übertragung des public Key des KSK zur Parent Zone wesentlich vereinfachen. Leider wird dieses Verfahren von den Verantwortlichen der Parent Zones (wie Verisign, DENIC etc.) momentan noch nicht umgesetzt. Wir werden deshalb erst einmal abwarten, mit welchen etwaigen Problemen die ICANN bei ihrem 2017/2018 stattfinden Rollover des KSK der Root DNS Server zu kämpfen hat und werden dann diese Erfahrungen in unsere KSK Rollover Strategie einfließen lassen.
Der ZSK wird bei uns automatisiert turnusmäßig ausgetauscht, da dort keine Interaktion mit der Parent Zone stattfinden muß.

Zum Erstellen, der zum Signieren der Zonen zu verwendenden Schlüssel, wird das Tool "dnssec-keymgr" verwendet. Damit lassen sich mit den Optionen aus einem definierten Policy File die Schlüssel erstellen und verwalten. Auch die Key Rollover lassen sich damit verwalten.

Nachdem die zum Signieren der Zone benötigten Schlüssel erzeugt und der Nameserver und die Zonen für die Verwendung von DNSSEC konfiguriert wurden, erfolgt ein Reload der Namserverkonfiguration. Dadurch werden die für DNSSEC definierten Zonen automatisiert mit den zugehörigen Schlüsseln signiert.

Nach dem Signieren werden die signierten Zonen vom Hidden Master automatisiert auf den Primary Nameserver und von dort auf die Secondary Nameserver verteilt. Sobald das geschehen ist, müssen die entsprechenden Hashwerte des public Keys des KSK von netplace.de und netplace.com bei den Parent Zonen für .de (DENIC) und .com (Verisign) hinterlegt werden. Sobald diese hinterlegten Werte in den Parent Zonen aktiv werden, ist der DNSSEC Vorgang abgeschlossen und beide Domains wurden als fully validated angezeigt (den DNSSEC Status einer Domain kann man abfragen mit dem Tool "delv":
z.B. delv +vtrace any example.com)
.

Aussehen einer signierte Zone

  • example.com. 3215 IN DNSKEY 256 3 8 AwEAAZu77tLm4/O9ZDVp9O9zzV/ws.......

    example.com. 3215 IN DNSKEY 257 3 8 AwEAAbOFAxl+Lkt0UMglZizKEC1AxUu8zl......

    example.com. 3215 IN RRSIG DNSKEY 8 2 3600 20170514032001 20170422222358 31406 example.com. GOcgQWcn/HQu8EZIuRJxHP8QrDvryUUekU8UZ4F+1RTy2ftjGwC/2g5s....

    Abfrage mit: dig DNSKEY example.com +dnssec +noall +answer


    Im DNSKEY Record mit der Key Flag 256 ist der public Key des ZSK enthalten. Der ZSK wird zum Signieren aller Records der Zone bis auf die DNSKEY Records verwendet.
    Im DNSKEY Record mit der Key Flag 257 ist der public Key des KSK enthalten. Der KSK wird verwendet um das SET aus DNSKEY 256 und DNSKEY 257 zu signieren. Die Key Flags sind immer gleich, der ZSK hat immer 256 und der KSK hat immer 257.
    Jeder der beiden Keys besteht aus einem public Key und einem private Key. In der Zone eingetragen ist immer nur der public Key des ZSK und des KSK.
    Der RRSIG DNSKEY Eintrag entsteht, in dem der über beide DNSKEY Records gebildete Hashwert mit dem private Key des KSK signiert wird.

    Der RRSIG besteht von aus folgenden Elementen:

    3215: aktueller TTL
    DNSKEY: Type des Ressource Records zu dem die RRSIG gehört
    8: benutzter Verschlüsslungsalgrorithmus
    2: Anzahl der Namenskomponenten des signierten Ressource Records (in diesem Fall 2 wegen example.com, bei z.b. www.example.com wären es 3)
    3600: TTL zum Zeitpunkt als der RRSIG erstellt wurde
    20170514032001: Endzeitpunkt bis zu dem die RRSIG gültig ist
    20170422222358: Anfangszeitpunkt ab dem die RRSIG gültig ist
    31406: Key ID des Keys mit der die RRSIG signiert wurde (in diesem Fall ist das die KeyID des KSK)
    example.com: Name der Zone
    danach kommt der signierte Hashwert des Resurce Records für den die RRSIG erstellt wurde.

  • www.example.com. 85012 IN A 93.184.216.34

    www.example.com. 85012 IN RRSIG A 8 3 86400 20170513081838 20170422102358 21214 example.com. iN9O4un35K7+VUiEo/Uyh4pWLvNgVU7voLCzPHqe....

    Abfrage mit : dig a www.example.com +dnssec +noall +answer

    dies ist zum Beispiel der A Record Eintrag für www.example.com welcher in IP Adresse 93.184.216.34 auflöst. Auch er enthält die zusätzliche Signatur RRSIG A (Die Elemente des RRSIG Records sind die gleichen, wie die beim RRSIG Record für die DNSKEY Records.(siehe oben)). 21214 ist die Key ID des ZSK mit dem die RRSIG erstellt wurde). Der RRSIG A Record wird erzeugt, indem der Hashwert des A Records mit dem privaten Schlüssel des ZSK signiert wird.


    Alle Resource Record Einträge außer den DNSKEY Records werden mit dem ZSK signiert

Welcher Vorteil ergibt sich nun aus einer signierten Zone:

Durch die Signaturen sind die Authentizität und die Integrität der jeweiligen vom Resolver abgefragten DNS Einträge gewährleistet. Dadurch das der öffentliche Schlüssel des Keys Signing Key (KSK) auch an übergeordneten Stelle (Parent) hinterlegt wurde (z.b. für .de bei der DENIC , für .com bei verisign), bildet sich eine sogenannte "Chain of Trust", d.h. von den Root DNS Servern bis zu den für eine DNS Zone verantwortlichen DNS Servern ist sichergestellt, das den zum Signieren verwendeten Schlüsseln vertraut werden kann.

Ablauf der Überprüfung der "Chain of Trust" am Beipiel www.example.com:

Chain of Trust Validierung

1. der Client fragt seinen eingetragenen DNS Server (Resolver) z.B. nach der IP Adresse für www.example.com
2. sobald der Resolver den authoritativen Nameserver a.iana-servers.net für die Zone example.com ermittelt hat, leitet er die Anfrage dorthin weiter. Falls auf dem Resolver DNSSEC enabled ist wird in der Anfrage noch zusätzlich ein DNSSEC Bit gesetzt (wodurch a.iana-servers.net veranlasst wird, für DNSSEC signierten Zonen die DNSSEC Signaturen in der Antwort mit zu liefern)
3. a.iana-servers.net liefert dem Resolver die IP Adresse für www.example.com und zusätzlich die dazugehörige Signatur
4. der Resolver fragt bei a.iana-servers.net zusätzlich noch nach den Schlüsseln, die zum Signieren der Zone verwendet wurden (DNSKEY records)
5. a.iana-servers.net liefert die DNSKEY Records für KSK und ZSK Schlüssel und die zugehörige Signatur
6. zur Überprüfung der Authentizität des KSK fragt der Resolver beim authoritative Nameserver a.gtld-servers.net für die Zone .com, nach dem dort für die Zone example.com hinterlegten Hashwert des KSK Schlüssels nach
7. a.gtld-servers.net liefert den für example.com hinterlegten KSK Hashwert an den Resolver. Dieser bildet aus dem unter Schritt 4 von a.iana-servers.net erhaltenen öffentlichen Schlüssel des KSK (DNSKEY Record) ebenfalls einen Hashwert und vergleicht die beiden Hashwerte. Stimmen sie überein ist die Authentizität des KSK Schlüssels für die Domain example.com gewährleistet
8. dieser Vorgang wiederholt sich jetzt für die Zone .com selbst: der Resolver fragt bei a.gtld-servers.net nach den Schlüsseln, die zum signieren der Zone verwendet wurden (DNSKEY records)
9. a.gtld-servers.net liefert die DNSKEY Records für KSK und ZSK Schlüssel und die zugehörige Signatur
10. zur Überprüfung der Authentizität des KSK für die Zone .com fragt der Resolver beim root Nameserver a.root-servers.net nach dem dort für die Zone .com hinterlegten KSK Hashwert nach
11. a.root-servers.net liefert den für die Zone .com hinterlegten KSK Hashwert an den Resolver. Dieser bildet aus dem unter Schritt 9 a.gtld-servers.net erhaltenen öffentlichen Schlüssel des KSK (DNSKEY Record) ebenfalls einen Hashwert und vergleicht die beiden Hashwerte. Stimmen sie überein, ist die Authentizität des KSK Schlüssels für die Zone .com gewährleistet (Den Root DNS Server selbst wird vom Resolver vertraut, die ROOT KSK Keys sind im Resolver schon als sogenannter "Trust Anchor" enthalten, deshalb ist damit die "Chain if Trust" komplett)
12. der Resolver liefert die für www.example.com ermittelte IP Adresse an den Client



Wichtig: Falls für eine Subdomain einer Zone ein eigenes Zone File definiert wurde, müssen im übergeordneten Zone File die Nameserver Einträge für die Subzone korrekt gesetzt werden, sonst kann die Subzone, selbst wenn in dieser DNSSEC nicht aktiv ist, von Resolvern an denen DNSSEC enabled ist nicht mehr aufgelöst werden.

Hintergrund: Solange eine Zone unsigniert ist, werden automatisch die Nameserver der übergeordneten Zone verwendet, wenn keine Nameserver für die Subzone definiert sind.
Wenn aber die übergeordnete Zone mit DNSSEC signiert ist, müssen explizit für die Subzone Nameserver Einträge gemacht werden, sonst schlägt die Namensauflösung für die Subzone fehl (da dies gegen die "Chain of Trust" verstößt).

Beispiel: bei der Zone example.com wäre z.B. subzone1.example.com eine Subzone mit eigenem Zone File.
d.h. im übergeordneten Zone File example.com muss explizit folgendes gesetzt werden und alle für subzone1.example.com authoritativen Nameserver müssen eingetragen werden:

subzone1.example.com.      IN    NS   Name des Primary Nameservers
subzone1.example.com.      IN    NS   Name des 1. Secondary Nameservers
subzone1.example.com.      IN    NS   Name des 2. Secondary Nameservers

FAZIT

Wir haben uns in den letzten Monaten intensiv mit dem Thema DNSSEC beschäftigt. Wir haben dabei verschiedene Möglichkeiten für die Aktivierung von DNSSEC getestet und ebenso verschiedene Verfahren für das Signieren der Zonen und für das Verwalten der zum Signieren verwendeten Schlüssel ausprobiert. Letztendlich haben wir uns dann für ein Verfahren entschieden, in welchem wir eine selbst entwickelte Lösung für die Aktivierung von DNSSEC verwenden und zum Verwalten und Erstellen der zum Signieren benötigten Schlüssel benutzen wir ein Keymanger Tool.
Das von uns eingesetzte Verfahren hat sich bisher in der Praxis bewährt und wir haben seit der Umstellung im Live Betrieb keine Probleme mit DNSSEC. Wir helfen unseren Kunden auch beim Umzug von Domains, für die bereits DNSSEC aktiviert ist, indem wir analysieren welches Verfahren für den Umzug der jeweilige Domain am besten passt.

DNSSEC ist ein komplexes Thema, das aber für uns den Aufwand für die Einarbeitung und Umsetzung wert war, da DNSSEC neben der reinen Absicherung von DNS auch noch viel Potential für weitere Anwendungsmöglichkeiten bietet. Vor allem das DANE Protokoll ist im Zusammenspiel mit DNSSEC eine interessante Möglichkeit, um von einer CA ausgestellte Zertifikate oder auch self-signed Zertifikate zusätzlich auch im DNS System zu legitimieren, was die Sicherheit beim Zugriff auf Webseiten noch weiter erhöht (wird leider momentan im Browser nur per zusätzlichen Plugin unterstützt). Durch dieses zusätzliche Legitimieren von Zertifikaten in den DNS Zonen kann auch die Sicherheit beim verschlüsselten E-Mail Verkehr weiter erhöht werden. Es besteht auch die Möglichkeit für PGP und für S/MIME die zu einer E-Mail Adresse gehörenden Schlüssel im DNS System zu hinterlegen und mittels DNSSEC Signatur die Authentizität dieser Schlüssel zu gewährleisten. Damit entfällt der mühevolle Autausch, der zum Verschlüsseln nötigen Public Keys zwischen den E-Mail Partnern, da alle E-Mail Clients die für die Verschlüsselung nötigen Public Keys direkt von einem DNS Server erhalten können und aufgrund der zusätzlichen DNSSEC Signatur auch sicher sein können, das der im DNS System hinterlegte Schlüssel auch zu der betreffenden E-Mail Adresse gehört.
Ebenso besteht mittels SSHFP die Möglichkeit SSH Key Fingerprints in der DNS Zone zu hinterlegen.

DNSSEC ist ein altes Protokoll (viele sagen auch ein veraltetes), aber wir sehen darin vor allem in Verbindung mit anderen Protokollen weiterhin viel Potential für die Zukunft.
Leider wird DNSSEC aktuell kaum eingesetzt. Es wäre deshalb wünschenswert, daß sowohl die Betreiber der großen Webseiten als auch die Betreiber der Resolver sich für die Aktivierung und Benutzung von DNSSEC entscheiden würden und im Zuge dessen mehr und mehr das gesamte Potential von DNSSEC, das weit über das reine Absichern von DNS hinausgeht, genutzt werden kann.