Inleiding tot DNS

Het Domain Name System is het "telefoonboek van het internet". DNS vertaalt domeinnamen naar IP-adressen zodat browsers en andere diensten internetbronnen kunnen laden, via een gedecentraliseerd netwerk van servers.

Wat is DNS?

Wanneer je een website bezoekt, wordt een numeriek adres teruggezonden. Wanneer je bijvoorbeeld privacyguides.orgbezoekt, wordt het adres 192.98.54.105 teruggezonden.

DNS bestaat al sinds de begindagen van het internet. DNS-verzoeken aan en van DNS-servers zijn niet over het algemeen versleuteld. In een residentiële omgeving krijgt een klant servers van de ISP via DHCP.

Onversleutelde DNS-verzoeken kunnen onderweg gemakkelijk worden gesurveilleerd en gewijzigd. In sommige delen van de wereld worden ISP's opgedragen primitieve DNS-filters te gebruiken. Wanneer je het IP-adres opvraagt van een domein dat is geblokkeerd, antwoordt de server mogelijk niet of met een ander IP-adres. Aangezien het DNS-protocol niet versleuteld is, kan de ISP (of om het even welke netwerkexploitant) DPI gebruiken om verzoeken te controleren. ISP's kunnen ook verzoeken blokkeren op basis van gemeenschappelijke kenmerken, ongeacht welke DNS-server wordt gebruikt.

Hieronder bespreken we en geven we een tutorial om te bewijzen wat een externe waarnemer kan zien met gewone onversleutelde DNS en versleutelde DNS.

Onversleutelde DNS

Using tshark (part of the Wireshark project) we can monitor and record internet packet flow. Dit commando registreert pakketten die aan de gespecificeerde regels voldoen:
```
tshark -w /tmp/dns.pcap udp poort 53 en host 1.1.1.1 of host 8.8.8.8
```
We kunnen dan dig (Linux, MacOS etc) of nslookup (Windows) gebruiken om de DNS lookup naar beide servers te sturen. Software zoals webbrowsers doen deze lookups automatisch, tenzij zij geconfigureerd zijn om gecodeerde DNS te gebruiken.
Linux, macOSWindows
dig +noall +answer privacyguides.org @1.1.1.1 dig +noall +answer privacyguides.org @8.8.8.8
nslookup privacyguides.org 1.1.1.1 nslookup privacyguides.org 8.8.8.8

Next, we want to analyse the results:

Wiresharktshark

wireshark -r /tmp/dns.pcap

tshark -r /tmp/dns.pcap

Als je het bovenstaande Wireshark-commando uitvoert, toont het bovenste deelvenster de "frames", en het onderste deelvenster toont alle gegevens over het geselecteerde frame. Oplossingen voor bedrijfsfiltering en -monitoring (zoals die welke door overheden worden aangeschaft) kunnen dit proces automatisch uitvoeren, zonder menselijke tussenkomst, en kunnen deze frames samenvoegen tot statistische gegevens die nuttig zijn voor de netwerkwaarnemer.

No.	Time	Source	Destination	Protocol	Length	Info
1	0.000000	192.0.2.1	1.1.1.1	DNS	104	Standard query 0x58ba A privacyguides.org OPT
2	0.293395	1.1.1.1	192.0.2.1	DNS	108	Standard query response 0x58ba A privacyguides.org A 198.98.54.105 OPT
3	1.682109	192.0.2.1	8.8.8.8	DNS	104	Standard query 0xf1a9 A privacyguides.org OPT
4	2.154698	8.8.8.8	192.0.2.1	DNS	108	Standard query response 0xf1a9 A privacyguides.org A 198.98.54.105 OPT

Een waarnemer kan elk van deze pakketten wijzigen.

Wat is "versleutelde DNS"?

Encrypted DNS can refer to one of a number of protocols, the most common ones being DNSCrypt, DNS over TLS, and DNS over HTTPS.

DNSCrypt

DNSCrypt was een van de eerste methoden om DNS-query's te versleutelen. DNSCrypt werkt op poort 443 en werkt met zowel de TCP- als de UDP-transportprotocollen. DNSCrypt is nooit ingediend bij de Internet Engineering Task Force (IETF) en is ook nooit door het Request for Comments (RFC) proces gegaan, dus is het buiten een paar implementaties nog niet op grote schaal gebruikt. Als gevolg daarvan is het grotendeels vervangen door het meer populaire DNS over HTTPS.

