30.6. DNS – Domain Name Service

30.6.6.1. /etc/namedb/named.conf

// $FreeBSD$
//
// Refer to the named.conf(5) and named(8) man pages, and the documentation
// in /usr/share/doc/bind9 for more details.
//
// If you are going to set up an authoritative server, make sure you
// understand the hairy details of how DNS works.  Even with
// simple mistakes, you can break connectivity for affected parties,
// or cause huge amounts of useless Internet traffic.

options {
// All file and path names are relative to the chroot directory,
// if any, and should be fully qualified.
    directory	"/etc/namedb/working";
	pid-file	"/var/run/named/pid";
	dump-file	"/var/dump/named_dump.db";
	statistics-file	"/var/stats/named.stats";

// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
	listen-on	{ 127.0.0.1; };

// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver.  To give access to the network, specify
// an IPv6 address, or the keyword "any".
//	listen-on-v6	{ ::1; };

// These zones are already covered by the empty zones listed below.
// If you remove the related empty zones below, comment these lines out.
	disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
	disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
	disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";

// If you've got a DNS server around at your upstream provider, enter
// its IP address here, and enable the line below.  This will make you
// benefit from its cache, thus reduce overall DNS traffic in the Internet.
/*
	forwarders {
		127.0.0.1;
	};
*/

// If the 'forwarders' clause is not empty the default is to 'forward first'
// which will fall back to sending a query from your local server if the name
// servers in 'forwarders' do not have the answer.  Alternatively you can
// force your name server to never initiate queries of its own by enabling the
// following line:
//	forward only;

// If you wish to have forwarding configured automatically based on
// the entries in /etc/resolv.conf, uncomment the following line and
// set named_auto_forward=yes in /etc/rc.conf.  You can also enable
// named_auto_forward_only (the effect of which is described above).
//	include "/etc/namedb/auto_forward.conf";
       

Um vom Cache Ihres Internetproviders zu profitieren, können hier forwarders aktiviert werden. Normalerweise sucht ein Nameserver das Internet rekursiv ab, bis er die gesuchte Antwort findet. Durch diese Option wird stets der Nameserver Ihres Internetproviders zuerst abgefragt, um von dessen Cache zu profitieren. Wenn es sich um einen schnellen, viel benutzten Nameserver handelt, kann dies zu einer Geschwindigkeitssteigerung führen.

	/*
	   Modern versions of BIND use a random UDP port for each outgoing
	   query by default in order to dramatically reduce the possibility
	   of cache poisoning.  All users are strongly encouraged to utilize
	   this feature, and to configure their firewalls to accommodate it.

	   AS A LAST RESORT in order to get around a restrictive firewall
	   policy you can try enabling the option below.  Use of this option
	   will significantly reduce your ability to withstand cache poisoning
	   attacks, and should be avoided if at all possible.

	   Replace NNNNN in the example with a number between 49160 and 65530.
	*/
	// query-source address * port NNNNN;
};

// If you enable a local name server, don't forget to enter 127.0.0.1
// first in your /etc/resolv.conf so this server will be queried.
// Also, make sure to enable it in /etc/rc.conf.

// The traditional root hints mechanism. Use this, OR the slave zones below.
zone "." { type hint; file "/etc/namedb/named.root"; };

/*	Slaving the following zones from the root name servers has some
	significant advantages:
	1. Faster local resolution for your users
	2. No spurious traffic will be sent from your network to the roots
	3. Greater resilience to any potential root server failure/DDoS

	On the other hand, this method requires more monitoring than the
	hints file to be sure that an unexpected failure mode has not
	incapacitated your server.  Name servers that are serving a lot
	of clients will benefit more from this approach than individual
	hosts.  Use with caution.

	To use this mechanism, uncomment the entries below, and comment
	the hint zone above.

	As documented at http://dns.icann.org/services/axfr/ these zones:
	"." (the root), ARPA, IN-ADDR.ARPA, IP6.ARPA, and ROOT-SERVERS.NET
	are availble for AXFR from these servers on IPv4 and IPv6:
	xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org
*/
/*
zone "." {
	type slave;
	file "/etc/namedb/slave/root.slave";
	masters {
		192.5.5.241;	// F.ROOT-SERVERS.NET.
	};
	notify no;
};
zone "arpa" {
	type slave;
	file "/etc/namedb/slave/arpa.slave";
	masters {
		192.5.5.241;	// F.ROOT-SERVERS.NET.
	};
	notify no;
};
*/

