DNSSEC-ondertekening op BIND named

1 Inleiding

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 (major) versies.

(De ontwikkelaars bij ISC nemen BIND 9 als uitgangspunt en noemen bijvoorbeeld 9.11 een 'major version'. Vanaf versie 9.12 zijn alle oneven versies developmentversies. Tot nu toe betreft dat dus versies 9.13, 9.15, 9.17 en 9.19.)

Waar mogelijk en relevant geven we in dit artikel steeds aan vanaf welke (productie-)versie een bepaalde feature ondersteund wordt. Dat is met name van belang voor gebruikers van enterpriseplatforms, omdat die uit stabiliteits- en veiligheidsoverwegingen in het algemeen niet de meest recente softwareversies gebruiken. Daarnaast kan het heel goed zijn dat de BIND-software op een bestaande server inmiddels opgewaardeerd is via het package-managementsysteem van het operating system, maar dat 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 (bij voorkeur versie 9.16 of hoger), al was het alleen maar omdat in de tussentijd natuurlijk ook bugs en securityproblemen uit de software zijn gehaald.

1.1 Hoe dit artikel te lezen

De DNSSEC-functionaliteit is in de loop der tijd aan de opeenvolgende feature releases van BIND toegevoegd. Die ontwikkeling loopt van het genereren van sleutelparen en het ondertekenen van zonefiles tot het automatiseren van het ondertekeningsproces en het sleutelbeheer. Onderstaande tabel geeft een overzicht van de functionaliteit zoals die over de versies heen beschikbaar is gekomen.

Tabel 1: Aanbevolen configuraties voor de verschillende feature releases van BIND.

De achtereenvolgende versies van BIND vormen een natuurlijke manier om de opbouw van de DNSSEC-functionaliteit te begrijpen. In dit artikel hebben we de volgorde echter omgedraaid: We beginnen met de configuratie vanaf versie 15-16, gevolgd door de toevoegingen en veranderingen van versie 17-18. Belangrijkste reden hiervoor is de introductie van volledig geautomatiseerd sleutelbeheer (middels de DNSSEC Policy) in versie 9.16. Zoals je verderop kunt zien, dekken deze versies ook de BIND-pakketten zoals die door de meeste actuele serverdistributies worden meegeleverd.

Hierna volgt de configuratie van DNSSEC op BIND versie 9.11-9.14. Hoewel deze versies nog geen volledige automatisering van het sleutelbeheer ondersteunen, werd hiertoe met de introductie van het 'dnssec-keymgr'-commando wel een belangrijke aanzet gegeven. Versie 9.11 wordt nog steeds meegeleverd als het standaard DNS-pakket op diverse actuele (LTS-)server-distributies.

In het laatste gedeelte van dit artikel bespreken we tenslotte DNSSEC zoals dat over de tijd heen in oudere versies van BIND (9.6-9.10) is geïmplementeerd. Hoewel deze versies naar ons beste weten niet meer worden meegeleverd met actuele distributies, kun je ze nog steeds tegenkomen op oudere DNS-systemen en als onderdeel van DNS-appliances.

Om te voorkomen dat gebruikers van BIND-systemen ouder dan versie 15 zich eerst door een heleboel uitleg heen moeten worstelen van configuratie-opties die niet voor hun versie beschikbaar zijn, hebben we ons best gedaan om de secties voor de versies 9-11-9.14 en 9.6-9.10 zoveel mogelijk op zichzelf te laten staan. Tegelijkertijd hopen we dat gebruikers van oudere versies in de beschrijving van de laatste functionaliteit (en dan vooral in het gebruiksgemak daarvan) aanleiding zien om hun DNS-systemen op te waarderen naar een recente versie (9.16 en later).

In dit artikel bespreken we 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.

Inhoudsopgave

• 1 Inleiding

  • 1.1 Hoe dit artikel te lezen

• 2 RHEL, CentOS en Fedora

  • 2.1 RHEL en CentOS Stream versie 9

  • 2.2 RHEL en CentOS (Stream) versie 8

  • 2.3 Fedora

• 3 Ubuntu Server

Deel 1: Uitganspunten

• 4 DNS-zonefile

• 5 DNSSEC in BIND

  • 5.1 Cryptografische algoritmen

Deel 2: BIND versies 9.15-9.18 – Volledig geautomatiseerd DNSSEC-management

• 6 DNSSEC Policy

  • 6.1 Key and Signing Policy (KASP)

  • 6.2 Sleutelmanagement

  • 6.3 Verwijderen DNSSEC-bescherming

Deel 3: BIND versies 9.11-9.14 – Geautomatiseerde (her)ondertekening en sleutelbeheer

• 7 Automatisering sleutelbeheer en rollovers

  • 7.1 De policy file

  • 7.2 Genereren opvolgende sleutelparen

  • 7.3 Coverage

  • 7.4 Zonestatus

  • 7.5 Showzone

Deel 4: BIND versies 9.6-9.10 – De basisfunctionaliteit voor DNSSEC

• 8 Genereren sleutelparen en ondertekenen zonefile

  • 8.1 De eerste configuratie

  • 8.2 Genereren sleutels

  • 8.3 ZSK-sleutelpaar

  • 8.4 Random generator

  • 8.5 Sleutelbestanden

