DNSSEC, DoT en DoH: welkome aanvullingen op DNS

Het Domain Name System (DNS) vertaalt begrijpelijke domeinnamen naar IP-adressen en zorgt ervoor dat jij niet elke keer een IP-adres moet intypen wanneer je een website bezoekt. Hoe belangrijk dit systeem ook is voor de werking van het internet, het brengt ook gevaren met zich mee indien het misbruikt wordt. Sinds het einde van de jaren negentig zijn diverse partijen daarom al aan de slag gegaan met het creëren van veiligheidsmaatregelen rondom DNS. In dit artikel kijken we naar een populaire kwetsbaarheid en bespreken we enkele maatregelen waarmee jij of je bezoekers veiliger (jouw) websites kunnen bezoeken.

Manipulatie van de DNS-cache

Ter illustratie van de mogelijke gevaren van DNS nemen we DNS cache poisoning als voorbeeld. Hierbij wordt de cache van een DNS resolver gemanipuleerd en wordt het mogelijk om een internetgebruiker nietsvermoedend naar een valse website te sturen met diefstal van data als wachtwoorden en creditcardgegevens als gevolg.

Hoe werkt cache poisoning in het kort?

1. De aanvaller stuurt eerst een verzoek voor het IP-adres van een bepaald subdomein (123.bank.com) dat niet bestaat van bijvoorbeeld een bank naar een DNS resolver.
2. De resolver heeft logischerwijs geen antwoord en verzoekt uiteindelijk een authoritative nameserver van de aan te vallen bank om het juiste antwoord op het IP-adresverzoek te geven. 
3. Voordat deze onderliggende nameserver antwoord kan geven, stuurt de aanvaller richting de resolver een grote hoeveelheid nepantwoorden die van een legitieme server van de bank lijken af te komen. Dit allemaal nog voordat de server van de bank het juiste antwoord (er is geen IP-adres dat doorverwijst naar dat domein) heeft kunnen geven.
4. Naast het IP-adres voor het subdomein 123.bank.com (A record) omvat het nepantwoord ook het IP-adres van de neppe nameserver (NS record) waarheen opvolgende verzoeken voor het domein bank.com gestuurd mogen worden.
5. De resolver accepteert het nepantwoord en slaat zowel het A record als het NS record op in het cachegeheugen. 
6. Nu de vervalste gegevens zich in het cachegeheugen bevinden is het voor de aanvaller tijd voor de volgende stap: het lokken van de gebruiker via bijvoorbeeld een phisingmail naar een neppagina van de bank.
7. De computer van een nietsvermoedende gebruiker verzoekt daarna de resolver voor het IP-adres van de bank en krijgt het vervalste foute IP-adres terug uit het cachegeheugen.
8. De gebruiker komt vervolgens uit op de website van de aanvaller die er precies uitziet zoals de pagina van de bank en vult niets vermoedend zijn of haar gegevens in.

 

Quick fix

Er zijn meerdere manieren bedacht om de bovenstaande aanval enigszins te bemoeilijken. Elk DNS-verzoek van een resolver richting andere servers gaat bijvoorbeeld gepaard met een specifiek 16 bit-ID-nummer. Een nepantwoord van een aanvaller moet over hetzelfde ID beschikken om een aanval te doen slagen. Eerst werden per DNS-verzoek opvolgende ID-nummers gebruikt waardoor het raden van een juist ID redelijk snel verliep. Dankzij de introductie van willekeurige ID-nummers duurt dit in theorie langer, maar zoals uit de bovenstaande video blijkt, in de praktijk verreweg niet lang genoeg door de verjaardagenparadox.

Naast het willekeurig kiezen van een ID-nummer, is het ook mogelijk om een willekeurige sourcepoort te kiezen waarlangs het DNS-verzoek verstuurd wordt. Dit maakt het mogelijk een 16 bit-ID op te schalen naar een 32 bit-ID, wat het raden van het juiste ID-nummer aanzienlijk verlengt.