/*	Serving the following zones locally will prevent any queries
	for these zones leaving your network and going to the root
	name servers.  This has two significant advantages:
	1. Faster local resolution for your users
	2. No spurious traffic will be sent from your network to the roots
*/
// RFCs 1912 and 5735 (and BCP 32 for localhost)
zone "localhost"        { type master; file "/etc/namedb/master/localhost-forward.db"; };
zone "127.in-addr.arpa" { type master; file "/etc/namedb/master/localhost-reverse.db"; };
zone "255.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };

// RFC 1912-style zone for IPv6 localhost address
zone "0.ip6.arpa"       { type master; file "/etc/namedb/master/localhost-reverse.db"; };

// "This" Network (RFCs 1912 and 5735)
zone "0.in-addr.arpa"   { type master; file "/etc/namedb/master/empty.db"; };

// Private Use Networks (RFCs 1918 and 5735)
zone "10.in-addr.arpa"     { type master; file "/etc/namedb/master/empty.db"; };
zone "16.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "17.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "18.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "19.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "20.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "21.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "22.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "23.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "24.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "25.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "26.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "27.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "28.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "29.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "30.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "31.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "168.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };

// Link-local/APIPA (RFCs 3927 and 5735)
zone "254.169.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };

// IETF protocol assignments (RFCs 5735 and 5736)
zone "0.0.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };

// TEST-NET-[1-3] for Documentation (RFCs 5735 and 5737)
zone "2.0.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "100.51.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "113.0.203.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };

// IPv6 Range for Documentation (RFC 3849)
zone "8.b.d.0.1.0.0.2.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };


// Domain Names for Documentation and Testing (BCP 32)
zone "test" { type master; file "/etc/namedb/master/empty.db"; };
zone "example" { type master; file "/etc/namedb/master/empty.db"; };
zone "invalid" { type master; file "/etc/namedb/master/empty.db"; };
zone "example.com" { type master; file "/etc/namedb/master/empty.db"; };
zone "example.net" { type master; file "/etc/namedb/master/empty.db"; };
zone "example.org" { type master; file "/etc/namedb/master/empty.db"; };


// Router Benchmark Testing (RFCs 2544 and 5735)
zone "18.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "19.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };

// IANA Reserved - Old Class E Space (RFC 5735)
zone "240.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "241.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "242.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "243.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "244.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "245.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "246.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "247.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "248.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "249.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "250.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "251.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "252.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "253.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "254.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };

// IPv6 Unassigned Addresses (RFC 4291)
zone "1.ip6.arpa"       { type master; file "/etc/namedb/master/empty.db"; };
zone "3.ip6.arpa"       { type master; file "/etc/namedb/master/empty.db"; };
zone "4.ip6.arpa"       { type master; file "/etc/namedb/master/empty.db"; };
zone "5.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "6.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "7.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "8.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "9.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "a.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "b.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "c.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "d.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "e.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "0.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "1.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "2.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "3.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "4.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "5.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "6.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "7.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "8.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "9.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "a.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "b.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "0.e.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "1.e.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "2.e.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "3.e.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "4.e.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "5.e.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "6.e.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "7.e.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };

// IPv6 ULA (RFC 4193)
zone "c.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "d.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };

// IPv6 Link Local (RFC 4291)
zone "8.e.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "9.e.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "a.e.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "b.e.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };

// IPv6 Deprecated Site-Local Addresses (RFC 3879)
zone "c.e.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "d.e.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "e.e.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };
zone "f.e.f.ip6.arpa"		{ type master; file "/etc/namedb/master/empty.db"; };

