DNSSEC - einfaches howto?

04/10/2008 - 16:21 von Holger Marzen | Report spam
Ich pflege meine Zonenfiles selbst, allerdings auf einem Hidden Primary.
Somit habe ich auf die Software (Bind) des Nameservers, der die Anfragen
beantwortet, keinen Einfluss.

Kann ich unter diesen Umstànden DNSSEC verwenden? Gibt es ein einfaches
HowTo, wo explizit erklàrt ist, mit welchen Tools ich Schlüssel
erstelle, wie ich Records (welche?) signiere und wo ich den öffentlichen
Schlüssel hinterlegen kann?
 

Lesen sie die antworten

#1 Hauke Lampe
04/10/2008 - 22:21 | Warnen spam
Holger Marzen schrieb:

Ich pflege meine Zonenfiles selbst, allerdings auf einem Hidden Primary.
Somit habe ich auf die Software (Bind) des Nameservers, der die Anfragen
beantwortet, keinen Einfluss.



Wenn du die Nameserver deiner Domain marzen.de meinst, sollten sie es
zumindest von der Software her können. BIND versteht DNSSEC seit 9.3.x,
IIRC:

version.bind. 0 CH TXT "9.5.0-P1"

Kann ich unter diesen Umstànden DNSSEC verwenden?



Im Prinzip, ja.

Eventuell muss in der Konfiguration DNSSEC aktiviert werden, damit der
Server Antworten auch mit den passenden RRSIG und ggf. NSEC Records
garniert. Das kann man leider nur pro View und nicht pro Zone
konfigurieren.

Seit BIND 9.4 muss man aber nicht mehr zwangslàufig auch die Validierung
von Signaturen im Resolver einschalten (der z.B. für Notify benötigt wird).
Damit vermeidet man unerwartete Seiteneffekte bei anderen Kunden und hat
bessere Chancen, eine Extrawurst zu bekommen.

|dnssec-enable yes;
|dnssec-validation no;


Gibt es ein einfaches HowTo, wo explizit erklàrt ist, mit welchen Tools
ich Schlüssel erstelle, wie ich Records (welche?) signiere



Es gibt im Web mehrere. Auf die Schnelle finde ich jetzt nur
http://www.nlnetlabs.nl/dnssec_howto/ wieder. Es steht aber letztlich
überall dasselbe drin.

Der technische Teil ist recht einfach. Mit dnssec-keygen je ein oder zwei
làngere Key Signing Keys (KSK) und kürzere Zone Signing Keys (ZSK) erzeugen
und mit $INCLUDE im Zonefile einbinden, dieses mit dnssec-signzone
signieren und anschliessend die signzierte Zone im Nameserver eintragen.

Für den weiteren Betrieb musst du beachten, daß die Signaturen ein
Ablaufdatum haben und rechtzeitig erneuert werden müssen, weil sonst die
Domain von validierenden Resolvern nicht mehr aufgelöst wird[1]. BIND soll
ab 9.6 automatisch re-signen können und 9.7 soll endlich bequemere Tools
mitbringen, heisst es.

Es gibt auch einen Satz Tools aus einem RIPE Projekt unter
https://www.ripe.net/projects/disi/...int_tool/. Mit denen konnte ich
mich bisher aber nicht anfreunden und benutze eigenes Shellgescripte um
Zonen nach Änderungen zu signieren, wöchentlich die Signaturen
aufzufrischen oder Keys zu verwalten.

Auf der Todo-Liste habe ich noch, dnssec-signzone in mehrere Teile zu
zerlegen um in einzelnen Schritten Records unterschiedlich zu signieren und
das Ganze dann zusammenzufügen und mit NSEC RRs versehen zu können. So soll
etwa der A RR meines DynDNS-Eintrags nur für einen Tag gültig sein und die
Signatur nicht automatisch erneuert werden, der dazugehörige SSHFP hingegen
eine làngere Gültigkeit besitzen und wöchentlich neu signiert werden. Das
ist mit dnssec-signzone bisher nicht ohne größere Verrenkungen möglich.

In Sachen anwenderfreundlicher Bedienung gibt es also noch eine Menge zu
frickeln.

Komplizierter ist aber eigentlich die Handhabung der Schlüssel. Du musst
zwischen den Paranoia- und Audit-Anforderungen einer CA und der
Bequemlichkeit eines durchschnittlichen DNS-Admins den Kompromiss finden,
der zu deiner Risikoeinschàtzung passt.

In meiner Erprobungsphase mit privaten Spieldomains habe ich kein Problem
damit, alle private keys der Einfachheit halber online auf dem primàren
Nameserver zu lagern. Dadurch àndert sich an der relativen Sicherheit
nichts. Wer die nötigen Rechte auf dem Server erlangt, kann den Zoneninhalt
àndern. Das war vorher schon so.

