Anoniem surfen met DNS-encryptie voor Windows, macOS en Linux

Het maakt niet uit waar je op internet allemaal op bezoek gaat: bijna altijd verstuurt je systeem daarbij metadata in de vorm van DNS-informatie. Daarmee kunnen ook anderen achterhalen welke websites je op internet allemaal bekijkt. De Internet Engineering Task Force heeft manieren gespecificeerd die dat kunnen voorkomen zodat anoniem surfen mogelijk is. We laten zien hoe je daar lekkages bij Linux, macOS en Windows mee kunt dichten.

Zonder contacten met een Domain Name Server (DNS) is een internetdienst amper nog te gebruiken. De meeste DNS-requests verlopen echter in leesbare tekst. Dat was lange tijd geen probleem. Nadat berichtendiensten en reclamebureaus DNS-requests echter gingen gebruiken als makkelijk toegankelijke databronnen voor het maken van gebruikersprofielen, ontwikkelden wereldwijd meerdere werkgroepen protocollen die dat moet tegengaan door het DNS-verkeer te versleutelen. De bekendste daarvan van zijn DNS-over-TLS en DNS-over-HTTPS, oftewel DoT en DoH.

Inmiddels zijn de eerste implementaties beschikbaar. Maar daarmee wordt dan alleen het browserverkeer gedicht. Je wilt echter de complete DNS-communicatie van een pc versleutelen. En om de DNS-requests zo veel mogelijk te spreiden om het maken van profielen te bemoeilijken, wil je bijvoorbeeld meer dan één DNS-resolver gebruiken en zeker niet die van Google (8.8.8.8).

Hiervoor zijn zowel DoT- als DoH-clientprogramma’s geschikt. Beide protocollen verhogen de beveiliging en de privésfeer van DNS-requests door ze te versleutelen en de servers te authenticeren. Dat is niet alleen voor anoniem surfen handig. Als bijeffect krijg je bij een onbetrouwbaar netwerk – bijvoorbeeld bij een mobiel netwerk of bij een ongunstige wifiverbinding – meteen een hogere betrouwbaarheid van de name-resolution.

Mobiele apparaten zoals notebooks, tablets en smartphones profiteren dus nog eens extra van DoT en DoH. Dat komt doordat het versleutelde DNS-verkeer het Transmission Control Protocol (TCP) gebruikt. Zenders kunnen met TCP data­verkeerfouten onderweg herkennen en compenseren door die data opnieuw te sturen. De DNS-resolutie duurt dan langer omdat de latentie toeneemt, maar is wel betrouwbaarder. Het DNS-verkeer gebruikt normaal gesproken het User Datagram Protocol (UDP), dat geen fout­herkenning en correctiemogelijk­heden bevat. In principe kan een gewone DNS-client ook TCP gebruiken, maar dat gebeurt alleen in uitzonderingssituaties (bijvoorbeeld als het DNS-antwoord te groot is). Bij DoT en DoH is TCP daarentegen standaard.

DoT- en DoH-programma’s zijn in essentie DNS-proxy’s. In theorie zijn ze dus ook geschikt om het uitgaande DNS-verkeer te censureren. Dat kan bijvoorbeeld met de populaire Pi-hole voor de kleine Raspberry Pi. Pi-hole kan bijvoorbeeld kletsgrage smart-tv’s een individuele muilkorf geven en daarmee je privacy bewaken. Bij de hier genoemde DoT- en DoH-clients zijn eigenlijk alleen DNSCrypt en Unbound geschikt voor het aansturen van uitgaand DNS-verkeer.

De nieuwe Android-versie met de naam Pie gebruikt standaard al DNS-over-TLS. Bij iOS kun je dat toevoegen met de app DNSCloak. Die versleutelt het DNS-verkeer met het DoH- of met het propriëtaire DNSCrypt-protocol (zie de link onderaan dit artikel). In dit artikel leggen we uit hoe je de huidige DoT- en DoH-clients op Windows, macOS en Linux kunt configureren.

In de volgende voorbeelden gebruiken we om het overzichtelijk te houden slechts maar een paar DNS-resolvers. Maar als je de handleidingen goed wilt volgen, moet je zo veel mogelijk resolvers op je systeem configureren. Op de website van het project DNS Privacy staan omvangrijke lijsten.

