Dnssec

aus PUG, der Penguin User Group
Wechseln zu: Navigation, Suche

DNSSEC

Bis jetzt betrifft das nur alle User, wenn DNSSEC flächendeckend eingeführt ist, wird es einige Leute jedoch betroffen machen.

Leider hat Debian eine recht angestaubte bind9 Version, die zwar DNSSEC kann, aber sie kommt eben nicht mit allen Keyformaten zurecht. Das gilt auch für die Keys des Denic Testbed Projekts. Das Format des Denic Keys wird vom Bind 9.5 nicht unterstützt. Es spricht aber nichts dagegen auch auf einem Produktions Debian Server Bind 9.7 zu verwenden, isc.org bezeichnet diese Version als stabil. In Debian Squeeze ist Bind 9.7 dabei.

RFC

DNSSEC ist in den folgenden RFCs definiert:

Debian Paket kochen

Zunächst muss Squeeze ein die sources.lst eingetragen werden: deb-src http://ftp.de.debian.org/debian/ squeeze main, dann werden die Sourcen mit apt-get source bind9 geholt.

Bevor compiliert werden kann, ist in der debian/rules der ganze config Teil für Bind wie folgt zu ersetzen: 

        ./configure --prefix=/usr \
                --mandir=\$${prefix}/share/man \
                --infodir=\$${prefix}/share/info \
                --sysconfdir=/etc/bind \
                --localstatedir=/var \
                --enable-threads \
                --enable-largefile \
                --with-libtool \
                --enable-shared \
                --enable-static \
                --with-openssl=/usr \
                --with-gssapi=/usr \
                --with-gnu-ld \
                --with-dlz-postgres=no \
                --with-dlz-mysql=no \
                --with-dlz-bdb=no \
                --with-dlz-filesystem=yes \
                --with-dlz-ldap=yes \
                --with-dlz-stub=yes \
                --enable-ipv6
        touch configure-stamp

Mit dpkg-buildpackage -d wird nun compiliert.

Die Debian Pakate müssen jetzt alle installiert werden, bind9_9.7.0.dfsg.P1-1 mault sonst (zu Recht) wegen der Abhängigkeiten.

DNSSEC einrichten

Die folgenden Beispiele aktivieren DNSSEC für die Root-Zonen, RIPE (reverse DNS) und dem Denic Testbed. Wenn Denic irgendwann DNSSEC produktiv nutzt, dann kann man die testbed include Zeite rausnehmen, weil das dann über den Keychain der Root-Nameserver läuft.

named.conf.options

options {
	directory "/var/cache/bind";
	auth-nxdomain no;    # conform to RFC1035
        version "taunusstein.net";
        allow-query { any; };
        allow-transfer { 127.0.0.1/8; 192.168.0.0/16; };
        match-mapped-addresses yes;
	recursion yes;
	allow-recursion { 127.0.0.0/8; 192.168.0.0/16; };
	listen-on { 127.0.0.1; 192.168.1.1; };
	listen-on-v6 { 2a01:7a0:1:2::1;};
	dnssec-enable yes;
	dnssec-validation yes;
	dnssec-lookaside "." trust-anchor "dlv.isc.org";
};

include "/etc/bind/dlv.isc.org.named.conf";

include "/etc/bind/ripe-ncc-dnssec-keys-new.txt";

include "/etc/bind/denic-testbed.conf";

dlv.isc.org.named.conf

trusted-keys {
	dlv.isc.org. 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh";
};

denic-testbed.conf

Das entspricht dem Vorschlag von Denic 

// Anfang DE DNSSEC Testbed /////////////////////////////////////////////////
//
// Konfigurationsbeispiel fuer ISC BIND 9 (9.7 oder neuer)
//
/////////////////////////////////////////////////////////////////////////////
//
// Umlenkung der DNS-Anfragen fuer die TLD DE auf zwei separate Adressen
// <http://www.denic.de/dnssec>
//
// Weitere Hinweise im BIND-"ARM", Kapitel 6:
//   ``server Statement Definition and Usage''
//   ``zone Statement Definition and Usage''

zone "de" {
	type forward;
	// Die Reihenfolge der beiden Adressen kann beliebig gewaehlt
	// werden
	forwarders {
		81.91.161.228;	// auth-fra.dnssec.denic.de
		87.233.175.25;	// auth-ams.dnssec.denic.de
		// IPv6 nur bei geeigneter Konnektivität aktivieren
		2A02:568:0:1::53;	// auth-fra.dnssec.denic.de
	};
	forward first;
};

