30.6. Domeinnaamsysteem (DNS)

30.6.6.1. /etc/namedb/named.conf

// $FreeBSD$
//
// In de handleidingpagina's named.conf(5) en named(8), en in de
// documentatie in /usr/share/doc/bind9 zijn meer details te vinden.
//
// Voor het opzetten van een autoratieve server is een grondig begrip
// van de werking van DNS noodzakelijk.  Zelfs eenvoudige fouten kunnen // de werking verstoren voor beïnvloede partijen of veel onnodig
// Internetverkeer veroorzaken.

options {
       // Alle namen van bestanden en paden zijn relatief aan de chroot-map,
       // indien aanwezig, en moeten volledig gekwalificeerd zijn.
       directory       "/etc/namedb/working";
       pid-file        "/var/run/named/pid"
       dump-file       "/var/dump/named_dump.db"
       statistics-file "/var/stats/named.stats"

// Als named alleen als een lokale resolver gebruikt wordt, is dit een
// veilige standaardinstelling.  Om named toegang tot het netwerk te
// verschaffen, dient deze optie gecommentarieerd te worden, het
// juiste IP-adres opgegeven te worden, of dient deze optie verwijderd
// te worden.
       listen-on       { 127.0.0.1; };

// Als u IPv6 aan heeft staan op dit systeem, dient deze optie
// uitgecommentarieerd te worden om als lokale resolver te dienen.  Om
// toegang tot het netwerk te verschaffen, dient een IPv6-adres of het
// sleutelwoord "any" gegeven te worden.
//     listen-on-v6    { ::1; };

// Deze zones zijn reeds opgenomen door de lege zones die hieronder
// staan.  Als u de gerelateerde lege zones hieronder verwijdert,
// dienen deze regels uitgecommentarieerd te worden.
        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";

// Als er een DNS-server beschikbaar is bij een upstream provider dan
// kan het IP-adres op de regel hieronder ingegeven worden en kan die
// geactiveerd worden.  Hierdoor wordt voordeel gehaald uit de cache,
// waardoor het algehele DNS-verkeer op het Internet vermindert.
/*
       forwarders {
               127.0.0.1;
       };

*/

// Als de 'forwarders'-clausule niet leeg is, is de standaard om "forward
// first" te gebruiken, welke terug zal vallen op het versturen van een
// verzoek naar uw lokale server als de naamservers in 'forwarders' het
// antwoord niet weten.  Als alternatief kunt u uw naamserver dwingen om
// nooit zelf verzoeken in te dienen door de volgende regel aan te
// zetten:
//     forward only;

// Als u forwarding automatisch wilt configureren gebaseerd op de regels
// in /etc/resolv.conf, verwijder dan het commentaar van de volgende
// regel en stel in /etc/rc.conf named_auto_forward=yes in.  U kunt ook
// named_auto_forward_only aanzetten (het effect hiervan is hierboven
// beschreven).
//      include "/etc/namedb/auto_forward.conf";

Zoals al in het commentaar staat kan van een cache in de uplink geprofiteerd worden als forwarders ingeschakeld worden. Onder normale omstandigheden maakt een naamserver recursief verzoeken tot het Internet op zoek naar zekere naamservers tot er een antwoord komt waar het naar op zoek is. Door de bovenstaande optie in te schakelen wordt eerst de uplink naamserver (of de opgegeven naamserver) gevraagd, waardoor er gebruik gemaakt kan worden van de cache van die server. Als die uplink naamserver een drukke, snelle naamserver is, kan het erg de moeite waard zijn om dit aan te zetten.

/*
	  Moderne versies van BIND gebruiken standaard een random
	  UDP-poort voor elk uitgaand verzoek om de kans op cache
	  poisoning drastisch te verminderen.  Alle gebruikers wordt met
	  klem verzocht om deze mogelijkheid te gebruiken en hun
	  firewalls overeenkomstig aan te passen.

	  ALS EEN LAATSTE UITVLUCHT om een beperkende firewall te
	  omzeilen kunt u proberen om onderstaande optie aan te zetten.
	  Het gebruik van deze optie vermindert uw kans om een cache
	  poisoning aanval te weerstaan aanzienlijk, en dient indien
	  mogelijk te worden vermeden.

	  Vervang NNNNN in het voorbeeld door een getal tussen 49160 en
	  65530.
	*/
	// query-source address * port NNNNN;
};

