Public Keys für das DNS

Transkript

1 DNSSEC verheiratet Namensauflösung und PKI 66 Beglaubigte Adressen Manche Angriffe aus dem Internet richten sich gegen den wichtigen Dienst der Namensauflösung. DNSSEC tritt an, um diesen Dienst mit moderner Kryptographie zu versehen. Sowohl die Admins der Anwender als auch die der Anbieter müssen aber mitspielen, um mehr Authentizität zu schaffen. Eric Amberg Normalerweise läuft die Sache so: Surft ein Anwender etwa [ linux-magazin.de] per Browser an, schickt sein Rechner zuerst eine Anfrage an den in der»/etc/resolv.conf«konfigurierten Nameserver [1]. Der möge anhand der in der URL enthaltenen FQDN die IP liefern. Kann dieser kontaktierte Resolver den Request nicht selbst beantworten, fragt er hierarchisch im Internet weitere Server, bis er eine Antwort erhält [2]. Die Adresse nutzt der Browser schließlich, um die Inhalte abzurufen. Für den Benutzer verläuft dieser Vorgang automatisch im Hintergrund. Er will sich aber darauf verlassen, dass die Antwort unverfälscht, also authentisch bei ihm ankommt. Manipulieren Angreifer die Namensauflösung, landet der Benutzer auf einer ganz anderen Webseite. Um das zu verhindern, erweitern die DNS Security Extensions (DNSSEC) den bewährten Namensdienst um kryptographische Signaturen der einzelnen Einträge [3]. Aber auch das reicht alleine noch nicht aus: Die öffentlichen Schlüssel der verwendeten asymmetrischen Verschlüsslung müssen ebenso authentisch sein. Effektiv ist dazu eine Public- Key-Infrastruktur (PKI) notwendig. Public Keys für das DNS Um beide Elemente der Namensauflösung hinzuzufügen, bedarf es zunächst eines Resolvers, der mit DNSSEC umgehen kann. Da die meisten zum Beispiel die in der Libc eingebauten Stub-Resolver dazu nicht in der Lage sind, installieren Admins im Netz des Unternehmens oder der Organisation einen Nameserver und aktiviert dessen DNSSEC. Fragen nun die Clients im Netzwerk diesen Server nach IP-Adressen, liefert er mittels DNSSEC gesicherte Erkenntnisse. Der Weg zwischen Client und erstem Server bleibt dabei jedoch ungesichert und lässt sich zumindest theoretisch ma- nipulieren. Jeder Sicherheitsverantwortliche muss für sich entscheiden, ob dies für seine Nutzer ein Problem ist. Der DNSSEC-Resolver prüft nun, ob die Anfrage in einer Zone liegt, die der Betreiber der Domain durch DNSSEC gesichert hat. Das ist immer dann der Fall, wenn der Request im Bereich eines Secure Island liegt. Die obersten Knoten solcher Strukturen heißen Secure Entry Points (SEP, siehe Abbildung 1). Der Admin muss sie a priori im DNSSEC-Resolver eintragen. Die Liste der SEPs entspricht damit funktional ungefähr den mitgelieferten CA-Zertifikaten in einem Webbrowser. Eine einsame Insel Praktisch ist, dass DNSSEC die gleichen Zugriffsmechanismen wie das klassische DNS nutzt. Weil der Resolver nur Resource Records (RR) von einem Server abfragt, ist das System abwärtskompatibel. Die zusätzliche Sicherheit besteht darin, dass ein DNSSEC-aktivierter Resolver Signaturen auf den Resource Records validiert. Ist eine Antwort mal nicht korrekt, verwirft er sie. Das ist ein sehr sicheres Verfahren, da die Benutzer gar nicht erst in Versuchung kommen, eine potenziell kompromittierte Antwort zu verwenden. Für die Anwender kann es aber auch ungewohnt sein, da der Server mit»nxdo- MAIN«antwortet. Dies bedeutet so viel wie Diese Domain gibt es nicht. Im Vergleich dazu öffnet sich beim Einsatz einer PKI mit Webzertifikaten in diesem Fall ein Fenster. Der Benutzer entscheidet nun, wie er auf das ungültige Zertifikat reagiert leider schlagen viele die Warnung einfach aus.