We hebben een aantal andere links en configuratiebestanden verzameld die bij toepassen van dit artikel van pas komen. Bovendien is het zinvol om de request-snelheid van tijd tot tijd te meten en langzame DNS-resolvers in elk geval tijdelijk uit te commentariëren. Voor request-metingen kun je de tool dig gebruiken (bijvoorbeeld dig ct.nl). Het programma laat in het veld ‘Query time’ zien hoe lang het duurt tot een request beantwoord is (bijvoorbeeld 22 ms). In de toekomst zouden DoT- en DoH-clients de beste DNS-resolvers zelf kunnen opzoeken en dynamisch configureren – afhankelijk van de selectiecriteria die je bij de instellingen gekozen hebt. De Internet Engineering Task Force werkt aan dergelijke specificaties.

Totdat dergelijke methoden als RFC gestandaardiseerd zijn en in de softwareproducten geïmplementeerd zijn, moet je de DNS-resolvers van je keuze handmatig configureren.

De DoT- en DoH-programma’s kun je vrij simpel op alle computers installeren waarop de DNS-communicatie versleuteld moet gaan worden. Ze nemen de DNS-requests in ontvangst die eigenlijk voor een DNS-resolver bedoeld zijn (proxy). Die worden zoals gebruikelijk verwacht op poort 53, en wel op het loopback-adres van de computer waarop ze zijn ingesteld. Dat zijn 127.0.0.1 (IPv4) en ::1 (IPv6).

Daarom kan op een computer daar altijd maar één programma actief voor zijn. Om een ander programma te testen, moet je het op dat moment draaiende programma tijdens het uitproberen even deactiveren of verwijderen.

DoH heeft het voordeel dat het dezelfde doelpoort als HTTPS-webdiensten gebruikt, namelijk poort 443. Die poort staat bij de meeste firewalls open, met name bij openbare wifi-hotspots. DoT gebruikt normaal gesproken daaren­tegen de eigen poort 853, die bij de meeste firewalls dichtstaat. Je kunt voor DoT ook wel een eigen poort gebruiken, maar alleen als de server die aanbiedt. De meeste aanbieders van DoT-resolvers configureren die echter alleen voor poort 853.

De deelnemers aan het project DNSCrypt ontwikkelen al sinds jaren software voor een versleutelde communicatie tussen een DNS-client en de resolver. Het DNSCrypt-protocol is wel openbaar gedocumenteerd, maar is geen internetstandaard geworden en is daardoor ook nog niet zo populair. De in Go geschreven versie 2 van de DNSCrypt-software is niet alleen voor het eigen DNSCrypt-protocol bedoeld, maar ook voor DoH.

Simple-DNSCrypt is een implementatie voor Windows. Je hebt daar minstens Windows 7 SP1 en het .NET-framework 4.6.1 voor nodig. We konden de software zonder problemen bij de laatste versie van Windows 10 gebruiken.

Na het installeren werkt de software op de achtergrond als Windows-service. De gewenste DNSCrypt- en DoH-servers kun je instellen met een grafisch configuratiebestand, dat zich op de taakbalk bevindt.

Met de standaardinstellingen gebruikt het programma alle hem bekende servers, die de DNS-reply’s via DNSSEC valideren en naar eigen zeggen geen gebruikersactiviteiten loggen. Als je voor de internettoegang IPv6 gebruikt, moet je bij de grafische interface het onderdrukken van IPv6-DNS-reply’s uitschakelen bij de instelling ‘Block IPv6’.

Om ervoor te zorgen dat Windows DNS-requests naar Simple-DNSCrypt stuurt, moet je in de TCP/IP-configuratie voor de DNS-resolver de IP-adressen 127.0.0.1 (IPv4) en ::1 (IPv6) invoeren. Vervolgens kun je bij Simple-DNSCrypt op het tabblad ‘Query Log’ volgen hoe de software de DNS-requests verwerkt.