// WICHTIG: Diese Liste muss regelmaessig gepflegt werden und
//          darf nur im Zusammenhang mit der Testbed-Infrastruktur
//          eingesetzt werden!
//          Die Markierung als "bogus" verhindert, dass die offiziellen
//          Nameserver gefragt werden.
server 194.0.0.53	{ bogus yes; };	// a.nic.de
server 208.48.81.43	{ bogus yes; };	// c.de.net
server 81.91.164.5	{ bogus yes; };	// f.nic.de
server 77.67.63.105	{ bogus yes; };	// l.de.net
server 195.243.137.26	{ bogus yes; };	// s.de.net
server 194.246.96.1	{ bogus yes; };	// z.nic.de

server 2001:678:2::53	{ bogus yes; };	// a.nic.de
server 2001:608:6:6::10	{ bogus yes; };	// f.nic.de
server 2001:668:1f:11::105	{ bogus yes; };	// l.de.net

trusted-keys {
	"de." 257 3 8 "AwEAAZ1FqQED8QBrk3Jk4q96lggh4uiwlbdbZ0posfIgcaJJqfTNBfEhn6PEPqqRP73libD55vujfYzKMN0fVd34wrdOpSTpMbw+oqQpJyecfGVYH1fnqws23n5QE03/7SN98O8Cm+HBpB66JurTHWD3f4es8IUoumb/SXY44qb+oqWfmM3wS8aQVA5d2gHpKrRIPlDHA/MB3FHGL64VpfV8KJ76kp1RBthR7Y0qalTskOouVeCOEa7gUiIljt1kTf64HFGsRi11klpCHBjtTiTg7MFN25nASuhbyTmWlRxPyg79BK7EDQ+tAe09NYkS1P7tOe8ola9IpQHTWO6ttTmSnyE=";
};

//
// named-checkconf nicht vergessen!
//
// Ende DE DNSSEC Testbed Phase0 ////////////////////////////////////////////

ripe-ncc-dnssec-keys-new.txt

Das File ist etwas größer, daher hier nur der Link:

https://www.ripe.net/projects/disi//keys/ripe-ncc-dnssec-keys-new.txt

named

Mit named-checkconf sollte man das jetzt alles prüfen. "No News Are Good News" gilt auch hier, in diesem Fall kann man mit /etc/init.d/bind9 restart den named neu starten. Wenn der named dann keine unfreundlichen Bemerkungen im Syslog hinterlässt, dann ist Dein Nameserver nun DNSSEC fähig und prüft Reverse DNS für RIPE IPs, die .de Domains soweit diese am Denic Testbed beteiligt sind und viele .com und .net Domains.

Test

Bei RIPE ist DNSSEC produktiv und der Keychain der Root-Nameserver sollte benutzt werden. Mit dig +dnssec -x 193.138.96.2 kann man sich davon überzeugen, dass alles läuft. 

; <<>> DiG 9.7.0-P1 <<>> +dnssec -x 193.138.96.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26954

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1 

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;2.96.138.193.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
2.96.138.193.in-addr.arpa. 3600	IN	PTR	mailin.taunusstein.net.
2.96.138.193.in-addr.arpa. 3600	IN	RRSIG	PTR 5 6 3600 20100531074002 20100501074002 1206 96.138.193.in-addr.arpa. ZQyFQ4p5CSfUGqsjT/PD0bLWHGyeVIQCa7A3TcTBadzLVtCrUWQQqkFE bRvTQW3DwvMgwC91X+UwWPsJ3c1oJSvjDMMjlipl65PrOTGrTquWGxQH FwUUHjAVVgbCrS6ov/l8sldP/YS9/Y+dSUMAcJce8hJoSPrAJO4JztKD I20=

;; AUTHORITY SECTION:
96.138.193.in-addr.arpa. 3600	IN	NS	ns1.taunusstein.net.
96.138.193.in-addr.arpa. 3600	IN	NS	ns2.taunusstein.net.
96.138.193.in-addr.arpa. 3600	IN	RRSIG	NS 5 5 3600 20100531074002 20100501074002 1206 96.138.193.in-addr.arpa. QcvbiuI0C2GrR9f7E/k5MwV0DqDzl8mW8L6qfPD9Frg/xLex10IzNDxy 69vX3hfZYQIrIenxMLdC5rNmULflmNmI588BSt610BM2zr7dc8p9GCWR bQhY5ha49c0aKQVYGWBjY6bObrW86YqD3466s/SdEPpc1asM1m1sVoL4 tks=

;; Query time: 611 msec
;; SERVER: 192.168.1.6#53(192.168.1.6)
;; WHEN: Sat May  1 12:06:07 2010
;; MSG SIZE  rcvd: 492

