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

DNS-over-HTTPS verovert de browserwereld

"Internetproviders moeten DoH voor hun klanten beschikbaar maken"

Rood digitaal hangslot in een digitale omgeving - Cybersecurityconcept
  • dinsdag 18 mei 2021

DNS-over-HTTPS (DoH) is in een paar jaar tijd behoorlijk populair geworden – zeker als je dat vergelijkt met de enorm langzame adoptie van veel oudere standaarden als DNSSEC en IPv6. Die populariteit heeft DoH te danken aan de toepassing en promotie ervan door grote spelers als Mozilla, Google (Public DNS), Microsoft, Quad9 en Cloudflare (1.1.1.1). DoH is wat ons betreft een prima aanvulling op DNSSEC, maar er zijn ook mensen die terechte zorgen hebben over de datahonger van Big Tech en de gevolgen voor de privacy. Wij geven er de voorkeur aan om DoH als technologie los te zien van die grote ondernemingen, en waarschuwen liever voor de privacy-implicaties bij het gebruik van hun DNS-diensten. Dat betekent dat wij adviseren om DoH wél te gebruiken (als je zelf geen lokale, validerende, recursieve resolver draait), maar dan wel op het niveau van het operating system, en waar mogelijk de DoH-server van je eigen internetprovider in te stellen.

DNS-over-HTTPS

Het DoH-protocol (gestandaardiseerd als RFC 8484) doet precies wat de naam al aangeeft: het bouwt vanaf de client een HTTPS-verbinding op naar de recursieve resolver, waarna de DNS-queries en -responses vervolgens over deze versleutelde verbinding worden getransporteerd. Daarmee lost DoH twee problemen op: ten eerste wordt zo de vertrouwelijkheid van de DNS-uitwisseling beschermd. Daarmee is DoH een complementaire aanvulling op DNSSEC, dat immers alleen de authenticiteit en de integriteit van DNS-records garandeert. Ten tweede beschermt DoH wat heet "The Last Mile" van DNSSEC: het laatste stuk van de DNS-keten tussen de client en de recursieve resolver. Clients hebben traditioneel immers alleen een stub resolver aan boord, die wel DNS-queries naar een recursieve resolver kan sturen maar zelf geen DNSSEC-validatie op de DNS-responses kan uitvoeren. In plaats daarvan vertrouwt de stub resolver op de AD-vlag die door een validerende resolver als onderdeel van de DNS-response naar de client wordt teruggestuurd. Hoewel DoH niet kan voorkomen dat een validerende resolver zelf de DNS-records naar de eindgebruiker vervalst, kan er onderweg naar de client in ieder geval niets met de responses gebeuren.

DoH geen vervanger DNSSEC

Merk op dat DoH desondanks geen vervanger voor DNSSEC is. RFC 8484 richt zich alleen op use cases waarbij DoH wordt ingezet tussen eindgebruikers en caching resolvers, op het niveau van het operating system (door de stub resolver) of op applicatieniveau (door de webbrowser). Die caching resolvers kunnen dan bij een internetprovider staan (als je de standaardinstelling van je modem laat staan) of bij een van de DNS-diensten zoals Google Public DNS, 1.1.1.1 en Quad9 (als je die geselecteerd hebt). Maar zelfs als DoH in de toekomst op alle DNS-verbindingen gebruikt zou worden, blijft DNSSEC nodig, en wel op alle plekken waar een DoH-verbinding termineert. Dat is in de eerste plaats op de client van de eindgebruiker, die (cryptografisch gesproken) immers niet kan vertrouwen op de AD-vlag die door de caching resolver wordt gezet. Wij zijn dan ook voorstander van DNSSEC-validatie op de machine van de eindgebruiker. Op de tweede plaats is dat natuurlijk de cachende resolver zelf, waar validatie altijd zou moeten plaatsvinden voordat records in de vorm van DNS-responses naar eindgebruikers worden gestuurd. Gelukkig gebeurt dat inmiddels steeds vaker [1, 2]. En op de derde plaats bij de autoritatieve nameservers, waar clients erop moeten kunnen vertrouwen dat de daar gepubliceerde gegevens gegarandeerd correct zijn (dat wil in dit geval zeggen: dat deze gegevens ondertekend zijn). Hiervoor geldt dat we dit in Nederland voor de .nl-zone heel goed doen, maar dat er internationaal nog veel te weinig gebeurt.