2 Liegt die Anfrage jedoch nicht innerhalb eines Secure Island, löst der Resolver die Anfrage mit herkömmlichen Methoden auf und liefert die Antwort an den anfragenden Client. Sicherheitsverantwortliche sollten sich beim Einsatz von DNSSEC im Klaren darüber sein, dass Nutzer nicht ohne Weiteres erkennen können, ob Antworten vom Server durch DNSSEC gesichert waren oder nicht. Langfristig streben die Befürworter des DNSSEC-Systems dahin, nur noch einen einzigen SEP zu haben, der auf die Root- Zone des DNS zeigt. Eine Chain of Trust verkettet die Signaturschlüssel sämtlicher hierarchisch darunterliegender Zonen. Dies erlaubt es DNSSEC-Resolvern, Signaturen zu validieren. In der Praxis ist es jedoch noch nicht ganz so weit gekommen, noch existieren mehrere unabhängige Secure Islands. Bis diese zusammenwachsen, werden Administratoren von Resolvern noch mehrere Trusted Keys als SEPs pflegen müssen. Teamwork ist gefragt Um DNSSEC zu einem Erfolg werden zu lassen, ist die Mithilfe zweier Gruppen notwendig: Anwender profitieren nur dann vom System, wenn Netzverwalter für ihre Anwender Server bereitstellen, die per DNSSEC Antworten validieren, und Betreiber von Nameservern ihre Zonen signieren und in das Vertrauensgeflecht der über ihnen liegenden Zonen einbinden [4]. Der freie Nameserver ISC sub1.abc.org abc.org sub2.abc.org sub3.abc.org. (Root) Bind, der vielen als Referenzimplementation von DNS gilt, liefert für beide Einsatzzwecke Lösungen [5]. Dazu erweitert der DNSSEC-Nameserver sein Zonefile. Neben den administrativen Informationen im SOA enthält es hauptsächlich Resource Records, die eine entsprechende Zuordnung von DNS-Namen zu IP-Adressen oder anderen Namen oder umgekehrt enthalten. DNSSEC schützt diese RRs mittels Signaturen. Um das zu bewerkstelligen, führt DNSSEC eine Reihe weiterer RRs ein, die Tabelle 1 auflistet. Verkettetes Vertrauen DNSSEC arbeitet mit asymmetrischen Schlüsselpaaren, also mit öffentlichen und zugehörigen privaten Schlüsseln. Die Architekten der IETF (Internet Engineering Task Force) haben das System zweistufig entworfen: Ein Zone Signing Key (ZSK) schützt die einzelnen Resource Records eines Zonefile. Er ist seinerseits durch den Key Signing Key (KSK) geschützt (Abbildung 2). Innerhalb einer Zone reicht die Kenntnis des öffentlichen KSK aus, um zunächst den ZSK und dann die RRs zu validieren. Von einer Parent- zu einer Child-Zone stellt DNSSEC das Vertrauen über den Resource Record Delegation Signer her. Ganz oben in der Kette des Vertrauens thront ein KSK, den die Spezifikation Secure Entry Point oder auch Trusted Anchor nennt, der darunter liegende.org.de.arpa SEP sub1.xyz.de xyz.de sub2.xyz.de sub3.xyz.de ftp.sub2.xyz.de Secure Island 194.in-addr.arpa in-addr.arpa in-addr.arpa 195.in-addr.arpa Secure Island Abbildung 1: DNSSEC bildet Secure Entry Points (SEP) im Domänenbaum des DNS. Später sollen die Secure Islands einmal zu einem großen DNS-Kontinent zusammenwachsen. SEP Zonenbaum dient als Secure Island. Es liegt am Admin einer Organisation, solche SEPs in der Konfiguration seines DNSSEC-Servers zu pflegen. Dazu trägt er die KSKs der von ihm gewünschten Secure Islands in die Sektion»trusted-keys«der Konfigurationsdatei»named.conf«ein (siehe Listing 1). Er sollte in der Hierarchie möglichst die höchsten verfügbaren KSKs nutzen und natürlich darauf achten, dass diese Schlüssel selbst authentisch übertragen wurden. Nach dem Zonennamen folgen drei Felder: Das Flags Field definiert die Art des Schlüssels 256 steht für ZSK und 257 für KSK. Das zweite Feld nennt sich Protocol Field und muss laut RFC 4034 immer 3 enthalten. Der dritte Wert spezifiziert den benutzten Algorithmus, wobei 5 für RSA/ SHA-1 steht. Client oder Server? Das Standardszenario ist ein DNS-Server als Resolver im lokalen Netzwerk, der einen Forwarder befragt, beispielsweise beim Provider. Die so erhaltenen Antworten vom Provider-DNS-Server validiert er. Bevor das möglich ist, muss der Administrator zunächst DNSSEC einschalten. ISC empfiehlt den Bind-Server Listing 1: DNS-Config der SEPs 01 trusted-keys { 02 "example.com." "AwEAAcDKu5Kqbk92caGeQ2GjQDucJ2t6jfUb 04 gdye+zyw6qs9porvim5vitifft1jygb5rngf 05 wfwqedm2eeopakoynjdnvagdjfd/4sep7djw 06 A4zPEvy8LYXCAqkbL5FqZcv9fbYHF2rKYlZJ 07 y5mbmeok/x4nrxcjwsicbpie4/mhjwmr1+ja 08 AVlyODwko2edeilKuW5y/LpPvdZ3qXsw6mTU 09 pa39ncgbzdbhvyfzrqhnxjcd2cy6rwe5zyck 10 c9vyqqafflxx5h56aif0mi1i7f7uzjm6waic 11 iv+ckvufkbcdqpobthbwh67vqd8kljlrsegt 12 wrwzbgfjhugkm56mhzcfytk="; "tux.local." "AwEAAa+z+JB9qd6Q9Kg7isg/DqJdqX9Kqxpu 16 One4zGlUWNJXAT5ivVva5N4l1YOPfq2M+dJH 17 Mxg9jmFZmrTLS8HYvuYzTVuBMh1u3hvS6UBr 18 SzEJdqWDpO/AJbWDUP+SIfryeW0ZV7weHDX7 19 Xjqrrh2+8+Dc/k8LFxoocBeio9gljYMLdIvM 20 ddouohfxx6o4wvvnhuwf+i1hdoqgdoowgrck 21 9KO0fZpx8h/dwwyqL4/9Zk0MLF6KQaxg0+tQ 22 khhi6sq+7bymnnbaujqlwly8qrla/gaajahu 23 PaHbJ1vzg+G5mLFI1vEt5FTGVXWJp0GWD6yK 24 uldryll0ooapq8fg9aqmrvk="; 25 }; Sysadmin 67

