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

DNSSEC-validatie op een Infoblox appliance

DNS-operators die hun eigen systemen opzetten vertrouwen daarvoor meestal op Linux of een BSD-variant in combinatie met BIND of PowerDNS. Heb je niet genoeg aan de DNSSEC-functionaliteit die BIND named op dit moment biedt, dan kun je named (of een andere autoritatieve name-server) ook combineren met OpenDNSSEC, een complete oplossing voor geautomatiseerd sleutelbeheer en ondertekening.

In grote commerciële omgevingen kiest men vaker voor appliances, en dan meestal die van Infoblox. Zo worden deze gebruikt door bijna alle Nederlandse banken, maar bijvoorbeeld ook door de Universiteit Leiden.

Wie al Infloblox appliances in huis heeft en zijn domeinen wil ondertekenen of zijn (caching) resolvers wil laten valideren, hoeft daarvoor in principe maar heel weinig te doen. Voor ondertekening is het slechts een kwestie van aanklikken; validatie staat standaard al aan. Wel blijft het belangrijk om de default-instellingen voor DNSSEC te controleren. Bovendien vereist DNSSEC een goed gesynchroniseerde systeemtijd.

Hoe dit artikel te lezen

In dit artikel behandelen we de DNSSEC-configuratie voor een validerende resolver op Infoblox. De configuratie van een Infoblox appliance als autoritatieve name-server lees je in een ander artikel.

We hebben bij het schrijven van dit artikel gebruik gemaakt van een OVA image met Infoblox NIOS versie 8.2.2, draaiend op VMware ESXi versie 6.5.0.

We bespreken 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 Infoblox NIOS 8.2 Administrator Guide.

Infoblox DDI appliances

Met de Trinzic productlijn levert Infoblox een reeks van zowel fysieke als virtuele appliances voor DNS/DHCP/IPAM (DDI). Het binnenwerk van de systemen is gebaseerd op Fedora Linux en BIND.

Bij het schrijven van dit artikel hebben we gebruik gemaakt van een IB-V825 virtuele machine (VM) voorzien van NIOS versie 8.2.2. Een dergelijke virtuele evaluatie-versie is ook beschikbaar via de website van Infoblox.

Infoblox-klanten met een support-overeenkomst raden we ten zeerste aan hun NIOS software op te waarderen naar de laatste versie alvorens met DNSSEC aan de slag te gaan.

Systeemtijd

Om te beginnen vraagt DNSSEC om een goed gesynchroniseerde systeemtijd. Waar het traditionele DNS-protocol alleen relatieve tijdsaanduidingen gebruikt (TTL's), introduceert DNSSEC absolute tijdsaanduidingen. De digitale handtekeningen (in de RRSIG records) hebben immers een absolute geldigheidsperiode.

Voor het automatisch synchroniseren van de systeemtijden van de appliances moeten we de NTP service configureren. Deze levert een hiërarchische infrastructuur om systeemklokken (op UTC) UTC) over Internet gelijk te schakelen (via UDP/123). Voor de configuratie van de ingebouwde NTP-server van Infoblox verwijzen we naar het hands-on artikel over DNSSEC-ondertekening op een Infoblox appliance (sectie 2), waarin deze in detail wordt besproken.

DNSSEC-instellingen

Als de tijdsynchronisatie voor elkaar is, moeten we de default-instellingen voor DNSSEC aanpassen/controleren. Om te beginnen verifiëren we dat de EDNS0-optie aan staat. Deze biedt een uitbreiding op het oude DNS-protocol, zodat nu ook de grotere DNSSEC-pakketten en bijbehorende vlaggen en velden ondersteund worden.

Daarvoor gaan we naar de 'Data Management' -> 'DNS' tab en selecteren in de Toolbar de 'Grid DNS Properties'. Klik op 'Toggle Advanced Mode', waarmee een heleboel extra tabs beschikbaar komen, en open nu de 'General'/'Advanced' tab. Daar vinden we halverwege de optie 'Disable EDNS0'; zorg dat deze uit staat.

DNSSEC-validatie

Voor de DNSSEC-specifieke instellingen klikken we in hetzelfde window naar de 'Basic'/'DNSSEC' tab. De ondersteuning voor DNSSEC in het algemeen ('Enable DNSSEC') en validatie in het bijzonder ('Enable DNSSEC validation') staan beide standaard aan.

Met deze instelling wordt DNSSEC-validatie in één keer voor het hele grid aangezet. Wil je validatie aan (of uit) zetten op een specifiek Grid Member (typisch een caching resolver), dan ga je eerst naar de 'Data Management' -> 'DNS' -> 'Members' tab. Daar selecteer je de betreffende server en klikt vervolgens op het 'Edit' icoon. In het 'Member DNS Properties' window selecteer je dan de 'DNSSEC'/'Basic' tab, waar je de grid-brede instellingen kunt overrulen.

Verlopen handtekeningen en negatieve trust anchors

