Start Protokolle DNSSEC
DNSSEC E-Mail
Geschrieben von: tpm   

Dass das Domain Name System viele Schwächen aufweist, zu denen auch sicherheitskritische Faktoren zählen, ist seit Jahren bekannt. Aus diesem Grund wurde auch schon lange an dauerhaften Lösungen gearbeitet, welche im Wesentlichen auf eine Erweiterung des des Domain Name Systems und seines Protokolls um verschiedene Sicherheitsmerkmale hinausgelaufen sind.

 

Die Erweiterung am System wird DNSSEC (Domain Name System Security Extentions) bezeichnet. Das primäre Ziel dieser Erweiterung ist es die Echtheit der DNS Daten zu garantieren. Diese Maßnahme resultiert aus den vielen im Laufe der Jahre bekannt gewordenen Angriffsmöglichkeiten auf das Domain Name System. Weiterführender Weblink zum RFC 3833

Dabei verhindert DNSSEC einen Großteil der Angriffsmöglichkeiten, welche mehr oder weniger durch das bisherige DNS/Protokoll selbst verantwortet wurden, im Wesentlichen durch drei Maßnahmen:
  1. Prüfung des Clients auf Unverfälschtheit der empfangenen DNS Daten
  2. Prüfung des Clients auf Authentizität des DNS Servers
  3. Strategie zur Kennzeichnung nicht existierender Domains

Im Kern läuft DNSSEC darauf hinaus, die Echtheit der DNS Daten durch digitale Signierung mittels asymmetrischer Kryptographie sicherzustellen, wie es bereits aus verschiedenen anderen Technologien bekannt und erprobt ist.

Zum allgemeinen Verständnis dieser Technologie muss man zumindest realisieren, dass sie auf einem korrespondierenden Schlüsselpaar (privater Schlüsselteil und öffentlicher Schlüsselteil) beruht. Mit dem privaten Schlüsselteil werden Daten digital signiert, mit dem öffentlichen Schlüsselteil lässt sich die Echtheit der Signatur, respektive der Daten überprüfen. Eine Rekonstruktion des privaten Schlüsselteils über den öffentlichen Schlüsselteil ist jedoch nicht möglich.

In jedem Fall bleiben die Nutzinformationen (Resource Records) unverschlüsselt. Dies trägt zum einen dem Grundgedanken der freien Information bei. Viel entscheidender ist allerdings, dass die Abwärtskompatibilität zum bisherigen DNS System gewährleistet bleiben muss.

 

Wie dies nun bei DNSSEC umgesetzt wird, soll im Folgenden an der Domain olymp.network und unter Verwendung des Nameservers bind9 (Version 4 oder höher) genauer betrachtet werden. Zwingend erforderlich fü DNSSEC ist die Protokollerweiterung EDNS, welche momentan in der Version 0 vorliegt.

Die verwendete Zonendatei (Datenbank, die alle Resource Records einer Domain enthält) für diesen Beitrag ist relativ einfach gehalten und hat zum jetzigen Zeitpunkt folgendes Erscheinungsbild:

 

example 
$TTL	3D
@	IN SOA 	zeus.olymp.network.	root.zeus.olymp.network. (
		2009121901	; Serial
		8H		; Refresh
		2H		; Retry
		4W		; Expire
		1D )		; Negative Cache TTL
	   TXT "Eintrag im TXT Feld der Datei db.olymp.network"

collapse/expand

 

Die Prozedur beginnt mit der Erstellung von Schlüsselpaaren für die Zonendatei. DNSSEC sieht dafür zwei Schlüsselpaare vor:

  • ZSK (Zone Signing Key; private und public)
  • KSK (Key Signing Key; private und public)

Der ZSK dient zur Signierung der Resource Record Sets, womit später die Unverfälschtheit verifiziert werden kann, während mit dem KSK hierarchische Vertrauensstellungen (Chains of Trust) realisiert werden. Diese werden dann zur Authentizitätsprüfung genutzt.

 

Aus Sicherheitsgründen wird die Schlüsselerstellung und spätere Signierung auf einem separaten System, also nicht dem Live Nameserver erfolgen. Dazu ist es notwendig, dass auch auf diesem separaten System der Nameserver bind9 installiert ist und Kopien der zu signierenden Zonendateien vorliegen.