DNS over TLS (DoT)

DNS over TLS is een andere methode voor het versleutelen van DNS-communicatie die is gedefinieerd in RFC 7858. Support was first implemented in Android 9, iOS 14, and on Linux in systemd-resolved in version 237. Preference in the industry has been moving away from DoT to DoH in recent years, as DoT is a complex protocol and has varying compliance to the RFC across the implementations that exist. DoT werkt ook op een speciale poort 853 die gemakkelijk kan worden geblokkeerd door restrictieve firewalls.

DNS over HTTPS (DoH)

DNS over HTTPS, as defined in RFC 8484, packages queries in the HTTP/2 protocol and provides security with HTTPS. Ondersteuning werd voor het eerst toegevoegd in webbrowsers zoals Firefox 60 en Chrome 83.

Native implementatie van DoH dook op in iOS 14, macOS 11, Microsoft Windows, en Android 13 (het zal echter niet standaard worden ingeschakeld ). Algemene Linux desktop ondersteuning wacht op de systemd implementatie dus het installeren van third-party software is nog steeds vereist.

Ondersteuning voor besturingssystemen

Android

Android 9 en hoger ondersteunen DNS over TLS. De instellingen kunnen worden gevonden in: Instellingen → Netwerk & internet → Privé-DNS.

Apple apparaten

De nieuwste versies van iOS, iPadOS, tvOS en macOS ondersteunen zowel DoT als DoH. Beide protocollen worden ondersteund via configuratieprofielen of via de DNS Settings API.

Na installatie van een configuratieprofiel of een app die gebruik maakt van de DNS Settings API, kan de DNS-configuratie worden geselecteerd. Als een VPN actief is, zal de resolutie binnen de VPN-tunnel de DNS-instellingen van het VPN gebruiken en niet je systeembrede instellingen.

Apple biedt geen native interface voor het maken van versleutelde DNS-profielen. Secure DNS profile creator is een onofficiële tool voor het maken van je eigen versleutelde DNS-profielen, echter worden deze niet ondertekend. Ondertekende profielen hebben de voorkeur; ondertekening valideert de oorsprong van een profiel en helpt de integriteit van de profielen te waarborgen. Een groen "Geverifieerd" label wordt gegeven aan ondertekende configuratieprofielen. Voor meer informatie over het ondertekenen van codes, zie Over het ondertekenen van codes.

Linux

systemd-resolved, which many Linux distributions use to do their DNS lookups, doesn't yet support DoH. If you want to use DoH, you'll need to install a proxy like dnscrypt-proxy and configure it to take all the DNS queries from your system resolver and forward them over HTTPS.

Wat kan een buitenstaander zien?

In dit voorbeeld zullen we vastleggen wat er gebeurt als we een DoH-verzoek doen:

Start eerst tshark:

tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1"

Ten tweede, doe een aanvraag met curl:

curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org

Na het verzoek te hebben gedaan, kunnen we de packet capture stoppen met CTRL + C.
Analyseer de resultaten in Wireshark:
```
wireshark -r /tmp/dns_doh.pcap
```

We can see the connection establishment and TLS handshake that occurs with any encrypted connection. Als we kijken naar de "toepassings gegevens" pakketten die volgen, bevat geen van hen het domein dat we hebben aangevraagd of het IP adres dat wordt teruggestuurd.

Waarom zou ik geen versleutelde DNS gebruiken?

Op plaatsen waar internet wordt gefilterd (of gecensureerd), kan het bezoeken van verboden bronnen eigen gevolgen hebben waarmee je rekening moet houden in jouw bedreigingsmodel. Wij niet suggereren het gebruik van gecodeerde DNS voor dit doel. Use Tor or a VPN instead. Als je een VPN gebruikt, moet je de DNS-servers van jouw VPN gebruiken. Wanneer je een VPN gebruikt, vertrouwt je hen al jouw netwerkactiviteiten toe.

Wanneer we een DNS lookup doen, is dat meestal omdat we toegang willen tot een bron. Hieronder bespreken we enkele van de methoden die jouw surf-activiteiten kunnen onthullen, zelfs wanneer je versleutelde DNS gebruikt:

