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 (voorjaar 2018) zitten we halverwege het roll-over proces voor het KSK-sleutelpaar van de root zone. 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.

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 BIND 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 (weer per view):

  [root@system ~]# rndc secroots -
  secure roots as of 11-Apr-2018 13:24:11.522:

   Start view localhost_resolver
     Secure roots:

  ./RSASHA256/20326 ; managed
  ./RSASHA256/19036 ; managed

     Negative trust anchors:

   Start view internal
     Secure roots:

  ./RSASHA256/20326 ; managed
  ./RSASHA256/19036 ; managed

     Negative trust anchors:

   Start view external
     Secure roots:

  ./RSASHA256/20326 ; managed
  ./RSASHA256/19036 ; managed

     Negative trust anchors:

Staat het KSK-2017 trust anchor met keyid 20326 er niet bij in deze lijst (met de status 'managed' of 'trusted'), dan vind je hier uitgebreide informatie over de root KSK roll-over van ISC, de ontwikkelaar van BIND named.

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 BIND versie 9.11.0). Deze mogelijkheid is met name bedoeld om validatiefouten bij verkeerd geconfigureerde ("bogus") domeinen (tijdelijk) uit te schakelen.

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

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 localhost_resolver)

Geven we hier tenslotte nog het commando om de goede werking van een validerende resolver op afstand te testen (vervang <ADRES> door 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.

DNSviz-servfail.nl

Als nieuwe DNSSEC-functionaliteit voor BIND beschikbaar komt, zullen we die in dit artikel verwerken.

Reacties

  • dinsdag 26 februari 2019

    .nl-domeinnaam

    Domain Connect: nieuwe standaard die domeinnaamgebruik vereenvoudigt

    Thumb-domain-names-web-concept

    Een niet gebruikte domeinnaam, wordt vaak niet verlengd

    Lees meer
  • donderdag 25 april 2019

    SIDN Labs

    Nieuw gezamenlijk onderzoeksprogramma voor veiligere, stabielere en transparantere internetcommunicatie

    Thumb-trust

    We have called it 2STiC

    Lees meer
  • woensdag 25 september 2019

    Over SIDN

    Nieuwkomers leren kennen onder het genot van een taartje

    Thumb Karel & Muohanad Welcome app

    Met de Welcome-app wordt sociaal integreren een piece of cake

    Lees meer

Sorry

De versie van de browser die je gebruikt is verouderd en wordt niet ondersteund.
Upgrade je browser om de website optimaal te gebruiken.