Die Erstellung der Schlüsselpaare führt der Administrator einer Domain selbst, beziehungsweise ein Zonenverwalter durch. Der Nameserver bind9 liefert dazu das Programm dnssec-keygen gleich mit. Für DNSSEC lautet die Syntax wie folgt:

 

example 
dnssec-keygen -a Algorithmus -b Schlüssellänge -n ZONE [-f KSK] Schlüsselname

 

...für die Zone olymp.network ergeben sich daraus folgende Kommandos...

 

input 
dnssec-keygen -a RSASHA1 -b 768 -n ZONE olymp.network.
dnssec-keygen -a DSA -b 1024 -n ZONE -f KSK olymp.network.

 

Anmerkung: Welche Algorithmen wofür verwendet werden, ist nicht verbindlich vorgeschrieben. Grundsätzlich sollte der ZSK eine nicht zu starken Algorithmus erhalten, während der KSK hingegen mit einem deutlich stärkeren belegt wird. Ein Grund dafür ist der, dass der ZSK um ein vielfaches öfter durch Resolver gegengerechnet wird als der KSK. Ein zu starker Algorithmus würde so unweigerlich zu einem enormen Rechenaufwand der Teilnehmer im DNSSEC System führen. Ein weiterer Grund ist der öftere Schlüsselwechsel des ZSKs, womit eine schwächere Verschlüsselung nicht zwingend ein erhöhtes Sicherheitsrisiko darstellt. Eine Übersicht der möglichen Schlüssel ist auf iana.org einsehbar. Weiterführender Weblink

Tipp: Sollte die Schlüsselerstellung überdurchschnittlich lange dauern (etwa >10 Sekunden), ist es möglich, dass es Probleme mit dem Device /dev/random gibt, welches standardmäßig für Zufallswerte herangezogen wird. Eine Lösung wäre hier die Verwendung des Devices /dev/urandom.

 

Durch die Option -n ZONE wird festgelegt, dass asymmetrische Schlüsselpaare erstellt werden sollen. Die Alternative -n HOST erstellt ein symmetrisches Schlüsselpaar, welche für Zonentransfers oder Updates der Nameserver verwendet werden. Das Thema TSIG (Transfer Signature) für sicheren Zonentransfer ist aber kein direkter Bestandteil von DNSSEC, weshalb es hier nicht weiter behandelt wird. Mit -f KSK wird der Key Signing Key definiert, womit er spezielle inhaltlich Parameter erhält, die ihn als KSK kennzeichnen. Der Parameter Schlüsselname ist ein frei wählbarer Bezeichner. Er sollte sich aber idealerweise mit dem der Zone decken, auf die er sich bezieht.

Im Resultat liegen dann vier Schlüssel vor, deren Dateinamen einem festen Muster folgen:

 

example 
KSchlüsselname+Algorithmus_ID+Key_ID.private oder .key

 

Alle Schlüssel beginnen mit einem K, gefolgt vom verwendeten Schlüsselnamen. Darauf folgt ein Code der angibt, welcher Algorithmus verwendet wurde (hier 003 für DSA und 005 für RSASHA1). Schließlich folgt ein Key Identifier und die Endung key (öffentlicher Teil) oder private (privater Teil). In diesem Fall liegen nach der Erstellung also folgende Schlüssel vor:

  • Kolymp.network.+003+34597.key
  • Kolymp.network.+003+34597.private
  • Kolymp.network.+005+05025.key
  • Kolymp.network.+005+05025.private

Zur Veranschaulichung der Inhalt der Datei Kolymp.network.+005+05025.key (öffentlicher Teil vom ZSK):

 

example 
olymp.network. IN DNSKEY 256 3 5 AwEAAbEZIEhs+0Onx10pGxhddtFsEREoRtUIM38CGGn4vF4PdYbm/kmf 
vsfOFOofBlykjQJNqynJviqieZPmkKimN4l0PT8Cb5DpF2yo717o+vRQ hwB0EMHBt4pH49zMdvtQ+Q==

 

... und der Inhalt der Datei Kolymp.network.+003+34597.key (öffentlicher Teil vom KSK)...

 