• 9 Ondertekenen

  • 9.1 Verifiëren

  • 9.2 Smart signing

  • 9.3 Revoke

  • 9.4 Sleutelbeheer

  • 9.5 Ondertekende zone

  • 9.6 Automatisering

  • 9.7 Geen roll-overs

  • 9.8 Een enkelvoudig sleutelpaar

  • 9.9 DNSSEC records als include

• 10 Uploaden sleutelmateriaal

  • 10.1 Wachten op resolver caches

  • 10.2 CDS en CDNSKEY-records

• 11 Herondertekening

  • 11.1 Refresh

Deel 5: Geautomatiseerde (her)ondertekening

• 12 Auto-DNSSEC

  • 12.1 Maintain

  • 12.2 Setup

  • 12.3 Ondertekening

  • 12.4 Ondertekende zonefiles en journaalbestanden

• Inline-Signing

  • 13.1 Configuratie en gebruik

• 14 Afsluiting

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 meerdere community-gedragen varianten beschikbaar zijn: respectievelijk RHEL, CentOS (Stream), Rocky Linux, AlmaLinux en Fedora.

2.1 RHEL en CentOS Stream versie 9

RHEL9 is voorzien van BIND versie 9.16 (versie 9.16.23 na de meest recente updates op RHEL 9.1). De upstream distributie CentOS Stream 9 zit ook op versie 9.16.23 (januari 2023).

Installeer je op je huidige RHEL9/Rocky9/AlmaLinux9/CentOS9-systeem (handmatig) een meer recente versie van BIND, let dan op dat je tegelijkertijd een nieuw (bijbehorend) configuratiebestand installeert.

2.2 RHEL en CentOS (Stream) versie 8

RHEL8 is voorzien van BIND versie 9.11 (versie 9.11.36 na de laatste updates op RHEL 8.7). De upstreamdistributie CentOS Stream 8 zit ook op versie 9.11.36 (januari 2023).

Installeer je op je huidige RHEL8/Rocky8/AlmaLinux8/CentOS8-systeem (handmatig) een meer recente versie van BIND, let dan op dat je tegelijkertijd een nieuw (bijbehorend) configuratiebestand installeert. Versie 9.16 bracht belangrijke nieuwe DNSSEC-functionaliteit met zich mee; we bespreken die verderop.

2.3 Fedora

Fedora 37 is voorzien van BIND versie 9.18 (versie 9.18.7 na de meest recente updates), net als de toekomstige versie Fedora 38 (versie 9.18.8 via de updates). Fedora 36 was voorzien van BIND 9.16 (versie 9.16.27 na de laatste updates).

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.

Tabel 2: De BIND-versies meegeleverd met de verschillende releases van Ubuntu Server.

Deel 1: Uitganspunten

4 DNS-zonefile

Uitgangspunt voor dit artikel is een goed werkende (autoritatieve) DNS-installatie. Dat wil in ons geval zeggen dat we een zonefile 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.

Tabel 3: Overzicht DNSSEC-functionaliteit in BIND.

5.1 Cryptografische algoritmen

De cryptografische algoritmen gebaseerd op SHA-2 ('RSA/SHA-256' en 'RSA/SHA-512') zijn vanaf versie 9.6.2 in BIND beschikbaar. De ECDSA-gebaseerde algoritmen ('ECDSA Curve P-256 with SHA-256' en 'ECDSA Curve P-384 with SHA-384') vanaf versie 9.9.2. En de EdDSA-gebaseerde algoritmen ('Ed25519' en 'Ed448') vanaf versie 9.10.7.

RFC 8624 raadt het gebruik van algoritme nummer 13 ('ECDSA Curve P-256 with SHA-256') aan, naast nummer 8 ('RSA/SHA-256'), dat lange tijd de standaard was en nu langzaam uitgefaseerd wordt ten gunste van de ECDSA-gebaseerde algoritmen.

Nummer 10 ('RSA/SHA-512'), een variant van nummer 8, is nooit populair geworden en wordt inmiddels ontraden. Nummer 14 ('ECDSA Curve P-384 with SHA-384') is een sterkere versie van nummer 13, maar is op dit moment nog niet nodig. De kans is echter groot dat in de toekomst niet nummer 14 maar een EdDSA-gebaseerd algoritme (nummer 15, 'Ed25519') de opvolger van nummer 13 gaat worden.

Deel 2: BIND versies 9.15-9.18 – Volledig geautomatiseerd DNSSEC-management

De fundamenten onder volledig geautomatiseerd DNSSEC-management werden in BIND geïntroduceerd over de versies 9.7 tot en met 9.11. Dat begon met de automatische (her)ondertekening van zones in versies 9.7/9.8 ('auto-dnssec maintain'), welke in de versies 9.9/9.10 verder in de code base werd geïntegreerd (Inline-Signing).

Vanaf versie 9.11 werd ook het sleutelbeheer geautomatiseerd met behulp van het 'dnssec-keymgr'-commando en de bijbehorende policy file. Daarmee werd de hele set-up van DNSSEC teruggebracht tot de configuratiebestanden van BIND, met alleen nog een laatste cron job voor het genereren van nieuwe sleutelparen (indien nodig) met behulp van het 'dnssec-keymgr'-commando.