// IP6.INT is Deprecated (RFC 4159)
zone "ip6.int"			{ type master; file "/etc/namedb/master/empty.db"; };

// NB: Do not use the IP addresses below, they are faked, and only
// serve demonstration/documentation purposes!
//
// Example slave zone config entries.  It can be convenient to become
// a slave at least for the zone your own domain is in.  Ask
// your network administrator for the IP address of the responsible
// master name server.
//
// Do not forget to include the reverse lookup zone!
// This is named after the first bytes of the IP address, in reverse
// order, with ".IN-ADDR.ARPA" appended, or ".IP6.ARPA" for IPv6.
//
// Before starting to set up a master zone, make sure you fully
// understand how DNS and BIND work.  There are sometimes
// non-obvious pitfalls.  Setting up a slave zone is usually simpler.
//
// NB: Don't blindly enable the examples below. :-)  Use actual names
// and addresses instead.

/* An example dynamic zone
key "exampleorgkey" {
	algorithm hmac-md5;
	secret "sf87HJqjkqh8ac87a02lla==";
};
zone "example.org" {
	type master;
	allow-update {
		key "exampleorgkey";
	};
	file "/etc/named/dynamic/example.org";
};
*/

/* Example of a slave reverse zone
zone "1.168.192.in-addr.arpa" {
	type slave;
	file "/etc/namedb/slave/1.168.192.in-addr.arpa";
	masters {
		192.168.1.1;
	};
};
*/

Hierbei handelt es sich um Slave-Einträge für eine Reverse- und Forward-DNS-Zone, die in der Datei named.conf definiert sind.

Für jede neue Zone muss ein zusätzlicher Eintrag in named.conf erstellt werden.

Ein einfacher Eintrag für eine Zone example.org könnte beispielsweise so aussehen:

zone "example.org" {
        type master;
        file "master/example.org";
};     

Die Option type legt fest, dass es sich um eine Master-Zone handelt, deren Zoneninformationen sich in der Datei /etc/namedb/master/example.org befinden. Diese Datei wird durch die Option file festgelegt.

zone "example.org" {
        type slave;
        file "slave/example.org";
};     

Hier handelt es sich um einen Slaveserver, der seine Informationen vom Masterserver der betreffenden Zone bezieht und diese in der angegebenen Datei speichert. Wenn der Masterserver nicht erreichbar ist, verfügt der Slaveserver über die transferierten Zoneninformationen und kann diese an andere Rechner weitergeben.

30.6.6.2. Zonendateien

Die in der Datei /etc/namedb/master/example.org definierte Zonendatei für example.org könnte etwa so aussehen:

$TTL 3600        ; 1 hour default TTL
example.org.    IN      SOA      ns1.example.org. admin.example.org. (
                                2006051501      ; Serial
                                10800           ; Refresh
                                3600            ; Retry
                                604800          ; Expire
                                300             ; Negative Response TTL
                        )

; DNS Servers
                IN      NS      ns1.example.org.
                IN      NS      ns2.example.org.

; MX Records
                IN      MX 10   mx.example.org.
                IN      MX 20   mail.example.org.

                IN      A       192.168.1.1

; Machine Names
localhost       IN      A       127.0.0.1
ns1             IN      A       192.168.1.2
ns2             IN      A       192.168.1.3
mx              IN      A       192.168.1.4
mail            IN      A       192.168.1.5

; Aliases
www             IN      CNAME   example.org.

Beachten Sie, dass jeder mit einem “.” endende Rechnername ein exakter Rechnername ist, während sich alles ohne einen abschließenden “.” relativ auf den Ursprung bezieht. ns1 steht daher beispielsweise für ns1.example.org..

Eine Zonendatei hat folgenden Aufbau:

recordname      IN recordtype   value

Die am häufigsten verwendeten DNS-Einträge sind:

example.org. IN SOA ns1.example.org. admin.example.org. (
                        2006051501      ; Serial
                        10800           ; Refresh after 3 hours
                        3600            ; Retry after 1 hour
                        604800          ; Expire after 1 week
                        300 )           ; Negative Response TTL

	  IN NS           ns1.example.org.