3 68 ab der Version Das Programm erfordert, DNSSEC bereits beim Übersetzen zu aktivieren. Die meisten Distributionen haben diese Option in ihren»bind9«-paketen bereits vorbereitet. Die»dnssec-tools«sind für manchen Test und das Debugging nützlich, aber nicht zum Betrieb notwendig. In der Konfigurationsdatei»named.conf«setzt der Admin zunächst die Option»dnssec-enable yes;«, um die DNSSEC- Funktionalität generell zu aktivieren. Ist mindestens ein Trusted Key als SEP definiert, bleibt nur noch ein Reload von»named«per Init-Skript und der Resolver im Beispiel validiert die Zonen»example.com«,»tux.local«und alle per Chain of Trust darunterliegenden Zonen, etwa»filiale1.example.com«. Signieren einer Zone Betreiber von Nameservern müssen natürlich erst einmal Schlüsselpaare für ihre Domains und Zonen generieren und einrichten. Auf dem Primary-Domain- Server erzeugt der Admin zunächst Zone Signing Keys und Key Signing Keys, um 01 cat Kexample.net key 02 example.net. IN DNSKEY ( 03 ZUPI4+0M1V0+SQmFzHQtZMuzLH3UxWE0GmG5Gfj ijandhgg8ld3io1azwn6divfevzgr0otaddonfy =oelkw== ) Listing 2: Key-Eintrag für Zonefile damit die einzelnen Zoneneinträge zu signieren. Alle für eine Zone zuständigen (und damit autoritativen) Server muss er für DNSSEC mit der Option»dnssec-enable yes;«aktivieren. Auf dem Primary Nameserver erzeugt er mit dem Befehl dnssec-keygen -a RSASHA1 -b 2048 U -n ZONE example.com ein Schlüsselpaar für die Zone»example. com«. Die Option»-a«spezifiziert die Algorithmen, hier RSA und SHA-1. Der Admin kann auch andere Algorithmen wie beispielsweise DSA oder RSA/MD5 angeben, die Entwickler empfehlen aber meist RSA mit SHA-1. Der Parameter»-b«gibt die Schlüssellänge an, mit»-n«folgt der Eigner des Eintrags. Für Zonen ist dies»zone«, darüber hinaus gibt es unter anderem»host«,»entity«und»user«, die jedoch in dieser Betrachtung keine Rolle spielen. Der so erstellte Schlüssel dient als ZSK. Um einen passenden KSK zu erzeugen, ergänzt der Administrator den Befehl um die Option»-f KSK«. Als Ergebnis entsteht zum Beispiel die Datei mit dem Namen»Kexample.net «. Er besteht aus der Verkettung eines»k«für den KSK, des Domainnamens, der Verschlüsselungs- und Hash-Algorithmen und einer zufällig generierte Key-ID, jeweils getrennt durch ein Pluszeichen. Bei den Algorithmen steht 1 für RSA/ MD5, 3 für DSA und 5 für RSA/SHA-1. Nachdem der Sysadmin die Schlüssel generiert hat, befinden sich im aktuellen Verzeichnis der öffentliche, auf».key«endende, sowie der private Schlüssel, der auf».private«endet. Den öffentlichen Schlüssel (siehe Listing 2) darf der Betreiber des Nameservers nun direkt per Direktive»$include«in sein Zonefile einbinden, wie Listing 3 zeigt. Schlüssel an Zonen binden Im Anschluss lässt sich die Zone mit»dnssec-signzone«signieren und mit dnssec-signzone -o example.com U -k Kexample.com U example.com.zone Kexample.com entsprechend modifizieren. Dabei gibt»-k«den KSK an. Das Programm sortiert nun die Zoneneinträge, fügt NSEC- Records ein, DNSKEY-RRs durch ZSK und KSK, alle anderen Einträge durch den ZSK. Zusätzlich erzeugt es die neuen Dateien»dsset-example.com«und»keyset-example.com«. Die neue Datei erhält».signed«als Endung. Die resultierenden Zoneneinträge zeigt Listing 4 im Detail, die Schlüssel sind stark gekürzt dargestellt. Je ein RRSIG-Record mittels privatem ZSK einen der ursprünglichen Einträge der Zone. Der Server veröffentlicht die beiden Public Keys des ZSK (256) und des KSK (257) über den Resource Listing 3: Zonefile vor der Signatur 01 ; example.com zone 02 ; 03 $TTL $ORIGIN example.com IN SOA ns1.example.com. ( 07 admin.example.com ) NS ns.example.com. 16 ns1.example.com. A a A b A $include Kexample.com key ; ZSK 21 $include Kexample.com key ; KSK Parent-Zone: Start of Authorization (SOA) Key Signing Key (KSK) Zone Signing Key (ZSK) Resource Record 1: IN A Resource Record 2: IN A Resource Record 3: IN A Resource Record n: DS... verweist per Hash gesichert auf Secure Entry Point (SEP) Child-Zone: Start of Authorization (SOA) Key Signing Key (KSK) Zone Signing Key (ZSK) Resource Record 1: IN A Resource Record 2: IN A Resource Record 3: IN A Resource Record n: DS... Abbildung 2: Der Key Signing Key (KSK) den Zone Signing Key (ZSK), der alle anderen Zonefile-Einträge. Das hierarchische PKI-System ist analog zur Struktur Aufbau von DNS-Zonen aufgebaut.