Met de introductie van DNSSEC Policy in versie 15/16 hebben de ontwikkelaars van BIND de laatste stap in de automatisering van DNSSEC(-ondertekening) gezet. Vanaf versie 9.16 kunnen policy's voor sleutelbeheer en de ondertekening van zones in het configuratiebestand 'named.conf' worden gespecificeerd. De software zorgt dan zelf dat handtekeningen (RRSIG-records) en ZSK/KSK-sleutelparen steeds up-to-date zijn. Daarmee is de noodzaak verdwenen om scripts en cron jobs in te zetten om je ondertekende zones actueel te houden.

6 DNSSEC Policy

Vanaf BIND named versie 9.16 kun je een 'dnssec-policy' in het 'named.conf'-configuratiebestand specifiëren. Dat doe je door een statement als volgt in de zoneconfiguratie op te nemen:

zone "example.nl." {
    type master;
    file "db.example.nl";
    inline-signing yes;
    dnssec-policy "dnssec-policy-1";
};

Let op dat je (vanaf versies 9.16.33 en 9.18.7) voor het gebruik van DNSSEC Policy ook expliciet moet aangeven of je daarbij Dynamic DNS (via 'allow-update' of 'update-policy') of Inline-Signing wilt gebruiken. Deze 2 mogelijkheden maken deel uit van Auto-DNSSEC, waarmee de (her)ondertekening van een zone volledig geautomatiseerd verloopt op basis van de beschikbare sleutelparen. In het eerste geval (geïntroduceerd met versie 9.7.0) wordt gebruik gemaakt van de 'Dynamic DNS'-faciliteit van named (via de 'local-ddns' key) om een bestaande zone on-the-fly te ondertekenen. Inline-Signing (beschikbaar vanaf versie 9.9.0) is de doorontwikkeling van Auto-DNSSEC in combinatie met de 'update-policy local'-optie en maakt geen (oneigenlijk) gebruik meer van Dynamic DNS. We bespreken deze features verderop in meer detail.

Vanaf versie 9.19/9.20 zal Auto-DNSSEC (deprecated vanaf versies 9.16.33 en 9.18.10) niet meer beschikbaar zijn, maar compleet zijn vervangen door DNSSEC Policy (die naast volledig automatische (her)ondertekening dus ook volledig automatisch sleutelbeheer doet).

De DNSSEC policy gespecificeerd in de zone verwijst naar een definitie in de globale configuratie:

dnssec-policy "dnssec-policy-1" {
  ...
  }

Daarmee zijn we ook af van DNSSEC-gerelateerde configuratie-opties verspreid over verschillende plekken en files; alle policy-instellingen kunnen nu op één centrale plaats gespecificeerd en beheerd worden.

6.1 Key and Signing Policy (KASP)

De Key and Signing Policy (KASP) laat je niet alleen de herondertekening automatiseren (zoals Auto-DNSSEC en Inline-Signing al deden) maar ook het aanmaken van nieuwe sleutelparen (vergelijk het oudere 'dnssec-keymgr'-commando in combinatie met een cron job).

Hieronder zie je een voorbeeld van een complete policy-definitie:

dnssec-policy "dnssec-policy-1" {

  keys {
    ksk key-directory lifetime P1Y algorithm 8 4096;
    zsk key-directory lifetime P30D algorithm 8 2048;
    }

  purge-keys P90D;

  publish-safety PT2H;
  retire-safety PT2H;

  nsec3param iterations 0 optout false salt-length 0;

  signatures-validity P14D;
  signatures-validity-dnskey P14D;
  signatures-refresh P5D;

  max-zone-ttl P1D;
  zone-propagation-delay PT5M;

  dnskey-ttl PT1H;

  parent-ds-ttl P1D;
  parent-registration-delay 
  parent-propagation-delay PT1H;

  }

Als eerste definieert deze policy 2 typen sleutelparen. We gebruiken hier KSK- en ZSK-sleutelparen gebaseerd op DNSSEC-algoritme nummer 8 ('RSA/SHA-256') met een sleutellengte van respectievelijk 4.096 en 2.048 bits (die laatste is de default, dus die hadden we ook weg kunnen laten). Voor de KSK-sleutelparen hebben we hier een levensduur van 1 jaar gespecificeerd, terwijl we die voor ZSK-sleutelparen op 1 maand hebben gezet. Voor algoritme nummer 13 ('ECDSA Curve P-256 with SHA-256') hoeft de sleutellengte niet gespecificeerd te worden.

Als je wilt, kun je de aanduidingen 'lifetime' en 'algorithm' in die statements ook weglaten (wij hebben ze hier voor de duidelijkheid laten staan). Gebruik de aanduiding 'unlimited' voor sleutelparen die nooit gerold hoeven worden.

Werk je liever met enkelvoudige CSK-sleutelparen, dan gebruik je daarvoor de aanduiding 'csk' (waarvoor je vanzelfsprekend maar 1 type sleutelparen specificeert).

Onderstaande tabel geeft een overzicht van de betekenis en default-waarden van de overige opties beschikbaar voor 'dnssec-policy':

