BIND named, de meest gebruikte DNS-server, kan fungeren als (autoritatieve) name-server en/of (caching) resolver. In dit artikel bespreken we de configuratie van named als DNSSEC-validerende resolver. De ondertekening van een zone op een autoritatieve name-server wordt in een ander artikel behandeld.
Juist omdat er al zo veel bestaande BIND-implementaties zijn – sommige draaien al vele jaren lang – hebben we bij alle features zo veel mogelijk de versienummers gegeven waarbij de betreffende optie in de software beschikbaar is gemaakt. 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.
Validatie
De mogelijkheid om DNSSEC-ondertekende domeinen te valideren is destijds geïntroduceerd als onderdeel van BIND versie 9.6.2. Aanzetten gaat als volgt:
dnssec-enable yes; dnssec-validation auto; //dnssec-lookaside auto;
Let op dat je de 'dnssec-enable'-optie niet alleen aan moet zetten voor het ophoesten van digitale handtekeningen (de RRSIG-records) op een autoritatieve DNS-server, maar ook voor DNSSEC-validatie op een server die alleen als resolver dienst doet. Vanaf versie 9.16.0 is deze optie overbodig geworden, en vanaf versie 9.18.0 compleet verwijderd.
De 'auto'-optie voor de andere twee statements is beschikbaar vanaf versie 9.7.0, waarmee ook ondersteuning voor RFC 5011 (de automatische update van trust anchors) werd geïntroduceerd. Voor eerdere versies is (naast 'no') alleen de optie 'yes' beschikbaar. Die versies ondersteunen alleen statische trust anchors gespecificeerd in een 'trusted-keys'-statement (vanaf versie 9.16.0 vervangen door het 'trust-anchors'-statement).
Dynamic Lookaside Validation
De 'dnssec-lookaside'-optie configureerde Dynamic Lookaside Validation (DLV), een dienst van ISC (de ontwikkelaars van BIND) die stamt uit de tijd dat de root zone nog niet ondertekend was. Beheerders die destijds hun domeinen wel al wilden ondertekenen maar nog geen volledige chain of trust naar de root zone konden opbouwen, brachten hun DNS-deelboom (een 'island of trust') onder het 'dlv.isc.org.'-domein, wat een eigen trust anchor in BIND had.
De DLV-dienst is inmiddels niet meer relevant en is in september 2017 opgeheven. Vanaf versie 9.16.0 is alle DLV-gerelateerde code ook uit BIND verwijderd.
RFC 5011
Vanaf BIND versie 9.7.0 worden de trust anchors opgeslagen in de managed key database (in het bestand 'managed-keys.bind', of vanaf versie 9.8.0 per view in een '.mkeys'-bestand). Deze database wordt (eenmalig) geïnitaliseerd met de trust anchors gespecificeerd in het 'managed-keys'-statement ('initial-key'). Is dat statement niet aanwezig, dan wordt teruggevallen op de externe 'bindkeys-file' (default: bind.keys) of de sleutels die hard gecodeerd zijn in de software. Nieuwere versies van BIND zijn niet meer voorzien van het 'bind.keys'-bestand, en vallen daarmee altijd terug op de ingebakken trust anchors.
De initialisatie wordt door BIND alleen uitgevoerd als de resolver voor de eerste keer opgestart wordt en de managed key database nog leeg is. Deze zogenaamde bootstrap zorgt ervoor dat de actuele trust anchors van internet worden binnengehaald, gevalideerd en geïnstalleerd. Is dat eenmaal voor elkaar, dan worden de trust anchors in de managed key database voortaan automatisch (in-band) beheerd op basis van RFC 5011.
Vanaf versie 9.16.0 zijn de 'trusted-keys'- and 'managed-keys'-statements deprecated en moeten alleen nog de vervangende opties, respectievelijk 'static-key' en 'initial-key' (als onderdeel van het 'trust-anchors'-statement) gebruikt worden. Heb je de trust anchors niet in DNSKEY-formaat maar alleen in DS-formaat beschikbaar (dat geldt voor nieuwe root trust anchors aangekondigd maar nog niet gepubliceerd door IANA), dan kun je deze met de opties 'static-ds' en 'initial-ds' gebruiken.
Trust anchors
Beheerders van oudere validerende resolvers moeten zich ervan vergewissen dat de laatste publieke root KSK-sleutel (KSK-2017) inderdaad als trust anchor op hun systemen is geïnstalleerd en geactiveerd. Hieronder hebben we de belangrijkste informatie met betrekking tot de installatie van het KSK-2017 trust anchor voor de verschillende versies van BIND op een rijtje gezet.
KSK-2017 trust anchor met software meegeleverd vanaf april 2017 (versies 9.9.10, 9.10.5, 9.11.1 en later)
ondersteuning van RFC 5011 vanaf versie 9.7.0 (initialisatie via 'managed-keys')
handmatige installatie vanaf versie 9.6.2 (statische trust anchors via 'trusted-keys')
Checks
De inhoud van de managed key database kun je opvragen met het volgende commando (vanaf versie 9.11.0):
rndc managed-keys status
Voor oudere versies (vanaf 9.9.3) levert het script 'contrib/check5011.pl' vergelijkbare functionaliteit.
De output is een lijst met de trust anchors (per view):
[root@system ~]# rndc managed-keys status
view: resolver
next scheduled event: Tue, 03 Oct 2022 15:29:38 GMT
name: .
keyid: 19036
algorithm: RSASHA256
flags: SEP
next refresh: Tue, 03 Oct 2022 15:29:38 GMT
trusted since: Mon, 28 Dec 2015 20:05:54 GMT
keyid: 20326
algorithm: RSASHA256
flags: SEP
next refresh: Tue, 03 Oct 2022 15:29:38 GMT
trusted since: Thu, 10 Aug 2017 16:21:39 GMT
Het commando 'rndc secroots -' (vanaf versie 9.7.2) geeft een overzicht van zowel de managed keys als de statische en negatieve trust anchors (weer per view):
[root@system ~]# rndc secroots -
secure roots as of 25-Jan-2023 13:24:11.522:
Start view resolver
Secure roots:
./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed
Negative trust anchors:We zien hier dat er in dit geval twee trust anchors zijn geïnstalleerd: met respectievelijk keyid 19036 (KSK-2010) en 20326 (KSK-2017). Het proces voor de root KSK roll-over is inmiddels helemaal achter de rug, wat betekent dat het eventueel nog aanwezige oude trust anchor voor KSK-2010 van alle resolvers verwijderd moet worden. Uitgebreide informatie van ISC over de root KSK roll-over vind je hier.
Negatieve trust anchors
Voor het instellen van een negatieve trust anchor – een domein waarvoor validatie is uitgeschakeld, zoals gespecificeerd in RFC 7646 – gebruik je het commando 'rndc nta' (vanaf versie 9.11.0). Deze mogelijkheid is vooral bedoeld om validatiefouten bij verkeerd geconfigureerde ("bogus") domeinen (tijdelijk) te negeren.
Oude configuratiebestanden
Let op bij het checken van de versie van een bestaande BIND-installatie ('named -v') dat ook het gebruikte configuratiebestand ('/etc/named.conf') actueel is. Als een DNS-server al enige tijd geleden is opgezet en de software inmiddels via de systeem-updates naar een recentere versie is opgewaardeerd, is de configuratie gebaseerd op een eerdere versie vaak blijven staan. In dat geval kun je het beste de bestaande configuratie opwaarderen naar de actuele versie van BIND alvorens met DNSSEC aan de slag te gaan. De meegeleverde templates voor 'named.conf' vind je (op RHEL (en afgeleiden), CentOS (Stream) en Fedora) in de directory '/usr/share/doc/bind(-version)/sample/etc/'. Al is de template die daar staat overigens ook verouderd.
Testen
De huidige status voor wat betreft validatie door de resolver kun je opvragen met het commando 'rndc validation check' (vanaf versie 9.10):
[root@system ~]# rndc validation check DNSSEC validation is enabled (view resolver)
Geven we hier tenslotte nog het commando om de goede werking van een validerende resolver op afstand te testen (vervang <server> door de hostnaam of het adres van de server):
dig @<server> servfail.nl
Voor een validerende resolver moet deze opdracht de status SERVFAIL opleveren; zoals de domeinnaam al aangeeft is de DNSSEC chain of trust in dit geval expres niet gesloten ("bogus").
Een niet-validerende server controleert de aanwezigheid van digitale handtekeningen überhaupt niet en zal hier gewoon de status NOERROR teruggeven.
Als nieuwe DNSSEC-functionaliteit voor BIND beschikbaar komt, zullen we die in dit artikel verwerken.