4 Record»DNSKEY«. An dieser Stelle signieren sich die Schlüsselpaare gegenseitig. Alle anderen Signaturen führt der ZSK durch. Damit niemand unbemerkt einen Eintrag aus einer Zone entfernt, sind die sortierten RRs ringförmig verkettet. Ironischerweise ist genau dieser NSEC-RR eines der größten Hindernisse bei der flächendeckenden Einführung von DNSSEC: Einige Kritiker melden Datenschutzbedenken an, da Angreifer so alle Einträge einer Zone abfragen können. Dies nennen Experten Zone Walking. Nach dem erneuten Einlesen der Zonendateien liefert der Server die DNS-Antworten zusammen mit seinen Signaturen aus. Die Zonensignaturen sind standardmäßig 30 Tage gültig. Mit der Option»-e YYYYMMDDHHMMSS«passt ein Betreiber die Gültigkeitsdauer der Signaturen an. Anschließend muss der Administrator händisch oder per (zeitgesteuertem) Skript ein Zone Re-Signing durchführen, indem er»dnssec-signzone«mit den entsprechenden Optionen erneut aufruft. Wer Einträge zu einer Zone hinzufügt oder entfernt, muss sie zwangsläufig neu signieren. Nachdem der Admin seine Parent-Zone gesichert hat, darf er per Chain of Trust auch Child-Zonen schützen. Ein Resolver kann sich über einen Delegation- Signer-Eintrag (DS-RR) zur delegierten Tabelle 1: Neue Resource Records Zone hinabhangeln. Ein Hashwert in diesem Record nämlich den KSK der untergeordneten Zone. Vertrauen erwerben Die Signatur-Prozedur legt mittels»dnssec-signzone«zwei Dateien an,»dsset-example.com«und»keyset-example. com«. Mindestens eine der beiden muss der Administrator einer untergeordneten Zone seinem Kollegen zukommen lassen, der die Parent-Zone verwaltet. Der DS-Set in»dsset-example.com«enthält bereits einen passenden DS-RR, wie er im Zonefile des Parent einzutragen ist. Hat der Administrator»dnssec-signzone«für die Child-Zone»filiale1.example. com«ausgeführt, bekommt die Datei eine Zeile der Art: filiale1.example.com. IN DS U AE9882AD0F80C91663A1ADE3742B2BF2403A7283 Der Key-Set in der Datei»keyset-fili ale1. example.com«dagegen enthält den DNS- KEY-Zonefile-Eintrag für den KSK der Child-Zone. Damit kann der Admin des Parent den DS-Eintrag selbst einrichten, indem er den Schlüssel in einer Datei mit feststehendem Präfix»keyset-child«ablegt, also in diesem Fall»keyset-childfiliale1.example.com«. Sämtliche Dateien liegen im Zonefile- Verzeichnis gespeichert. Sind alle neuen Resource Record Beschreibung der Funktion DNSKEY Enthält zum einen den öffentlichen Teil des Zone Signing Key (ZSK) und zum anderen den öffentlichen Teil des Key Signing Key (KSK). RDATA Enthält neben dem Key auch die Angabe, welcher Art der Key ist, (R wie right, rechts) welchen Algorithmus und welches Protokoll DNSSEC nutzt. Außerdem ist zur eindeutigen Identifikation die Key-ID angegeben, die der Key im Dateinamen enthält. In der ursprünglichen Fassung im RFC 2535 hieß dieser Record»KEY«. Es war dabei möglich, einen beliebigen Public Key abzulegen, also beispielsweise auch für Benutzer. Dies führte zu einem unerwünschten Mehraufwand des Clients bei der Verfolgung der Chain of Trust. Die neue Fassung beschränkt Public Keys auf ZSK und KSK. RRSIG Gibt die Signatur des übergeordneten Resource Record an. Das Feld (Resource Record RDATA enthält unter anderem den en RR-Typ, den benutzten Signature) Algorithmus, das Ablaufdatum der Signatur und die Signatur selbst. NSEC (Next Entry) Gibt den jeweils nächsten Eintrag im Zonefile an. Ist der letzte Eintrag eines Zonefile erreicht, zeigt»nsec«auf den ersten Eintrag. Das stellt sicher, dass niemand Einträge unbemerkt löscht, da auch der»nsec«- Eintrag selbstverständlich durch einen»rrsig«ist. Gerade»NSEC«erweist sich allerdings als ein großes Problem bei der globalen Einführung von DNSSEC, da der Resource Record das so genannte Zone Walking ermöglicht. Dabei liest der Angreifer sukzessive alle Einträge aus einem Zonefile aus. DS (Delegation Signer) Ermöglicht es, einen Validierungsschlüssel einer untergeordneten Zone zu signieren, um so eine Chain of Trust zu erzeugen. Dateien am Platz, der Betreiber die Parent-Zone erneut, um die Verknüpfungen zu aktivieren. Er fügt die Option»-d«hinzu, damit»dnssec-signzone«automatisch den verbindenden DS-Record erzeugt. Alternativ bindet er das DS-Set mit der Direktive»$include«ein und das Zonefile des Parent. Hat der DS-Eintrag den KSK der Child- Zone»filiale1.example.com«und kennt ein DNSSEC-aktivierter Resolver den KSK des Parents als SEP, dann validiert er nun sowohl die Parent-Zone als auch die Child-Zone. Dies Verfahren lässt sich für weitere untergeordnete Zonen beliebig fortführen. Waisenkinder Ist die Parent-Zone ungesichert, besteht die Möglichkeit, den eigenen KSK über eine DNSSEC Lookaside Validation (DLV) Registry validieren zu lassen. ISC selbst stellt eine DLV-Registry zur Verfügung [6]. Möchte der Administrator den KSK seiner Zone an die DLV-Registry übermitteln, übergibt er mit»-l«deren Adresse: dnssec-signzone -l dlv.isc.org U -o example.com U -k Kexample.com U example.com.zone Kexample.net Der Aufruf schreibt die Datei»dlvsetexample.com«, die der Admin per an»dlv-registry@isc.org«zusammen mit dem Domainnamen und dem Namen des Administrators an ISC sendet. Nach einer Prüfung durch den DLV-Registrar richtet er einen DS-Record ein, der auf die Zone des Antragstellers zeigt. Somit eignet sich der von ISC betriebene Name server gut als SEP sofern man dem Unternehmen und seinen Authentisierungsprozessen vertraut. Sein oder nicht sein DNSSEC ist kein Allheilmittel, sein Einsatz ist aber dann eine sinnvolle Ergänzung, wenn es darum geht, sich mit authentischen Kommunikationspartnern zu verständigen. Das betrifft zum Beispiel Onlineshopping und -banking, aber auch andere Übertragungen sensibler Daten zwischen Computern, die sich über DNS suchen und auf die Namens- Sysadmin 69