Tabel 4: De betekenis en default-waarden van de overige opties beschikbaar voor 'dnssec-policy'.

BIND named definieert zelf al een default policy (met de naam 'default'). Gebruikers (beheerders) kunnen die als uitgangspunt nemen voor hun eigen policydefinities.

Merk op dat de syntax voor KASP heel anders is dan die voor de verderop besproken policy classes zoals gebruikt door het 'dnssec-keymgr'-commando (gedefinieerd in de policy file '/etc/dnssec-policy.conf'). Tijdsaanduidingen worden aangegeven volgens ISO 8601 of in TTL-stijl.

Voor de details omtrent de timing-aspecten van DNSSEC verwijzen we je naar een ander artikel, waarin we deze uitgebreid bespreken op basis van OpenDNSSEC.

6.2 Sleutelmanagement

Vanaf versie 9.16.5 is het commando 'rndc dnssec -status' beschikbaar om de huidige KASP policy's te bekijken, de sleutelparen die nu in gebruik zijn, de status van alle sleutelparen en de actuele rollovers:

[root@system]# rndc dnssec -status example.nl
dnssec-policy: dnssec-policy-1
current time:  Thu Feb 11 16:03:34 2023

key: 43281 (RSASHA512), KSK
  published:      yes - since Fri Aug 28 00:31:44 2022
  key signing:    yes - since Fri Aug 28 00:31:44 2022

  Next rollover scheduled on Wed Feb 10 20:21:50 2023
  - goal:           omnipresent
  - dnskey:         omnipresent
  - ds:             omnipresent
  - key rrsig:      omnipresent

key: 20426 (RSASHA512), ZSK
  published:      yes - since Sat Nov 21 00:31:44 2022
  zone signing:   yes - since Mon Dec 21 00:31:44 2022

  Next rollover scheduled on Sat Mar 20 22:26:44 2023
  - goal:           omnipresent
  - dnskey:         omnipresent
  - zone rrsig:     omnipresent

Een rollover kan handmatig in gang gezet (geforceerd) worden met het volgende commando (beschikbaar vanaf versie 9.16.8):

rndc dnssec -rollover [-when <datetime>] -key 43281 example.nl

Let op dat je (vanaf versie 9.16.7) expliciet onderstaand commando moet geven om BIND named te laten weten dat een nieuw DS-record in de bovenliggende zone beschikbaar is. Zolang je dat niet doet, zal named namelijk niet overschakelen naar het nieuwe KSK-sleutelpaar.

rndc dnssec -checkds -keyid 43281 published example.nl

Om BIND named te laten weten dat een sleutelpaar niet meer beschikbaar is (in de bovenliggende zone en in de caches), gebruik je dit commando:

rndc dnssec -checkds -keyid 14385 withdrawn example.nl

Vanaf versie 9.16.19 kun je de zone configuratie-optie 'parental-agents' (in combinatie met de 'parent-ds-ttl'-optie) gebruiken om een lijst van alle autoritatieve nameservers te specificeren waar DS-records beschikbaar moeten zijn. Daarmee vervalt de noodzaak om veranderingen in de registratie en publicatie van KSK-sleutelparen expliciet aan BIND named te melden. BIND named kan met die informatie nu immers zelf bepalen wanneer het veilig is om verder te gaan met de rollover.

6.3 Verwijderen DNSSEC-bescherming

Wil je de bescherming van DNSSEC om een of andere reden van een ondertekende zone verwijderen (zonder dat het betreffende domein daarbij "bogus" gaat), dan kun je vanaf versie 9.16.11 onderstaand statement gebruiken. Daarbij worden ook CDS/CDNSKEY-records voorzien van de DELETE-vlag gepubliceerd, zodat de DS-records automatisch uit de bovenliggende zone verwijderd kunnen worden (volgens het mechanisme beschreven in RFC 8078).

dnssec-policy none

Vanaf versie 9.16.16 moet je om een "bogus" domein te voorkomen eerst naar de instelling 'insecure' (totdat alle DNSSEC-records verwijderd zijn). Pas daarna kun je naar 'none' (of het 'dnssec-policy'-statement in zijn geheel weglaten).

dnssec-policy insecure

Deel 3: BIND versies 9.11-9.14 – Geautomatiseerde (her)ondertekening en sleutelbeheer

7 Automatisering sleutelbeheer en rollovers

Hoewel de configuratie van DNSSEC-ondertekening in versie 9.15 weer compleet op de schop is gegaan, was BIND versie 9.11 de eerste waarbij het heel eenvoudig was om zowel de (her)ondertekening als het sleutelbeheer volledig te automatiseren. Aan de nieuwe DNSSEC-features van versie 9.11 is goed te zien dat deze beveiligingstechnologie inmiddels volwassen was geworden en de implementatie zijn voltooiing naderde. De belangrijkste toevoeging voor wat betreft autoritatieve nameservers is het 'dnssec-keymgr'-commando. Deze Python-gebaseerde wrapper combineert de oudere 'dnssec-keygen'- en 'dnssec-settime'-commando's in 1 tool voor het automatiseren van sleutelbeheer en rollovers.

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 genoemde 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 (tezamen met de specificatie van de key directory). Eventueel kan nog een ander path voor het configuratiebestand worden opgegeven via de '-c'-optie. De key directory kan ook in de policy file zelf worden gespecificeerd (bijvoorbeeld per zone).

