Dit is de gearchiveerde site van het DNSSEC Kennisplatform (2012-2018).
Actuele informatie over DNSSEC vind je op https://sidn.nl/dnssec/.

DNSSEC checklist

Introductie

Deze checklist is bedoeld om op een eenvoudige manier te bepalen of u klaar bent voor de DNSSEC introductie in het .nl-domein. Het is geschreven voor de registrars en houders van .nl-domeinen.

De checklist is opgebouwd uit vier secties, te weten:

  1. Begrip van DNS en DNSSEC
  2. Systemen
  3. Processen
  4. Houders

Elk van deze secties bevat een aantal checklist items. Onder elk item staat extra uitleg. Deze uitleg kan nodig zijn om het desbetreffende item af te kunnen checken.

Mochten er naar aanleiding van deze items nieuwe vragen rijzen dan worden die toegevoegd aan deze lijst.

Begrip van DNS en DNSSEC

Dit gaat over het algemene begrip van DNS en DNSSEC en hoe u zoiets kan inbedden binnen uw organisatie.

  • Begrip van DNS en DNSSEC is van voldoende niveau:

    DNS en DNSSEC zijn in beginsel niet moeilijk. De duivel zit hem (zoals wel vaker) in de details. Gelukkig hoeft u zich als eindgebruiker of administrator niet verliezen in deze details. Op grote lijnen kennis hebben van het protocol is in de meeste gevallen voldoende.

    De cursussen van SIDN op het vlak van DNS en DNSSEC zijn een goede introductie. Op http://dnsseccursus.nl/ staat een uitgebreide DNSSEC cursus (in het Nederlands en het Engels).

    Verder is er de (technische) DNSSEC Howto van NLnet Labs:

    En ook niet onbelangrijk, de originele RFC's, zoals voor DNS:

    En de DNSSEC RFC's:

    Maar deze gaan natuurlijk een stuk dieper in op de materie.

  • De DNSSEC cursus op dnsseccursus.nl is bekeken:

    Op http://dnsseccursus.nl/ staat een uitgebreide DNSSEC cursus. Deze is te bekijken in het Nederlands en het Engels.

  • Het niveau van mijn medewerkers is op orde:

    U kunt bijvoorbeeld denken aan interne opleidingen van uw medewerkers. Hebben de medewerkers de SIDN cursus bekeken en begrepen?

  • Borgen van up-to-date blijven over de ontwikkelingen DNSSEC:

    Is er geborgd dat ieders begrip niveau up-to-date blijft. Hoe is dat nu geregeld in uw organisatie met betrekking tot DNS? DNSSEC is daar een natuurlijke toevoeging op.

  • Ik weet hoe ik DNS problemen moet oplossen:

    Het oplossen en detecteren van DNS/DNSSEC problemen is belangrijk. Kunt u of kunnen uw medewerkers omgaan met problemen in het DNS. Deze presentatie van RIPE64 geeft een paar goede handreikingen: https://ripe64.ripe.net/presentations/33-DNS_debug+monitor.pdf

Systemen