In deze schermen zie je ook de optie 'Accept expired signatures' staan. Deze optie zet je alleen in hele specifieke gevallen aan, namelijk als je resolver bepaalde DNS records blokkeert omdat de beheerder van het domein in kwestie vergeten is om de handtekeningen te vernieuwen. Omdat het verversen van die RRSIG records vanwege de hoge frequentie vrijwel altijd automatisch gebeurt, betekent dit meestal dat er "iets omgevallen" is. Je laat de validerende resolver dan alleen tijdelijk de verlopen handtekeningen accepteren, zolang de achterliggende problemen nog niet verholpen zijn.

Waar de 'Accept expired signatures' optie alle verlopen handtekeningen (tijdelijk) accepteert, kun je de 'Negative Trust Anchors' gebruiken om specifieke zones te whitelisten, eventueel ook gedurende een langere periode. Dit is typisch de plek waar je zones neerzet die DNSSEC-problemen hebben — bijvoorbeeld in hun configuratie — maar wel gebruikt worden in je organisatie, bijvoorbeeld voor een online (cloud) applicatie. Zones opgenomen in deze lijst worden helemaal niet gecontroleerd.

Trust anchors

In de lijst met 'Trust Anchors' neem je de domeinen op (met hun publieke sleutels) die je per definitie vertrouwt. Voordat de root zone ondertekend was werden top-level domeinen (TLD's) waarvoor DNSSEC wel al werkte op deze manier expliciet in validerende resolvers vastgelegd. Maar nu de root zone en de meeste TLD's daaronder van DNSSEC zijn voorzien, komt het verankeren van dit soort "islands of trust" eigenlijk niet meer voor. Omdat de Infoblox appliance het RFC 5011 protocol niet ondersteunt, moeten beheerders van validerende resolvers zich ervan vergewissen dat de nieuwe publieke root KSK-sleutel inderdaad als trust anchor op hun systemen is geïnstalleerd en geactiveerd. Is dat niet het geval, dan moet die toevoeging handmatig (out-of-band) gebeuren.

Handmatige installatie KSK-2017

De handmatige installatie van het nieuwe trust anchor begint met het binnenhalen van de publieke KSK-sleutels van de website van IANA. Maar voordat je de nieuwe publieke sleutel als trust anchor in je resolver installeert moet je eerst zeker weten dat dit inderdaad de juiste (authentieke) sleutel is. In het artikel 'Installatie trust anchor voor nieuwe root KSK' (onder de sectie 'Handmatige installatie') vind je een uitgebreide beschrijving voor het op een veilige manier binnenhalen en verifiëren van de actuele root sleutels.

Heb je de nieuwe KSK-2017 sleutel (met keyid 20326) eenmaal binnengehaald en voldoende geverifieerd, dan kun je deze als extra trust anchor in je Infoblox grid installeren. Daarvoor ga je naar de 'Data Management' -> 'DNS' tab en selecteer je in de Toolbar de 'Grid DNS Properties'. Onderaan in de 'DNSSEC'/'Basic' tab kun de KSK-2017 sleutel toevoegen. Nauwkeuriger bezien gaat het hier om de hash van de publieke sleutel (vergelijkbaar met de informatie in een DS record), dus let op dat je hier de juiste cryptografische instellingen gebruikt: KSK-2017 wordt gepubliceerd als een message digest (hash) van type nummer 2 (SHA-256) op een publieke sleutel op basis van DNSSEC-algoritme nummer 8 (RSA/SHA-256).

Indien de actuele publieke root KSK-sleutel nog niet op je systeem geïnstalleerd is, raden wij je sterk aan om het KSK-2017 trust anchor gelijk te installeren als je toch met de configuratie van je appliance(s) bezig bent. Infoblox Nederland gaf eerder aan zijn klanten hierover actief te informeren.

Afsluitend

Voor de configuratie van DNSSEC-validatie op een Infoblox appliance hoef je op de laatste versies van NIOS in principe niet meer te doen dan de default-instellingen te controleren. Een upgrade naar de laatste versie — gratis voor klanten met een support-overeenkomst — is dan ook zeer aan te raden alvorens met DNSSEC aan de slag te gaan. Wel vraagt DNSSEC om goed gesynchroniseerde systeemtijden. Daarvoor is het van belang eerst de NTP service te configureren.

Omdat de Infoblox software het RFC 5011 protocol niet ondersteunt zal je de KSK-2017 root sleutel handmatig als trust anchor moeten installeren als deze nog niet op je systeem beschikbaar is. De reden dat we niet licht aan deze tekortkoming voorbij willen gaan is dat het hier om een DNS appliance gaat. Appliances zijn immers bedoeld om met zo min mogelijk configuratie-inspanningen zo snel mogelijk ingezet te worden. Infoblox is in deze markt een grote speler, en veel belangrijke partijen vertrouwen op hun product.

Degenen die achterlopen met hun DNSSEC-implementaties — met name de banken en andere grote organisaties — zijn relatief vaak Infoblox-gebruikers. Een achterlopende DNSSEC-implementatie helpt hen niet om die achterstand in te halen.