Hands-on: DNSSEC -ondertekening op BIND named
1 Inleiding
Beheerders die zelf hun DNS -dienst onderhouden maken daarvoor meestal gebruik van BIND named, de meest gebruikte DNS-server buiten de wereld van de grote registrars. BIND named kan fungeren als (autoritatieve) name-server en/of (caching) resolver. In dit artikel behandelen we de ondertekening van een zone op een autoritatieve name-server. De configuratie van named als DNSSEC-validerende resolver lees je in een ander artikel.
De DNSSEC-functionaliteit van BIND is over de afgelopen jaren stapsgewijs ontwikkeld en inmiddels een volwassen onderdeel van deze DNS-server geworden. Dat betekent wel dat er aanzienlijke verschillen zijn tussen achtereenvolgende (minor) versies.
Waar mogelijk en relevant geven we in dit artikel steeds aan vanaf welke versie een bepaalde feature ondersteund wordt. Dat is met name van belang voor gebruikers van enterprise-platforms, omdat die uit stabiliteits- en veiligheidsoverwegingen in het algemeen niet de meest recente software-versies gebruiken. Daarnaast kan het heel goed zijn dat de BIND-software op een bestaande server inmiddels opgewaardeerd is via het package management systeem van het operating system, maar de gebruikte configuratie nog is gebaseerd op een oudere versie.
Desondanks raden we aan om een zo'n recent mogelijke versie van BIND te gebruiken, al was het alleen maar omdat in de tussentijd natuurlijk ook bugs en security-problemen uit de software zijn gehaald.
1.1 Hoe dit artikel te lezen
We behandelen hier de DNSSEC-functionaliteit van BIND named zoals die in de loop der tijd aan de opeenvolgende feature releases toegevoegd is, van het genereren van sleutelparen en het ondertekenen van zone files tot het automatiseren van het ondertekeningsproces en het sleutelbeheer. Daarmee biedt dit artikel een natuurlijke manier om de opbouw van die functionaliteit te begrijpen. Ben je bezig met een implementatie van DNSSEC-ondertekening op BIND, dan is het ook niet per se nodig om door te lezen over de mogelijkheden van latere versies.
We bespreken steeds de belangrijkste functionaliteit en opties om tot een complete (waar mogelijk geautomatiseerde) configuratie te komen. Voor de details en minder alledaagse opties verwijzen we naar de Administrator Reference Manual (ARM) en de man pages van BIND.
| BIND versies | aanbevolen configuratie |
|---|---|
| 9.6 | automatisering van (her)ondertekening en sleutelbeheer op basis van scripts en cron jobs, daarbij gebruikmakend van 'dnssec-keygen' en 'dnssec-signzone' |
| 9.7-9.8 | geautomatiseerde (her)ondertekening via Auto-DNSSEC ('auto-dnssec maintain'); updates via Dynamic DNS ('nsupdate -l' en 'rndc sign'); automatisering van sleutelbeheer op basis van scripts en cron jobs, daarbij gebruikmakend van 'dnssec-keygen', 'dnssec-keygen -S' (smart signing) vanaf versie 9.7.2 |
| 9.9-9.10 | geautomatiseerde (her)ondertekening via Auto-DNSSEC ('auto-dnssec maintain'), in combinatie met Inline-Signing ('inline-signing yes'); updates via 'rndc signing'; automatisering van sleutelbeheer op basis van scripts en cron jobs, daarbij gebruikmakend van 'dnssec-keygen -S' (smart signing) |
| 9.11 e.v. | geautomatiseerde (her)ondertekening via Auto-DNSSEC ('auto-dnssec maintain'), in combinatie met Inline-Signing ('inline-signing yes'); updates via 'rndc signing'; geautomatiseerd sleutelbeheer via 'dnssec-keymgr' en policy file /etc/dnssec-policy.conf |
Inhoudsopgave
Deel 1: Genereren sleutelparen en ondertekenen zone file
2 RHEL, CentOS en Fedora
We zijn voor dit artikel uitgegaan van de Red Hat Linux-distributies, omdat daarvan een commercieel-ondersteunde, een vrije en een community-gedragen variant beschikbaar zijn: respectievelijk RHEL, CentOS en Fedora.
2.1 RHEL en CentOS versie 7
Bij de introductie van RHEL7 was deze voorzien van BIND versie 9.9.4. En dat is nog steeds de huidige versie (via de updates van CentOS versie 7.4).
Wil je op een RHEL7/CentOS7-systeem een meer recente versie van BIND gebruiken, dan kun je het RPM-bestand voor versie 9.10.3 downloaden van de site van Benjamin Kraft. Let er daarbij op dat je tegelijkertijd een nieuw (bijbehorend) configuratiebestand installeert.
2.2 RHEL en CentOS versie 6
RHEL6 kwam in eerste instantie met BIND versie 9.7.0 en is inmiddels via de updates (CentOS versie 6.9) opgewaardeerd naar versie 9.8.2.
Wil je op je huidige RHEL6/CentOS6-systeem een meer recente versie van BIND gebruiken, dan kun je de RPM-bestanden voor versie 9.10.3 en 9.9.8 downloaden van de site van Benjamin Kraft. Let er daarbij op dat je tegelijkertijd een nieuw (bijbehorend) configuratiebestand installeert. Met name versie 9.9 bracht belangrijke nieuwe DNSSEC-functionaliteit met zich mee.
2.3 Fedora
Fedora 26 (en 27) zijn voorzien van BIND versie 9.11.1 (updates). Met versie 9.11 kwam ook weer nieuwe DNSSEC-functionaliteit beschikbaar.
Voor alle Linux-distributies gebaseerd op Red Hat (en de RPM package manager) geldt dat je de huidige (geïnstalleerde) versie van BIND als volgt kunt opvragen:
rpm -q bind
3 Ubuntu Server
Voor gebruikers van Ubuntu Server — de meeste gebruikte Linux-distributie voor servers, gebaseerd op Debian — geven we hieronder een overzicht van de BIND-versies die met de verschillende releases worden meegeleverd.
| Ubuntu Server release | BIND versie |
|---|---|
| 12.04.5 LTS (Precise Pangolin) | 9.8.1 |
| 14.04.5 LTS (Trusty Tahr) | 9.9.5 |
| 16.04.3 LTS (Xenial Xerus) | 9.10.3 |
| 17.10.1 (Artful Aardvark) | 9.10.3 |
| 18.04 LTS (Bionic Beaver) | 9.11.2 |
Deel 1: Genereren sleutelparen en ondertekenen zone file
4 DNS zone file
Uitgangspunt voor dit artikel is een goed werkende (autoritatieve) DNS-installatie. Dat wil in ons geval zeggen dat we een zone file db.example.nl (download) hebben voor het domein example.nl:
$TTL 1d ; ttl is 1 day
@ IN SOA dns1.example.nl. dns.example.nl. (
2017101300 ; serial (date & version)
8h ; refresh every 8 hours
20m ; retry after 20 minutes
4w ; expire after 4 weeks
20m ; negative caching ttl is 20 minutes
)
; DNS name servers
IN NS dns1.example.nl. ; primary name server
IN NS dns2.example.nl. ; secondary name server
; SMTP mail gateways
IN MX 10 mx.example.nl. ; MX gateway
IN MX 100 fallback-mx.example.nl. ; fallback MX gateway
; hosts
IN A 192.168.129.36 ; server
IN AAAA a022:2f87:1098::2:14 ; server (IPv6)
www IN CNAME example.nl. ; WWW server
ftp IN CNAME example.nl. ; FTP server
mx IN A 192.168.128.34 ; mail gateway
mx IN AAAA a022:2f87:1098::1:6 ; mail gateway (IPv6)
mail IN A 192.168.128.35 ; mail server
mail IN AAAA a022:2f87:1098::1:7 ; mail server (IPv6)
; exterior hosts
dns1 IN A 172.16.64.5 ; primary name server
dns1 IN AAAA 2f87:a022:0941::8:5 ; primary name server (IPv6)
dns2 IN A 172.16.128.6 ; secondary name server
dns2 IN AAAA 2f87:a022:0941::16:6 ; secondary name server (IPv6)
fallback-mx IN A 10.184.172.36 ; fallback mail gateway
fallback-mx IN AAAA 0941:20a2:7f34::32:7 ; fallback mail gateway (IPv6)
En dat deze als master (primary) staat geconfigureerd in de file /etc/named.conf:
zone "example.nl" {
type master;
file "db.example.nl";
};
5 DNSSEC in BIND
De ondersteuning van DNSSEC was een van de aanleidingen (met name voor het Amerikaanse leger) voor de ontwikkeling van BIND versie 9. Met de ondersteuning van NSEC3 en 'automatic zone re-signing' was BIND 9.6 de eerste versie met een moderne DNSSEC-implementatie.
Hieronder geven we een overzicht van de DNSSEC-functionaliteit zoals die in de loop der tijd aan de opeenvolgende feature releases van BIND is toegevoegd, en zoals die in dit artikel wordt behandeld.
| BIND release | feature | configuratie-opties en commando's |
|---|---|---|
| 9.7 | smart signing (9.7.2) | dnssec-enable yes dnssec-keygen dnssec-signzone dnssec-dnskey-kskonly yes update-check-ksk no dnssec-settime dnssec-revoke dnssec-verify dnssec-dsfromkey dnssec-checkds |
| Auto-DNSSEC | key-directory "/etc/bind/keys" auto-dnssec maintain update-policy local nsupdate -l rndc sign rndc loadkeys dnssec-loadkeys-interval dnssec-secure-to-insecure serial-update-method sig-validity-interval |
|
| 9.9 | Inline-Signing | inline-signing yes rndc signing rndc zonestatus (9.10.0) |
| 9.11 | key management | dnssec-keymgr /etc/dnssec-policy.conf dnssec-coverage (9.9.3) rndc showzone |
| 9.12 | dnssec-cds |
5.1 Cryptografische algoritmen
De cryptografische algoritmen gebaseerd op SHA-2 (RSA/SHA-256 en RSA/SHA-512) zijn pas vanaf versie 9.6.2 beschikbaar. En de ECDSA-gebaseerde algoritmen ('ECDSA Curve P-256 with SHA-256' en 'ECDSA Curve P-384 with SHA-384') vanaf versie 9.9.2.
Op dit moment beschouwen we algoritmen nummer 8 (RSA/SHA-256) en 10 (RSA/SHA-512) als een veilig minimum. Voor nieuwe DNSSEC deployments raden we het efficientere algoritmenummer 13 (ECDSA Curve P-256 with SHA-256) aan.
Algoritme nummer 1 (RSA/MD5) moet je in ieder geval niet meer gebruiken. Het gebruik van de algoritmen gebaseerd op SHA-1 (nog vaak genoemd als standaard en gebruikt als default-instelling) raden we sterk af. Dat betreft algoritmen nummer 3 (DSA/SHA1) en nummer 6 (DSA-NSEC3-SHA1), en ook nummer 5 (RSA/SHA-1) en nummer 7 (RSASHA1-NSEC3-SHA1).
5.2 Configuratie
De configuratie van DNSSEC voor BIND named begint met het toevoegen van deze optie aan de configuratie file:
dnssec-enable yes;
Let op dat je de 'dnssec-enable' optie niet alleen aan moet zetten voor het ophoesten van DNSSEC-gerelateerde records op een autoritatieve DNS-server, maar ook voor DNSSEC-validatie op een server die alleen dienst doet als resolver.
5.3 Genereren sleutels
Voordat we ons domein example.nl kunnen ondertekenen, moeten we eerst twee sleutelparen (KSK en ZSK) genereren. Voor het genereren van het KSK-paar gebruiken we de volgende commando's:
mkdir -p /etc/bind/keys/ cd /etc/bind/keys/ dnssec-keygen -f KSK -3 -a ECDSAP256SHA256 -r /dev/random example.nl
[root@services]# dnssec-keygen -f KSK -3 -a ECDSAP256SHA256 -r /dev/random example.nl Generating key pair. Kexample.nl.+013+11769
BIND versies ouder dan 9.9.2 ondersteunen ECDSA niet, dus voor die gevallen gebruiken we de opties '-a RSASHA256 -b 4096' (RSA/SHA-256 met een sleutellengte van 4096 bits). Bij de selectie van een van de twee ECDSA-algoritmen is de sleutellengte inbegrepen, dus de '-b' optie niet nodig.
BIND versie 9.12 bevat geen standaardinstellingen meer voor de cryptografische algoritmen. Daarmee is de '-a' optie voor dnssec-keygen verplicht geworden.
De '-3' optie verifieert dat het gekozen algoritme compatibel is met NSEC3. Daarmee kunnen ook ondertekende antwoorden worden teruggestuurd als een Domeinnaam niet gevonden is (NXDOMAIN), zonder dat alle adressen binnen een domein op die manier door kwaadwillenden kunnen worden afgelopen en geïnventariseerd (name walking).
Voor DNSSEC-sleutelparen moeten de 'nametype' en 'class' gelijk zijn aan respectievelijk ZONE en IN. Omdat dit overeenkomt met de standaardinstellingen van dnssec-keygen hebben we de opties '-n ZONE -c IN' hierboven weggelaten. Wil je voor de sleutels een andere directory gebruiken dan de huidige, dan is daarvoor de '-K' optie beschikbaar.
5.4 ZSK-sleutelpaar
Voor het genereren van het ZSK-sleutelpaar gebruiken we een vergelijkbaar commando, maar nu zonder de '-f KSK' optie:
[root@services]# dnssec-keygen -3 -a ECDSAP256SHA256 -r /dev/random example.nl Generating key pair. Kexample.nl.+013+59790
Voor installaties ouder dan versie 9.9.2 gebruiken we de opties '-a RSASHA256 -b 2048' (RSA/SHA-256 met een sleutellengte van 2048 bits). Omdat we ZSK-sleutelparen veel vaker vervangen dan KSK-sleutelparen (bijvoorbeeld elk kwartaal in plaats van elk jaar), is een sleutellengte van 2048 bits hier voldoende.
5.5 Random generator
Bij het genereren van beide sleutelparen hebben we gekozen voor de pseudo-random generator /dev/random. Vooral op een machine waar maar weinig gebeurt of die net is opgestart kan het zijn dat deze (blokkerende) generator erg langzaam is omdat er op dat moment te weinig random bits beschikbaar zijn om de generator van nieuwe seed te voorzien. Een alternatief is de (niet-blokkerende) /dev/urandom generator. Deze wacht niet tot er voldoende random bits beschikbaar zijn maar levert in dat geval bit strings gegenereerd met minder entropie (randomness) in de seeds.
Vooral DSA-gebaseerde algoritmen zijn erg gevoelig voor een slecht geïnitialiseerde random-generator. Dat kan dus resulteren in een onveilig sleutelpaar. Voor productiesystemen moet daarom altijd de '-r /dev/random' optie worden gebruikt.
Vanaf versie 9.12 gebruikt BIND standaard een cryptografische library als OpenSSL voor het genereren van zijn random bits.
Gaat het om een grotere DNS-infrastructuur, dan is omwille van zowel de veiligheid als de schaalbaarheid een bump-in-the-wire architectuur op basis van OpenDNSSEC en een HSM (Hardware Security Module) aan te bevelen. De installatie en configuratie van OpenDNSSEC bespreken we in een ander artikel. BIND kan zelf ook gecombineerd worden met een HSM, maar dat valt buiten de scope van dit artikel.
5.6 Sleutelbestanden
Het op deze manier genereren van de twee sleutelparen levert vier bestanden op in de directory /etc/bind/keys/:
- Kexample.nl.+013+11769.key
- Kexample.nl.+013+11769.private
- Kexample.nl.+013+59790.key
- Kexample.nl.+013+59790.private
De bestanden met de extensie .private hebben de permissies 600 en bevatten de private (dat wil zeggen: geheime!) sleutels. De bestanden met de extensie .key bevatten de publieke sleutels in de vorm van een DNSKEY record. Aan die records kun je ook het verschil zien tussen KSK- en ZSK-sleutels: de waarden voor de vlaggen zijn respectievelijk 257 en 256 (de eerste heeft een gezette Secure Entry Point (SEP)-vlag). In de bestandsnamen zijn naast de betreffende domeinnaam ook het algoritme-nummer (in dit geval 13 voor ECDSAP256SHA256) en de keyid opgenomen. Die laatste is niet meer dan een willekeurig ("uniek") nummer om de verschillende sleutelparen uit elkaar te kunnen houden.
Normaal gesproken krijgen de DNSKEY records geen eigen TTL-waarde mee. Dan wordt die van het SOA record gebruikt. Maar het is ook mogelijk deze expliciet in te stellen via de '-L' optie (vanaf versie 9.9.0).
Naast het sleutelmateriaal zelf bevatten de bestanden ook datum-informatie. Deze velden zijn onderdeel van de 'smart signing' functionaliteit die werd geïntroduceerd met BIND versie 9.7.0. Daarover meer hieronder.
6 Ondertekenen
Voor het handmatig ondertekenen van een bestaande zone file db.example.nl gebruiken we het volgende commando:
dnssec-signzone -S -K /etc/bind/keys/ -g -a -r /dev/random -o example.nl db.example.nl
[root@services]# dnssec-signzone -S -K /etc/bind/keys/ -g -a -r /dev/random -o example.nl db.example.nl
Fetching ZSK 59790/ECDSAP256SHA256 from key repository.
Fetching KSK 11769/ECDSAP256SHA256 from key repository.
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
db.example.nl.signed
Eventueel kun je nog wat ruimte in de ondertekende zone file besparen door de '-x' optie mee te geven. Daarbij worden alleen de KSK-sleutels gebruikt om de DNSKEY RRset te ondertekenen, waarmee ZSK-ZSK-schakels uitgesloten zijn. Dezelfde optie is ook beschikbaar als de zone configuratie-optie 'dnssec-dnskey-kskonly yes' (vanaf BIND named versie 9.10.0 ook voor slave zones in combinatie met inline-signing). Deze optie geldt ook voor de CDS en CDNSKEY RRsets (vanaf versie 9.12).
Het resultaat is een ondertekende zone file db.example.nl.signed, die nu naast de DNSKEY records ook voor elke Resource Record Set (RRset) een RRSIG record bevat, met daarin de digitale handtekening voor die RRset. Daarnaast is een keten van (ondertekende) NSEC records toegevoegd, waarmee het niet-bestaan van een tussenliggende naam (NXDOMAIN) ook als DNSSEC-ondertekend antwoord kan worden teruggestuurd.
Bij het genereren van de zone file is geverifieerd dat deze tenminste één geldige, self-signed KSK-sleutel bevat en dat alle records zijn ondertekend. De '-a' optie zorgt ervoor dat alle digitale handtekeningen (de RRSIG records) ook zijn gevalideerd.
6.1 Verifiëren
Wil je de hele ondertekende zone file — inclusief de NSEC-keten — laten controleren, dan gebruik je daarvoor het volgende commando:
dnssec-verify -o example.nl db.example.nl.signed
[root@services]# dnssec-verify -o example.nl db.example.nl.signed
Loading zone 'example.nl' from file 'db.example.nl.signed'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoke
Heb je een DNSKEY RRset die alleen met de KSK-sleutel(s) ondertekend is (door dnssec-signzone te gebruiken met de '-x' optie), dan moet je ook hier de '-x' optie meegeven.
6.2 Smart signing
De '-S' optie (smart signing) zorgt ervoor dat ook de actuele publieke sleutels (de DNSKEY records zoals eerder gegenereerd in de /etc/bind/keys/ directory) in de zone file worden opgenomen (en ondertekend). De datum-informatie in de sleutelbestanden wordt daarbij gebruikt om te bepalen welke sleutels op dit moment relevant zijn:
- Created
- Publish: DNSKEY records met een datum in het verleden worden gepubliceerd
- Activate: DNSKEY records met een datum in het verleden worden gepubliceerd en gebruikt om de zone te ondertekenen
- Revoke: DNSKEY records met een datum in het verleden worden gepubliceerd als revoked (door middel van een gezette REVOKE-vlag); heeft zo'n record een geldige Publish-datum, dan wordt deze ook gebruikt om de zone te ondertekenen
- Inactive (Retire): DNSKEY records met een datum in het verleden worden wel gepubliceerd maar niet (meer) gebruikt om de zone te ondertekenen
- Delete (voorheen Unpublish): DNSKEY records met een datum in het verleden worden niet gepubliceerd en niet gebruikt om de zone te ondertekenen
Hiermee kan de hele levenscyclus van een sleutel worden doorlopen.
De datum-informatie kan al bij het genereren van de sleutelparen worden ingesteld door dnssec-signzone aan te roepen met de '-P/A/R/I/D' opties gevolgd door een datum-/offset-specificatie. De '-i' optie kun je gebruiken om het prepublicatie-interval (vanaf publicatie, tot aan activatie) op te geven.
Deze opties kunnen ook op bestaande sleutelparen worden toegepast via het 'dnssec-settime' commando. Let op dat dnssec-settime beide bestanden (.key en .private) van het sleutelpaar aanpast.
6.3 Revoke
Voor het zetten van de REVOKE-vlag op een bestaand sleutelpaar kun je het 'dnssec-revoke' commando gebruiken. Het resultaat is een nieuwe set sleutelbestanden (met een nieuwe keyid). Wil je daarbij gelijk de oude sleutelbestanden weghalen, dan gebruik je daarvoor de '-r' optie.
; This is a revoked key-signing key, keyid 24625, for example.nl. ; Created: 20180202134734 (Fri Feb 2 14:47:34 2018) ; Publish: 20180202134734 (Fri Feb 2 14:47:34 2018) ; Activate: 20180202134734 (Fri Feb 2 14:47:34 2018) ; Revoke: 20180205130153 (Mon Feb 5 14:01:53 2018) example.nl. IN DNSKEY 385 3 13 TlKOgcQK22K3fw8pUC2VZk9P2k1nx5XK8+UIOPU9b/GqwpU6XPqFVh8O qTycyHd/YYg8vzcAtl+K9nBbb621IA==
6.4 Sleutelbeheer
Worden geen expliciete datum-opties aan het dnssec-signzone commando meegegeven, dan worden alleen de velden Created, Publish en Activate toegevoegd (alle drie ingesteld op het tijdstip van aanmaken "now"). In principe is dat ook genoeg voor DNSSEC; sleutelparen hebben in protocol-technisch opzicht immers geen harde maar alleen een administratieve levensduur. Zoals je in de ondertekende zone file kunt zien bevatten de DNSKEY en DS records zelf ook geen timing-informatie (anders dan eventueel een eigen TTL).
In de praktijk worden sleutelparen echter regelmatig gerold. Voor KSK-sleutelparen gebeurt dat bijvoorbeeld elk jaar of elke paar jaar. Voor ZSK-sleutelparen is dat bijvoorbeeld elke maand of elk kwartaal.
Om naast een zojuist gegenereerd KSK- en ZSK-sleutelpaar een tweede ZSK-sleutelpaar te genereren voor een roll-over zou je bijvoorbeeld het volgende commando gebruiken:
dnssec-keygen -3 -a ECDSAP256SHA256 -P now -A +5w -r /dev/random example.nl
De opties '-P now -A +5w' maken dat dit sleutelpaar nu al wordt gepubliceerd, maar pas over 5 weken wordt geactiveerd. Dat wil zeggen dat BIND named het bijbehorende DNSKEY record wel meteen in de zone file opneemt, maar dit sleutelpaar nog niet gebruikt om de zone-informatie te ondertekenen. Zo worden overlappende sleutels gegenereerd, waarmee roll-overs zonder haperingen kunnen verlopen.
6.5 Ondertekende zone
Het door dnssec-signzone gegenereerde bestand db.example.nl.signed bevat een ondertekende zone die direct door de BIND named server kan worden ingelezen. Daarvoor hoeven we alleen het configuratiebestand /etc/named.conf aan te passen en opnieuw in te lezen:
zone "example.nl" {
type master;
file "db.example.nl.signed";
#file "db.example.nl";
};
rndc reload example.nl
Vervolgens kun je onderstaande commando gebruiken om te controleren of de DNSSEC records inderdaad door de lokale DNS-server worden opgehoest:
dig @localhost +dnssec example.nl
[root@services]# dig @localhost +dnssec example.nl ; <<>> DiG 9.11.1-P3-RedHat-9.11.1-4.P3.fc26 <<>> +dnssec example.nl ;; global options: +cmd ;; Got answer: ;; ->>HEADER<
6.6 Automatisering
Smart signing maakt het mogelijk om het sleutelbeheer en de ondertekening te automatiseren, en om koppelingen te maken naar management software. Daarvoor schrijf je dan wat shell scripts en cron jobs die voortbouwen op de dnssec-signzone en dnssec-settime commando's van BIND named.
De '-S-i' opties van dnssec-keygen (vanaf versie 9.7.2) maken het bovendien heel eenvoudig om roll-overs te automatiseren. Daarmee wordt een opvolger van een specifiek sleutelpaar gegenereerd (een zogenaamde linked key), klaar voor een automatische roll-over via het smart signing mechanisme van dnssec-signzone.
Deze opties worden ook ondersteund door dnssec-settime (bijvoorbeeld om het rollen naar een sleutelpaar met een ander cryptografisch algoritme te vergemakkelijken) en dnssec-keyfromlabel (vanaf versies 9.8.8 en 9.9.6).
6.7 Geen roll-overs
Wie dit alles niet nodig heeft kan ervoor kiezen om zijn bestaande sleutelparen te blijven gebruiken totdat deze uiteindelijk vervangen moeten worden vanwege (een probleem met) de veiligheid of een verandering van cryptografisch protocol.
Met de '-C' optie genereert dnssec-keygen "klassieke" sleutelbestanden die helemaal geen meta-data bevatten. Dat kan bijvoorbeeld handig zijn voor het genereren van nieuwe sleutelparen die door bestaande management software/scripts verwerkt moeten worden. DNSKEY records zonder datum-informatie worden door dnssec-signzone altijd in de zone file opgenomen en gebruikt om te ondertekenen.
Wil je een sleutelpaar dat wel meta-data bevat en geladen wordt, maar niet wordt gepubliceerd en gebruikt om de zone te ondertekenen, dan gebruik je de '-G' (Generate) optie.
6.8 Een enkelvoudig sleutelpaar
Een andere vereenvoudiging is om de sleutels niet op te splitsen in KSK- en ZSK-sleutelparen maar het bij een enkel (KSK-)sleutelpaar te houden. Met de '-z' optie gebruikt dnssec-signzone de KSK-sleutels om alle record sets te ondertekenen (in plaats van alleen de DNSKEY records, waaronder ook die voor de ZSK-sleutels, die in een getrapte KSK/ZSK-configuratie worden gebruikt voor de ondertekening).
Dezelfde optie is ook beschikbaar als de zone configuratie-optie 'update-check-ksk no' (vanaf BIND named versie 9.10.0 ook voor slave zones in combinatie met inline-signing).
Zo hebben de makers van PowerDNS als uitgangspunt om zo veel mogelijk van de complexiteit voor hun gebruikers (beheerders) te verbergen en te automatiseren. Voor de cryptografische sleutels betekent dit dat zij standaard met een enkel sleutelpaar werken.
Ongeacht welke DNS-server software je gebruikt, is dit in het algemeen echter alleen goed werkbaar als je zelden of nooit een roll-over doet, of als dit proces volledig geautomatiseerd is. Elke roll-over van een KSK-sleutelpaar vraagt immers om meerdere interacties met de beheerder van het bovenliggende domein voor het publiceren en verwijderen van de DS records.
6.9 DNSSEC records als include
Waar smart signing nu automatisch de actuele publieke sleutels in de zone file opneemt en ondertekent, moesten de DNSKEY records (de .key files) voorheen "handmatig" aan de zone file toegevoegd worden voordat deze met behulp van dnssec-signzone werd ondertekend. Dat kon bijvoorbeeld door een $INCLUDE statement in de originele zone file op te nemen. Welke sleutelparen voor de ondertekening moesten worden gebruikt, werd bij de aanroep expliciet aangegeven.
Met de '-C' optie is het nog steeds mogelijk om dnssec-signzone een apart bestand met de DNSKEY records voor de KSK-sleutels te laten genereren. Dat kan vooral handig zijn voor het aanleveren van sleutelmateriaal bij de beheerder van het bovenliggende domein — de finale stap bij het ondertekenen van een domein.
Wil je alle DNSSEC-specifieke records — DNSKEY, RRSIG, NSEC(3) en NSEC3PARAM — gescheiden houden van de zone file, dan gebruik je dnssec-signzone met de '-D' optie. Je kunt het gegenereerde bestand db.example.nl.signed vervolgens in de bestaande zone file binnenhalen middels een $INCLUDE statement.
7 Uploaden sleutelmateriaal
SIDN, de beheerder van het .nl top-level domein, vraagt zijn registrars om de DNSSEC-koppeling te kunnen maken (een schakel in de chain of trust) niet om DS records maar om DNSKEY records. Door uit die DNSKEY records zelf de DS records te genereren houdt SIDN controle over het daarbij gebruikte hash-algoritme.
De DS records (voor zowel algoritme nummer 1 als 2) zijn tegelijkertijd met de ondertekende zone file gegenereerd en bevinden zich in het bestand dsset-example.nl.:
example.nl. IN DS 11769 13 1 390B0855277C304F9D32FD8A81F6122828DACBC1 example.nl. IN DS 11769 13 2 57B09F079CFB3B7767B6B8EA03A70FFB861469565CB2CA07961C3169 0837B9B7
De meeste registry's voor andere top-level domeinen dan .nl zullen hun domeinnaamhouders om dat laatste record vragen (digest type nummer 2, een digitaal uittreksel volgens SHA-256).
Indien nodig kun je de DS records uit een (publiek) sleutelbestand laten genereren met behulp van het 'dnssec-dsfromkey' commando:
dnssec-dsfromkey Kexample.nl.+013+11769.key
[root@services]# dnssec-dsfromkey Kexample.nl.+013+11769.key example.nl. IN DS 11769 13 1 390B0855277C304F9D32FD8A81F6122828DACBC1 example.nl. IN DS 11769 13 2 57B09F079CFB3B7767B6B8EA03A70FFB861469565CB2CA07961C31690837B9B7
Je kunt het Python-gebaseerde commando 'dnssec-checkds' gebruiken om te verifiëren dat een geregistreerd DS record inderdaad bij een specifiek DNSKEY record hoort, waarmee de schakel naar het hogergelegen domein gesloten is. Dat kan zowel op de sleutelbestanden direct als in het actuele DNS-systeem:
[root@services]# dnssec-checkds example.nl DS for KSK example.nl/013/11769 (SHA-1) missing from parent DS for KSK example.nl/013/11769 (SHA-256) found in parent
7.1 Wachten op resolver caches
Meestal kun je het sleutelmateriaal naar de beheerder van het bovenliggende domein uploaden via de management console van de registrar. Hoewel het verleidelijk is om dit al direct na het ondertekenen van een domein te doen, is het van belang te wachten totdat de nieuwe (ondertekende) zone overal beschikbaar is — dat wil zeggen: totdat de oude zone-informatie overal uit de caches van de resolvers is verdwenen. Gebruik daarvoor de TTL-waarde. Zolang een validerende resolver nog uitgaat van de oude zone-informatie zal deze domeinnamen die volgens de informatie in de bovenliggende zone ondertekend zouden moeten zijn immers blokkeren.
Beheerders van gedelegeerde (sub)domeinen kunnen DS records uit dsset-* en keyset-* files laten opnemen in de ondertekende zone file middels de '-g -d' opties van dnssec-signzone.
7.2 CDS en CDNSKEY records
Een relatief nieuwe mogelijkheid om DNSKEY/DS records geautomatiseerd te laten registreren bij het bovenliggende domein is gedefinieerd in RFC 7344 en 8078. Is een zone eenmaal ondertekend en gekoppeld aan een valide vertrouwensketen (chain of trust), dan kan nieuw sleutelmateriaal vanaf dat moment via de DNS(SEC)-infrastructuur zelf (in-band) naar het bovenliggende domein worden getransporteerd.
Daartoe worden de actuele KSK DNSKEY records van een zone ook als CDNSKEY en CDS record gepubliceerd. De beheerder van het bovenliggende domein scant regelmatig de autoritatieve servers voor zijn gedelegeerde (sub)domeinen voor nieuwe CDNSKEY/CDS records. De digitale handtekening onder die records garandeert de authenticiteit ervan, zodat ze vervolgens veilig als DS record in de bovenliggende zone gepubliceerd kunnen worden.
Daarmee bieden RFC 7344 en 8078 een vergelijkbaar mechanisme voor het uitwisselen van sleutelmateriaal tussen parent en child zones als RFC 5011, maar dan in omgekeerde richting.
Om deze mogelijkheid te gebruiken voeg je de opties '-P sync' en '-D sync' (met een datum-/offset-specificatie) toe aan je dnssec-signzone en dnssec-settime commando's voor respectievelijk het publiceren en verwijderen van de CDNSKEY/CDS records. Vanaf BIND versie 9.12 worden deze records ook daadwerkelijk meegenomen door de smart signing functie.
Voor beheerders van bovenliggende domeinen introduceert BIND versie 9.12 het 'dnssec-cds' commando, waarmee CDS/CDNSKEY records van gedelegeerde (sub)zones kunnen worden opgevraagd. De op deze manier gegenereerde dsset-* files kunnen via de '-g -d' opties van het 'dnssec-signzone' commando worden meegenomen in de bovenliggende zone. Een andere mogelijkheid van dnssec-cds is om een reeks 'nsupdate' opdrachten te genereren voor gebruik met dynamische zones.
8 Herondertekening
De hierboven beschreven configuratie levert een statische setup op die makkelijk via cron jobs onderhouden kan worden. Gebruik je een eerder ondertekende zone file als input voor dnssec-signzone, dan worden waar nodig de handtekeningen ververst. Handtekeningen afkomstig van een DNSKEY die inmiddels verwijderd is blijven staan zolang ze nog geldig zijn. Op die manier kunnen DNSKEY RRsets in de caches van validerende resolvers gebruikt blijven worden.
De RRSIG records in de ondertekende zone file krijgen standaard een geldigheidsduur mee van 30 dagen vanaf de ondertekening. Dat kun je ook zien in het bestand zelf, waar bij elk RRSIG record zowel de start- als eindtijd in absolute vorm staat aangegeven, bijvoorbeeld zoals hier:
86400 RRSIG SOA 13 2 86400 (
20180204101952 20180105101952 59790 example.nl.
TqiR14RvCEkCXvNhdnk25Nismk8l2s34fTbd
QmCj+1eKvfhZJsS1o6/I/q3F9BNeLWY9Ta7i
wq2qx7T8sE8RvA== )
Let op dat in het record zelf de eerste datum de einddatum is en de tweede de startdatum.
Wil je de start- en eindtijd anders instellen, dan zijn daarvoor respectievelijk de opties '-s' en '-e' beschikbaar, waarmee een absolute of een relatieve tijdsspecificatie kan worden meegegeven. Voor een geldigheidsduur van twee weken (1209600 seconden) bijvoorbeeld, zouden we dnssec-signzone met de optie '-e +1209600' gebruiken.
8.1 Refresh
Hieraan gerelateerd is de '-i' optie, waarmee een refresh-interval (in seconden) kan worden gespecificeerd. Geef je dnssec-signzone een eerder ondertekende zone file als input, dan worden alleen die records opnieuw ondertekend die binnen deze periode zouden verlopen. Daarmee fungeert dit interval dus als een veiligheidsperiode voor herondertekening.
Is het refresh-interval niet gespecificeerd, dan wordt hiervoor een kwart van de totale geldigheidsduur van de handtekeningen aangehouden. Voor de standaardperiode van 30 dagen komt dit dus neer op 7,5 dag.
In dit geval is een dagelijkse cron job dus voldoende om de ondertekende zone file up-to-date te houden.
Gaat het om een grote zone, dan is het nog aan te raden om de '-j' optie aan de dnssec-signzone opdracht mee te geven. Daarmee kan wat extra (random) tijd aan de levensduur van de afzonderlijke handtekeningen worden toegevoegd, zodat hun einddatum steeds verder uiteen gaat lopen. Op die manier worden niet alle handtekeningen steeds op hetzelfde moment ververst, zodat je met minder hardware resources toe kan.
Deel 2: Automatisering
9 Auto-DNSSEC
Vanaf versie 9.7.0 ondersteunt BIND named de zone configuratie-optie 'auto-dnssec'. <ftp://ftp.isc.org/isc/bind9/9.7.7/doc/arm/Bv9ARM.ch04.html#dnssec.dynamic.zones> Daarbij wordt intern gebruik gemaakt van de Dynamic DNS faciliteit van named (via de local-ddns key) om een bestaande zone on-the-fly te ondertekenen. Op die manier kan het hierboven beschreven proces geautomatiseerd worden, zodat veel van het handmatige geknutsel voor herondertekening en sleutelbeheer achterwege kan blijven.
Auto-DNSSEC ondersteunt twee verschillende niveaus van automatisering. Met de optie 'auto-dnssec allow' hoef je alleen de sleutelparen in de key directory te genereren (of te plaatsen), om daarna de zone te laten (her)ondertekenen middels deze opdracht:
rndc sign example.nl
In deze modus zal de 'rndc sign' opdracht wel elke keer opnieuw gegeven moeten worden als sleutelparen worden gerold of handtekeningen dreigen te verlopen.
Om alleen de DNSKEY records in een zone te actualiseren naar aanleiding van veranderingen in de key directory, zonder daarbij ook gelijk alle digitale handtekeningen te vernieuwen, gebruiken we deze opdracht (beschikbaar vanaf BIND versie 9.7.2):
rndc loadkeys example.nl
9.1 Maintain
Gebruik je de optie 'auto-dnssec maintain', dan wordt de key directory elk uur gecontroleerd op wijzigingen in de sleutelparen. Afhankelijk van de meta-data in de sleutelbestanden krijgt een sleutelpaar de status niet-gepubliceerd, gepubliceerd, actief, verlopen of ingetrokken. Zo worden de gepubliceerde DNSKEY records automatisch up-to-date gehouden. Bovendien worden indien nodig de digitale handtekeningen (in de RRSIG records) opnieuw gezet. Daarmee komt deze optie overeen met de 'auto-dnssec allow' optie in combinatie met de 'rndc sign' opdracht opgenomen in een cron job.
Auto-DNSSEC maakt het heel eenvoudig om de roll-over van ZSK-sleutelparen te automatiseren, simpelweg door steeds de nieuwe sleutels in de key directory te plaatsen (met behulp van de opdracht 'dnssec-keygen -S-i'). BIND named zal de nieuwe sleutels zelf als DNSKEY record publiceren, en ze gebruiken om te ondertekenen zodra ze actief worden. In principe is dit proces voor KSK-sleutelparen niet anders, ware het niet dat bijbehorend sleutelmateriaal "handmatig" bij het bovenliggende domein moet worden geregistreerd.
Gedetailleerde besturing van de dynamische zone en het ondertekeningsproces kan middels het 'nsupdate -l' commando. Deze mogelijkheid is hier met name van belang voor het instellen van de NSEC(3)parameters door het injecteren van een NSEC3PARAM record in de zone-informatie:
nsupdate -l update add example.nl NSEC3PARAM 1 1 100 1234567890
Volgens de standaardinstellingen wordt namelijk niet NSEC3 maar het oudere NSEC toegepast.
Het (her)ondertekeningsproces wordt na het versturen van deze opdracht meteen in gang gezet, waarbij ook de NSEC(3)-keten gegenereerd wordt.
De inhoud van het NSEC3PARAM record type is gedefinieerd in RFC 5155 (sectie 4).
Hoewel de hele (her)ondertekening van een zone ook direct via nsupdate aangestuurd kan worden zonder gebruik van Auto-DNSSEC (door achtereenvolgens de DNSKEY records en een NSEC3PARAM record aan de zone toe te voegen), behandelen we die mogelijkheid hier niet.
9.2 Setup
Om Auto-DNSSEC te gebruiken voegen we de volgende optie toe aan het configuratiebestand /etc/named.conf:
key-directory "/etc/bind/keys"
En de 'auto-dnssec maintain' en 'update-policy local' opties aan elke afzonderlijke zone-configuratie:
zone "example.nl" {
type master;
file "db.example.nl";
auto-dnssec maintain;
update-policy local;
};
Vervolgens geven we BIND named dit commando om de nieuwe configuratie in te lezen:
rndc reconfig
Waar we eerder de naam van de zone file 'db.example.nl' in het configuratiebestand vervingen door de ondertekende zone file 'db.example.nl.signed' gegenereerd met behulp van dnssec-signzone, blijft bij gebruik van de 'auto-dnssec' optie de naam van de originele zone file staan. Het ondertekenen van de zone-informatie gebeurt immers intern.
9.3 Ondertekening
Is het de eerste keer dat een zone file wordt ingelezen en zijn de DNSSEC-sleutels al aanwezig, dan wordt deze automatisch ondertekend en is een 'rndc sign' opdracht niet nodig.
Is de default frequentie van eens per uur voor de 'auto-dnssec maintain' functie niet genoeg (of te veel), dan kun je die aanpassen middels de configuratie-optie 'dnssec-loadkeys-interval' (vanaf BIND named versie 9.10.0 ook voor slave zones in combinatie met inline-signing).
Wanneer je de ondertekening van een zone weer ongedaan wilt laten maken, kun je de optie 'dnssec-secure-to-insecure yes' in de zone-configuratie plaatsen.
De optie 'auto-dnssec create' was ooit gereserveerd om BIND named ook nieuwe sleutelparen te laten genereren ter vervanging van sleutels die gaan verlopen. Daarmee zou de automatisering van DNSSEC compleet zijn geweest. De ontwikkelaars vonden bij nader inzien echter dat deze functionaliteit niet in named thuishoort, waarmee deze optie weer van de roadmap is verdwenen. In plaats daarvan is met versie 9.11 het 'dnssec-keymgr' commando geïntroduceerd (waarover meer verderop in dit artikel).
9.4 Ondertekende zone files en journaal-bestanden
De automatisch gegenereerde (ondertekende) zone files — in ons geval het bestand db.example.nl.signed — zijn in deze nieuwe opzet niet langer direct leesbaar. Omwille van de snelheid worden zone files nu in een binair formaat (raw) opgeslagen. Om ze toch te kunnen bekijken gebruik je het volgende commando:
named-checkzone -D -f raw -o - example.nl db.example.nl.signed
Of anders dig:
dig @localhost axfr example.nl
Daarnaast wordt er voor elke dynamische zone een journaal-bestand bijgehouden — db.example.nl.jnl in ons geval. Ook deze is in een binair formaat; je kunt hem bekijken met het commando:
named-journalprint db.example.com.jnl
10 Inline-Signing
Vanaf versie 9.9.0 <ftp://ftp.isc.org/isc/bind9/9.9.0/doc/arm/Bv9ARM.html> ondersteunt BIND ook Inline-Signing. Deze functie is de doorontwikkeling van Auto-DNSSEC in combinatie met de 'update-policy local' optie en maakt geen (oneigenlijk) gebruik meer van Dynamic DNS. Daarmee kan DNSSEC ook makkelijk ingezet worden op DNS-servers die per se statisch moeten zijn (bijvoorbeeld omdat zij hun zone files ontvangen vanuit een database-gedreven back-end of andersoortige DNS-software).
Een typische setup bevat een (hidden) master server die inline signing doet en de ondertekende zone file vervolgens naar een aantal (publieke) slave servers distribueert. Een andere mogelijkheid is om een BIND named server geconfigureerd voor inline signing als bump-in-the-wire in de DNS-infrastructuur op te nemen. Maar voor een dergelijke setup kun je ook OpenDNSSEC inzetten, dat daar specifiek voor bedoeld is. De configuratie van OpenDNSSEC bespreken we in een ander artikel.
10.1 Configuratie en gebruik
De configuratie van een zone voor Inline-Signing is vrijwel identiek aan die voor Auto-DNSSEC op basis van Dynamic DNS:
zone "example.nl" {
type master;
file "db.example.nl";
auto-dnssec maintain;
inline-signing yes;
#update-policy local;
};
Hetzelfde geldt voor het concrete gebruik van een Inline-Signing installatie: dat komt overeen met wat hierboven is beschreven. Voor de besturing die eerst via het 'nsupdate -l' commando plaatsvond is nu het 'rndc signing' commando beschikbaar. Let daarbij op het onderscheid met het 'rndc sign' commando dat al bestond.
Voor het instellen van de NSEC(3)-parameters gebruik je nu dus het commando 'rndc signing -nsec3param'. Deze genereert het NSEC3PARAM record dat voorheen met behulp van een 'nsupdate -l' opdracht in de zone-informatie geïnjecteerd werd. Het (her)ondertekeningsproces wordt meteen na het versturen van de 'rndc signing -nsec3param' opdracht in gang gezet, waarbij ook meteen de NSEC(3)-keten gegenereerd wordt.
Het controleren van de huidige status van een zone doe je met de volgende opdracht:
rndc signing -list example.nl
[root@services]# rndc signing -list example.nl Done signing with key 8160/RSASHA256 Done signing with key 19273/RSASHA256
Deel 3: Sleutelbeheer
11 Verdere automatisering
Aan de nieuwe DNSSEC features van BIND versie 9.11 is goed te zien dat deze beveiligingstechnologie inmiddels volwassen is geworden en de implementatie zijn voltooiing nadert. De belangrijkste toevoeging voor wat betreft autoritatieve name-servers is het 'dnssec-keymgr' commando. Zoals hierboven al gesuggereerd combineert deze Python-gebaseerde wrapper de 'dnssec-keygen' en 'dnssec-settime' commando's in een tool voor het automatiseren van sleutelbeheer en roll-overs.
Daartoe moet je een policy (over-all of per zone) aanmaken in de file /etc/dnssec-policy.conf. De inhoud van dit bestand wordt vervolgens door dnssec-keymgr (bijvoorbeeld als onderdeel van een hourly cron job) gebruikt om — indien nodig — nieuwe sleutelparen te genereren. Die worden vervolgens via de eerder besproken Auto-DNSSEC feature automatisch in gebruik genomen.
De aanroep van dnssec-keymgr ziet er dan bijvoorbeeld als volgt uit:
dnssec-keymgr -K /etc/bind/keys/ -r /dev/random
De specificatie van de random generator wordt binnen het 'dnssec-keymgr' script doorgegeven aan het 'dnssec-keygen' commando (tesamen met de specificatie van de key directory). Eventueel kan nog een ander path voor de configuratie file worden opgegeven via de '-c' optie. De key directory kan ook in de policy file zelf worden gespecificeerd (bijvoorbeeld per zone).
11.1 Policy file
De inhoud van de policy file '/etc/dnssec-policy.conf' bestaat uit policy classes ('policy'): profielen waarvan de instellingen door policies of andere policy classes overgeërfd kunnen worden. Algorithm policies ('algorithm-policy') bevatten instellingen per cryptografisch algoritme. Zone policies ('zone') tenslotte bevatten de policy voor een specifieke zone.
Hieronder geven we een voorbeeld van hoe de inhoud van een policy file er uit zou kunnen zien:
algorithm-policy RSASHA256 {
key-size zsk 2048;
key-size ksk 4096;
};
policy normal {
algorithm RSASHA256;
roll-period zsk 3mo;
roll-period ksk 1y;
pre-publish zsk 1mo;
pre-publish ksk 1mo;
post-publish zsk 1mo;
post-publish ksk 1mo;
coverage 6mo;
};
policy extra {
algorithm RSASHA256;
roll-period zsk 6mo;
roll-period ksk 2y;
pre-publish zsk 1mo;
pre-publish ksk 1mo;
post-publish zsk 1mo;
post-publish ksk 1mo;
coverage 1y;
};
zone example.nl. {
policy normal;
algorithm ECDSAP256SHA256;
};
Voor het (default) algoritme RSASHA256 definiëren we hier een sleutellengte van respectievelijk 2048 en 4096 bits voor de ZSK- en KSK-sleutelparen. Daarmee overrulen we de standaardinstelling die op 2048 bits staat voor beide typen. Daarnaast stellen we twee policies in: 'normal' en 'extra', waarbij die laatste langere tijdsperioden gebruikt. Voor onze zone example.nl gebruiken we tenslotte de 'normal' policy, maar dan in combinatie met het ECDSAP256SHA256 algoritme (nummer 13).
11.2 Genereren opvolgende sleutelparen
Hieronder kun je zien hoe dnssec-keymgr voortbouwt op de eerder gegenereerde sleutelbestanden in de /etc/bind/keys/ directory om aan de ingestelde policy voor example.nl te voldoen:
[root@services]# dnssec-keymgr -K /etc/bind/keys/ -r /dev/random # /usr/sbin/dnssec-settime -K /etc/bind/keys/ -I 20180503135334 -D 20180602135334 Kexample.nl.+013+59790 # /usr/sbin/dnssec-keygen -q -K /etc/bind/keys/ -S Kexample.nl.+013+59790 -r /dev/random -i 2592000
Eerst wordt de timing-informatie in de bestaande ZSK-sleutelbestanden (met keyid 59790) aangepast. Vervolgens wordt een daarop aansluitend sleutelpaar gegenereerd.
11.3 Coverage
Het (ook op Python gebaseerde) commando 'dnssec-coverage' (vanaf BIND versie 9.9.3) kun je gebruiken om te controleren voor hoe lang in de toekomst een zone nog geldige, aaneensluitende/overlappende sleutelparen heeft staan. Op die manier weet je zeker dat de DNSSEC-ondertekening niet onderbroken wordt (waarmee je domeinnamen onbereikbaar worden voor gebruikers van validerende resolvers).
dnssec-coverage -K /etc/bind/keys/ -m 1d -d 1d -r 1w example.nl
Het 'dnssec-coverage' commando gebruikt daarbij niet alleen de meta-data in de sleutelbestanden zelf, maar heeft ook informatie nodig over de maximale TTL (via de '-m' optie), de TTL specifiek voor de DNSKEY records (via de '-d' optie) en de periode voor herondertekening (via de '-r' optie). Lees je de zone data in vanuit een bestand (via de '-f' optie), dan gebruikt dnssec-coverage de TTL-informatie uit de zone file zelf.
Laat je de zone-naam weg, dan geeft dnssec-coverage een overzicht van alle zones in de key directory. Gebruik je de '-l' optie, dan krijg je alleen die zones te zien die binnen een bepaalde termijn aandacht nodig hebben. Tenslotte zijn er nog de '-z' en '-k' opties waarmee de check beperkt kan worden tot alleen ZSK- respectievelijk KSK-sleutelparen.
Hieronder controleren we de coverage van de sleutelbestanden die we eerder genereerden voor het domein example.nl:
[root@services]# dnssec-coverage -K /etc/bind/keys/ -m 1d -d 1d -r 1w example.nl
PHASE 1--Loading keys to check for internal timing problems
PHASE 2--Scanning future key events for coverage failures
Checking scheduled KSK events for zone example.nl, algorithm ECDSAP256SHA256...
Fri Feb 02 13:47:34 UTC 2018:
Publish: example.nl/ECDSAP256SHA256/24497 (KSK)
Activate: example.nl/ECDSAP256SHA256/24497 (KSK)
No errors found
Checking scheduled ZSK events for zone example.nl, algorithm ECDSAP256SHA256...
Fri Feb 02 13:53:34 UTC 2018:
Publish: example.nl/ECDSAP256SHA256/59790 (ZSK)
Activate: example.nl/ECDSAP256SHA256/59790 (ZSK)
Tue Apr 03 13:53:34 UTC 2018:
Publish: example.nl/ECDSAP256SHA256/12391 (ZSK)
Thu May 03 13:53:34 UTC 2018:
Inactive: example.nl/ECDSAP256SHA256/59790 (ZSK)
Activate: example.nl/ECDSAP256SHA256/12391 (ZSK)
Sat Jun 02 13:53:34 UTC 2018:
Delete: example.nl/ECDSAP256SHA256/59790 (ZSK)
No errors found
11.4 Zonestatus
Daarnaast kun je (vanaf BIND versie 9.10.0) het commando 'rndc zonestatus' gebruiken voor een uitgebreid status-overzicht voor een specifieke zone:
[root@services]# rndc zonestatus example.nl name: example.nl type: master files: db.example.nl serial: 2018012801 signed serial: 2018012803 nodes: 6 last loaded: Sun, 28 Jan 2018 19:54:50 GMT secure: yes inline signing: yes key maintenance: automatic next key event: Tue, 30 Jan 2018 13:14:01 GMT next resign node: ns1.example.nl/NSEC next resign time: Tue, 30 Jan 2018 18:48:44 GMT dynamic: no reconfigurable via modzone: no
11.5 Showzone
Hieraan gerelateerd is het commando 'rndc showzone' (vanaf BIND versie 9.11.0), dat de huidige configuratie-instellingen geeft voor een bepaalde zone:
[root@services]# rndc showzone example.nl
zone "example.nl" in { type master; file "db.example.nl";
auto-dnssec maintain; dnssec-dnskey-kskonly yes;
inline-signing yes; key-directory "/etc/bind/keys";
serial-update-method date; sig-validity-interval 10 7; };
Hier zien we ook twee aanvullende configuratie-opties die nog niet eerder aan bod zijn gekomen. De (default) optie 'serial-update-method date' zorgt ervoor dat het serienummer van een Dynamic DNS zone met één wordt opgehoogd elke keer dat een wijziging plaatsvindt. Alternatief is de instelling 'serial-update-method unixtime', waarbij in plaats daarvan het aantal seconden sinds de UNIX epoch wordt gebruikt (tenzij het huidige serienummer groter of gelijk is).
De optie 'sig-validity-interval 10 7' geeft aan dat de digitale handtekeningen (de RRSIG records) gegenereerd voor Dynamic DNS zones een geldigheidsduur van tien dagen hebben. Zeven dagen voor het verstrijken van die termijn worden ze automatisch ververst. Specificeer je dat laatste getal niet, dan wordt hiervoor standaard een kwart van de geldigheidsduur genomen.
De optie 'dnssec-dnskey-kskonly yes' bespraken we eerder bij het gebruik van de 'dnssec-signzone' opdracht.
12 Afsluiting
Hiermee zijn we aanbeland bij DNSSEC zoals dat nu door de meest recente versies van BIND ondersteund wordt. Zoals je hebt kunnen zien is het voor gebruikers van versie 9.11 relatief eenvoudig om een vrijwel volledig geautomatiseerde DNSSEC-installatie op te zetten. Het genereren van sleutelparen, het ondertekenen van zone files, het rollen van sleutels en het beheer van sleutels lopen allemaal vanzelf na de initiële configuratie. Alleen het uploaden van het KSK-sleutelmateriaal na een KSK roll-over moet in het algemeen nog met de hand gebeuren. Maar zodra de implementatie van RFC 7344 en 8078 (de CDN/CDNSKEY records) gemeengoed is, zal ook dit zonder menselijke tussenkomst kunnen gebeuren.
Als nieuwe DNSSEC-functionaliteit voor BIND beschikbaar komt, zullen we die in dit artikel verwerken.