Welke systemen worden door DNSSEC geraakt?

  • Mijn nameserver implementatie kan DNSSEC aan:

    De authoritatieve nameserver moet DNSSEC antwoorden gaan geven. De meeste DNS software ondersteunt DNSSEC al een aantal jaar. De nameserver implementaties die DNSSEC ondersteunen zijn (ondermeer):

    Over het algemeen is het zo dat een up-to-date nameserver installatie DNSSEC out-of-the-box ondersteunt. Maar uitzondering op die regel zijn bijvoorbeeld:

    Draait u zulke software, dan zal die moeten worden vervangen door implementaties die wel DNSSEC ondersteunen.

  • Mijn resolver ondersteunt DNSSEC:

    Dit staat nog los van het feit of u gaat valideren. Voordat u die beslissing kan nemen moet de resolver implementatie wel om kunnen gaan met DNSSEC.

    Resolvers die DNSSEC ondersteunen zijn:

    Resolvers die geen weet hebben van DNSSEC blijven werken, want DNSSEC is backwards compatible met DNS.

  • Het systeem om te signeren (en resignen) staat vast:

    U weet hoe en met welk systeem u uw zones gaat signeren. Er is een aantal producten en manieren om dit te doen, bijvoorbeeld:

  • een CRON job die 's nachts met dnssec-signzone (onderdeel van BIND9) de signatures ververst. Deze tool is slim en ververst alleen die signatures die bijna tegen hun expiratie datum aan lopen. De private key welke wordt gebruikt voor het signeren zal in dit geval on-line staan en aanspreekbaar moeten zijn door het dnssec-signzone proces.
  • BIND9 kan in versie 9.8 en 9.9 automatisch uw zone files onderhouden en regelt DNSSEC voor u.
  • OpenDNSSEC (http://www.opendnssec.org) is een oplossing die signeert en ook de key rollovers voor haar rekening neemt. OpenDNSSEC is ontworpen om als drop-in replacement tussen uw nameservers en uw provisioning systeem geplaatst te worden.
  • PowerDNS(SEC) 3.1 of hoger kan gebruikt worden als signer.

  • De sleutels zijn opgeslagen in een HSM (hardware security module):

    U kunt uw DNSSEC sleutels opslaan in een HSM. Een HSM geeft een goede (maar vaak dure) bescherming voor cryptografische sleutels. Ook het signeren van het DNS materiaal vindt dan plaats binnen de HSM.

    Aangezien er restricties zitten aan het gebruik van een HSM (hardware kan maar X-duizend signatures per seconde maken/ondersteunt maar bepaalde algoritme), kan gebruik van bijvoorbeeld iets als SoftHSM (http://www.opendnssec.org/softhsm/, onderdeel van OpenDNSSEC) wenselijk zijn. SoftHSM is niets anders dan een HSM geïmplementeerd in software.

    Ook afzien van een HSM is een mogelijkheid. Dan wordt de fysieke en netwerk beveiliging van het signeer systeem wel belangrijker.

  • Mijn klanten backend systeem kan DNSSEC aan:

    Uw DNS beheer systeem kan overweg met DNSSEC. In het simpelste geval valt u uw klanten nergens mee lastig. Of er is een aan/uit vinkje. Of klanten kunnen allerlei DNSSEC aspecten aanpassen voor hun domeinen.

  • Mijn systemen kunnen secure verhuizingen aan:

    Tijdens een verhuizing kan het straks voorkomen dat u DNSSEC materiaal ontvangt. U moet in staat zijn dit te kunnen opvangen, of, u moet weten hoe u DNSSEC voor dit domein uitzet via de DRS web interface van SIDN.

  • Mijn netwerk kan DNSSEC aan:

    Sommige (oudere) netwerk apparatuur of firewalls slaan alarm bij DNS pakketten die groter zijn dan 512 byes. Met DNSSEC komen er gegarandeerd grotere pakketten. Het aantal problemen is de laatste jaren een stuk kleiner geworden doordat de apparatuur geüpdate is. De volgende website is handig om uw netwerk te testen:

    Zoals gezegd neemt met DNSSEC de grootte van de antwoord pakketten toe. Dit kan tot een facter 8 groter zijn. Nu is de datastroom van DNS redelijk klein in vergelijking met andere protocollen, maar het is wel belangrijk om te zien dat met DNSSEC datastroom groter wordt.

  • Mijn monitoring is op orde:

    DNSSEC is minder vergevingsgezind dan DNS. Goede monitoring is dan ook belangrijk. Zie deze link:

    voor een lijst van monitoring tools.

    De 'wat' te monitoren behelst onder meer het volgende:

    • begin en eind datum van de signatures: zijn ze nog geldig?
    • validatie tests, klopt de signature data?
    • validatie tests, klopt de chain of trust nog. Is het hele te valideren pad, van de root, via .NL naar de data in de zone nog in orde? Zie ook http://dnssec-debugger.verisignlabs.com/
    • de systeem tijd is op orde.
    • zijn de zones gesigneerd met de juiste sleutels?

  • De systeem tijd is in orde:

    Er is wat speelruimte in het protocol ingebouwd, maar systemen die valideren en signeren hebben de correcte tijd nodig. U wordt ten sterkste aangeraden om NTP te gebruiken op deze systemen.

Processen

In welke processen wordt DNSSEC geraakt en waarom? Welke nieuwe processen brengt DNSSEC met zich mee en wanneer gebruikt u deze?

  • Validatie is aangezet:

    DNSSEC validatie zorgt ervoor dat de beveiliging die is toegevoegd door middel van het signeer proces ook daadwerkelijk gecontroleerd gaat worden.

    Er zijn twee software pakketten die DNSSEC validatie aan kunnen: de BIND9 resolver en de Unbound resolver. Beide pakketten ontlopen elkaar weinig.

    Het kan wenselijk zijn om te eerst te experimenteren met deze software. Op http://dnssectest.sidn.nl/ kunt u testen of u lokaal valideert.

  • Mijn DNSSEC beleid is bepaald:

    • De KSK/ZSK split maakt ZSK rollovers makkelijk. Gaat u rollovers uitvoeren, dan is deze splitsing aan te raden. Zo niet, dan kan er net zo makkelijk één sleutel gebruikt worden: CSK (Common Signing Key). Deze sleutel zal dan vrij statisch zal zijn.
    • De KSK is meestal groter dan de ZSK.
    • Gebruik geen RSA keys groter dan 2048 bits, dit is (nu) een goede afweging tussen te grote DNS pakketten en veiligheid. De KSK van .NL is 2048 bits.
    • Gebruik RSASHA256, dit is breed ondersteund in de software.
    • Gebruik NSEC voor zones waarvan de gehele inhoud publiek mag worden, gebruik NSEC3 voor de rest. Voor hele grote (miljoenen records) zones is NSEC3 met opt-out aan te raden.
    • Voor extra beveiliging kunt u de ZSK en KSK regelmatig vernieuwen; een rollover uitvoeren. Vanuit het DNSSEC protocol gezien is dit geen verplichting. U bent vrij om lang (altijd?) dezelfde sleutels te gebruiken. Mocht u besluiten om rollovers te gaan doen, automatiseer ze dan met een product als OpenDNSSEC.
    • (Droog) oefen regelmatig key rollovers, want in noodgevallen (KSK gestolen) zullen deze moeten plaatsvinden.

  • Mijn DNSSEC beleid is gepubliceerd:

    Eventueel kunt u een document op uw site plaatsen waarin dit DNSSEC beleid is vastgelegd, maar dit is geen verplichting.

  • Ik kan DNSSEC sleutels beheren en genereren:

    Voor DNSSEC zult u sleutels moeten maken. Voor DNSSEC sleutels zijn twee zaken van belang, het algoritme en de bit lengte. In RFC 4641 (en zijn opvolger 4641bis — URL) worden aanwijzingen gegeven. Zie: http://tools.ietf.org/html/rfc4641 Of zijn beoogd opvolger: http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-11

    Gebruikt u een (hardware) HSM dan ligt het algoritme en de sleutel lengte waarschijnlijk vast. Zo niet, dan kan de volgende tekst u misschien helpen.

    Het algoritme (in DNSSEC) bestaat uit een hash gedeelte en een cryptographisch gedeelte. Als hash algoritmes komen in aanmerking: MD5, SHA1, SHA2 en GOST.

    MD5 is bijna gekraakt en ook SHA1 begint (haar)scheurtjes te vertonen. Wilt u het zekere voor het onzekere nemen dan is SHA2 een goede keuze. GOST is pas kort geleden gestandaardiseerd binnen DNSSEC en is nog niet overal geïmplementeerd.

    Voor de cryptographische component kunt u kiezen uit: DSA, RSA en Elliptic Curve. DSA was, voor dat het patent op RSA verliep (in 2000), de eerste keus, maar inmiddels is RSA het algoritme du jour. Elliptic Curve is nieuw. Het grote voordeel ervan is dat het 'krachtiger' is dan RSA en de sleutels dus veel kleiner kunnen zijn.

    Als met al, is RSA met SHA2, op dit moment een goede keus. Dat algoritme heet binnen DNSSEC "RSASHA256".

    Bit lengtes verschillen per algoritme. Als we alleen kijken naar RSA, dan gebruikt SIDN voor .NL bijvoorbeeld 1024 bits voor de ZSK en 2048 bits voor de KSK. Dit zijn vrij standaard waardes.

  • Mijn registries ondersteunen DNSSEC:

    U bent op de hoogte of de registries die u gebruikt DNSSEC ondersteunen.

  • Ik kan (DNSSEC) EPP praten met mijn registries:

    Voor .NL is dit aan te raden, zeker als het volume toe neemt.

  • Ik kan key materiaal in de registries beheren (ook zonder EPP):

    U kunt via de DRS web interface sleutel materiaal weghalen voor .NL domeinen.

  • Ik kan omgaan met emergency key rollovers:

    Dit is een nood procedure. Het oude sleutel materiaal zal moeten worden weggehaald. Als u 1 (CSK) sleutel heeft, dan zal dit altijd parent communicatie inhouden: het oude DS record moet worden weggehaald en er zal een nieuwe voor in de plaats moeten komen.

    Bij de ZSK/KSK split ligt het eraan welke sleutel is gecompromiteerd:

    • ZSK: nieuwe ZSK gebruiken en resignen. Er is geen communicatie met SIDN nodig.
    • KSK: het oude DS record moet worden weggehaald bij SIDN. Er zal een nieuwe KSK aangemaakt moeten worden. Dan moet de zone geresigned worden. Daarna moet bij SIDN het DS record worden geüpdate.

    U kunt er ook voor kiezen om, voor deze zone, het DS record bij SIDN weg te halen en naar de status 'insecure' terug te vallen.

  • Ik kan DNSSSEC in noodgevallen voor individuele domeinnamen 'uitzetten':

    U kunt DNSSEC aan de authoritatieve server kant uitzetten door het desbetreffende domein 'insecure' te maken, oftewel te ontdoen van de DNSSEC records. Let op dat ook het DS record bij SIDN moet worden weggehaald.

    Aan de validatie kant kan bijvoorbeeld met Unbound een domein naam worden uitgesloten van DNSSEC validatie. Zie: http://www.unbound.net/documentation/howto_turnoff_dnssec.html

Houders

  • Ik weet wat ik moet als ik van provider verander:

    U verandert van provider, wat gebeurt er met uw sleutel materiaal? Een provider die DNSSEC ondersteunt zal het sleutel materiaal gewoon overnemen. Ook het DS records dat in de .NL zone staat blijft gewoon staan.

    Providers die DNSSEC niet ondersteunen hebben de keuze: alles overnemen, of het DNSSEC materiaal niet overnemen en tegelijkertijd de DS bij NL weghalen. Dit betekent dat uw domein naam dan insecure wordt.

  • Ik weet welke providers DNSSEC ondersteunen:

    — Wordt ingevuld zodra er een lijst bekend is —

  • Ik weet waar ik mijn DNSSEC beheer kan beleggen:

    —Wordt ingevuld zodra er een lijst bekend is —

  • Ik weet welke domeinen ik gesigneerd wil hebben:

    In principe is SIDN er voor om alle domeinen namen binnen de .NL zone gesigneerd te krijgen. Maar u kunt er voor kiezen om met een klein aantal te beginnen om DNSSEC "in de vingers" te krijgen. In dit licht bezien is het wellicht verstandig om met een minder belangrijke domein naam te beginnen, ervaring op te doen en daarna ook de belangrijke domein namen mee te nemen.

  • Ik weet wat DNSSEC is:

    U heeft zichzelf ingelezen en weet of u DNSSEC aan wil zetten op uw domeinen.