5 70 auflösung vertrauen. Auf Client-Seite verhindert eine großflächige Einführung von DNSSEC alleine schon die Tatsache, dass lokale Clients in der Regel das Protokoll nicht unterstützen. Sie bleiben damit auf einen lokalen DNS-Server angewiesen, der das kann. Aktuell sind hier keine Änderungen in Sicht. In hochsicheren Umgebungen ist der Einsatz von DNSSEC sowohl im lokalen Netzwerk als auch im Backbone sinnvoll. So kommt DNSSEC auch in der gegenwärtig im Aufbau befindlichen Telematik der elektronischen Gesundheitskarte zum Einsatz, um die Kommunikationspartner vom Leistungserbringer (zum Beispiel einem Arzt oder Apotheker) bis zum jeweiligen Fachdienst bei den Krankenkassen auf Netzwerkebene zu authentisieren. Allerdings kann DNSSEC in der Regel nur eine Ergänzung zu anderen Schutzmaßnahmen wie VPNs oder Public-Key- Infrastrukturen sein. Öffentliche PKIs verwalten von bekannten CAs e Zertifikate. Beruht der Einsatz von SSL/ TLS darauf, implementiert diese Technik ein ähnliches Maß an Authentizität und sorgt nebenbei auch noch für Vertraulichkeit, die DNSSEC nicht bieten kann. Der Nutzen von DNSSEC liegt eher im Schutz unbedarfter Anwender, die auch ein als nicht vertrauenswürdig eingestuftes Zertifikat akzeptieren würden. Stärken und Schwächen Mit DNSSEC eine Chain of Trust aufzubauen ist relativ einfach. Schwieriger wird es, sie auch zu verwalten. Alle Beteiligten benötigen vom obersten Parent bis zur letzten von dort delegierten Zone regelmäßig aktualisierte Schlüssel, wenn der Resolver sie korrekt validieren soll. Dass bisher erst eine TLD, nämlich die schwedische».se«, auf diese Weise ist, liegt aber zum größeren Teil an anderen Faktoren. Durch die NSEC-Einträge lassen sich alle Einträge einer Zone per Zone Walking sukzessive auslesen. Da die Entwickler der Protokolle DNS als öffentlichen und frei zugänglichen Dienst ansehen, haben sie die Vertraulichkeit ausdrücklich aus den Zielen von DNSSEC ausgeklammert. Andererseits ist sie integraler Bestandteil der Datenschutzziele. Daher sehen verschiedene Registrare Zone Walking als Datenschutzproblem an [7]. Eine mögliche Lösung des Problems liefert der Draft NSEC3, der den jeweils folgenden Datensatz verschlüsselt darstellt. Skeptiker bezweifeln indes, ob öffentlich auflösbare DNS-Namen schützenswert sind. Sie lassen zwar gelten, dass es nicht wünschenswert sei, wenn Unberechtigte ganze Zonen systematisch auslesen, wenden jedoch ein, dass andere Maßnahmen Datenschutz und Vertraulichkeit besser gewährleisten. Sie zählen Access Control Lists und Authentifizierung der Clients dazu, nehmen aber frei verfügbare DNS-Einträge davon aus. Letztlich liegt die Einschätzung im Ermessen der jeweiligen Sicherheitspolitik in Unternehmen oder Organisationen. Als einen weiteren Punkt, der die Einführung von DNSSEC verzögert, nennen einige Experten, dass die kryptographischen Prozeduren eines DNSSEC-Nameservers die Infrastruktur mindestens doppelt so stark belasten wie ein herkömmlicher Server. Der deutsche Registrar Denic [8] nennt dies als Hauptproblem, weshalb er noch kein DNSSEC eingeführt hat. Dadurch verzögert sich das Unterzeichnen der TLD».de«weiter. Listing 4: Signiertes Zonefile 01 ; File written on Wed Nov 20 17:02: ; dnssec\_signzone version example.com. 100 IN SOA ns.example.com. admin.example.com. ( ; serial ; refresh (1 minute 40 seconds) ; retry (3 minutes 20 seconds) ; expire (1 week) ; minimum (1 minute 40 seconds) 09 ) RRSIG SOA ( example.com. 12 Q7QT/Y3MhD9Zx6/...= ) NS ns.example.com RRSIG NS ( example.com. 16 k4dy4yrfmwtuskt...= ) NSEC a.example.com. NS SOA RRSIG NSEC DNSKEY RRSIG NSEC ( example.com. 20 fendttddyyrc7dq...= ) DNSKEY ( 22 AQPI4+0M1V055RS...= 23 ) ; key id = DNSKEY ( 25 AQOzgs4qea+ImJ ) ; key id = RRSIG DNSKEY ( example.com. 29 hfcuzcqnsqbiohn...= ) RRSIG DNSKEY ( example.com. 32 oyum/nlrnz7xdxi...= ) 33 a.example.net. 100 IN A RRSIG A ( example.com. 36 on1qemg7b47dwbo...= ) NSEC b.example.net. A RRSIG NSEC RRSIG NSEC ( example.com. 40 Kon6z25uqnHpGc9...= ) 41 b.example.net. 100 IN A RRSIG A ( example.com. 44 lwxfx2ebtpobvcx...= ) NSEC ns.example.com. A RRSIG NSEC RRSIG NSEC ( example.com. 48 Pg4u+EI+HzeFFQ3...= ) 49 ns.example.net. 100 IN A RRSIG A ( example.com. 52 Bm3vcmaEC3kdcJu...= ) NSEC example.com. A RRSIG NSEC RRSIG NSEC ( example.com. 56 weszezabdr+lpst...= )

