Kies jouw kleur

Veel bezocht

Veelgestelde vragen

  • Ik zoek de houder van een domeinnaam. Waar vind ik die?

    Via de Whois kun je de huidige houder van een domeinnaam opzoeken. Om de persoonsgegevens in te zien moet je vanwege de privacygevoelige informatie eerst de gebruikersvoorwaarden van de Whois accepteren. Gegevens van privé personen kunnen ook afgeschermd zijn vanwege de AVG (Algemene verordening gegevensbescherming).

    Op de pagina domeinnaam zoeken lees je meer over wat een domeinnaam is, de werking van de Whois en de privacy van persoonsgegevens.

  • Ik wil mijn domeinnaam verhuizen. Hoe doe ik dat?

    Je wilt je domeinnaam verhuizen naar een andere registrar. Vraag dan je verhuistoken op bij je huidige registrar. Lees de verhuisstappen op de pagina domeinnaam verhuizen.

  • Ik wil mijn contact/adresgegevens aanpassen bij mijn .nl-domeinnaam. Hoe doe ik dat?

    Neem contact op met je registrar. Jouw registrar kan de contactgegevens bij je domeinnaam voor je aanpassen. Wij raden je aan het resultaat te controleren via de Whois. Lees meer over het aanpassen van je gegevens bij contactgegevens wijzigen.

  • Waarom staat mijn domeinnaam in quarantaine?

    Wij weten niet wat de reden van de opheffing is. Neem contact op met je registrar. Het voordeel van de quarantaine is dat je altijd de mogelijkheid hebt om een opheffing die je niet had bedoeld te herstellen.

    Voorbeeld: In de voorwaarden van je registrar staat dat je elk jaar je abonnement moet verlengen. Dat gebeurt dan niet automatisch. Zo kan het gebeuren dat je domeinnaam wordt opgeheven zonder dat je er om gevraagd hebt.

  • Ik heb een klacht over mijn provider/registrar. Kan ik daarvoor bij SIDN terecht?

    Wanneer je een klacht hebt over of een geschil met je registrar dan zijn er verschillende mogelijkheden om tot een oplossing te komen. Hierover lees je meer op pagina klacht over registrar. SIDN heeft geen formele klachtenprocedure voor het behandelen van een klacht over jouw registrar.

  • Waaraan moet ik voldoen als registrar?

    Wil je zelf direct domeinnamen kunnen registreren bij SIDN voor je klanten of voor je eigen organisatie? Dan kun je .nl-registrar worden. Lees meer over de voorwaarden en de manier waarop je je kunt inschrijven als registrar via de pagina registrar worden.

Meer veelgestelde vragen

ZONEMD beschermt de integriteit van complete zonefiles

Nieuwe beveiligingsmethode eind dit jaar in root zone opgenomen

Digitaal hangslot in blauwgekleurde moederbordachtige digitale omgeving
  • donderdag 20 juli 2023

Het relatief nieuwe ZONEMD-record kan aan een zone worden toegevoegd om de integriteit van de DNS-informatie in de betreffende zone te waarborgen. Daarmee weten ontvangers/gebruikers van een zonefile zeker dat hun kopie correct en compleet is. Het ZONEMD-record zelf wordt op zijn beurt beschermd door middel van een DNSSEC-handtekening, waarmee deze bescherming cryptografisch waterdicht is.

Op dit moment wordt gewerkt aan de toevoeging van een ZONEMD-record aan de root zone [1, 2]. Deze extra beveiliging is vooral van belang voor beheerders van recursieve resolvers die ook een complete kopie van de root zone lokaal willen cachen.

Maar ook voor ons is het ZONEMD-record potentieel interessant: Om te zorgen dat onze autoritatieve servers op allerlei plaatsen over de wereld beschikbaar zijn, maken we in het algemeen gebruik van peering-overeenkomsten met betrouwbare partners ("collega's") uit de internetinfrastructuurwereld. Maar we onderzoeken ook wat de mogelijkheden zijn om autoritatieve nameservers voor de .nl-zone onder te brengen op relatief goedkope virtuele machines bij commerciële dienstverleners. Daarbij is vanzelfsprekend cruciaal dat de DNS-informatie altijd te vertrouwen moet zijn, ongeacht eventuele beveiligingsproblemen bij een dienstverlener.

Planning

Volgens de huidige planning zal het ZONEMD-record [1] op 13 september 2023 aan de root zone worden toegevoegd. In eerste instantie zal het algoritmenummer op een gereserveerde (private) instelling worden gezet, zodat er geen validatie kan plaatsvinden. Op 13 december wordt dan overgeschakeld naar het SHA-384 algoritme, waarna afnemers het ZONEMD-record kunnen gebruiken om de integriteit van de zonefile te controleren. De rootservers zelf zullen op zijn vroegst een jaar na deze introductie het ZONEMD-record gaan valideren. Hoewel er geen impact op afnemers/gebruikers wordt verwacht, is het goed te weten dat de root zone file vanaf dit najaar een extra record-type en beveiligingsfeature bevat.

Kopieën van zonefiles

Er zijn verschillende goede redenen waarom een recursieve resolver een complete kopie van de root zone lokaal zou willen cachen. RFC 8806 noemt er 2: om vertragingen te voorkomen in geval van netwerkaanvallen en om het afluisteren van verkeer met de rootservers tegen te gaan. Een ondertekend ZONEMD-record garandeert dan de integriteit van de lokale kopie (en impliciet de authenticiteit van de bron).