Een derde fix, ook wel DNS 0x20 genoemd, is gebaseerd op het feit dat DNS in beginsel niet hoofdlettergevoelig is. Door DNS-verzoeken te versturen met willekeurige hoofdletters in de domeinnaam en te vereisen dat het antwoord van een authoritative nameserver precies dezelfde hoofdletters bevat, wordt het een aanvaller nog moeilijker gemaakt om een nepantwoord succesvol te versturen. Deze fix heeft het nooit gehaald tot een officiële standaard, maar wordt in de praktijk regelmatig gebruikt door DNS-servers.

Zoals degene die cache poisoning wereldwijd bekend heeft gemaakt, Dan Kaminsky, het zelf zegt: met quick fixes doe je het probleem niet verdwijnen. DNS is enkel minder kwetsbaar geworden. Een langdurige oplossing is gewenst.

 

DNSSEC zorgt voor veilige antwoorden

Die oplossing is er gekomen in de vorm van DNSSEC. Dit is een uitbreiding op het huidige DNS waarbij er validatie op meerdere niveaus plaatsvindt aan de hand van publieke en private beveiligingssleutels. Deze validatie is mogelijk doordat in 2010 voor het hoogste niveau binnen DNS, het rootdomein, de eerste beveiligingssleutel gesigneerd is. Daardoor kan een ‘chain of trust’ opgebouwd worden tussen meerdere authoratative nameservers en weet jij dat het antwoord op jouw DNS-verzoek 100% legitiem is. Dat gaat als volgt.

Stel je wil www.transip.nl bezoeken. Om het juiste IP-adres op te halen volgt een schakel van veiligheidschecks op elk niveau binnen het DNS. De zoektocht begint bij een DNS-resolver, die een trust anchor voor het rootniveau bevat. Dat betekent dat de resolver de antwoorden die daarvandaan komen sowieso kan valideren. Als de resolver vervolgens vraagt waar .nl staat, krijgt hij van de root zowel de NS-als DS-records terug. Daarmee kan de resolver direct de DNSKEY’s valideren van de beheerder van het onderliggende .nl-domein. Dit gebeurt bij SIDN omdat de DNSKEY’s voor .nl-domeinen daar zijn ondergebracht. Vervolgens herhaalt het proces zich op een lager niveau. Er wordt door de resolver gevraagd waar de server verantwoordelijk voor transip.nl staat en deze krijgt direct de NS- en de DS-records terug voor het transip.nl-domein.

Dit werkt zo voor alle niveaus en op deze manier wordt een chain of trust gebouwd waarin alle onderdelen van de schakel veilig zijn. Daarmee blijft de authenticiteit en de integriteit van het antwoord gewaarborgd en zal het juiste IP-adres behorend tot een gezochte domeinnaam in het cachegeheugen van een DNS-resolver worden opgeslagen.

Backwards compatible en een basis voor meer

Een groot voordeel van DNSSEC is dat het backwards compatible is. Mocht een domein nog geen DNSSEC gebruiken, dan valt het systeem terug naar traditionele DNS en wordt alsnog het antwoord op het DNS-verzoek gegeven. Dit blijft natuurlijk een veiligheidsrisico, maar het zorgt er in ieder geval voor dat het internet blijft werken zoals verwacht en dat er geleidelijk aan stappen worden gemaakt om de veiligheid van DNS-servers te verbeteren.

Een leuke bijkomstigheid is dat DNSSEC de mogelijkheid biedt aan andere beveiligingsstandaarden om DNSSEC als onderliggende beveiligingslaag te gebruiken. Denk bijvoorbeeld aan DANE (beveiligde verbindingen) die deze methode inzet als bouwblok voor de eigen beveiligingslaag. 

The last mile

