Mein DNSsec-Setup

Vor ein paar Tagen habe ich bereits über einen Teil meines Nameserver-Setups mit Bind geschrieben. Ich habe erklärt, wie DDNS mit bind verwendet werden kann um beispielsweise Kunden die Möglichkeit zu geben Änderungen an Ihren Zonen über ein standardisiertes Protokoll durchzuführen oder die sich häufiger ändernde IP des Internetanschlusses zuhause immer aktuell im DNS zu hinterlegen. Dabei habe ich erwähnt, dass ein interessantes Argument für den Einsatz von DDNS zum Updaten von Zonen auch ist, dass bind in diesem Fall sich automatisch darum kümmert diese erneut zu signieren. Wie dieses Setup funktioniert möchte ich in diesem Artikel beschreiben.

Ziele meines Setups

Wenn man versucht etwas kryptografisch abzusichern, dann sollte der erste Schritt immer der gleiche sein. Es ist zu bestimmen, gegen welche Arten von „Angriffen“ man sich schützen möchte. Je nachdem was man sich hier für Vorgaben macht kommt man zu teilweise komplett verschiedenen „optimalen Lösungen“.

In meinem Setup kommt es mir nicht darauf an die höchstmögliche Sicherheit herzustellen. Vielmehr ist das Ziel meines DNSsec-Einsatzes die Grundsicherheit zu erhöhen. Einfache Angriffe mit dem Ziel DNS-Einträge im Cache von DNS-Resolvern zu verfälschen sollen verhindert werden. DNSsec soll bei mir deswegen möglichst breit und damit für alle Zonen verwendet werden. Es ist deshalb wichtig, dass möglichst kein zusätzlicher Aufwand in der Verwaltung der Zonen entsteht oder dieser nur minimal ist.

Indem ich bei meinem Setup die zur Signatur der Zonen genutzten Private-Keys auf meinem Server ablege(n muss), habe ich an einem anderen Punkt jedoch keinen erhöhten Schutz meiner Zonen: wenn es einem Angreifer gelingt durch irgendeine Lücke in meinen DNS-(Master-)Server einzudringen, so kann er Modifikationen an meiner Zone vornehmen und für diese trotzdem eine gültige Signatur erzeugen.

Ein weiterer Punkt bei dem mein Setup keine Verbesserung der Sicherheit bringt ist der Schutz gegen Angriffe, die meine Zonen unerreichbar machen. Es gibt sogar Überlegungen, dass der Einsatz von DNSsec prinzipiell die Sicherheit im Internet gegen DOS-Angriffe vermindert. Bei der DNS Amplification Attack werden DNS-Server genutzt um andere Server mit einem DOS-Angriff zu überziehen. Die Aktivierung von DNSsec vergrößert dabei die Gefahr, dass der eigene DNS-Server hierfür missbraucht wird.

Konfiguration von bind

In diesem Abschnitt erkläre ich welche Änderungen an den Konfigurationsdateien von bind vorgenommen werden müssen, damit die eigenen Zonen signiert ausgeliefert werden. Wie sich zeigen wird ist dies gar nicht viel. Es reichen zwei kleine Änderungen.

Grundsätzliches aktivieren von DNSsec

Damit bind grundsätzlich den Umgang mit DNSsec aktiviert, muss dies in der Konfiguration im options-Abschnitt angegeben werden:

options {
    directory "/var/cache/bind";

    auth-nxdomain no;    # conform to RFC1035
    listen-on-v6 { any; };

    allow-recursion { 127.0.0.1; ::1; };

    dnssec-enable yes;
    dnssec-validation yes;

    allow-transfer {
        key doux.amessage.eu.;
        key eder.amessage.eu.;
    };
};

Zur Aktivierung muss hier einfach der Eintrag „dnssec-enable yes;“ angegeben werden. (Der Eintrag „dnssec-validation yes;“ ist nicht notwendig und auf einem reinen autoritativen Nameserver auch nicht sinnvoll. Der Eintrag ist bei mir nur vorhanden, da ich meinen bind für localhost als recursive DNS-Server nutze.)

Diese Konfigurationsänderung muss sowohl auf dem Master-Nameserver wie auch auf allen Slave-Nameservern erfolgen.

Den einzelnen Zonen mitteilen wo sich die zugehörigen Keys befinden