Vanuit SIDN kunnen we hier nog een derde reden voor de toepassing van ZONEMD aan toevoegen: registry’s die voor hun secondary nameservers (ook) gebruikmaken van virtuele servers bij commerciële aanbieders willen zeker weten dat ook daar de juiste DNS-informatie wordt opgehoest. Het ZONEMD-record zorgt dat alleen de correcte en complete zonefile op die cloudservers wordt ingeladen (ervan uitgaande dat de DNS-software niet gecompromitteerd is).

Onderscheid met TSIG en DNSSEC

Essentieel verschil met de bestaande TSIG-beveiliging voor zone transfers (AXFR) en updates (IXFR) is dat ZONEMD niet het transport maar de integriteit van de zonefile zelf beschermd. Bovendien moet voor TSIG eerst een geheime sleutel uitgewisseld worden tussen de primary en de secondary.

In principe zou je de integriteit van een zonefile ook kunnen verifiëren door alle individuele DNSSEC-handtekeningen af te lopen en te valideren. De originele DNS-records vormen tezamen met de tussenliggende NSEC(3)-records immers een gelinkte keten die de hele name space van de betreffende zone afdekt (denk maar aan zone walking). Maar dat kost veel verwerkingskracht, zeker bij gebruik van een ECDSA-gebaseerd DNSSEC-algoritme. Bovendien omvat DNSSEC toch niet alle records in de zone: non-apex NS-records (delegaties), glue records en NSEC(3)-records voor niet-ondertekende delegaties ontbreken (die laatste alleen als het Opt-Out-bit aan staat). Uitgangspunt voor DNSSEC is dat het de integriteit van DNS-responses beschermd, terwijl ZONEMD dat doet voor complete zonefiles.

ZONEMD en DNSSEC

Het ZONEMD-record zelf (gedefinieerd in RFC 8976) steekt relatief eenvoudig in elkaar: Alle informatie in de zone wordt eerst in een gestandaardiseerde alfanumerieke volgorde gezet, waarna de hashwaarde over het geheel wordt berekend. Deze zogenaamde message digest (een statistisch unieke, digitale samenvatting) wordt gepubliceerd in het ZONEMD-record, tezamen met het serienummer van de zonefile en het gebruikte hashalgoritme (SHA-384 of SHA-512).

Merk op dat de berekening van de ZONEMD-hash en de ondertekening met DNSSEC onderling verweven zijn. Het ondertekeningsproces begint met de opname van een placeholder voor het ZONEMD-record. Pas daarna kun je de zone ondertekenen, waarbij nu ook de juiste NSEC(3)-records rondom de ZONEMD RRset worden gegenereerd. Vervolgens kun je de hashwaarde voor het ZONEMD-record uitrekenen (waarin nu ook de juiste NSEC(3)-records worden meegenomen). De digitale handtekening (in een RRSIG-record) voor de actuele ZONEMD RRset moet dan als laatste worden toegevoegd.

Validatie

Bij de validatie van de ZONEMD-hash aan de ontvangende kant moet eerst de DNSSEC-validatie van het ZONEMD-record uitgevoerd worden. Of DNSSEC wel of niet gebruikt wordt, kun je zien aan de aanwezigheid van een DS-record in de bovenliggende zone (voor de root zone is het DS-record al op een DNSSEC-validerende resolver beschikbaar in de vorm van een trust anchor).

Daarna wordt de hash over de ontvangen zonefile op exact dezelfde wijze uitgerekend als aan de verzendende kant en vergeleken met de hashwaarde in het meegestuurde ZONEMD-record. De zonefile is alleen geldig als de 2 hashwaarden overeenkomen, en alleen dan mag de nieuwe zone door de nameserver ingeladen worden.

Grote zones met veel dynamiek

Het zojuist beschreven proces van sorteren en hashen (aan verzendende zijde) en valideren (ook weer sorteren en hashen, nu aan ontvangende zijde) kost vanzelfsprekend tijd. De root zone bevat zo'n 1.500 topleveldomeinen en verandert niet al te vaak, waarmee de ZONEMD-berekening en -validatie goed te doen is.

Dat ligt heel anders voor grote zones met veel dynamiek. Zo bevat de .nl-zone nu 6,3 miljoen domeinnamen en wordt deze elk half uur ververst. We hebben dat half uur ook echt nodig: De Hardware Security Modules (HSM's) die we in 2021 nieuw hebben aangeschaft waren in principe snel genoeg, maar voor de overstap van DNSSEC-algoritme nummer 8 naar nummer 13 hebben we wel het ondertekenings- en validatieproces moeten optimaliseren. Alleen op die manier konden we de arbeidsintensievere validatie van de meer dan 20 miljoen ECDSA-gebaseerde handtekeningen in de nieuwe .nl-zone binnen die tijd uitvoeren.

ZONEMD lookup

"ZONEMD is voor ons zeker interessant," zegt Stefan Ubbink, DNS-engineer bij SIDN, "maar de omvang en verversingssnelheid van de .nl-zone maken dat we eerst heel goed naar de noodzaak en opbrengsten enerzijds en de nadelen en inspanningen anderzijds moeten kijken. Bovendien hebben we eind vorig jaar het Opt-Out-bit voor de .nl-zone uitgezet, waarmee nu ook alle NSEC(3)-records voor niet-ondertekende delegaties in de zone zijn opgenomen. Met deze uitgebreide bescherming van DNSSEC is een extra beveiliging in de vorm van een ZONEMD-record een stuk minder van belang. Op dit moment zijn er dan ook geen concrete plannen om ZONEMD in de .nl-zone op te nemen. Wel volgen we met belangstelling de ontwikkelingen rondom de root zone."