IP-adres

De eenvoudigste manier om de surfactiviteit vast te stellen, is te kijken naar de IP-adressen waartoe jouw apparaten toegang hebben. Als de waarnemer bijvoorbeeld weet dat privacyguides.org op 198.98.54.105staat, en jouw apparaat gegevens opvraagt van 198.98.54.105, is de kans groot dat je Privacy Guides bezoekt.

Deze methode is alleen nuttig wanneer het IP-adres toebehoort aan een server die slechts enkele websites host. Het is ook niet erg nuttig als de site wordt gehost op een gedeeld platform (bijv. Github Pages, Cloudflare Pages, Netlify, WordPress, Blogger, enz.). Het is ook niet erg nuttig als de server gehost wordt achter een reverse proxy, wat heel gebruikelijk is op het moderne Internet.

Server Naam Aanwijzing (SNA)

Server Name Indication wordt meestal gebruikt wanneer een IP-adres veel websites host. Dit kan een dienst als Cloudflare zijn, of een andere Denial-of-service-aanval bescherming.

Begin opnieuw te vangen met tshark. We hebben een filter toegevoegd met ons IP adres zodat je niet veel pakketten opvangt:
```
tshark -w /tmp/pg.pcap poort 443 en host 198.98.54.105
```
Dan gaan we naar https://privacyguides.org.
Na het bezoek aan de website, willen we de packet capture stoppen met CTRL + C.
Vervolgens willen we de resultaten analyseren:
```
wireshark -r /tmp/pg.pcap
```
We zullen de verbinding tot stand zien komen, gevolgd door de TLS handshake voor de Privacy Gidsen website. Rond frame 5. zie je een "Client Hello".

Vouw de driehoek ▸ uit naast elk veld:

▸ Transport Layer Security
  ▸ TLSv1.3 Record Layer: Handshake Protocol: Client Hello
    ▸ Handshake Protocol: Client Hello
      ▸ Uitbreiding: server_name (len=22)
        ▸ Uitbreiding servernaam-aanduiding

Wij kunnen de SNI-waarde zien die aangeeft welke website wij bezoeken. Het tshark commando kan je de waarde rechtstreeks geven voor alle pakketten die een SNI waarde bevatten:
```
tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
```

Dit betekent dat zelfs als we "Encrypted DNS" servers gebruiken, het domein waarschijnlijk zal worden onthuld via SNI. The TLS v1.3 protocol brings with it Encrypted Client Hello, which prevents this kind of leak.

Governments, in particular China and Russia, have either already started blocking it or expressed a desire to do so. Onlangs is Rusland begonnen met het blokkeren van buitenlandse websites die gebruik maken van de HTTP/3 norm. Dit komt doordat het QUIC protocol dat deel uitmaakt van HTTP/3 vereist dat ClientHello ook gecodeerd wordt.

Protocol voor onlinecertificaatstatus (PVOC/OCSP)

Een andere manier waarop jouw browser jouw surfactiviteiten kan onthullen is met het Online Certificate Status Protocol. Wanneer je een HTTPS-website bezoekt, kan de browser controleren of het -certificaat van de website is ingetrokken. Dit gebeurt over het algemeen via het HTTP-protocol, wat betekent dat het niet versleuteld is.

Het OCSP-verzoek bevat het certificaat "serienummer", dat uniek is. Het wordt naar de "OCSP responder" gezonden om de status ervan te controleren.

We kunnen simuleren wat een browser zou doen met het openssl commando.

Haal het server certificaat op en gebruik sed om alleen het belangrijke deel te bewaren en schrijf het uit naar een bestand:

openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 |
    sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert

Haal het tussenliggende certificaat op. Certificaatautoriteiten (CA) ondertekenen een certificaat gewoonlijk niet rechtstreeks; zij gebruiken een zogeheten "intermediair" certificaat.
```
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 |
    sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert
```
Het eerste certificaat in pg_and_intermediate.cert is eigenlijk het servercertificaat uit stap 1. We kunnen sed opnieuw gebruiken om te wissen tot de eerste instantie van END:
```
sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \
    /tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
```
Haal de OCSP responder voor het server certificaat op:
```
openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
```
Ons certificaat toont de Lets Encrypt certificaat responder. Als we alle details van het certificaat willen zien, kunnen we gebruik maken van:
```
openssl x509 -text -noout -in /tmp/pg_server.cert
```