Als je er zeker van wilt zijn dat de DNS-requests niet meer onversleuteld via UDP of TCP verstuurd worden, installeer je Wireshark en log je daar wat verkeer mee terwijl je verschillende websites oproept. Activeer vervolgens het displayfilter DNS, dan zou je in de weergave geen DNS-pakketten meer te zien moeten krijgen.

Als alternatief voor Stubby en Simple-DNSCrypt kun je de veelzijdige DNS-­resolver Unbound gebruiken. Unbound is sinds versie 1.7.1 geschikt voor DoT. We adviseren om de op dit moment actuele versie te gebruiken. Vanaf 1.8.2 kan Unbound overweg met DoT, ook als het als Windows-service op de achtergrond draait, en kan het servercertificaten controleren met de Windows Certificate Store.

Een installer van Unbound voor Windows kun je online vinden. Na het installeren schakel je DoT in bij het bestand C:Program Filesunboundservice.conf. Unbound moet de DNS-requests verdelen over meerdere DoT-servers. Als je geen IPv6 voor je internettoegang gebruikt, moet je de servers met IPv6-adressen uitcommentariëren. Bij veel aansluitingen is IPv6 echter geactiveerd. Dan ziet een voorbeeldconfiguratie er zo uit:

Om Unbound te gebruiken, zet je bij de TCP-configuratie van het Windows-systeem de DNS-resolver in het veld voor de DNS-server – dat zijn de loopback-adressen 127.0.0.1 (IPv4) en ::1 (IPv6).

Stubby heeft tot nu toe alleen bij macOS een grafische interface gekregen. Daarmee is het programma als systeemservice in te stellen en ook te testen. De grafische interface bevindt zich nog in een heel vroeg ontwikkelstadium. De ontwikkelaars zijn dan ook dankbaar voor alle foutmeldingen en verbetervoorstellen die ze ontvangen.

Je kunt Stubby als alternatief ook via de Terminal bedienen. De software wordt dan via de pakketmanager Homebrew of MacPorts geïnstalleerd. Als je nog geen pakketmanager gebruikt, is dit het moment om er daar een van te installeren – maar niet beide, want ze zitten elkaar in de weg in dat geval. Als Homebrew eenmaal geïnstalleerd is, kun je Stubby op de volgende manier op de Mac krijgen:

brew install stubby sudo brew services start stubby

Het tweede commando stelt Stubby in als systeemservice en start het programma op de achtergrond. Met MacPorts installeer je Stubby op de volgende manier:

sudo port install stubby sudo port load stubby

Om Stubby te gebruiken, stel je bij de netwerkconfiguratie op het tabblad DNS de beide loopback-adressen in, dus 127.0.0.1 (IPv4) en ::1 (IPv6).

De DNS-resolver van de huidige Linux-systemen kan sinds versie 239 (Fedora 29, Ubuntu 18.10) met TLS versleutelde DNS-requests zelf versturen. Het proces systemd-resolved verwacht DNS-requests op het loopback-adres 127.0.0.53 op poort 53. Linux-systemen met die Systemd-versie sturen de DNS-requests standaard naar dat adres, ook als in /etc/resolv andere DNS-resolvers staan.

In de standaardconfiguratie staan DoT en de DNSSEC-validering uitgeschakeld. Je kunt die op twee plekken activeren. Het bestand /etc/systemd/resolved.conf bevat de globale configuratie van Systemd-resolver. Zo ziet een voorbeeld van /etc/systemd/resolved.conf eruit:

DNS=9.9.9.9 1.1.1.1 DNSSEC=true DNSOverTLS=opportunistic Cache=yes

Daarmee worden twee DNS-resolvers geconfigureerd, namelijk een van Quad9 (9.9.9.9) en een van Cloudflare (1.1.1.1). Bovendien wordt de DNSSEC-validering ingeschakeld en wordt DoT op de modus ‘opportunistic’ gezet. Systemd-resolved gebruikt dan TLS waar mogelijk, maar stelt dat niet als dwingende voorwaarde. Als een TLS-verbinding niet lukt, stuurt de software de DNS-requests op de klassieke manier via UDP of TCP. Dat is de enige optie die je in de huidige versie kunt instellen