DNSSEC speelt een belangrijk onderdeel in het fixen van de betrouwbaarheid van een DNS-antwoord dat een resolver terugkrijgt. Wat vaak over het hoofd wordt gezien, is dat dit antwoord nog terug moet naar de (browser)client die het verzocht heeft. Zolang deze client zelf geen gebruikmaakt van DNSSEC, is ‘the last mile’ van de resolver richting de client in theorie onbetrouwbaar doordat het vatbaar is voor een man-in-the-middle-aanval. Ook al verwacht je een (geverifieerd) DNS-antwoord van een resolver, wie garandeert er dat dit antwoord echt van de resolver afkomstig is?

Het juist instellen van DNSSEC op je eigen systeem voorkomt dit probleem aangezien je pas dan kan zeggen dat het antwoord van A tot Z en terug volledig betrouwbaar is. Houd wel in het achterhoofd dat dit nog helemaal niks doet qua privacy; je bent er alleen zeker van dat er niet gesleuteld is aan het antwoord op je DNS-verzoek. Een internetserviceprovider zou nog steeds kunnen inzien welke website je hebt verzocht.

Aangezien de meerderheid van de mensen op hun eigen systeem geen DNSSEC hebben ingesteld en privacy niet gewaarborgd is, zijn er in de afgelopen jaren meerdere oplossingen voorgesteld. Twee populaire opties hebben te maken met het versleutelen van DNS-verkeer richting een resolver via een beveiligde verbinding. DNS over TLS (DoT) transporteert DNS-verkeer over een TLS-tunnel op poort 853. DNS over HTTPS (DoH) transporteert het DNS-verkeer samen met regulier webverkeer over een beveiligde HTTPS-verbinding op poort 443 richting een betrouwbare DoH resolver (met hard-coded certificaat).

Beide opties dienen als aanvulling op DNSSEC maar gebruiken andere middelen, wat tot de nodige voor- en nadelen leidt. Zo is DoT geen goede kandidaat om een externe DNS-resolver te bereiken indien je op voorhand weet dat poort 853 geblokkeerd is op een netwerk, vaak het geval bij hotel-, onderwijs- en bedrijfsnetwerken. Aan de andere kant heeft DoH ook zijn nadelen. Een veelgehoord argument is dat er momenteel alleen grote bedrijven zoals Cloudflare DoH resolvers ter beschikking stellen aan het grote publiek, wat tot centralisatie van het DNS-ecosysteem leidt. Vandaar ook het verzoek aan ISP’s om zelf DoH resolvers in te stellen.

Zelf aan de slag?

Hoe je het ook wendt of keert: DNSSEC, DoT en DoH zijn een stap in de goede richting om DNS een stuk veiliger te maken en overheden, browser-vendors en andere internetorganisaties ontvangen het met open armen. Nederland is zelfs koploper in de implementatie van DNSSEC. Ook de implementatie van DoH gaat rap nu Mozilla en Google druk bezig zijn om de techniek in hun browsers mogelijk te maken.

Zolang je geen eigen DNS-server onderhoudt, zal jouw domeinaanbieder DNSSEC moeten instellen voor je domeinnaam. Zelf DNSSEC instellen is dus niet vereist. Wil je weten of op jouw domeinnaam DNSSEC actief is? Doe dan de check op internet.nl. Je ziet dan meteen of jouw domein aan deze beveiligingsstandaard voldoet en bent er zo zeker van dat alles vanaf jouw kant van de DNS-keten goed staat ingesteld.

Let op: DNSSEC wordt door je provider ingesteld voor je domeinnaam. Je provider heeft geen invloed op het instellen van DNSSEC voor the last mile zoals hierboven besproken. Daar zijn internetgebruikers zelf verantwoordelijk voor.

Voor DoH zal je ook weinig moeten instellen aangezien dit binnenkort wordt ingebakken in Firefox en Chrome. Mocht je geen voorkeur hebben voor de DoH resolvers waar deze browsers gebruik van maken, dan heb je nog de optie om van DoH resolver te wisselen en eens te experimenten met een Nederlands alternatief als DoH via PowerDNS.

Hoe kijk jij aan tegen deze nieuwe technieken en denk je dat het een welkome aanvulling is op DNS? Laat het ons weten in de comments hieronder.