example 
olymp.network. IN DNSKEY 257 3 3 CMYSXp/ecjPRupcPXXKUAetz9W8nlvQcVrybMgLj7vOsUyUMlA+0XnKb 
vL/OyMWokbRciBZdEQjshSR+hgtM8i8PmRLNcMlgTaMnCE4DLCff6X2D +VU9KB/EzYQ8Y+a6t4R+5JTDVea8lSzZ
fr9ykroD65oLkpOpOxjUhCDp EbxEZti3UWuDgDnMMlaBGouidPMN42eIJBUSgeHv/FAmPFEQ491yaEk2 PAoR6LR
tDWTms9fTMx32X3FlFMRiEwfY5ttcEIBb1AANfQdboN6Sl8B3 Dby4FbuSfKYwkkXNDqfNOaZqqiNnQ+S8saL0PBt
sP71PhJGiZ99EW9cj TWDeXBsrVXq+4TuXwEt67PkSh7CEupsky5FR8mp/02DfSMra/skbB6qS 7XbBtAbMdPEONu
NBYE8MFI/gDZB0kzvAQ9d+CoZXxnRv46qZJ5FMMTtB VRNiPNVkYrR/GM01xEAZdIByJ5pPuO2MoSH3IbJBZjGVe9
tx8WYDlBwj 7BCiO2v9jAFZDBqQoJ4frhh3eLg/Fmca5ld/

 

Tipp: Die Differenzierung zwischen ZSK und KSK kann mitunter sehr verwirrend sein. Ein eindeutiges Merkmal für einen KSK ist der Wert hinter DNSKEY (hier 257). Ist dieser Wert ungerade, dann handelt es sich immer um einen KSK.

 

Der Resource Record Typ lautet DNSKEY, womit ein Resolver diesen Eintrag als öffentlichen Teil eines Schlüsselpaares identifizieren kann. Daher auch die Ähnlichkeit des Inhalts mit einem Resource Record einer Zonendatei. Die privaten Schlüsselteile bleiben im geschützten Besitz des Administrators/Zonenverwalters. Die öffentlichen Schlüssel hingegen werden der Zonendatei einfach im Klartext angefügt:

 

input 
cat K*.key >> db.olymp.network

 

...die verwendete Zonendatei db.olymp.network sieht nun wie folg aus:

 

example 
$TTL	3D
@	IN SOA 	zeus.olymp.network.	root.zeus.olymp.network. (
		2009121901	; Serial
		8H		; Refresh
		2H		; Retry
		4W		; Expire
		1D )		; Negative Cache TTL
	   TXT "Eintrag im TXT Feld der Datei db.olymp.network"

collapse/expand

 

Unabhängig von DNSSEC muss jetzt noch der Serial Wert erhöht werden, damit bind9 später die Zonendatei als aktuallisiert anerkennt (2009121901 -> aktuelles Datum). Alternativ kann auch bei der nachfolgenden Signierung die Option -N verwendet werden. Dieser inkrementiert den Serial Wert allerdings lediglich um 1, weshalb die manuelle Anpassung sinnvoller ist.

 

Nun ist die Zonendatei soweit vorbereitet und kann digital signiert werden. Der Nameserver bind9 liefert dazu ebenfalls einen geeigneten Befehl mit, dnssec-signzone. Auch dieser Befehl bietet eine Reihe von Optionen. Zu den wichtigen gehören unter anderem die Optionen zur Angabe des Gültigkeitszeitraums, der für zukünftige Schlüsselwechsel gut überlegten Strategien folgen sollte. Das Ziel sollte sein, zum Ablauf einer Periode immer zwei Schlüssel eines Schlüsseltyps (ZSK, KSK) in der Zonendatei zu halten. Dieses Prinzip soll folgendes Schema verdeutlichen:

 

example 
            Periode n+1           Periode n+2           Periode n+3
                 |                     |                     | 
...- ZSK n ------|\\                   |                     |
               //|------ ZSK n+1 ------|\\                   |
                                     //|------ ZSK n+2 ------|\\
                                                           //|------ ZSK n+3 -...
                                                             |