Het 'dnssec-keymgr'-commando is weer uit BIND verwijderd vanaf versie 9.18.0 (want niet meer nodig bij gebruik van DNSSEC Policy).

7.1 De policy file

De inhoud van de policy file '/etc/dnssec-policy.conf' bestaat uit policy classes ('policy <name>'): profielen waarvan de instellingen door policies of andere policy classes overgeërfd kunnen worden. Algorithm policy's ('algorithm-policy <algorithm>') bevatten instellingen per cryptografisch algoritme. Zone policy's ('zone <name>') 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 2.048 en 4.096 bits voor de ZSK- en KSK-sleutelparen. Daarmee overrulen we de standaardinstelling die op 2.048 bits staat voor beide typen. Daarnaast stellen we 2 policy's 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).

7.2 Genereren opvolgende sleutelparen

Hieronder kun je zien hoe 'dnssec-keymgr' voortbouwt op eerder gegenereerde sleutelbestanden in de '/etc/bind/keys/' directory om aan de ingestelde policy voor example.nl te voldoen:

[root@system]# dnssec-keymgr -K /etc/bind/keys/ -r /dev/random
# /usr/sbin/dnssec-settime -K /etc/bind/keys/ -I 20220503135334 -D 20220602135334 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.

7.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 zouden 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 zonefile 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 opties '-z' en '-k', waarmee de check beperkt kan worden tot alleen ZSK- respectievelijk KSK-sleutelparen.

Hieronder controleren we de coverage van sleutelbestanden die we eerder genereerden voor het domein example.nl:

[root@system]# 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 2023:
    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 2023:
    Publish: example.nl/ECDSAP256SHA256/59790 (ZSK)
    Activate: example.nl/ECDSAP256SHA256/59790 (ZSK)
  Tue Apr 03 13:53:34 UTC 2023:
    Publish: example.nl/ECDSAP256SHA256/12391 (ZSK)
  Thu May 03 13:53:34 UTC 2023:
    Inactive: example.nl/ECDSAP256SHA256/59790 (ZSK)
    Activate: example.nl/ECDSAP256SHA256/12391 (ZSK)
  Sat Jun 02 13:53:34 UTC 2023:
    Delete: example.nl/ECDSAP256SHA256/59790 (ZSK)

No errors found

Het 'dnssec-coverage'-commando is uit BIND verwijderd vanaf versie 9.18.0 (want niet meer nodig bij gebruik van DNSSEC Policy).

7.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@system]# rndc zonestatus example.nl
name: example.nl
type: master
files: db.example.nl
serial: 2023012801
signed serial: 2023012803
nodes: 6
last loaded: Sun, 28 Jan 2023 19:54:50 GMT
secure: yes
inline signing: yes
key maintenance: automatic
next key event: Tue, 30 Jan 2023 13:14:01 GMT
next resign node: ns1.example.nl/NSEC
next resign time: Tue, 30 Jan 2023 18:48:44 GMT
dynamic: no
reconfigurable via modzone: no

7.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@system]# 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 2 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 1 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 10 dagen hebben. 7 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' bespreken we verderop bij het gebruik van de 'dnssec-signzone'-opdracht.

Deel 4: BIND versies 9.6-9.10 – De basisfunctionaliteit voor DNSSEC

8 Genereren sleutelparen en ondertekenen zonefile

8.1 De eerste configuratie

De configuratie van DNSSEC voor oudere versies van BIND named begint met het toevoegen van deze optie aan het configuratiebestand:

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.

Vanaf versie 9.5 al is 'dnssec-enable yes' de default instelling. Vanaf versie 9.16.0 is deze optie overbodig geworden, en vanaf versie 9.18.0 compleet verwijderd.

8.2 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/
chown root:named /etc/bind/keys/
chmod 775 /etc/bind/keys/
cd /etc/bind/keys/

dnssec-keygen -f KSK -3 -a ECDSAP256SHA256 -r /dev/random example.nl

[root@system]# 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 nog niet, dus voor die gevallen gebruiken we de opties '-a RSASHA256 -b 4096' ('RSA/SHA-256' met een sleutellengte van 4.096 bits). Bij de selectie van een van de 2 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 optie '-3' verifieert dat het gekozen algoritme compatibel is met NSEC3 (dat geldt sowieso voor alle algoritmen vanaf nummer 6). Daarmee kunnen ook ondertekende antwoorden worden teruggestuurd als een domeinnaam niet gevonden is (NXDOMAIN/NODATA), zonder dat alle namen binnen een domein op die manier door kwaadwillenden kunnen worden afgelopen en geïnventariseerd (zone 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.

8.3 ZSK-sleutelpaar

Voor het genereren van het ZSK-sleutelpaar gebruiken we een vergelijkbaar commando, maar nu zonder de '-f KSK'-optie:

[root@system]# 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 2.048 bits). Omdat we ZSK-sleutelparen veel vaker vervangen dan KSK-sleutelparen (bijvoorbeeld elk kwartaal in plaats van elk jaar), is een sleutellengte van 2.048 bits hier voldoende.