DNSSEC wordt belangrijker

Dat laatste – DNSSEC-ondertekening op de autoritatieve nameservers, ongeacht het gebruik van DoH – wordt belangrijker naarmate systemen vaker in de cloud worden ondergebracht. 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 ook wij onderzoeken 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. Voor een volledig met DNSSEC ondertekende zone is dat geborgd (ervanuitgaande dat gebruikers ook valideren). Uit efficiency-overwegingen worden de NSEC3-records van niet-ondertekende domeinen in de huidige .nl-zone door ons nu nog niet ondertekend. Dat zou dus eerst moeten gebeuren. Hiervoor zijn nog geen concrete plannen, maar ons idee is om dat te zijner tijd samen te doen met een roll-over naar het ECDSA encryptie-protocol (DNSSEC-algoritme nummer 13).

Zelf resolven en valideren

Resolving – de vertaling van domeinnamen naar IP-adressen – is traditioneel een taak van het operating system. Dat betekent dat je een volwaardige, validerende resolver op je computer moet installeren (in plaats van de stub resolver) om de cryptografische bescherming van DNSSEC volledig door te trekken naar je eigen systeem. Daarvoor kunnen we je de Unbound-software van NLnet Labs van harte aanbevelen. Deze is inmiddels ook de standaard op veel Linux- en BSD-distributies. Bovendien ondersteunt Unbound vanaf versie 1.12 ook downstream DoH – dat wil zeggen: voor gebruikers van Unbound als (centrale) caching resolver. Hetzelfde geldt voor BIND named vanaf versie 9.17.10. PowerDNS ondersteunt DoH als onderdeel van de dnsdist load balancer. Ondersteuning voor upstream DoH – dat wil zeggen: van recursieve resolvers naar autoritatieve nameservers – is zoals gezegd geen onderdeel van RFC 8484. Daarvoor zouden de autoritatieve nameservers eerst DoH moeten aanbieden, maar dat heeft grote implicaties voor de beheerders van grote topleveldomeinen. Waar het leeuwendeel van het DNS-verkeer nu over het efficiënte UDP-protocol loopt, zou voor DoH dan voor elke bevragende resolver een TCP-verbinding aangeboden moeten worden. Als je weet dat SIDN op dit moment voor de .nl-zone grofweg 3 miljard queries per dag, van 1,5 miljoen verschillende resolvers verwerkt, dan begrijp je dat de ondersteuning van DoH veel meer resources zou vereisen. Wat dat betreft verwachten wij meer van DNS-over-QUIC, onderdeel van HTTP/3, waarbij HTTPS over UDP wordt getransporteerd.

DoH in Firefox