Überhaupt keine private keys auf exponierten Servern zu haben, gibt dir
dagegen recht guten Schutz gegen unerlaubte Änderungen an deinen Zonen
durch Freiwillige aus dem Internet. Der Aufwand, an die Keys zum Signieren
der Zone zu kommen, ist deutlich höher. Der Aufwand, den der Admin für jede
gewünschte Änderung betreiben muss, natürlich auch. Für DynDNS oder ein
Webinterface für Kundendomains ist das nicht praktikabel. Sicherlich kann
man hier mit einem Hidden Primary noch etwas Spielraum schaffen, die Reine
Lehre sieht aber vor, auch dort keine privaten Schlüssel stàndig liegen zu
haben.

Für den Produktivbetrieb würde ich wohl die private keys der KSKs offline
lagern (auf einer Smartcard o.à.) und nur ins System bringen, wenn neue
ZSKs generiert und signiert werden müssen. Dadurch kann ich langlebige,
"sicher" verwahrte Keys an der Schnittstelle zur übergeordneten Zone bzw.
DLV verwenden und spare Verwaltungsaufwand. Die Keys, mit denen dann die
eigentlichen Nutzdaten signiert werden, kann ich im schnellen oder sogar
automatisierten Zugriff halten und in kürzeren Abstànden austauschen.

Meine persönliche Best Practice habe ich da noch nicht gefunden.


und wo ich den öffentlichen Schlüssel hinterlegen kann?



Der DNSSEC-Theorie nach gibts du den öffentlichen Schlüssel (bzw. einen
Hash davon) über den normalen Dienstweg, z.B. das Webinterface eines
Registrars über das du auch die NS Records ànderst, an die Parent-Zone,
damit sie dort als DS Records eingetragen und signiert werden und die Kette
von der Root-Zone aus durchgeprüft werden kann.

Es dürfte allerdings noch einige Zeit dauern, bis der Idealzustand weltweit
erreicht ist, zumal es anscheinend mehr politische als technische Steine
aus dem Weg zu ràumen gibt.

DNSSEC mit DLV als Verzeichnis der Insel-Keys funktioniert dagegen bereits
brauchbar.

Etwas problematisch wird es wieder dadurch, daß man sich auf Resolver-Seite
(zumindest bei BIND) auf einen DLV-Anbieter festlegen muss und nicht
mehrere befragen kann. Als Herausgeber einer Zone will man daher nach
Möglichkeit in allen relevanten Verzeichnissen stehen.

Mir sind derzeit genau 3 Anbieter von DLV-Zonen bekannt:

ISC: https://secure.isc.org/ops/dlv/

Der Beschreibung nach fahren sie mit großem Aufwand eine Paranoiasimulation
einer CA. Meine Versuche, eine ENUM-Zone eintragen zu lassen, blieben
bislang jedoch unbeantwortet. Die Zahl der gelisteten Zonen ist gering und
ich vermute, daß dlv.isc.org auch nur von den Grossen Jungs[tm] benutzt
wird.

Besser gefàllt mir da Lutz Donnerhackes automagische DLV Registry nach
RFC5011. Domain eintragen und Knopf drücken:
https://www.iks-jena.de/leistungen/dnssec.php

Das automatische Einsammeln neuer Keys nach RFC5011 scheint mir ein
sinnvoller Mittelweg zwischen dem Sicherstellen der Autorisierung über Wege
außerhalb von DNS und der praktischen Nutzbarkeit zu sein. Allerdings habe
ich die Vorgehensweise noch nicht ausreichend genau verstanden, um sie mit
eigenen Worten zusammenfassen zu können.

Und dann gibts da noch den DNSSEC-Crawler. Über den weiss ich allerdings
nichts genaues: http://secspider.cs.ucla.edu/


Eigentlich wollte ich zu DNSSEC schon làngst einen Workshop im Hamburger
Bildungswerk anbieten (Arbeitstitel "DNSSEC is easy (to configure) and a
nightmare (to administrate)"). Ich muss wohl mal ein paar Tage Urlaub
nehmen und zusammenschreiben, was ich bisher dazu weiss. Dann verstehe ich
es auch selber besser. :)

Zum Schluss noch ein Zitat:

"if your point is that dnssec is [a] horrid misshapen pig that even its
mother could not love, then you will find noone (anywhere) willing to argue
otherwise. it's late, it's ugly, it's fragile, it's a pig, and that's the
universal view of it, there are no dissenters." -- Paul Vixie



BTW, mit TCP/IP hat DNSSEC aber nur indirekt zu tun.
Ich leite mal um nach de.comp.security.misc (oder passt das eher nach
de.comm.internet.infrastruktur?)


HTH,
Hauke. "ENUM mache ich nur mit DNSSEC über IPv6"



[1] Das ist mir letztens gerade auf den Fuss gefallen, als ich ein
IPSec-Konfigurationsproblem debuggen musste und dazu Dokumentation auf
openswan.org suchte: http://bugs.xelerance.com/view.php?id˜3

Ähnliche fragen