Dat is een nadeel, want als aanvallers poort 853 blokkeren, kunnen ze de Systemd-client dwingen om DNS-­requests onversleuteld te verzenden (een zogeheten downgrade-attack). Om dat te verhinderen, kun je tools als Stubby gebruiken. Die werken indien gewenst ook in de strict-modus en versturen DNS-requests dan alleen via een TLS-tunnel. Als dat niet kan, dan werkt de DNS-resolving niet. Browsers zullen dan foutmeldingen geven als ‘server niet gevonden’.

De globale configuratie van Systemd-resolver wordt doorgaans in de network-units van de nieuwe dienst Systemd-networkd overschreven. In plaats daarvan stelt bij de huidige Linux-versies Systemd-networkd de configuratie van de netwerkinterfaces in en stelt bijvoorbeeld een IPv6-SLAAC, DHCPv6- en DHCPv4-client beschikbaar.

Daardoor wordt echter ook DoT en de DNSSEC-validering uitgeschakeld. Daarom moet je de network-unit voor elke netwerkinterface opnieuw aanmaken en aanpassen. De network-units staan in /etc/systemd/network/. Als daar nog geen unit-bestanden in staan, dan heeft de computer een dynamische netwerkconfiguratie en staan de network-units in de directory /run/systemd/network. Als dat het geval is, dan kopieer je de network-units daar vandaan naar de directory /etc/systemd/network en kun je ze daar bewerken.

Zo ziet een voorbeeld voor de network-unit van de ethernetinterface enp0s3 eruit bij een installatie van ubuntu 18.10:

DNSSEC en DoT kun je activeren bij het deel

en in de globale configuratie. In het voorbeeld zijn voor die netwerkinterface twee DNS-resolvers opgenomen, namelijk 1.1.1.1 en 9.9.9.9. Met Systemd-networkd kun je echter elke netwerkinterface een andere DNS-configuratie geven.

Dat kun je gebruiken bij netwerken met een split-horizon-DNS. Dat is bijvoorbeeld het geval bij bedrijfsnotebooks, die tegelijkertijd toegang hebben via mobiel internet, maar ook via het wifi van het bedrijfsnetwerk. Bij de traditionele besturingssystemen geldt voor een dergelijke computer slechts één DNS-configuratie, wat betekent dat je oftewel de bedrijfs­resources (Windows Active Directory) of de internet-DNS bereikt, maar niet allebei. Linux kan met het nieuwe schema verschillende netwerken en hun afzonderlijke configuraties tegelijkertijd gebruiken.

Met de regel UseDNS=false negeert Systemd-resolved de via DHCP verkregen DNS-resolvers en gebruikt die dan niet voor het omzetten van domein­namen. Dat is in de meeste gevallen ook gewenst omdat die in de regel geen DoT aanbieden. Maar bij een notebook die bijvoorbeeld via wifi contact maakt met een hotspot, moet je die regel verwijderen omdat anders het aanmelden bij de captive-portal van de hotspot mislukt – daarvoor is immers de via DHCP meegedeelde DNS-resolver nodig.

Veranderingen aan de configuratie worden pas werkzaam na een herstart van het systeem. Met het commando systemd-resolve –status kun je de belangrijkste instellingen van de actieve configuratie laten weergeven:

Met de hiervoor genoemde oplossingen kun je het DNS-verkeer versleutelen. Dat maakt beter anoniem surfen mogelijk en vergroot de betrouwbaarheid van de name-resolution. We hebben andere opties, zoals Stubby voor Windows, DNSCrypt-Proxy en Unbound voor macOS en DNSCrypt-Proxy 2 voor Linux ook bekeken.

DoT en DoH zijn nog jonge protocollen, en de hier genoemde programma’s ontwikkelen zich snel. Bovendien komen er nog nieuwe bij. Het loont daarom ook om de links in dit artikel regelmatig eens te bezoeken om te kijken of er nog nieuwe ontwikkelingen zijn op dit gebied. Naast de hier genoemde DoT- en DoH-programma’s zijn er daarnaast veel andere implementaties, bijvoorbeeld in Go, Rust, Java en nog veel meer.

(Carsten Strotman, c’t magazine)