Ein NS-Eintrag. Jeder Nameserver, der für eine Zone verantwortlich ist, muss über einen solchen Eintrag verfügen.

	  localhost       IN      A       127.0.0.1
	  ns1             IN      A       192.168.1.2
	  ns2             IN      A       192.168.1.3
	  mx              IN      A       192.168.1.4
	  mail            IN      A       192.168.1.5

Der Eintrag A bezieht sich auf Rechnernamen. ns1.example.org würde also zu 192.168.1.2 aufgelöst werden.

	  IN      A       192.168.1.1

Diese Zeile weist die IP-Adresse 192.168.1.1 dem aktuellen Ursprung, in unserem Fall also example.org, zu.

	  www             IN CNAME        @

Der Eintrag für den kanonischen Namen wird dazu verwendet, Aliase für einen Rechner zu vergeben. Im Beispiel ist www ein Alias für den “Master”-Rechner, dessen Name dem Domainnamen example.org (oder 192.168.1.1) entspricht. CNAMEs können daher niemals gleichzeitig mit einem anderen Eintrag für denselben Hostname eingerichtet werden.

	  IN MX   10      mail.example.org.

Die Option MX legt fest, welcher Mailserver für eintreffende Mails der Zone verantwortlich ist. mail.example.org ist der Rechnername des Mailservers, der eine Priorität von 10 hat.

Es können auch mehrere Mailserver mit verschiedener Priorität (10, 20, ...) vorhanden sein. Ein Mailserver, der eine Mail an example.org verschicken will, verwendet zuerst den MX mit der höchsten Priorität (das heißt den mit der niedrigsten Prioritätsnummer), danach den mit der nächsthöheren Priorität. Und dies solange, bis die E-Mail zugestellt werden kann.

Für (bei Reverse-DNS verwendete) in-addr.arpa-Zonendateien wird das gleiche Format verwendet. Der einzige Unterschied besteht in der Verwendung der Option PTR an Stelle der Optionen A und CNAME.

$TTL 3600

1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. (
                        2006051501      ; Serial
                        10800           ; Refresh
                        3600            ; Retry
                        604800          ; Expire
                        300 )           ; Negative Response TTL

        IN      NS      ns1.example.org.
        IN      NS      ns2.example.org.

1       IN      PTR     example.org.
2       IN      PTR     ns1.example.org.
3       IN      PTR     ns2.example.org.
4       IN      PTR     mx.example.org.
5       IN      PTR     mail.example.org.

Durch diese Datei werden den Rechnernamen der fiktiven Domäne IP-Adressen zugewiesen.

Beachten Sie bitte, dass es sich bei allen Namen auf der rechten Seite eines PTR-Eintrags um absolute (fully qualified) Domainnamen handeln muss, die mit “.” enden.

30.6.8.1. Rekursive DNS-Server Konfiguration

Die Aktivierung der DNSSEC-Überprüfung von Anfragen, die von einem rekursiven DNS-Server stammen, benötigt ein paar Änderungen in der named.conf. Bevor man jedoch diese Änderungen durchführt, muss der Root-Zonenschlüssel oder Vertrauensanker erworben werden. Momentan ist der Root-Zonenschlüssel nicht in einem Dateiformat verfügbar, dass von BIND benutzt werden kann, so dass dieser manuell in das richtige Format konvertiert werden muss. Der Schlüssel selbst kann durch Abfrage an die Root-Zone erhalten werden, indem man dazu dig verwendet. Durch Aufruf von

% dig +multi +noall +answer DNSKEY . > root.dnskey

wird der Schlüssel in root.dnskey abgelegt. Der Inhalt sollte so ähnlich wie folgt aussehen:

. 93910 IN DNSKEY 257 3 8 (
	AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
	bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
	/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
	JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
	oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
	LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
	Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
	LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
  	) ; key id = 19036
. 93910 IN DNSKEY 256 3 8 (
	AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf
	UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE
	g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V
	EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt
) ; key id = 34525