Entscheidend ist hier in der Flags das ad, was bedeutet, dass die Abfrage authentifiziert ist. Wie man sieht, sind meine PI Netze bereits DNSSEC signiert, die KSKs sind auch bei RIPE registiert. Im Denic Testbed sind auch die Domains tsst-test.de und ip6-test.de beteiligt, auch da müsste dann das ad Flag bei der Abfrage gesetzt sein.

Zone auf DNSSEC umstellen

Es wird zunächst davon ausgegangen, dass bereits ein fehlerfreies Zonenfile vorliegt. Die Zone soll mal im Beispiel quake0.de heissen. Damit nichts durcheinander kommt und die Verzeichnisse übersichtlich bleiben, wurde erst das Verzeichnis quake.de/ erzeugt, dort liegt auch das Zonenfile, dass ebenfalls quake0.de heisst.

Zone Signing Key (ZSK) erstellen

dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 -n ZONE quake0.de

Danach liegen die Files Kquake0.de.+005+12345.key und Kquake0.de.+005+12345.private im Verzeichnis. Die Nummern können sich durchaus unterscheiden.

Key Signing Key (KSK) erstellen

dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 -n ZONE -f KSK quake0.de

Danach liegen die Files Kquake0.de.+005+23456.key und Kquake0.de.+005+23456.private im Verzeichnis. Die Nummern können sich durchaus unterscheiden.

Zonenfile vorbereiten

Zunächst ist wie bei jeder Änderung die Seriennummer zu aktualisieren. Dann werden mit cat K*.key >> quake.de die public Keys an das Zonenfile angehängt.

Zone signieren

Leider sieht man den Filenamen nicht gleich an, ob das ein ZSK oder KSK ist, macht aber nichts, das folgende Skript ermittelt die richtige KSK Datei:

<source lang="bash">

  1. !/bin/sh

KEYFILE=`grep -l "IN DNSKEY 257" *.key` KSK=`basename $KEYFILE .key` dnssec-signzone -k $KSK quake0.de </source>

Wenn da nur <zone> blah... signed kommt, dann hat es geklappt. Weiterhin ist auch ein File quake0.de.signed zu finden.

Das .signed File wird dann in die Zonenkonfig des Bind eingebunden.

Script dnssec.sh

In Kurzform kann man die Schritte in ein kleines Shell-Script "dnssec.sh" einbauen. Dieses hier löscht die Keys der angegebenen Zone und bereinigt bei jedem Aufruf automatisch die Zonefiles. Aufgerufen wird es mit dnssec.sh Zonefile.

Hint: Das Script ist auf openSUSE 11.1 getestet worden und muss eventuell für andere Distris angepasst werden.

<source lang="bash">

  1. !/bin/bash
  1. dnssec.sh
  3. Written by Udo Neist 06.05.2010
  5. This library is free software; you can redistribute it and/or modify it
  6. under the terms of the GNU General Public License as published by
  7. the Free Software Foundation; either version 2.1 of the License, or (at
  8. your option) any later version.

zonedir="/var/lib/named/master" domain=`basename $1`

function cleaning() { 

       echo "Removing old keys..."
       rm -f K$1*
       rm -f dsset-$1*
       rm -f $1*.signed
       sed -i /DNSKEY/d $1

}

function signingkeys() { 

       echo "Key signing key..."
       dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 -n ZONE $1
       echo "Zone signing key..."
       dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 -n ZONE -f KSK $1

}

function signingzonefile() { 

       echo "copying public key into zonefile..."
       grep -h "IN DNSKEY" K$2*.key >> "$1/$2"
       echo "Signing zonefile..."
       KEYFILE=`grep -l "IN DNSKEY 257" K$2*.key`
       KSK=`basename $KEYFILE .key`
       dnssec-signzone -k $KSK $2

}

echo "dnssec.sh signing $domain" cleaning $domain signingkeys $domain signingzonefile $zonedir $domain </source>

Mit dem Einzeiler for i in `ls /var/lib/named/master/*`; do /PFAD ZU dnssec.sh/dnssec.sh $i; done lässt sich das gleich für alle Zonen bewerkstelligen.

KSK

Die .key Datei der Key Signing Keys kann man an den Registrar übermitteln. Bisher habe ich nur einen Registrar für .de Domains gefunden, der DNSSEC unterstützt. Für Reverse DNS Delegationen nimmt RIPE die entsprechenden Einträge an.

Kritik

DNSSEC löst nicht alle Sicherheitsprobleme von DNS, Dan Bernstein (der qmail Autor) hat mit DNSCurve eine interessante Alternative geschaffen, allerdings wollen Root-Nameserver Betreiber davon wohl nichts wissen.

Christian, ergänzt von weinbauer

Abgerufen von „https://www.pug.org/mediawiki/index.php?title=Dnssec&oldid=6819“