Verbeteringen doorgevoerd aan de .nl-zone

Instellingen voor NSEC3 aangepast

Digitaal hangslot tegen een achtergrond met binaire code

Onlangs voerden we een aantal belangrijke verbeteringen door in de zone, waarbij we nieuwe instellingen voor NSEC3 hebben toegepast. NSEC3, gedefinieerd in RFC 5155, is onder andere bedacht om het 'zone walking'-veiligheidsprobleem van NSEC tegen te gaan. Door bij NSEC3 het zogenoemde opt-out-bit uit te zetten, kan een resolver beter gebruikmaken van zijn cache en kunnen kwaadwillenden de zone niet meer straffeloos aanpassen, als ze die weten te bemachtigen.

NSEC3

Agressief cache-gebruik levert snelheidswinst en efficiëntie op voor validerende resolvers

NSEC3 is een onderdeel van DNSSEC en wordt gebruikt om met behulp van digitale ondertekening aan te geven dat een opgevraagde naam niet bestaat. De opt-out-mogelijkheid zou alleen gebruikt moeten worden bij grote zones met weinig handtekeningen. Aangezien de .nl-zone een grote zone is met veel handtekeningen (~58%), hebben we besloten om het opt-out-bit uit te zetten.

Fouten

Toen we de benodigde wijzigingen doorvoerden op onze testomgeving, kwam er een aantal fouten in OpenDNSSEC aan het licht. Verder zagen we dat we ook de nameserverconfiguraties moesten aanpassen om te zorgen dat er geen problemen zouden ontstaan met de grootte van de journal. De journal is een lokale database waarin wijzigingen opgeslagen worden. Een nameserver krijgt namelijk om de zoveel tijd een bericht met wat er gewijzigd is en door dit in een journal op te slaan kan hij deze (kleine) wijzigingen ook weer doorgeven aan een andere nameserver.

We hebben alle wijzigingen een aantal keer in onze test- en acceptatie-omgevingen doorlopen en aangepast totdat we een versie hadden die zonder problemen in productie uitgevoerd kon worden. Het uitzetten van het opt-out-bit heeft ervoor gezorgd dat de zonefile van ~3.6 GB naar ~4.5 GB is gegaan (een groei van ~26%) en verder duurt het ondertekeningsproces nu 3 minuten langer.

Best Current Practice

Met deze wijziging voldoet SIDN weer aan de Best Current Practice (BCP), zoals beschreven in RFC 9276/BCP 236. Niet voldoen aan deze standaard zou kunnen betekenen dat resolvers op internet ten onrechte zouden kunnen besluiten dat de zone niet beveiligd is of zelfs helemaal fout (errorcode SERVFAIL). Door de wijziging zijn we weer goed voorbereid op de toekomst.

Achtergrond

Naast het uitzetten van het opt-out-bit hebben we op aanbeveling van de RFC/BCP de salt aangepast: deze is veranderd van “1 0 5 32280ECEE31048D8” naar “1 0 0 -”. Dit betekent dat we van 5 iteraties naar 0 en van een salt-lengte van 8 bytes (32280ECEE31048D8) naar een salt-lengte van 0 bytes (-) zijn gegaan.

Agressief cachegebruik

In juli 2017 werd RFC 8198 gepubliceerd, die in juli 2021 bijgewerkt werd door RFC 9077. Deze RFC’s gaan over het lokaal opslaan (cachen) van DNS-antwoorden door een resolver en over hoe de resolver deze cache op "agressieve" wijze kan gebruiken. Bij DNSSEC wordt er via een NSEC-record aangegeven welke records niet bestaan tussen bepaalde namen. Bijvoorbeeld als .nl de volgende items in de zone heeft staan:

a.nl IN AAAA 2001:db8:53:49:44:4e:6e:6c
d.nl IN A 192.0.2.1

Als een client een resolver eerst om b.nl en daarna om c.nl vraagt, dan kan de resolver het antwoord voor c.nl uit de cache geven omdat via het eerste NSEC-antwoord al bekend is dat er niets tussen a.nl en d.nl bestaat.

Opt-out

Bij NSEC3, wat voor .nl gebruikt wordt, is er een mogelijkheid om een opt-out-bit aan te zetten, waardoor alleen records ondertekend worden als er een DS-record in de .nl-zone staat. Helaas werkt de cache van de resolver dan alleen maar voor precies dezelfde vragen. Dus bijvoorbeeld alleen als b.nl eerder aan de resolver is gevraagd, kan de resolver het antwoord uit de cache geven. Het zou dus kunnen zijn dat c.nl wel bestaat, maar geen DS-record in de .nl-zone heeft, waardoor deze niet in het NSEC3-antwoord genoemd werd. Door het opt-out-bit uit te zetten, kan een resolver nog beter gebruik maken van de cache, zoals beschreven in RFC 8198 en 9077.

Op dit moment hebben we nog geen goed inzicht op het gebruik van de agressieve NSEC3-cache. Dit onderzoeken we op een later moment.