Seien Sie nicht alarmiert, wenn der von Ihnen bezogene Schlüssel anders als in diesem Beispiel aussieht. Diese könnten sich in der Zwischenzeit geändert haben. In dieser Ausgabe sind eigentlich zwei Schlüssel enthalten. Der erste Schüssel mit dem Wert 257 nach dem DNSKEY-Eintrag ist derjenige, der benötigt wird. Der Wert zeigt an, dass es sich um einen sicheren Einstiegspunkt (SEP), gemein auch als Schlüsselsignierungsschlüssel (KSK) bekannt, handelt. Der zweite Schüssel mit dem Wert 256 ist der untergeordnete Schlüssel, im allgemeinen auch als Zonen-Signaturschlüssel (ZSK) bezeichnet. Weitere Schlüsselarten werden später in Abschnitt 30.6.8.2 erläutert.

Nun muss der Schlüssel verifiziert und so formatiert werden, dass BIND diesen verwenden kann. Um den Schlüssel zu verifizieren, erzeugen Sie einen DS RR-Satz. Erstellen Sie eine Datei, welche die RRs enthält, mittels

% dnssec-dsfromkey -f root-dnskey . > root.ds

Diese Einträge verwenden SHA-1 sowie SHA-256 und sollten ähnlich zu folgendem Beispiel aussehen, in dem der längere, SHA-256, benutzt wird.

. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E
. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

Der SHA-256 RR kann nun mit dem Abriss in https://data.iana.org/root-anchors/root-anchors.xml verglichen werden. Um absolut sicher zu sein, dass der Schlüssel nicht zusammen mit den XML-Daten verändert wurde, kann die Datei mittels der PGP Signatur in https://data.iana.org/root-anchors/root-anchors.asc überprüft werden.

Als nächstes muss der Schlüssel in das passende Format gebracht werden. Dies unterscheidet sich ein bisschen von den BIND Versionen 9.6.2 und 9.7 und höhere. In Version 9.7 wurde die Ünterstützung zur automatischen Verfolgung und notwendigen Aktualisierung von Änderungen am Schlüssel eingebaut. Dies wird durch den Einsatz von managed-keys erreicht, wie in dem Beispiel unten gezeigt ist. Wenn die ältere Version eingesetzt wird, kann der Schlüssel durch eine trusted-keys-Anweisung eingebaut werden und die Aktualisierung muss händisch erfolgen. In BIND 9.6.2 sollte das Format folgendermassen aussehen:

trusted-keys {
	"." 257 3 8
	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
	QxA+Uk1ihz0=";
};

In 9.7 wird das Format stattdessen wie folgt aussehen:

managed-keys {
	"." initial-key 257 3 8
	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
  	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
  	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
  	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
  	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
  	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
  	QxA+Uk1ihz0=";
};

Der Root-Schlüssel kann nun zu named.conf hinzugefügt werden, entweder direkt oder durch Inkludierung der Datei, die den Schlüssel enthält. Nachdem diese Schritte absolviert sind, muss BIND konfiguriert werden, um DNSSEC-Validierung für Anfragen durchzuführen, indem named.conf bearbeitet und die folgende options-Direktive hinzugefügt wird:

dnssec-enable yes;
dnssec-validation yes;

Um zu prüfen, dass es tatsächlich funktioniert, benutzen Sie dig, um eine Anfrage zu einer signierten Zone durch den Resolver, der gerade konfiguriert wurde, zu stellen. Eine erfolgreiche Antwort wird den AD-Eintrag aufweisen, um anzudeuten, dass die Daten authentisiert sind. Eine Anfrage wie

% dig @resolver +dnssec se ds

sollte den DS RR für die .se-Zone zurückgeben. In dem Abschnitt flags: sollte der AD-Eintrag gesetzt sein, wie im folgenden zu sehen ist:

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

Der Resolver ist nun in der Lage, Anfragen ans DNS zu authentisieren.

30.6.8.2. Autoritative DNS-Server Konfiguration