Start de pakketopname:

tshark -w /tmp/pg_ocsp.pcap -f "tcp port http"

Doe het OCSP-verzoek:

openssl ocsp -issuer /tmp/intermediate_chain.cert \
             -cert /tmp/pg_server.cert \
             -text \
             -url http://r3.o.lencr.org

Open de opname:

wireshark -r /tmp/pg_ocsp.pcap

Er komen twee pakketten met het "OCSP"-protocol: een "Request" en een "Response". Voor de "Aanvraag" kunnen we het "serienummer" zien door het driehoekje ▸ naast elk veld uit te vouwen:

▸ Online Certificate Status Protocol
  ▸ tbsRequest
    ▸ requestList: 1 item
      ▸ Verzoek
        ▸ reqCert
          serialNumber

Voor de "Response" kunnen we ook het "serienummer" zien:

▸ Online Certificate Status Protocol
  ▸ responseBytes
    ▸ BasicOCSPResponse
      ▸ tbsResponseData
        ▸ antwoorden: 1 item
          ▸ SingleResponse
            ▸ certID
              serialNumber

Of gebruik tshark om de pakketten te filteren op het Serienummer:

tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber

Als de netwerkwaarnemer het publieke certificaat heeft, dat publiekelijk beschikbaar is, kunnen zij het serienummer met dat certificaat vergelijken en op basis daarvan de site bepalen die je bezoekt. Het proces kan worden geautomatiseerd en IP-adressen kunnen worden gekoppeld aan serienummers. Het is ook mogelijk om Certificate Transparency logs te controleren op het serienummer.

Moet ik versleutelde DNS gebruiken?

We hebben dit stroomschema gemaakt om te beschrijven wanneer u versleutelde DNS zou moeten gebruiken:

graph TB
    Begin[Begin] --> anoniem{Probeert<br> anoniem te zijn?}
    anoniem--> | Ja | tor(Use Tor)
    anoniem --> | Nee | censuur{Censuur<br> vermijden?}
    censuur --> | Ja | vpnOrTor(Gebruik<br> VPN of Tor)
    censuur --> | Nee | privacy{Wil je privacy<br> van ISP?}
    privacy --> | Jaa | vpnOrTor
    privacy --> | Nee | onaangenaam{ISP wijzigt<br> zoekopdrachten?}
    onaangenaam --> | Ja | encryptedDNS(Gebruik<br> versleutelde DNS<br> met derde partij)
    onaangenaam --> | Nee | ispDNS{Doet ISP ondersteunen<br> versleutelde DNS?}
    ispDNS --> | Ja | useISP(Gebruik<br> versleutelde DNS<br> met ISP)
    ispDNS --> | Nee | nothing(Doe niets)

Versleutelde DNS met een derde partij mag alleen worden gebruikt om redirects en basis-DNS-blokkering van te omzeilen als je er zeker van kunt zijn dat er geen gevolgen zijn of als je geïnteresseerd bent in een provider die een aantal rudimentaire filters uitvoert.

Lijst van aanbevolen DNS-servers

Wat is DNSSEC?

DNSSEC (Domain Name System Security Extensions) is een functie van DNS waarmee reacties op domeinnaamzoekopdrachten worden geverifieerd. Het biedt geen bescherming van de privacy voor die lookups, maar voorkomt dat aanvallers de antwoorden op DNS-verzoeken manipuleren of vergiftigen.

Met andere woorden, DNSSEC ondertekent gegevens digitaal om de geldigheid ervan te helpen garanderen. Om een veilige lookup te garanderen, vindt de ondertekening plaats op elk niveau in het DNS lookup-proces. Als gevolg daarvan kunnen alle antwoorden van DNS worden vertrouwd.

Het DNSSEC-ondertekeningsproces is vergelijkbaar met iemand die een juridisch document met een pen ondertekent; die persoon ondertekent met een unieke handtekening die niemand anders kan maken, en een gerechtsdeskundige kan naar die handtekening kijken en verifiëren dat het document door die persoon is ondertekend. Deze digitale handtekeningen garanderen dat er niet met de gegevens is geknoeid.

