Hands-on: DNSSEC -validatie op BIND named
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 jarenlang — 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 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.
De 'auto' optie voor de andere twee statements is beschikbaar vanaf BIND versie 9.7.0, waarmee ook ondersteuning voor RFC 5011 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.
Dynamic Lookaside Validation
De 'dnssec-lookaside' optie configureert Dynamic Lookaside Validation (DLV), een dienst van ISC 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.
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 file). 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.
Deze initialisatie voert BIND alleen uit 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.
Root KSK roll-over
Op het moment dat we dit schrijven (najaar 2017) is het roll-over proces voor het KSK-sleutelpaar van de root zone in volle gang. Dat betekent dat ICANN, de beheerder van de root zone, het huidige cryptografische sleutelpaar dat de basis vormt voor de DNSSEC-infrastructuur (KSK-2010) vervangt door een nieuw sleutelpaar (KSK-2017).
De daadwerkelijke roll-over zou op 11 oktober 2017 plaatsvinden, maar die transitie is onlangs uitgesteld. Een nieuwe datum is nog niet bekend, maar beheerders van validerende resolvers wordt dringend aangeraden om hun systemen up-to-date te brengen — voor zover zij dat nog niet gedaan hebben.
- achtergrond
- veel gestelde vragen
- handmatige installatie
- automatische installatie
- test
- roll-over uitgesteld
Nieuw trust anchor
Voor beheerders van validerende resolvers betekent dit dat zij zich ervan moeten vergewissen dat de nieuwe publieke root KSK-sleutel inderdaad als trust anchor op hun systemen is geïnstalleerd en geactiveerd. Vanaf het moment van de daadwerkelijke roll-over zijn de digitale handtekeningen gebaseerd op het oude KSK-2010 sleutelpaar namelijk niet meer geldig. Dat betekent dat validerende resolvers die niet zijn voorzien van het nieuwe trust anchor dan geen mogelijkheid meer hebben om de handtekeningen onder de DNS-records te verifiëren, waarmee alle domeinnamen voor de gebruikers/applicaties van de betreffende resolver onbereikbaar zijn geworden.
Hieronder hebben we de belangrijkste informatie met betrekking tot de installatie van het nieuwe KSK-2017 trust anchor voor de verschillende versies van BIND op een rijtje gezet. Voor de details verwijzen we naar de hierboven genoemde artikelen, waarin ook meer specifieke informatie voor de configuratie van BIND is opgenomen.
- 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 2017 15:29:38 GMT
name: .
keyid: 19036
algorithm: RSASHA256
flags: SEP
next refresh: Tue, 03 Oct 2017 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 2017 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 (dump) van zowel de managed keys als de statische en negatieve trust anchors.
Staat het KSK-2017 trust anchor met keyid 20326 er niet bij in deze lijst (met de status 'trusted'), dan vind je hier uitgebreide informatie over de root KSK roll-over van ISC, de ontwikkelaar van BIND named.
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/CentOS en Fedora) in de directory /usr/share/doc/bind(-version)/sample/etc/. Al is de template die daar staat overigens ook verouderd.
Testen
Geven we hier tenslotte nog het commando om de goede werking van een validerende resolver te testen (vervangdoor de naam of het adres van de server):
dig @ADRES servfail.nl
Voor een validerende resolver moet deze opdracht de status SERVFAIL opleveren; zoals de Domeinnaam al aangeeft is de DNSSEC chain of trust expres niet gesloten (bogus). Een niet-validerende server controleert de aanwezigheid van digitale handtekeningen überhaupt niet en zal de status NOERROR teruggeven.