Um einen autoritativen Nameserver dazu zu bringen, als eine DNSSEC-signierte Zone zu fungieren, ist ein wenig mehr Aufwand nötig. Eine Zone ist durch kryptographische Schlüssel signiert, die erzeugt werden müssen. Es ist möglich, nur einen Schlüssel dazu zu verwenden. Die vorgeschlagene Methode ist jedoch, einen starken, gut geschützten Schlüsselsignierungsschlüssel (KSK) einzusetzen, der nicht oft gewechselt wird und einen Zonensignierungsschlüssel (ZSK), der öfter ausgewechselt wird. Informationen zu vorgeschlagenen Einsatzarten können in RFC 4641: DNSSEC Operational Practices nachgelesen werden. Einsatzszenarien, welche die Root-Zone betreffen, finden Sie in DNSSEC Practice Statement for the Root Zone KSK operator sowie DNSSEC Practice Statement for the Root Zone ZSK operator. Der KSK wird dazu verwendet, um eine Kette von Autorität für die Daten, die diese Validierung benötigen, zu erschaffen und wird als solche auch als sicherer Einstiegspunkt (SEP)-Schlüssel bezeichnet. Ein Nachrichtenabriss dieses Schlüssels, der auch Delegation Signer (DS)-Eintrag genannt wird, muss in der Elternzone veröffentlicht werden, um die Vertrauenskette herzustellen. Wie dies erreicht wird, hängt von dem Besitzer der Elternzone ab. Der ZSK wird verwendet, um die Zone zu signieren und muss nur dort öffentlich zugänglich gemacht werden.

Um DNSSEC für die example.com-Zone, welche in den vorherigen Beispielen verwendet wird, zu aktivieren, muss als erster Schritt dnssec-keygen benutzt werden, um das KSK und ZSK Schlüsselpaar zu generieren. Dieses Schlüsselpaar kann unterschiedliche kryptographische Algorithmen nutzen. Es wird empfohlen, RSA/SHA256 für die Schlüssel zu nutzen. Eine Schlüssellänge von 2048 Bits sollte genügen. Um den KSK für example.com zu generieren, geben Sie

% dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com

ein und um den ZSK zu erzeugen, setzen Sie folgenden Befehl ab:

% dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com

dnssec-keygen gibt zwei Dateien aus, den öffentlichen und den privaten Schlüssel und zwar in Dateinamen, die ähnlich lauten wie Kexample.com.+005+nnnnn.key (öffentlich) und Kexample.com.+005+nnnnn.private (privat). Der nnnnn-Teil des Dateinamens ist eine fünfstellige Schlüsselkennung. Passen Sie genau auf, welche Kennung zu welchem Schlüssel gehört. Das ist besonders wichtig, wenn mehrere Schlüssel in einer Zone vorliegen. Es ist auch möglich, die Schlüssel umzubenennen. Für jede KSK-Datei tun Sie folgendes:

% mv Kexample.com.+005+nnnnn.key Kexample.com.+005+nnnnn.KSK.key
% mv Kexample.com.+005+nnnnn.private Kexample.com.+005+nnnnn.KSK.private

Für die ZSK-Dateien ersetzen Sie KSK für ZSK wenn nötig. Die Dateien können nun in der Zonendatei inkludiert werden, indem die $include Anweisung verwendet wird. Es sollte folgendermassen aussehen:

$include Kexample.com.+005+nnnnn.KSK.key    ; KSK
$include Kexample.com.+005+nnnnn.ZSK.key    ; ZSK

Schliesslich signieren Sie die Zone und weisen BIND an, die signierte Zonendatei zu benutzen. Um eine Zone zu signieren, wird dnssec-signzone eingesetzt. Der Befehl, um eine Zone example.com zu signieren, die in example.com.db liegt, sollte wie folgt aussehen:

% dnssec-signzone -o example.com -k Kexample.com.+005+nnnnn.KSK example.com.db Kexample.com.+005+nnnnn.ZSK.key