...--------------------- KSK n ------------------------------|\\
                                                           //|-------KSK n+1 -...
                                                                     
 ( - )  Schlüssel in Verwendung
 ( // ) Schlüssel angekündigt, aber noch nicht gültig
 ( \\ ) Schlüssel gültig, aber nicht weiter zur Signierung genutzt

 

Tiefer soll an dieser Stelle nicht in die Strategien zum Schlüsselwechsel (Key Rollover) eingegangen werden. Daher wird im weiteren Verlauf auch auf die Anwendung mehrerer Schlüssel vom gleichen Typ (Mehrfachsignierung) verzichtet.

Eine weitere sinnvoler Option ist -k, welche explizit den darauf folgenden Schlüssel als KSK definiert:

 

input 
dnssec-signzone -s now+0 \
-o olymp.network -k Kolymp.network.+003+34597 \
db.olymp.network Kolymp.network.+005+05025

 

...die Zonendatei wird dadurch mit dem KSK und dem ZSK signiert. Die signierte Zonendatei erhält automatisch die Dateinamenserweiterung .signed ...

 

example 
; File written on Wed Feb 10 17:25:25 2010
; dnssec_signzone version 9.4.2-P2.1
olymp.network.		259200	IN SOA	zeus.olymp.network. root.zeus.olymp.network. (
					2009121902 ; serial
					28800      ; refresh (8 hours)
					7200       ; retry (2 hours)
					2419200    ; expire (4 weeks)
					86400      ; minimum (1 day)
					)

collapse/expand

Tipp: Mit dem Programm named-checkzone kann man eine bereits signierte Zonendatei auf Formatierungsfehler überprüfen.

 

Der Signierungsprozess über das Programm dnssec-signzone hat folgende Aktionen durchgeführt:

  1. vorschriftsmäßige Formatierung
  2. hinzufügen von NSEC Einträgen
  3. anfügen der Key ID als Kommentar zu den DNSKEY Records
  4. DNSKEY Resource Record Set mit dem KSK und dem ZSK signieren
  5. alle anderen Resource Records mit dem ZSK signieren
  6. Erstellung der Dateien dsset-olymp.network. und keyset-olymp.network. im lokalen Verzeichnis

Der Signierungsprozess ist hiermit abgeschlossen. Damit der Nameserver die signierte Zonendatei nun auch nutzt, muss ihm dies natürlich mitgeteilt werden. Dazu wird in der Datei named.conf.local folgender Eintrag hinzugefügt, beziehungsweise angepasst:

 

example 
include "/etc/bind/rndc.key";

zone "olymp.network" {
	type master;
	notify no;
	file "/etc/bind/db.olymp.network.signed";
};

zone "100.168.192.in-addr.arpa" {
	type master;
	notify no;
	file "/etc/bind/db.192.168.100";
};

 

...und in der Datei named.conf.options DNSSEC aktiviert oder ggf. auch hinzugefügt werden...

 

example 
dnssec-enable yes;

 

Nach einem anschließenden Neustart oder dem neuen Laden der Konfiguration, ist der Nameserver soweit bereit, DNSSEC basierte Anfragen beantworten zu können.

 

 

Nun sollen die einzelnen Merkmale von DNSSEC unter dem Aspekt als Maßnahmen gegen Angriffsmöglichkeiten auf das DNS System erläutert werden. Die am einfachsten zu erklärende Maßnahme ist die Prüfung auf Unverfälschtheit mit Hilfe des ZSKs.

Erfragt ein Resolver beispielsweise beim DNS Server den zuständigen Mailserver für die Zone (MX Eintrag), empfängt er als Antwort:

  • den NS Eintrag selbst ( MX    10 zeus.olymp.network. )
  • seine Signatur ( RRSIG    MX 5 2 259200 20100312162525 ...gekürzt... FO6DgReGFEK/l  )
  • und den öffentlichen Schlüsselteil vom ZSK ( DNSKEY    256 3 5 ...gekürzt... ;key id = 5025 )

Da der verwendete Algorithmus (RSASHA1) ja vermerkt ist (Key Code 5), kann der Client nun die Signatur lokal gegenrechnen. Ist das Ergebnis und die Signatur gleich, kann er sicher sein, dass die Daten auf dem Transportweg nicht manipuliert wurden. Die Daten gelten damit als unverfälscht.

 

Damit hat ein Resolver aber noch keine Gewissheit, ob er auch wirklich den authorisierten DNS Server angefragt hat. Schließlich könnte er auf einen manipulierten DNS Server umgeleitet worden sein. Hierfür hat DNSSEC das Prinzip der Chain of Trust vorgesehen. Dieses beruht darauf, dass ein hierarchisch übergeordneter DNS Server (Parent) die Authenzität des untergeordneten DNS Servers (Child) bestätigt. Und an diesem Punkt kommen der Key Signing Key (KSK), sowie die vorher erstellten Dateien dsset-olymp.network. und keyset-olymp.network. ins Spiel.

Die keyset-Datei ist letztendlich nichts anderes, als der offentliche Schlüsselteil vom KSK der Domain olymp.network Die dsset-Datei hingegen enthält einen kryptologischen Hashwert auf den öffentlichen Schlüsselteil vom KSK der Domain olymp.network. und zwar in dem Format, wie es letztendlich auch in der Zonendatei der Domain network. eingetragen werden muss. Nämlich als Resource Record Typ DS (Delegation Signer).

Anmerkung: Genau genommen enthält die dsset-Datei zwei kryptologische Hashwerte. Einen mit SHA-1 und einen mit SHA-256. Letzteres wird zwar als sicherer erachtet, wird aber noch nicht in global eingesetzt. Um eine Kompatibilität für die Einführungszeit von DNSSEC zu gewährleisten, werden daher beide verwendet. Informationen zum Delegation Signer

Nachdem der Administrator der Domain olymp.network seine signierte Zonendatei in das Live System integriert hat, übergibt er die Dateien dsset-olymp.network. und keyset-olymp.network. auf einem sicheren Weg dem Administrator der Domain network. Nachdem sich dieser nun vergewissert hat, dass der ihm übergebene öffentliche Teil vom KSK wirklich im Live System der untergeordneten Domain existiert, hat er zwei Möglichkeiten:

  • einfaches anfügen des Inhalts der dsset-Datei in seine Zonendatei mit dem Befehl cat und späteres signieren
  • beim signieren seiner eigenen Zonendatei mit dnssec-signzone, der Option -g und unter Einbeziehung der keyset-Datei den kryptologischen Hashwert selbst erzeugen

Je nach dem, welche Variante gewählt wurde, kann nun der Administrator der Zonendatei network mit seinem eigenen privaten Schlüsselteil vom ZSK, die Zonendatei für die Domain network (mit oder ohne Option -g) signieren. Ab diesem Punkt vertraut der Parent dem Child und eine Chain of Trust wurde gebildet. Startet ein Resolver nun eine DNS Abfrage, arbeitet er sich durch diese Kette zum autorisierten Nameserver durch. Damit ist die Authentizität des autorisierten Nameservers gewährleistet.

 

Chain of Trust durch Delegation Signer

 

Das System mit den zwei Schlüsselvarianten (ZSK und KSK) scheint im ersten Moment etwas verwirrend, hat aber einen enormen Vorteil. Gäbe es nur einen Schlüssel und stände ein Schlüsselwechsel oder auch nur eine Änderung in der Zonendatei an, wäre jedesmal auch der Parent involviert, da er diesen ja auch mit seinem eigenen Schlüssel signieren muss, damit die Chain of Trust aufrecht erhalten bliebe.

Durch dieses 2-Schlüssel System kann der Child mit seiner Zonendatei quasi "tun und lassen, was er will", solange er den KSK benutzt, dem er auch seinem Parent übergeben hat.

 

Ein Problem das mit DNSSEC momentan noch besteht ist die Frage, wo die Chain of Trust beginnt. Dem sogenannten Trust Anchor. Der Trust Anchor definiert sich als erster sicherer Einstiegspunkt einer Chain of Trust. Früher oder später wird er bei den Root Servern beginnen. Da DNSSEC aber nicht auf einen Schlag umgesetzt werden kann, bietet es die Möglichkeit von Secure Entry Points (SEPs) für jede signierte Zone oder alternativ DNSSEC Lookaside Validators (DLVs) für mehrere signierte Zonen.

 

Fiktive Darstellung eines Archipelago of Trust inkl. DLV und einer Island of Trust inkl. SEP

 

Mehrere signierte Zonen die im Verbund einen DLV als Trust Anchor anbieten werden Archipelago of Trust genannt, während eine autarke Chain of Trust als Island of Trust bezeichnet wird. In diesem Beispiel bieten zwei Zonen SEPs an. Prinzipiell kann aber jede signierte Zone ihren SEP anbieten. Im Endeffekt ist schließlich auch ein Trust Anchor oder DLV ein SEP.

 

Administratoren können schon jetzt diverse DLVs nutzen. Einen davon stellt das ICS bereit. DLV Service auf isc.org

Wie ein Trust Anchor, DLV oder SEP weitergegeben werden, ist nicht festgeschrieben. Vorzugsweise werden sie aber von deren zuständigen Administratoren über eine sichere Website veröffentlicht, inklusive der Key Rollover Phasen. Diese können dann im lokalen Resolver eingetragen und verwendet werden. Beispiel für SEPs von ripe.net

 

Eine weitere Schwäche des bestehenden Domain Name Systems ist die fehlende eindeutige Behandlung von nicht existierenden Einträgen. Um dieses Problem zu elemieren, werden die Next Secure (NSEC) Einträge in einer Zonendatei verwendet. Jedes bekannte Ziel einer Zonendatei erhält einen NSEC Eintrag. Dieser verweist in alphabetischer Reihenfolge auf das nächste Ziel in der Zonendatei. Das letzte Ziel verweist wieder auf das erste Ziel und so schließt sich der Kreis. Zur Verdeutlichung soll folgender, auf die wesentlichen Elemente reduzierter Auszug der Zonendatei für olymp.network dienen:

 

example 
olymp.network.            259200   IN     SOA    zeus.olymp.network.
                          86400    NSEC   hera.olymp.network. NS SOA MX TXT RRSIG NSEC DNSKEY
hera.olymp.network.       259200   IN     A      192.168.100.30
                          86400    NSEC   perseus.olymp.network. A TXT RRSIG NSEC
perseus.olymp.network.    59200    IN     A      192.168.100.20
                          86400    NSEC   poseidon.olymp.network.A TXT RRSIG NSEC
poseidon.olymp.network.   59200    IN     A      192.168.100.10
                          86400    NSEC   zeus.olymp.network. A TXT RRSIG NSEC
zeus.olymp.network.       259200   IN     A      192.168.100.200
                          86400    NSEC   olymp.network. A TXT RRSIG NSEC

 

Fragt ein Resolver beispielsweise nach hermes.olymp.network, so beinhaltet die Antwort des DNS Servers unter anderem die existierenden Ziele vor ( hera.olymp.network ) und nach ( perseus.olymp.network ) diesem nicht existenten Ziel ( hermes.olymp.network ). Damit kann der Resolver validieren, dass es den Eintrag hermes.olymp.network nicht gibt.

 

Dieses Verfahren scheint vielleicht unnötig kompliziert, da es doch einfacher wäre, eine simple Antwort mit entsprechendem Vermerk an einen Resolver zurückzusenden. Mit der Idee hinter DNSSEC ständen so einem Verfahren aber einige Probleme gegenüber:

  • Zum einen enthält eine Zonendatei ja nur Ziele die sie kennt und nicht Ziele, die sie nicht kennt.
  • Des Weiteren muss jedes in der Zonendatei eingetragene Ziel digital signiert sein - was offline durchgeführt wird - bevor die signierte Zonendatei in ein Live System eingebunden wird.

Aber woher sollte ein Administrator nun wissen, nach welchem nicht existierenden Ziel später mal angefragt wird? Somit ist also ein Verfahren über eine direkte Antwort praktisch nicht durchführbar.

Ein Dilemma welches mit NSEC leider einher geht ist das Problem, dass jedermann durch gezielte Anfragen den kompletten Inhalt einer Zonendatei auslesen kann. Dieser Vorgang wird als Zonewalking bezeichnet. Vom Sicherheitsaspekt her betrachtet stellt dies erstmal kein größeres Problem dar. Aber viele DNS Server Betreiber sehen den Inhalt ihrer Zonendateien als Geschäftsgeheimis an und haben deshalb bereits seit längerem Einwände gegen NSEC vorgebracht. Als Kompromiss ist die Erweiterung NSEC3 hervorgegangen.

NSEC3 beruht darauf, dass bei einer Antwort eines DNS Servers auf ein nicht existierendes Ziel, nicht die existierenden Ziele übermittelt werden, die alphabetisch davor und danach stehen, sondern vorkonfigurierte HASH Werte. Diese lassen dann keinen Rückschluss auf die existierenden Ziele im Klartext zu. RFC 5155 auf ietf.org

Der Nameserver bind9 unterstützt NSEC3 ab Version 6. Aufgrund der deutlich erhöhten Belastung für die Teilnehmer im DNSSEC System, sowie des Netzes, sollte aber auf den Einsatz von NSEC3 verzichtet werden.

 

Nun werden noch die Protokolländerungen und Erweiterungen genauer betrachtet. Zum einen bekommen mit DNSSEC zwei bisher ungenutzte Felder im bisherigen DNS Protokoll eine wichtige Bedeutung zugesprochen. Das Checking Disabled Feld (CD) und das Authenticated Data Feld (AD). Beide Felder sind nur ein Bit groß und dienen als Flag (aktiviert / nicht aktiviert).

Des Weiteren ist, wie eingangs erwähnt, die Protokollerweiterung Enxtended DNS Version 0 (EDNS0) notwendig. Diese ermöglicht erst die erforderliche Paketgröße von bis zu 4096 Bytes via UDP, was aufgrund der zusätzlich übermittelten Informationen bei DNSSEC notwendig ist.

Anmerkung: UDP ist ein unzuverlässiges Protokoll. Das bedeutet unter anderem, dass Informationen in der Reihenfolge verarbeitet werden, wie sie beim Empfänger eintreffen. Und diese kann, aufgrund der Natur von Paketvermittelnden Netzen wie das Internet, erheblich von der Sendereihenfolge abweichen. Respektive erhält der Empfänger dann nutzlose Informationen. Solange aber alle Informationen innerhalb eines UDP Segments übertragen werden, entfällt dieses Problem. Zwar bietet schon DNS allgemein einen Fallback auf TCP, womit fragmentierte Pakete möglich wären. Aber dies verursacht unnötigen Overhead, ist damit langsamer und sollte eben nur eine Notlösung sein.

Mit in der Protokollerweiterung EDNS0 wird auch das neue Feld DNSSEC OK (DO) eingeführt, welches wie CD und AD als Flag dient.

 

Die Auswirkungen dieser drei Flags lässt sich am besten mit dem Verlauf einer klassischen Namensauflösung, beginnend bei einem lokalen Client und unter Verwendung eines vom ISP zugewiesenen primären Nameservers beschreiben:

 

Ablauf einer DNSSEC Abfrage

 

Anmerkung:  Dabei gilt es zu berücksichtigen, dass die vom ISP zugewiesenen Nameserver in der Regel reine Cached Nameserver sind. Das bedeutet, dass sie für keine Zonen autorisiert sind, respektive keine eigenen Zonendateien halten und ausschließlich Ergebnisse für einen gewissen Zeitraum zwischenspeichern.

 

Startet der lokale Resolver eine DNSSEC Anfrage, so wird in jedem Fall das DO Flag in der Erweiterung EDNS0 gesetzt. Mit dem  CD Flag lässt sich nun bestimmen, wo die Validierung durchgeführt wird:

  • Soll der ISP Nameserver die Validierung vornehmen, wird das CD Flag nicht gesetzt. Daraufhin durchläuft der ISP Namserver die Chain of Trust und validiert die Empfangenen Daten. Ist die Prüfung positiv verlaufen, enthält die Antwort an den lokalen Resolver ein gesetztes AD Flag. Somit weiß der lokale Resolver, dass die empfangenen DNS Daten bereits validiert wurden und kann ihnen vertrauen. Zusätzlich speichert der ISP Nameserver das Ergebnis für eine gewisse Zeit in seinem lokalen Cache, damit zeitnahe Anfragen an das gleiche Ziel nicht nochmal komplett validiert werden müssen.
  • Wünscht der lokale Resolver hingegen die Validierung selbstständig durchzuführen, ist das CD Flag zu setzen. Damit wird der ISP Nameserver angwiesen, alle zur Validierung notwendigen Informationen in der Antwort an den lokalen Resolver zurückzuliefern. Das AD Flag in der Antwort an den lokalen Resolver ist dann nicht gesetzt. Zudem muss der lokale Resolver bei diesem Verfahren den Trust Anchor oder SEP kennen, da dieser zur Validierung der Chain of Trust notwendig ist.

Anmerkung: Letzteres Verfahren hindert den ISP Nameserver jedoch nicht daran, trotzdem eine Validierung durchzuführen und das Ergebnis im lokalen Cache zu speichern. Schließlich könnte zeitnah ein anderer lokaler Resolver das gleiche Ziel abfragen, jedoch mit dem Wunsch, dass diesmal der ISP Nameserver die DNS Daten validiert.

 

Beim Header für das DNS Protokoll hat sich äußerlich nicht viel verändert. Lediglich die bereits angesprochenen Flags AD und CD sind hinzugekommen. Auch der Bereich Questions RRs und Answers RRs ist völlig kompatibel zum bisherigen DNS System. Die wesentlichen Zusatzinformationen, die für DNSSEC benötigt werden sind im Bereich Additional RRs untergebracht:

 

Aufbau des Protokolls mit DNSSEC (vereinfacht)

 

Der Additional RRs Bereich beginnt mit einem Eintrag, welcher die Unterstützung von EDNS (8Bit) und dessen Version (Bit) signalisiert. Darauf folgt das für DNSSEC essentielle DNSSEC OK (DO) Flag. Ist dieses gesetzt, wird den weiteren Nameservern signalisiert, dass der Resolver zum Empfang von DNSSEC Daten fähig ist. Respektive enthält dann auch die Antwort alle DNSSEC relevanten Daten. Ursprügliche Pläne alleine das Vorhandensein des EDNS0 Bereichs als Beweis für die DNSSEC Fähigkeit des Resolvers zu verwenden, wurden wieder verworfen, damit EDNS0 in Zukunft nicht nur auf die Verwendung von DNSSEC beschränkt bleibt.

Anmerkung: Die Unterbringung des Flags DO im EDNS0 Header hat entgegen weitläufiger Meinungen nichts damit zu tun, dass im DNS Header kein Platz mehr dafür wäre - schließlich wäre ja noch ein Bit frei. Vielmehr macht es, unter Berücksichtigung aller Aspekte, an seiner jetzigen Stelle einfach mehr Sinn.

Die weiteren Einträge im Bereich Additional RRs variieren, je nach Art der Anfrage. Dieses stellt die wesentlichen zusätzlichen Einträge in der Antwort eines autorisierten Nameservers für einen gültigen Eintrag dar. Dazu gehört zum einen der öffentliche Schlüsselteil vom ZSK, sowie der Eintrag zur kompletten Signaturinformation, welche sich durch das Feld Type Covered auf einen eindeutigen Resource Record (oder Resource Record Set) im Bereich Answers RR bezieht. Weblink zu rfc-archive.org

 

Zusammenfassend lässt sich feststellen, dass DNSSEC das bestehende DNS System alles andere als vereinfacht. Aber die Notwendigkeit eines Verifizierungssystems wurde ja bereits zu Beginn verdeutlicht. Dass DNSSEC in dieser Form umgesetzt wurde, ist ein Kompromiss aus Kompatibilität zum bestehenden DNS System, sowie Kriterien großer DNS Server Betreiber.

Zumindest kann man sich gewiss sein, dass die Administration von Nameservern die DNSSEC unterstützen, durch eine Vielzahl an Tools um einiges erleichtert wird.

 


Zusätzliche Informationen:

  • Ein bestehendes Problem ist noch die Unterstützung von DNSSEC und EDNS0 bei vielen SOHO Routern.
  • Durch den erhöhten Rechenaufwand und Netzwerkverkehr, können DDoS Attacken theoretisch effektiver durchgeführt werden.
  • In Betriebssystem implementierte Resolver (bsp. Windows 7) sind in der Regel non-validating security-aware Resolver. Das bedeutet, dass sie lediglich das Flag AD in einer Antwort auswerten können. Die Validierung übernimmt dann entweder der Nameserver des ISPs oder ein Windows Server mit aktivem DNS Server im Local Area Network.
Zuletzt aktualisiert am Samstag, den 23. Oktober 2010 um 11:03 Uhr