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 de cliënt met behulp van DNSmasq

  • maandag 26 oktober 2015

Lees hier hoe je in een paar stappen je Debian- of Ubuntu-werkplek DNSSEC-validatie op cliënt-niveau geeft met behulp van Dnsmasq.

Dnsmasq, wie kent het niet?

Dnsmasq is een lichtgewicht, makkelijk te configureren DNS-forwarder, annex DHCP-server die je veel tegenkomt in SOHO-routers en allerhande andere ‘embedded devices’, maar bijvoorbeeld ook in Linux-distributies zoals Ubuntu, waar hij sinds versie 12.04 standaard aan staat.

Sinds versie 2.69 is Dnsmasq in staat om DNSSEC-validatie te doen en dat is een forse stap voorwaarts. De kwaliteit van de code kreeg de afgelopen maanden een flinke oppepper dankzij een financiële bijdrage van het ‘techfund’ van Comcast, de op een na grootste ISP van de V.S. die heel vooruitstrevend is op gebieden als IPv6 en DNSSEC.  

Validatie op de cliënt heeft de toekomst

Validatie op de cliënt is interessant. Lang niet alle ISP’s hebben validatie al aangezet (ondanks dat grote partijen, zoals Google met zijn Public DNS ze al zijn voorgegaan). Maar ook al is de resolver bij jouw ISP een validerende resolver, dan nog is het pad tussen die een resolver en jouw eind-systeem (de stub) kwetsbaar voor Kaminsky-aanvallen. Daarom zou validatie op die cliënt wel eens de toekomst kunnen hebben.

Er bestaan al meerdere initiatieven om DNSSEC-validatie naar het systeem van de eindgebruiker te brengen, zoals bijvoorbeeld DNSSEC-trigger van NLnetLabs, of het leuke –maar niet altijd even praktisch bruikbare- nss-ubdns van Robert Edmonds. De nieuwe DNSSEC-implementatie van Dnsmasq voegt hier zeker wat toe. Want het gaat immers om een stukje software dat al op veel plaatsen gebruikt wordt en dat juist daar DNSSEC-validatie in is ‘gebakken’, biedt perspectieven met betrekking tot het probleem van te weinig DNSSEC-validatie.

Zelf proberen

Helaas wordt de huidige versie van Ubuntu (14.04) uitgeleverd met Dnsmasq versie 2.68 en daar zit DNSSEC-validatie dus nog net niet in. Geen probleem; dit kan betrekkelijk eenvoudig worden opgelost, door gewoon gebruik te maken van de broncode. Hieronder leg ik uit hoe dit op Ubuntu 14.04 werkt. Ik ga er hierbij wel van uit dat je al het nodige weet, met name over source-packages ‘rebuilden’.

Slechts een paar stappen

Haal op de Ubuntu-systeem de source op van de Dnsmasq-pakketten:

apt-get source dnsmasq dnsmasq-utils dnsmasq

En haal vervolgens alles op wat nodig is om die pakketten opnieuw te bouwen:

apt-get build-dep dnsmasq-base dnsmasq-utils dnsmasq

Haal vervolgens de source van Dnsmasq op met:

git clone git://thekelleys.org.uk/dnsmasq.git

(in mijn geval versie 2.71)Volg dan deze stappen:

cd dnsmasq

Bewerk de Makefile en plaats dit: COPTS         = -DHAVE_DNSSEC

debuild -us -uc
cd ..

Installeer het zojuist gemaakte package (ik ga er even vanuit dat je ‘dnsmasq-base’ draaide en die wilt upgraden met ‘the latest & greatest’:

dpkg -i dnsmasq-base_2.70-1_amd64.deb

(rare naam, voor een 2.71 versie – maar zo was het bij mij nou eenmaal...)

Je bent er nu bijna. Dnsmasq zit nogal verweven in de Gnome NetworkManager, dus we moeten nog een stap zetten voor we aan de slag kunnen. Er moeten wat configuratie-opties worden gedefinieerd. Dat kan eenvoudig door een file aan te maken in ‘ /etc/NetworkManager/dnsmasq.d/’, met bijvoorbeeld deze opties:

cache-size=150
dnssec
trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
#log-async
#log-queries

De laatste twee regels gebruik ik alleen om te debuggen. Zorg ervoor dat het trust-anchor overeenkomt met wat er nu in de root-zone staat.

Ok, we zijn zover, laten we gaan testen!

service network-manager restart

Werkt het?

Of je de nieuwe versie draait, kun je simpel testen met een:

dig CH TXT version.bind @localhost

En daarna naar hartenlust spelen met lokale DNSSEC-validatie op de cliënt, bijvoorbeeld:

dig +dnssec +multi www.sidnlabs.nl

Of

dig +adflag +multi servfail.sidnlabs.nl

Die bewust niet valideert.

Controleer ook of het AD-bitje wel/niet is gezet:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19776
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

Als het werkt, is dit misschien het moment om de manpage van Dnsmasq er op na te slaan. Want Dnsmasq is standaard nogal vergevingsgezind, omdat het ook wil blijven werken als gecommuniceerd wordt met een resolver die helemaal geen DNSSEC begrijpt. Maar als jouw resolver wel DNSSEC-records kan doorgeven (ook al zijn ze niet gevalideerd), dan kan je Dnsmasq wat strenger instellen met de optie:

--dnssec-check-unsigned

(oftewel dnssec-check-unsigned toevoegen in het bestandje in /etc/NetworkManager/dnsmasq.d/)

Met validatie op die cliënt is jouw internetverbinding weer een stukje veiliger geworden en profiteer je van DNS-bescherming op domeinnamen zoals paypal.com, vmware.com en 1,7 miljoen .nl domeinnamen.

Kijk rechtsboven op deze pagina of je een groen DNSSEC-slotje ziet. Ook op www.dnssec.nl kun je rechtsboven aan het slotje zien of je wel of niet valideert. En anders is er nog http://dnssectest.sidnlabs.nl om te testen.

Veel plezier en laat gerust je ervaringen weten. Mocht je een bug vinden, dan zal Simon Kelly, de auteur van de software deze vast in dank aanvaarden.