6 Wie so oft gibt es auch politische Uneinigkeiten. Die Frage, wer etwa den Private Key der Root-Zone verwalten soll, ist bislang ungeklärt. Einerseits fordern RIPE und andere Registrare ICANN (Internet Corporation for Assigned Names and Numbers) dazu auf, die Root-Zone schnellstmöglich zu signieren, andererseits möchte kaum jemand den Private Key allein einer amerikanischen Behörde anvertrauen. Viele betrachten die Root- Zone-Server als bislang letzte Verteidigungslinie gegen staatliche Eingriffe, die niemand einfach so aufgeben möchte. DNSSEC vor der Umsetzung Die globalen Diskussionen hindern private Zonenadministratoren jedoch nicht daran, DNSSEC zu testen und einzuführen. Für die meisten privaten Zonen trifft die Datenschutz-Problematik von NSEC ohnehin kaum zu, da sie nur»www«,»mail«und andere öffentliche Einträge enthalten. Hinterlegen sie den Public KSK an zentraler Stelle, zum Beispiel einer DLV-Registry, können Dritte DNSSEC problemlos nutzen. Sind persönliche Daten involviert wie beim Online-Banking oder -Shopping, können die Betreiber einer solchen Domain ein echtes Vertrauensplus durch die Bereitstellung einer DNSSEC-gesicherten Zone schaffen. Es bleibt zu hoffen, dass die DNSSEC- Befürworter die verbleibenden Probleme zügig lösen, um einige weitere TLDs, zum Beispiel die deutsche».de«, zu signieren. Die Denic arbeitet angeblich mit Hochdruck daran. (mg) n Infos [1] Klaus Schmidt, Nils Magnus, DNS: Da werden sie geholfen : LPI-Kurs, Folge 18, Linux-Magazin 01/08, S. 80 [2] Stephan Lichtauer, Gelbe Seiten: Konfiguration und Betrieb von DNS-Servern : Linux-Magazin 06/00, S. 134 [3] Mehrere Standarddokumente spezifizieren DNSSEC: RFC 4033 (Intro), RFC 4034 (Records) und RFC 4035 (Protocol) und RFC 3658 (DS): [ tools. ietf. org/ html] [4] DNSSEC-Howto: [ nlnetlabs. nl/ dnssec_howto] [5] ISC-Nameserver: [ www. isc. org] [6] ISC-DLV-Registry: [ secure. isc. org/ index. pl?/ ops/ dlv/] [7] Bericht vom 2. Internet Governance Forum (IGF), Rio de Janeiro: [ www. heise. de/ newsticker/ meldung/ 99000] [8] Denic-Seite zu DNSSEC: [ www. denic. de/ de/ domains/ dnssec] Der Autor Eric Amberg arbeitet seit vielen Jahren als Systemingenieur für IT-Netzwerke in großen Unternehmen. Seine Spezialgebiete sind Linux und Netzwerksicherheit. Darüber hinaus ist er als Autor für Fachbücher und -zeitschriften tätig. Sein Buch Linux Server mit Debian GNU/ Linux ist im Juni 2007 erschienen. 71 Anzeige