// Als er een lokale naamserver wordt gebruikt, vergeet dan niet om
// eerst 127.0.0.1 in /etc/resolv.conf te zetten zodat die gevraagd
// wordt.  Controleer ook dat het in /etc/rc.conf is aangezet.

// Het traditionele root-hint-mechanisme.  Gebruik dit OF de
// onderstaande slaafzones.
zone "." { type hint; file "/etc/namedb/named.root"; };

/*	Het slaaf maken van de volgende zones vanaf de root-naamservers
	heeft een aantal aanzienlijke voordelen:
	1. Snellere lokale resolutie voor uw gebruikers
	2. Geen vals verkeer dat vanaf uw netwerk naar de roots wordt verzonden
	3. Betere weerstand tegen elke mogelijk falen van de rootserver/DDoS

	Wel is het zo dat deze methode meer toezicht vraagt dan het
	hintbestand om er zeker van te zijn dat een onverwachte
	faalmodus uw server niet heeft lamgelegd.  Naamservers die
	veel clienten serveren zullen meer voordeel uit deze aanpak
	halen dan individuele hosts.  Met zorg gebruiken.

	Verwijder het commentaar uit de onderstaande regels en
	commentarieer de bovenstaande hintzone om dit mechanisme te
	gebruiken.

	Zoals gedocumenteerd op http://dns.icann.org/services/axfr/ zijn deze
	zones: "." (de root), ARPA, IN-ADDR.ARPA, IP6.ARPA en ROOT-SERVERS.NET
	beschikbaar voor AXFR van deze servers op IPv4 en 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;
};

/*	Het lokaal serveren van de volgende zones voorkomt dat enig
	verzoek voor deze zones uw netwerk verlaat en naar de
	root-naamservers gaat.  Dit heeft twee aanzienlijke voordelen:
	1. Snellere lokale resolutie voor uw gebruikers
	2. Er zal geen vals verkeer vanaf uw netwerk naar de roots worden verzonden
*/
// RFCs 1912 en 5735 (en BCP32 voor 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-stijl zone voor IPv6 localhost adres
zone "0.ip6.arpa"	{ type master; file "/etc/namedb/master/localhost-reverse.db"; };

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

// Netwerken voor privaat gebruik (RFC 1918 en 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"; };

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

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

// TEST-NET-[1-3] voor documentatie (RFCs 5735 en 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-bereik voor documentatie (RFC 3849)
zone "8.b.d.0.1.0.0.2.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

// Domeinnamen voor documentatie en testen (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 benchmarken (RFC 2544 en 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"; }

// Gereserveerd door IANA - oude ruimte van klasse E (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"; }