Der Schlüssel, welcher mit dem Argument -k übergeben wird, ist der KSK und die andere Schlüsseldatei ist der ZSK, welcher für die Signatur benutzt werden soll. Es ist möglich, mehr als einen KSK und ZSK anzugeben, was das Ergebnis zur Folge hat, dass die Zone mit allen übergebenen Schlüsseln signiert wird. Dies kann dann benötigt werden, um Zonendaten mit mehr als einem Algorithmus zur Signierung zu verwenden. Die Ausgabe von dnssec-signzone ist eine Zonendatei mit allen signierten RRs. Diese Ausgabe wird in einer Datei mit der Endung .signed abgelegt, wie beispielsweise example.com.db.signed. Die DS-Einträge werden ebenfalls in eine separate Datei dsset-example.com geschrieben. Um diese signierte Zone zu verwenden, ändern Sie die Zonendirektive in named.conf, so dass example.com.db.signed benutzt wird. Standardmässig sind die Signaturen nur 30 Tage gültig, was bedeutet, dass die Zone in etwa 15 Tagen erneut signiert werden muss, um sicher zu stellen, dass Resolver keine Einträge mit veralteten Signaturen zwischenspeichern. Es ist möglich, ein Skript und einen cron-Job zu schreiben, um dies zu erledigen. Lesen Sie dazu die relevanten Anleitungen, um Details zu erfahren.

Stellen Sie sicher, dass die privaten Schlüssel vertraulich bleiben, genau wie mit allen anderen kryptographischen Schlüsseln auch. Wenn ein Schlüssel geändert wird, ist es gute Praxis den neuen Schlüssel in die Zone zu inkludieren, noch während der alte Schlüssel noch zum signieren eingesetzt wird, um dann auf den neuen Schlüssel zum signieren zu wechseln. Nachdem diese Schritte erfolgt sind, kann der alte Schlüssel aus der Zone entfernt werden. Wenn das nicht geschieht, können DNS-Daten für einige Zeit nicht verfügbar sein, bis der neue Schlüssel durch die DNS-Hierarchie propagiert wurde. Für weitere Informationen bezüglich Schlüsselübergabe und andere DNSSEC-Einsatzszenarien lesen Sie RFC 4641: DNSSEC Operational practices.

30.6.8.3. Automatisierung mittels BIND 9.7 oder höher

Beginnend mit der Version 9.7 von BIND wurde eine neue Eigenschaft vorgestellt, die Smart Signing genannt wird. Diese zielt darauf ab, das Schlüsselmanagement und den Signierungsprozess einfacher zu gestalten und zu automatisieren. Durch ablegen der Schlüssel in ein Verzeichnis, genannt key repository und die Verwendung der neuen Option auto-dnssec, ist es möglich eine dynamische Zone zu erzeugen, welche dann erneut signiert wird, wenn dazu der Bedarf besteht. Um diese Zone zu aktualisieren, benutzen Sie nsupdate mit der neuen Option -l. Es hat also rndc die Fähigkeit gewonnen, Zonen mit Schlüsseln im Key Repository zu verwenden, indem die Option sign eingesetzt wird. Um BIND anzuweisen, diese automatische Signierung und Zonenaktualisierung für example.com zu nutzen, fügen Sie die folgenden Zeilen zur named.conf hinzu:

zone example.com {
	type master;
	key-directory "/etc/named/keys";
	update-policy local;
	auto-dnssec maintain;
	file "/etc/named/dynamic/example.com.zone";
};

Nachdem diese Änderungen durchgeführt wurden, erzeugen Sie die Schlüssel für die Zone wie in Abschnitt 30.6.8.2 beschrieben wird, legen diese Schlüssel im Key Repository ab, dass als Argument key-directory in der Zonenkonfiguration steht und die Zone wird automatisch signiert. Aktualisierungen für eine Zone, die auf diese Art und Weise konfiguriert wurde, muss mittels nsupdate erfolgen, dass sich um die erneute Signierung der Zone mit den hinzugefügten Daten kümmern wird. Für weitere Details, lesen Sie Abschnitt 30.6.10 und die Dokumentation von BIND.