Die zweite notwendige Änderung ist es, dass die Definition der Zone noch um zwei Zeilen erweitert wird:

zone "mwimmer.com" in {
    auto-dnssec maintain;
    type master;
    notify yes;
    file "/etc/bind/zones/mwimmer.com.zone";
    update-policy {
        grant root.user.invalid.     subdomain mwimmer.com. ANY;
        grant matthias.user.invalid. subdomain mwimmer.com. ANY;
    };
    allow-transfer {
    key root.user.invalid.;
    key doux.amessage.eu.;
        key matthias.user.invalid.;
    };
    key-directory "/etc/bind/keys";
};

Hier habe ich über „auto-dnssec maintain;“ bind mitgeteilt, dass er bei Updates der Zone diese automatisch neu signiert. Außerdem habe ich mit „key-directory "/etc/bind/keys";“ angegeben wo bind nach den notwendigen Private-Keys zur Signatur der Zone sucht. Ohne letzteren Eintrag würde bind in seinem working Directory suchen. Dieses ist auf einem Debian-System (wie man auch im vorherigen Config-Ausschnitt sieht) /var/cache/bind, was für eine Ablage der DNSsec-Keys nicht geeignet ist, da dieses Verzeichnis normalerweise nicht mit gebackupt wird.

Diese Änderung ist nur auf dem Master-Nameserver notwendig.

Einrichten einer Zone

Zum Einrichten einer neuen Zone auf meinem Nameserver erstelle ich hierfür zuerst eine normale, nicht signierte Zonendatei. Außer den Einträgen auto-dnssec und key-directory in der Bind-Konfiguration, die ich sofort mit eintrage, wird die Zone also zuerst vollkommen normal und ohne Signaturen angelegt und mit einem Aufruf von rndc reconfig auch aktiviert. (Wurde die Konfiguration einer bestehenden Zone geändert um beispielsweise bei einer bereits vorhandenen Zone DNSsec nachzurüsten, so muss stattdessen rndc reload benutzt werden.)

Die Zone wird ab diesem moment von bind ausgeliefert, ist aber noch unsigniert. Im nächsten Schritt geht es jetzt also darum die notwendigen DNSsec-Schlüssel zu erzeugen. Es werden hierzu zwei Schlüsselpaare erzeugt. Das eine paar ist der Key-Signing-Key (KSK). Ein Fingerabdruck hiervon sollte soweit möglich später in die übergeordnete Zone hinterlegt werden. Mit diesem Key-Signing-Key wird später von bind das zweite Schlüsselpaar, der sogenannte Zone-Signing-Key (ZSK), unterschrieben. Erst mit dem Zone-Signing-Key werden dann tatsächlich die eigenen Records in der Zone unterschrieben.

Die Erstellung der beiden Schlüsselpaare erfolgt mit dem Tool dnssec-keygen, das Teil der bind-Distribution ist (Debian-Paket: bind9utils):

dnssec-keygen -K /etc/bind/keys -a RSASHA512 -b 2048 -f KSK mwimmer.com

dnssec-keygen -K /etc/bind/keys -a RSASHA512 -b 1024 mwimmer.com

Je nachdem wie viel Entropie auf eurem System vorhanden ist, kann die Erzeugung dieser zwei Schlüsselpaare durchaus mehrere Stunden beanspruchen. Also nicht verzweifeln, wenn lange Zeit nichts vorwärts geht. Am besten startet ihr die Schlüsselerzeugung also in einem screen.

Nach der Erstellung der Schlüsselpaare muss noch sichergestellt werden, dass die Schlüssel von bind gelesen werden können. Da dnssec-keygen den Private-Key nur für den Datei-Owner lesbar macht (Zugriffsrechte „rw-------“) müssen wir auf einem Debian-System die erzeugten Dateien beispielsweise dem User „bind“ zuweisen.

Wenn nun beide Schlüsselpaare erzeugt und für bind lesbar sind, müssen wir bind noch mitteilen, dass er diese Keys ab sofort zur Signatur der Zone verwenden soll: rndc sign mwimmer.com

Voilà: bind liefert ab diesem Moment eine signierte Zone aus und kümmert sich auch darum, wann die Zone neu signiert werden muss.

Signaturen der Zone in der übergeordneten Zone eintragen (lassen)