// Niet-toegewezen IPv6-adressen (RFC 4291)
zone "1.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "2.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 lokale link (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 verouderde site-lokale adressen (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 verouderd (RFC 4159)
zone "ip6.int"	{ type master; file "/etc/namedb/master/empty.db"; }

// NB: De IP-adressen hieronder zijn bedoeld als voorbeeld en dienen
//     niet gebruikt te worden!
//
// Voorbeeld instellingen voor slaafzones.  Het kan handig zijn om
// tenminste slaaf te worden voor de zone waar de host onderdeel van
// uitmaakt.  Bij uw netwerkbeheerder kan het IP-adres van de
// verantwoordelijke meester-naamserver nagevraagd worden.
//
// Vergeet niet om de omgekeerde lookup-zone op te nemen!
// Dit is genoemd na de eerste bytes van het IP-adres, in omgekeerde
// volgorde, met daarachter ".IN-ADDR.ARPA", of "IP6.ARPA" voor IPv6.
//
// Het is van groot belang om de werking van DNS en BIND te begrijpen
// voordat er een meester-zone wordt opgezet.  Er zijn nogal wat
// onverwachte valkuilen.  Het opzetten van een slaafzone is
// gewoonlijk eenvoudiger.
//
// NB: Zet de onderstaande voorbeelden niet blindelings aan. :-)
// Gebruik in plaats hiervan echte namen en adressen.
/* Een voorbeeld van een dynamische zone
key "exampleorgkey" {
       algorithm hmac-md5;
       secret "sf87HJqjkqh8ac87a02lla==";
};

zone "example.org" {
       type master;
       allow-update {
               key "exampleorgkey";
       };
       file "/etc/namedb/dynamic/example.org";
};
*/

/* Voorbeeld van een omgekeerde slaafzone
zone "1.168.192.in-addr.arpa" {
       type slave;
       file "/etc/namedb/slave/1.168.192.in-addr.arpa";
       masters {
               192.168.1.1;
       };
};
*/

In named.conf zijn dit voorbeelden van slaafregels voor een voorwaartse en een omgekeerde zone.

Voor iedere nieuwe zone die wordt aangeboden dient een nieuwe instelling voor de zone aan named.conf toegevoegd te worden.

De eenvoudigste instelling voor de zone example.org kan er als volgt uitzien:

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

De zone is een master, zoals aangegeven door het statement type, waarvan de zoneinformatie in /etc/namedb/example.org staat, zoals het statement file aangeeft.

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

In het geval van de slaaf wordt de zoneinformatie voor een zone overgedragen van de master naamserver en opgeslagen in het ingestelde bestand. Als de masterserver het niet meer doet of niet bereikbaar is, dan heeft de slaveserver de overgedragen zoneinformatie nog en kan het die aanbieden.

30.6.6.2. Zonebestanden

Een voorbeeldbestand voor een masterzone voor example.org (bestaande binnen /etc/namedb/master/example.org) ziet er als volgt uit:

$TTL 3600        ; 1 uur standaard TTL
example.org.     IN      SOA      ns1.example.org. admin.example.org. (
                                 2006051501      ; Serienummer
                                 10800           ; Verversen
                                 3600            ; Opnieuw proberen
                                 604800          ; Verlopen
                                 300             ; Negatieve antwoord-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

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

; Aliases
www              IN      CNAME   example.org.

Iedere hostnaam die eindigt op een “.” is een exacte hostnaam, terwijl alles zonder een “.” op het einde relatief is aan de oorsprong. Zo wordt ns1 bijvoorbeeld vertaald naar ns1.example.org..

De regels in een zonebestand volgen de volgende opmaak:

recordnaam      IN recordtype   waarde

De meest gebruikte DNS-records:

example.org. IN SOA ns1.example.org. admin.example.org. (
                        2006051501      ; Serienummer
                        10800           ; Ververs na 3 uur
                        3600            ; Opnieuw proberen na 1 uur
                        604800          ; Verlopen na 1 week
                        300             ; Negatieve antwoord-TTL

       IN NS           ns1.example.org.

Hierboven staat een NS-regel. Voor iedere naamserver die bevoegde antwoorden moet geven voor de zone hoort er zo'n regel te zijn.

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

Een A-record geeft een machinenaam aan. Hierboven is te zien dat ns1.example.org zou resolven naar 192.168.1.2.

       IN      A       192.168.1.1

Deze regel kent IP-adres 192.168.1.1 toe aan de huidige oorsprong, in dit geval example.org.

www             IN CNAME        @

Een canoniek naamrecord wordt meestal gebruikt voor het geven van aliassen aan een machine. In het voorbeeld is www een alias naar de “master” machine waarvan de naam gelijk is aan de domeinnaam example.org (192.168.1.1). CNAME's kunnen nooit samen met een ander soort record voor dezelfde hostnaam gebruikt worden.

               IN MX   10      mail.example.org.

MX records geven aan welke mailservers verantwoordelijk zijn voor het afhandelen van inkomende mail voor de zone. mail.example.org is de hostnaam van een mailserver en 10 is de prioriteit voor die mailserver.

Het is mogelijk meerdere mailservers in te stellen met prioriteiten 10, 20, enzovoorts. Een mailserver die probeert mail af te leveren voor example.org probeert dat eerst bij de MX met de hoogste prioriteit (het record met het laagste prioriteitsnummer), daarna de tweede hoogste, enzovoort, totdat de mail afgeleverd kan worden.

Voor in-addr.arpa zonebestanden (omgekeerd DNS) wordt dezelfde opmaak gebruikt, maar dan met PTR-regels in plaats van A of CNAME.

$TTL 3600

1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. (
                        2006051501      ; Serienummer
                        10800           ; Ververs
                        3600            ; Opnieuw proberen
                        604800          ; Verlopen
                        300 )           ; Negatieve antwoord-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.

Dit bestand geeft de juiste IP-adressen voor hostnamen in het voorbeelddomein hierboven.

Het is het vernoemen waard dat alle namen aan de rechterkant van een PTR-record volledig gekwalificeerd dienen te zijn (i.e., met een “.” eindigen).

30.6.8.1. Configuratie van een recursieve DNS-server

Het aanzetten van DNSSEC-validatie van verzoeken die door een recursieve DNS-server worden uitgevoerd heeft enkele aanpassingen aan named.conf nodig. Voordat deze wijzigingen worden gemaakt dient de rootzone-sleutel, of vertrouwensanker, te worden opgehaald. Momenteel is de rootzone-sleutel niet beschikbaar in een bestandsformaat dat BIND begrijpt, dus moet het handmatig in het juiste formaat omgezet worden. De sleutel zelf kan verkregen worden door de rootzone ervoor met dig te ondervragen. Door

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

te draaien, wordt de sleutel in root.dnskey opgeslagen. De inhoud dient er ongeveer als volgt uit te zien:

. 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

Schrik niet als de verkregen sleutels anders zijn dan in dit voorbeeld. Ze kunnen zijn veranderd nadat deze instructies voor het laatst waren bijgewerkt. De uitvoer bevat in feite twee sleutels. De eerste sleutel, met de waarde 257 na het DNSKEY-recordtype, is degene die nodig is. Deze waarde geeft aan dat dit een Secure Entry Point ( SEP) is, beter bekend als een Key Signing Key (KSK). De tweede sleutel, met de waarde 256, is een deelsleutel, beter bekend als een Zone Signing Key (ZSK). Meer over de verschillende soorten sleutels komt aan bod in Paragraaf 30.6.8.2.

Nu moet de sleutel gecontroleerd en geformatteerd worden zodat BIND deze kan gebruiken. Maak om de sleutel te controleren een DS - RR-paar aan. Maak een bestand aan dat deze RRs bevat aan met

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

Deze records gebruiken respectievelijk SHA-1 en SHA-256, en dienen er als het volgende voorbeeld uit te zien, waarbij het langere record SHA-256 gebruikt.

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

Het SHA-256 RR kan nu worden vergeleken met de digest in https://data.iana.org/root-anchors/root-anchors.xml. Om er absoluut zeker van te zijn dat er niet geknoeid is met de sleutel kunnen de gegevens in het XML-bestand worden gecontroleerd met de PGP-handtekening in https//data.iana.org/root-anchors/root-anchors.asc.

Vervolgens dient de sleutel juist geformateerd te worden. Dit verschilt een beetje tussen versie 9.6.2 en versie 9.7 en later van BIND. In versie 9.7 is ondersteuning toegevoegd om automatisch veranderingen aan de sleutel te volgen en deze bij te werken indien nodig. Dit wordt gedaan met managed-keys zoals in het volgende voorbeeld te zien is. Als de oudere versie gebruikt wordt, wordt de sleutel toegevoegd met een commando trusted-keys en dient deze handmatig bijgewerkt te worden. Voor BIND 9.6.2 ziet het formaat er uit als:

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

Voor versie 9.7 ziet het formaat er echter zo uit:

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

De rootsleutel kan nu aan named.conf worden toegevoegd, ofwel direct of door een bestand dat de sleutel bevat te includen. Stel na deze stappen BIND in zodat het DNSSEC-validatie uitvoert op verzoeken door named.conf te bewerken en het volgende aan de directief options toe te voegen:

dnssec-enable yes;
dnssec-validation yes;

Om te controleren dat het ook echt werkt, kan dig gebruikt worden om een verzoek op een ondertekende zone uit te voeren met de zojuist geconfigureerde resolver. Een succesvol antwoord zal de vlag AD bevatten om aan te geven dat de gegevens zijn geautenticeerd. Een verzoek als

% dig @resolver +dnssec se ds

zou het DS RR paar voor de .se-zone moeten teruggeven. In de sectie flags: moet de vlag AD te zien zijn, als in:

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

De resolver is nu in staat om DNS-verzoeken te autenticeren.

30.6.8.2. Configuratie van een autoratieve DNS-server

Om een autoratieve naamserver een met DNSSEC ondertekende zone te laten serveren is wat meer werk nodig. Een zone wordt ondertekend met cryptografische sleutels die aangemaakt moeten worden. Het is mogelijk om hier slechts één sleutel voor te gebruiken. De methode die de voorkeur verdient is echter om een sterke, goed beschermde Key Signing Key (KSK) die niet vaak wordt geroteerd en een Zone Signing Key (ZSK) die vaker wordt geroteerd te hebben. Informatie over aanbevolen procedures staat in RFC 4641: DNSSEC Operational Practices. Procedures betreffende de rootzone staan in DNSSEC Practice Statement for the Root Zone KSK operator en DNSSEC Practice Statement for the Root Zone ZSK operator. De KSK wordt gebruikt om een autoriteitsketen voor de te valideren gegevens op te bouwen en wordt daarom ook een Secure Entry Point (SEP)-sleutel genoemd. Een bericht-digest van deze sleutel, dat Delegation Signer (DS)-record genoemd wordt, moet gepubliceerd zijn in de ouderzone om een vertrouwensketen op te bouwen. Hoe dit bereikt wordt hangt af van de eigenaar van de ouderzone. De ZSK wordt gebruikt om de zone te ondertekenen, en hoeft alleen daar gepubliceerd te worden.

Om DNSSEC aan te zetten voor de zone example.com zoals beschreven in de voorgaande voorbeelden, dient als eerste dnssec-keygen gebruikt te worden om het sleutelpaar met de KSK en ZSK te genereren. Dit sleutelpaar kan verschillende cryptografische algoritmes gebruiken. Het wordt aanbevolen om RSA/SHA-256 voor de sleutels te gebruiken, een sleutellengte van 2048 bits zou voldoende moeten zijn. Om de KSK voor example.com te genereren:

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

en om de ZSK te genereren:

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

dnssec-keygen maakt twee bestanden, de publieke en private sleutels in bestanden met namen als Kexample.com.+005+nnnnn.key (publiek) en Kexample.com.+005+nnnnn.private (privaat). Het gedeelte nnnnn van de bestandsnaam is een sleutel-ID van vijf cijfers. Houd bij welke sleutel-ID bij welke sleutel hoort. Dit is in het bijzonder van belang wanneer er meerdere sleutels per zone zijn. Het is ook mogelijk om de sleutels te hernoemen. Voor elk KSK-bestand:

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

Voor ZSK-bestanden dient KSK waar nodig door ZSK vervangen te worden. De bestanden kunnen nu worden opgenomen in het zonebestand, door de opdracht $include te gebruiken. Het zou er ongeveer als volgt uit moeten zien:

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

Onderteken tenslotte de zone en vertel BIND om het ondertekende zonebestand te gebruiken. Voor het ondertekenen van een zone wordt dnssec-signzone gebruikt. Het commando om de zone example.com, dat zich in example.com.db bevindt, zou er ongeveer zo uit moeten zien:

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

De sleutel die aan het argument -k wordt meegegeven is de KSK en het andere sleutelbestand is de ZSK dat bij het ondertekenen gebruikt moet worden. Het is mogelijk om meer dan één KSK en ZSK op te geven, wat tot gevolg heeft dat de zone met alle meegegeven sleutels wordt ondertekend. Dit kan nodig zijn om zonegegevens aan te leveren die met meerdere algoritmes zijn ondertekend. De uitvoer van dnssec-signzone is een zonebestand met daarin alle RRs ondertekend. Deze uitvoer komt in een bestand met de extensie .signed terecht, zoals example.com.db.signed. De DS-records worden ook naar een apart bestand dsset-example.com geschreven. Om deze ondertekende zone te gebruiken hoeft alleen de zone-directief in named.conf veranderd te worden om example.com.db.signed. Standaard zijn de ondertekeningen slechts 30 dagen geldig, wat betekent dat de zone over ongeveer 15 dagen hertekend moet worden om er zeker van te zijn dat resolvers geen records met oude ondertekeningen cachen. Het is mogelijk om hiervoor een script en een crontaak te maken. Bekijk de relevante handleidingen voor details.

Zorg ervoor dat de private sleutels veilig blijven, zoals met alle cryptografische sleutels. Bij het veranderen van een sleutel kan het beste de nieuwe sleutel in de zone opgenomen worden, en nog met de oude sleutel te ondertekenen, en om daarna over te stappen op de nieuwe sleutel. Nadat deze handelingen zijn voltooid kan de oude sleutel uit de zone worden verwijderd. Wanneer dit niet wordt gedaan kunnen de DNS-gegevens tijdelijk onbeschikbaar zijn totdat de nieuwe sleutel door de DNS-hiërarchie is gepropageerd. Meer informatie over sleutelwisselingen en andere praktijken rondom DNSSEC staan in RFC 4641: DNSSEC Operational practices.

30.6.8.3. Automatisering met BIND 9.7 of nieuwer

In versie 9.7 van BIND is een nieuwe mogelijkheid genaamd Smart Signing geïntroduceerd. Deze mogelijkheid heeft als doel om het sleutelbeheer en ondertekenproces eenvoudiger te maken door delen van deze taken te automatiseren. Door de sleutels in een sleutelreservoir te stoppen en de nieuwe optie auto-dnssec te gebruiken, is het mogelijk om een dynamische zone aan te maken welke opnieuw getekend wordt indien dat nodig is. Gebruik om deze zone bij te werken nsupdate met de nieuwe -l. rndc kan nu ook zones ondertekenen met sleutels uit het sleutelreservoir door de optie sign te gebruiken. Voeg, om BIND dit automatische ondertekenen en bijwerken van zones te laten gebruiken voor example.com, het volgende aan named.conf toe:

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

Nadat deze veranderingen gemaakt zijn, dienen de sleutels voor de zone aangemaakt te worden zoals uitgelegd in Paragraaf 30.6.8.2, deze sleutels in het sleutelreservoir gestopt te worden dat als argument aan de key-directory in het zoneconfiguratie is meegegeven, waarna de zone automatisch zal worden ondertekend. Zones die op deze manier zijn geconfigureerd dienen met nsupdate te worden gedaan, dat voor het opnieuw ondertekenen van de zone met de nieuw toegevoegde gegevens zal zorgen. Zie voor meer details Paragraaf 30.6.10 en de BIND-documentatie.