DNSSEC implementeert een hiërarchisch digitaal ondertekeningsbeleid over alle lagen van DNS. Bijvoorbeeld, in het geval van een privacyguides.org lookup, zou een root DNS-server een sleutel ondertekenen voor de .org nameserver, en de .org nameserver zou dan een sleutel ondertekenen voor privacyguides.org's gezaghebbende nameserver.

Adapted from DNS Security Extensions (DNSSEC) overview by Google and DNSSEC: An Introduction by Cloudflare, both licensed under CC BY 4.0.

Wat is QNAME-minimalisatie?

A QNAME is a "qualified name", for example discuss.privacyguides.net. In the past, when resolving a domain name your DNS resolver would ask every server in the chain to provide any information it has about your full query. In this example below, your request to find the IP address for discuss.privacyguides.net gets asked of every DNS server provider:

Server	Question Asked	Response
Root server	What's the IP of discuss.privacyguides.net?	I don't know, ask .net's server...
.net's server	What's the IP of discuss.privacyguides.net?	I don't know, ask Privacy Guides' server...
Privacy Guides' server	What's the IP of discuss.privacyguides.net?	5.161.195.190!

With "QNAME minimization," your DNS resolver now only asks for just enough information to find the next server in the chain. In this example, the root server is only asked for enough information to find the appropriate nameserver for the .net TLD, and so on, without ever knowing the full domain you're trying to visit:

Server	Question Asked	Response
Root server	What's the nameserver for .net?	Provides .net's server
.net's server	What's the nameserver for privacyguides.net?	Provides Privacy Guides' server
Privacy Guides' server	What's the nameserver for discuss.privacyguides.net?	This server!
Privacy Guides' server	What's the IP of discuss.privacyguides.net?	5.161.195.190

While this process can be slightly more inefficient, in this example neither the central root nameservers nor the TLD's nameservers ever receive information about your full query, thus reducing the amount of information being transmitted about your browsing habits. Een verdere technische beschrijving is te vinden in RFC 7816.

Wat is EDNS Client Subnet (ECS)?

Het EDNS Client Subnet is een methode voor een recursieve DNS-oplosser om een subnetwerk te specificeren voor de host of client die de DNS-query uitvoert.

Het is bedoeld om de levering van gegevens te "versnellen" door de client een antwoord te geven dat toebehoort aan een server die zich dicht bij hem bevindt, zoals een content delivery network, die vaak worden gebruikt bij videostreaming en het serveren van JavaScript-webapps.

This feature does come at a privacy cost, as it tells the DNS server some information about the client's location, generally your IP network. For example, if your IP address is 198.51.100.32 the DNS provider might share 198.51.100.0/24 with the authoritative server. Some DNS providers anonymize this data by providing another IP address which is approximately near your location.

If you have dig installed you can test whether your DNS provider gives EDNS information out to DNS nameservers with the following command:

dig +nocmd -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats

Note that this command will contact Google for the test, and return your IP as well as EDNS client subnet information. If you want to test another DNS resolver you can specify their IP, to test 9.9.9.11 for example:

dig +nocmd @9.9.9.11 -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats

If the results include a second edns0-client-subnet TXT record (like shown below), then your DNS server is passing along EDNS information. The IP or network shown after is the precise information which was shared with Google by your DNS provider.

o-o.myaddr.l.google.com. 60 IN TXT "198.51.100.32"
o-o.myaddr.l.google.com. 60 IN TXT "edns0-client-subnet 198.51.100.0/24"
;; Query time: 64 msec
;; SERVER: 9.9.9.11#53(9.9.9.11)
;; WHEN: Wed Mar 13 10:23:08 CDT 2024
;; MSG SIZE  rcvd: 130

U bekijkt de Nederlands versie van Privacy Handleidingen, vertaald door ons fantastische taalteam op Crowdin. Als u een fout, of onvertaalde secties op deze pagina ziet, overweeg dan alstublieft om te helpen! Bezoek Crowdin

You're viewing the Dutch copy of Privacy Guides, translated by our fantastic language team on Crowdin. If you notice an error, or see any untranslated sections on this page, please consider helping out!