Hoewel DoH dus prima door de stub resolver – en dus op het niveau van het operating system – uitgevoerd kan worden, gebeurt het nu vooral op applicatieniveau. DoH kwam breed in de aandacht toen Mozilla in 2019 aankondigde zijn Firefox browser voor Amerikaanse gebruikers standaard naar Cloudflare's DoH-servers te willen laten verwijzen. Het idee was om deze instelling de default te maken [1, 2], behalve voor computers die een kinderveilige/gefilterde of lokale DNS-dienst gebruiken, of wanneer een 'split horizon'-configuratie gedetecteerd wordt. Het mag geen verwondering wekken dat een deel van de internetgemeenschap over Mozilla heen viel, waaronder de Britse access providers en Bert Hubert (de oprichter van PowerDNS). Hun grootste bezwaren zijn de onmogelijkheid om te filteren (verplicht in de UK) of door te verwijzen, de centralisatie van de DNS-dienst, de privacyconsequenties, en de mogelijkheden tot censuur. Hubert betoogt zelfs dat DoH niets toevoegt aan de beveiliging, en vanwege de centralisatie naar Amerikaanse DNS-dienstverleners een achteruitgang is op privacygebied. De Electronic Frontier Foundation (EFF) erkent deze problemen, maar spreekt zich juist uit vóór DoH. De centralisatie willen zij tegengaan door access providers op te roepen zelf DoH-diensten voor hun klanten beschikbaar te maken. Op die manier heb je wel de bescherming van DoH, terwijl de decentrale recursie/validatie-infrastructuur blijft bestaan.

DoH in Chrome

Google kondigde in 2020 aan DoH (wat zij 'Secure DNS' noemen) in hun Chrome-browser te gaan ondersteunen. Daarbij kunnen gebruikers naast Google's eigen 'Public DNS'-dienst uit nog vijf andere aanbieders kiezen. Weet Chrome dat je huidige DNS-dienstverlener ook DoH aanbiedt, dan schakelt hij automatisch om naar dit nieuwe protocol. [1, 2, 3] Inmiddels heeft ook Mozilla naar aanleiding van bovengenoemde discussies een tweede DoH-dienstverlener (NextDNS) aan zijn browser toegevoegd.

Marco Davids
Marco Davids, research engineer bij SIDN Labs

Marco Davids, research engineer bij SIDN Labs, zit er op een vergelijkbare manier in als de EFF: "Ik wil DoH als technologie loskoppelen van Big Tech en hun belangen. DoH is door de technische mensen bij Mozilla bedacht, en die beweren dat er goede afspraken zijn gemaakt met Cloudflare over hun positie als Trusted Recursive Resolver (TRR) [1, 2, 3, 4]. Desondanks is het goed dat er in de Firefox browser inmiddels meer keuze is, voor wie het toch niet vertrouwt. Google's aanpak in Chrome spreekt me ook aan. Van Google wordt gezegd dat ze interesse hebben in de DNS-gegevens. Dat mag zo zijn, maar dat associeer ik niet uitsluitend met DoH. Immers speelt dit ook bij hun al langer bestaande traditionele DNS-dienst."

DoH bij internetproviders

"Je kunt het aanbieden van meerdere keuzen zien als een succesvolle interventie van de internetgemeenschap," aldus Davids. "Misschien was het wel de verkeerde kant op gegaan als mensen zoals Bert Hubert niet voor nieuwe inzichten bij Mozilla hadden gezorgd. Als je kijkt hoe Google DoH nu heeft geïmplementeerd, dan is dat een mooie oplossing. Maar de missie van Bert en de EFF is nog niet voorbij: internetproviders moeten zorgen dat DoH voor hun klanten beschikbaar komt." Op dit moment ondersteunen, voor zo ver bij ons bekend, alleen Freedom, XS4ALL en ZeelandNet/Deltanet DoH voor hun klanten. Maar ook ons eigen SIDN Labs biedt een (publiek beschikbare) experimentele DoH-resolver aan (deze dienst is eind december 2021 gestopt). Deze twee lijsten helpen je om (internationale) publieke DoH-aanbieders te vinden:

Als je DoH aan zet op het niveau van het operating system – waar wij vinden dat dit thuishoort – dan is er geen reden om DoH voor de browser apart aan te zetten. Sterker nog: dan moet je DoH in je browser juist uitzetten, om te voorkomen dat deze DNS-verkeer lekt naar andere plaatsen dan je voor het operating system in zijn geheel hebt ingesteld, of dat DNSSEC-validatie (typisch door Unbound) of filtering (bijvoorbeeld door Pi-hole) wordt omzeild.