Damit fremde Nameserver die Signaturen in der Zone prüfen können, müssen diese wissen welche Keys überhaupt berechtigt sind die Zone zu signieren. Bei DNSsec geschieht dies, indem die Signatur(en) des/der berechtigten Keys in die übergeordnete Zone eingetragen werden. Die Keys mit denen ich die Zone „mwimmer.com“ signiere sind entsprechend also in der Zone „com“ eingetragen. Indem die Zone „com“ wiederum selbst signiert ist und deren Schlüssel in der DNS-Root-Zone eingetragen ist usw. reicht es auf anderen Nameservern aus, dass dort nur die gültigen Keys für die Root-Zone eingetragen werden müssen. Die Funktionsweise ist also sehr ähnlich zu der von X.509-Zertifikaten. Auch bei diesen müssen einem Browser nur die Stammzertifikate der Zertifizierungsstellen bekannt.

Wie konkret in die übergeordnete Zone eingetragen wird was die gültigen Key-Signing-Keys sind ist sehr unterschiedlich. Was man allgemein nur sagen kann ist, dass dieser Eintrag über den Registrar erfolgt bei dem man die Domains registriert hat. Ob dieser DNSsec überhaupt unterstützt und wenn ja wie man ihm die Keys bekannt macht, ist von Registrar zu Registrar verschieden.

Ich persönlich habe mir für InterNetX entschieden und bin wegen DNSsec extra zu diesem Provider gewechselt, da meine vorherigen Provider leider alle nicht in der Lage waren DNSsec-Signaturen anzunehmen.

Außerdem ist es auch so, dass noch nicht bei allen Top-Level-Domains überhaupt eine Delegation mit DNSsec möglich ist. Bei den meisten größeren TLDs (z.B. .DE, .com, .net, .org, .eu) ist dies allerdings kein Problem mehr.

Ich möchte euch noch kurz zeigen, wie die Konfiguration der DNSsec-Delegation vom Falle von InterNetX geschieht.

DNSsec bei InterNetX (AutoDNS 3.0)

Hinweis vorweg: DNSsec unterstützt das Eintragen der Fingerprints von DNSsec-Schlüsseln in die übergeordneten Zonen. Wenn man DNSsec benutzen möchte, so muss man die Nameserver jedoch (mit den oben beschriebenen Einstellungen) selbst betreiben. Die Nameserver, die man über den AutoDNS verwalten kann, sind selbst nicht für DNSsec aktiviert.

Damit InterNetX die Signatur des Schlüssels mit dem wir unsere Zonen signieren an die übergeordnete Registry weiter gibt, müssen wir unseren öffentlichen Teil des Key-Signing-Keys bei der jeweiligen Zone hinterlegen. Damit der entsprechende Reiter bei der Zone im AutoDNS erscheint, müssen wir „DNSSEC aktivieren“ in den Einstellungen der Benutzeroberfläche aktivieren.

Grundsätzliches aktivieren von DNSsec in der Oberfläche des AutoDNS 3.0

Nachdem diese Einstellung aktiviert ist, erhalten wir in der Domainverwaltung wenn wir eine Domain bearbeiten einen zusätzlichen Reiter „DNSSEC“:

Reiter „DNSSEC“ in der Oberfläche des AutoDNS 3.0

In diesem Reiter müssen wir den verwendeten Algorithmus unseres Key-Signing-Keys eintragen (in obigem Beispiel haben wir einen RSASHA512-Schlüssel erzeugt, wir wählen also „10 (RSA/SHA-512)“. Außerdem tragen wir den BASE64-enkodierten öffentlichen Schlüssel (public Key) in das darunter stehende Eingabefeld ein. Zu diesem öffentlichen Schlüssel kommen wir am einfachsten, wenn wir unseren Nameserver fragen:

dig mwimmer.com DNSKEY | grep 257

Hinweis: Ich habe die Erfahrung gemacht, dass es mit AutoDNS 3.0 bei DE-Domains nicht funktioniert, wenn ich den DNSsec-Schlüssel bereits bei der Registrierung mit angebe. Die Domain wird dann zwar registriert, aber der Fingerprint des DNSsec-Keys nicht mit eingetragen. Ich habe mir deswegen auch bei der Registrierung angewöhnt diese zuerst ohne DNSsec durchzuführen und wenn sie fertig ist, bearbeite ich die Zone nochmals und trage die DNSsec-Einstellungen im AutoDNS 3.0 nach.