8.4 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) generator '/dev/urandom'. 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.

8.5 Sleutelbestanden

Het op deze manier genereren van de 2 sleutelparen levert 4 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, waarover hieronder meer.

9 Ondertekenen

Voor het handmatig ondertekenen van een bestaande zonefile '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@system]# 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 zonefile 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' (en 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). En vanaf versie 9.18.0 is 'dnssec-dnskey-kskonly yes' de default-instelling geworden.

Het resultaat is een ondertekende zonefile 'db.example.nl.signed', die nu naast de DNSKEY-records ook voor elke record set een RRSIG-record bevat, met daarin de digitale handtekening voor die set. Daarnaast is een keten van (ondertekende) NSEC-records toegevoegd, waarmee het niet-bestaan van een tussenliggende naam (NXDOMAIN/NODATA) ook als DNSSEC-ondertekend antwoord kan worden teruggestuurd.

Bij het genereren van de zonefile is geverifieerd dat deze tenminste 1 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.

9.1 Verifiëren

Wil je de hele ondertekende zonefile – inclusief de NSEC-keten – laten controleren, dan gebruik je daarvoor het volgende commando:

dnssec-verify -o example.nl db.example.nl.signed

[root@system]# 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.

9.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 zonefile worden opgenomen (en ondertekend). De datuminformatie in de sleutelbestanden wordt daarbij gebruikt om te bepalen welke sleutelparen op dit moment relevant zijn:

• Created

• Publish: DNSKEY-records met een geldigheidsperiode in het verleden worden gepubliceerd

• Activate: DNSKEY-records met een geldigheidsperiode in het verleden worden gepubliceerd en gebruikt om de zone te ondertekenen

• Revoke: DNSKEY-records met een geldigheidsperiode 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 geldigheidsperiode in het verleden worden wel gepubliceerd maar niet (meer) gebruikt om de zone te ondertekenen

• Delete (voorheen Unpublish): DNSKEY-records met een geldigheidsperiode in het verleden worden niet gepubliceerd en niet gebruikt om de zone te ondertekenen

Hiermee kan de hele levenscyclus van een sleutelpaar 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.

9.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: 20230202134734 (Fri Feb  2 14:47:34 2023)
; Publish: 20230202134734 (Fri Feb  2 14:47:34 2023)
; Activate: 20230202134734 (Fri Feb  2 14:47:34 2023)
; Revoke: 20230205130153 (Mon Feb  5 14:01:53 2023)
example.nl. IN DNSKEY 385 3 13 TlKOgcQK22K3fw8pUC2VZk9P2k1nx5XK8+UIOPU9b/GqwpU6XPqFVh8O qTycyHd/YYg8vzcAtl+K9nBbb621IA==

9.4 Sleutelbeheer

Worden geen expliciete datum-opties aan het 'dnssec-signzone'-commando meegegeven, dan worden alleen de velden Created, Publish en Activate toegevoegd (alle 3 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 zonefile 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 het zojuist gegenereerde KSK- en ZSK-sleutelpaar een tweede ZSK-sleutelpaar te genereren voor een rollover 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 zonefile opneemt, maar dit sleutelpaar nog niet gebruikt om de zone-informatie te ondertekenen. Zo worden overlappende sleutelparen gegenereerd, waarmee rollovers zonder haperingen kunnen verlopen.

9.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 reconfig
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@system]# dig @localhost +dnssec example.nl

; <<>> DiG 9.16.33-RH <<>> @localhost +dnssec example.nl
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20694
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 11

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;example.nl.                    IN      A

;; ANSWER SECTION:
example.nl.             86400   IN      A       192.0.2.36
example.nl.             86400   IN      RRSIG   A 8 2 86400 20230117215936 20221219070640 1396
    example.nl. rabwdZ0NrKUJ3Q9iVjc8zSH+owRTjeWw5ZIiRdwSQs4aBgAcliT/xPCp
    bQfozbtfM/xEZGnAuAApx4XWDaau6RJhzTBnyKkQwnNxocRdqRq+3wv8
    iupU9YQvF+GDVcdMXJYlVMNPjNH3VO6Vq6jvAPVFsDouzc/63z7ZC2kr Yts=

;; AUTHORITY SECTION:
example.nl.             86400   IN      NS      dns1.example.nl.
example.nl.             86400   IN      NS      dns2.example.nl.
example.nl.             86400   IN      RRSIG   NS 8 2 86400 20230117033111 20221218130640 1396
    example.nl. ZamHjFmu5Ng3r7TvL2ZMTqCYMKOtUaC6Zk+dhEU710v9VqTKtnXlb8WY
    ga+1gSwFtmtts97Xq3Sy1U1JpfhFTu3eEeU3tLBaZvELuAIEw8Mj4Xh2
    dtOonKUsAiwvWBqE0ZjjiBmXmFoFtVez1SP7vzVUV0ouUT49Up66Nduh Bcs=

;; ADDITIONAL SECTION:
dns1.example.nl.        86400   IN      A       198.51.100.5
dns1.example.nl.        86400   IN      AAAA    2001:db8:cafe::8:5
dns2.example.nl.        86400   IN      A       203.0.113.5
dns2.example.nl.        86400   IN      AAAA    2001:db8:f00d::16:6
dns1.example.nl.        86400   IN      RRSIG   A 8 3 86400 20230122030846 20221223013109 15460
    example.nl. SrFVcwVONHOk97OL81zrdCQw4zZj3bi2/VhZ9edfRydIVGkxv6S8pHgk
    EU72Gp3TFBprHJ7ytM8bNXJ3bi9N0gXKW5oILTCadrHcxL24XQdAdNpO
    uR/XSVQVzbkp9m1HNn7DTQYF2K57JNHXd+Vt/Oh+Nwp/orru1F2pwooh ubM=
dns1.example.nl.        86400   IN      RRSIG   AAAA 8 3 86400 20230122050156 20221222213109 15460
    example.nl. SvpjhSawql1QRtVPzOzGrZ4OtJlRPhPjjYeTei3JGL987zV8AZrTkaFk
    xB0T5ddwiMK7RAkDo0qJm2J49gfJMGQI2lPTmpYdvNUlTI6LieKW1ZDq
    FqjjPrm1fZWOJzvXoEkisD+T+3NLAey6bWJiEB0tYoTfxuudePsIIl+l Y7Y=
dns2.example.nl.        86400   IN      RRSIG   A 8 3 86400 20230121140246 20221222133109 15460
    example.nl. e6p7ktNEw4Vt/DCM6nGYeqTPjxKoKcfx9JJIpoDuC4ph4sS7rFiAniB0
    GpW+DiAua6Ng+CnS1y8mP7WZ+HAlrgGAzdC8fBt5eU90mTbQCjOPmsaB
    a1YAhZs8rWnOER/o6vW1UOwnFw0Sj2Gd0MpTQLIKGGF5OUvP3g9Ve4pC 3+w=
dns2.example.nl.        86400   IN      RRSIG   AAAA 8 3 86400 20230121180325 20221223033109 15460
    example.nl. iZmMeTLSwbv3rD62VAw6rh7Fh3O1RX1woXhOSApAMmvo2VXsP/ClAtIs
    nZA0GdivP6ueMy6aHFak8cZs10c35t0puqp+KycDMOsTjRbKtpnl51b2
    j6yXZkR1yV/+twRvYE8z+BLxxQItSa8LIVlF5e/+/p+pvNv+QdxcKXsW Nlk=

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon Jan 08 12:17:37 CET 2023
;; MSG SIZE  rcvd: 1634

9.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.

De '-S <key> -i <interval>'-opties van 'dnssec-keygen' (vanaf versie 9.7.2) maken het bovendien heel eenvoudig om rollovers te automatiseren. Daarmee wordt een opvolger van een specifiek sleutelpaar gegenereerd (een zogenaamde linked key), klaar voor een automatische rollover 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).

9.7 Geen rollovers

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 datuminformatie worden door 'dnssec-signzone' altijd in de zonefile opgenomen en gebruikt om te ondertekenen.

Wil je een sleutelpaar dat wel metadata bevat en geladen wordt, maar niet wordt gepubliceerd en gebruikt om de zone te ondertekenen, dan gebruik je de '-G' (Generate)-optie.

9.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. Bij een dergelijk enkelvoudig sleutelpaar spreekt men ook wel van de Combined Signing Keys (CSK).

Met de '-z'-optie gebruikt 'dnssec-signzone' de KSK-sleutels om alle recordsets 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 zoneconfiguratie-optie 'update-check-ksk no' (en 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 enkelvoudig sleutelpaar werken.

Ongeacht welke DNS-serversoftware je gebruikt, is dit in het algemeen echter alleen goed werkbaar als je zelden of nooit een rollover doet, of als dit proces volledig geautomatiseerd is. Elke rollover 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.

9.9 DNSSEC records als include

Waar smart signing nu automatisch de actuele publieke sleutels in de zonefile opneemt en ondertekent, moesten de DNSKEY-records (de '.key'-bestanden) voorheen "handmatig" aan de zonefile toegevoegd worden voordat deze met behulp van 'dnssec-signzone' werd ondertekend. Dat kon bijvoorbeeld door een '$INCLUDE'-statement in de originele zonefile op te nemen. Welke sleutelparen voor de ondertekening moesten worden gebruikt, werd bij de aanroep van 'dnssec-signzone' 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 zonefile, dan gebruik je 'dnssec-signzone' met de '-D'-optie. Je kunt het gegenereerde bestand 'db.example.nl.signed' vervolgens in de bestaande zonefile binnenhalen middels een '$INCLUDE'-statement.

10 Uploaden sleutelmateriaal

SIDN, de beheerder van het .nl-topleveldomein, 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 zonefile 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 topleveldomeinen 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. Vanaf versie 9.16.0 worden niet langer ook de records voor SHA-1 (hash-algoritme nummer 1) gegeven, maar alleen die voor SHA-256 (nummer 2). En vanaf versie 9.16.24 worden geen records voor revoked sleutelparen meer gegeven.

dnssec-dsfromkey Kexample.nl.+013+11769.key

[root@system]# 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 bovengelegen domein gesloten is. Dat kan zowel op de sleutelbestanden direct als in het actuele DNS-systeem:

[root@system]# 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

Het 'dnssec-checkds'-commando is uit BIND verwijderd vanaf versie 9.18.0 (want niet meer nodig bij gebruik van DNSSEC Policy).

10.1 Wachten op resolver caches

Meestal kun je het sleutelmateriaal naar de beheerder van het bovenliggende domein uploaden via de managementconsole 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-*-bestanden laten opnemen in de ondertekende zonefile middels de '-g -d <directory>'-opties van 'dnssec-signzone'.

10.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 8078. Is een zone eenmaal ondertekend en gekoppeld aan een valide vertrouwensketen (de 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 nameservers 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 biedt RFC 8078 een vergelijkbaar mechanisme voor het uitwisselen van sleutelmateriaal tussen parent en child zones als RFC 5011, maar dan in omgekeerde richting (complementair).

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 <directory>'-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.

Vanaf versie 9.18.0 worden niet langer ook de records voor SHA-1 (hash-algoritme nummer 1) verwerkt, maar alleen die voor SHA-256 (nummer 2).

11 Herondertekening

De hierboven beschreven configuratie levert een statische setup op die makkelijk via cron jobs onderhouden kan worden. Gebruik je een eerder ondertekende zonefile 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 zonefile 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 (
                      20230204101952 20230105101952 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 2 weken (1.209.600 seconden) bijvoorbeeld, zouden we 'dnssec-signzone' met de optie '-e +1209600' gebruiken.

11.1 Refresh

Hieraan gerelateerd is de '-i'-optie, waarmee een refresh-interval (in seconden) kan worden gespecificeerd. Geef je 'dnssec-signzone' een eerder ondertekende zonefile 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 zonefile 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 5: Geautomatiseerde (her)ondertekening

12 Auto-DNSSEC

Vanaf versie 9.7.0 ondersteunt BIND named de zoneconfiguratie-optie 'auto-dnssec'. 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 2 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

12.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 metadata 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 rollover 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 <key> -i <interval>'). 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 NSEC3-parameters door het injecteren van een NSEC3PARAM-record in de zone-informatie:

nsupdate -l update add example.nl NSEC3PARAM 1 0 0 -

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-recordtype is gedefinieerd in RFC 5155 (sectie 4), met een belangrijke update in RFC 9276 (hier in detail besproken). Vanaf versie 9.18.0 zijn bovenstaande instellingen in BIND de default geworden.

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.

12.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 opties 'auto-dnssec maintain' en 'update-policy local' aan elke afzonderlijke zoneconfiguratie:

zone "example.nl" {
  type master;
  file "db.example.nl";
  auto-dnssec maintain;
  update-policy local;
  };

Vervolgens geven we BIND dit commando om de nieuwe configuratie in te lezen:

rndc reconfig

Waar we eerder de naam van de zonefile 'db.example.nl' in het configuratiebestand vervingen door de ondertekende zonefile 'db.example.nl.signed' gegenereerd met behulp van 'dnssec-signzone', blijft bij gebruik van de 'auto-dnssec'-optie de naam van de originele zonefile staan. Het ondertekenen van de zone-informatie gebeurt nu immers intern.

12.3 Ondertekening

Is het de eerste keer dat een zonefile 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 slavezones 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 zoneconfiguratie 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 (dit wordt in paragraaf 7 uitgebreid besproken).

12.4 Ondertekende zonefiles en journaalbestanden

De automatisch gegenereerde (ondertekende) zonefiles – in ons geval het bestand 'db.example.nl.signed' – zijn in deze nieuwe opzet niet langer direct leesbaar. Omwille van de snelheid worden zonefiles 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 journaalbestand 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.nl.jnl

13 Inline-Signing

Vanaf versie 9.9.0 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 zonefiles ontvangen vanuit een databasegedreven back-end of andersoortige DNS-software).

Een typische setup bevat een (hidden) master server die inline signing doet en de ondertekende zonefile vervolgens naar een aantal (publieke) slaveservers 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.

13.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 NSEC3-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 NSEC3-keten gegenereerd wordt.

Het controleren van de huidige status van een zone doe je met de volgende opdracht:

rndc signing -list example.nl

[root@system]# rndc signing -list example.nl
Done signing with key 8160/RSASHA256
Done signing with key 19273/RSASHA256

14 Afsluiting

In dit artikel bespraken we DNSSEC zoals dat nu door de meest recente versies (9.18, februari 2023) en eerdere versies van BIND ondersteund wordt. Zoals je hebt kunnen zien is het voor gebruikers van versie 9.16 en later heel eenvoudig geworden om een volledig geautomatiseerde DNSSEC-installatie op te zetten. Het genereren van sleutelparen, het ondertekenen van zonefiles, het rollen van sleutels en het beheer van sleutelparen lopen allemaal vanzelf na de initiële configuratie. Alleen het uploaden van het KSK-sleutelmateriaal na een KSK rollover moet in het algemeen nog met de hand gebeuren. Maar zodra de implementatie van RFC 8078 (de CDN/CDNSKEY-records) gemeengoed is, zal ook dit zonder menselijke tussenkomst kunnen gebeuren.

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

Heb je feedback op het artikel? Laat het ons vooral weten via communicatie@sidn.nl.