Introduction aux DNS

Le système de nom de domaine est "l'annuaire de l'internet". Le DNS traduit les noms de domaine en adresses IP afin que les navigateurs et autres services puissent charger les ressources de l'internet, grâce à un réseau décentralisé de serveurs.

Qu'est-ce que le DNS ?

Lorsque vous visitez un site web, une adresse numérique est renvoyée. Par exemple, lorsque vous visitez privacyguides.org, l'adresse 192.98.54.105 est renvoyée.

Le DNS existe depuis les premiers jours de l'Internet. Les demandes DNS faites à destination et en provenance des serveurs DNS sont généralement non chiffrées. Dans un environnement résidentiel, un client se voit attribuer des serveurs par le FAI via DHCP.

Les demandes DNS non chiffrées peuvent être facilement surveillées et modifiées en transit. Dans certaines régions du monde, les fournisseurs d'accès à Internet reçoivent l'ordre de procéder à un filtrage DNS primitif. Lorsque vous demandez l'adresse IP d'un domaine bloqué, le serveur peut ne pas répondre ou répondre avec une adresse IP différente. Le protocole DNS n'étant pas chiffré, le FAI (ou tout opérateur de réseau) peut utiliser DPI pour surveiller les demandes. Les FAI peuvent également bloquer des requêtes sur la base de caractéristiques communes, quel que soit le serveur DNS utilisé.

Ci-dessous, nous discutons et fournissons un tutoriel pour prouver ce qu'un observateur extérieur peut voir en utilisant un DNS normal non chiffré et un DNS chiffré.

DNS non chiffré

En utilisant tshark (qui fait partie du projet Wireshark ), nous pouvons surveiller et enregistrer le flux de paquets Internet. Cette commande enregistre les paquets qui répondent aux règles spécifiées :
```
tshark -w /tmp/dns.pcap udp port 53 and host 1.1.1.1 or host 8.8.8.8
```
Nous pouvons ensuite utiliser dig (Linux, MacOS, etc.) ou nslookup (Windows) pour envoyer la recherche DNS aux deux serveurs. Les logiciels tels que les navigateurs web effectuent ces recherches automatiquement, à moins qu'ils ne soient configurés pour utiliser un DNS chiffré.
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
Ensuite, nous voulons analyser les résultats :
Wiresharktshark
wireshark -r /tmp/dns.pcap
tshark -r /tmp/dns.pcap

Si vous exécutez la commande Wireshark ci-dessus, le volet supérieur affiche les "trames", et le volet inférieur affiche toutes les données relatives à la trame sélectionnée. Les solutions de filtrage et de surveillance d'entreprise (telles que celles achetées par les gouvernements) peuvent effectuer ce processus automatiquement, sans interaction humaine, et peuvent agréger ces trames pour produire des données statistiques utiles à l'observateur du réseau.

N°	Temps	Source	Destination	Protocole	Longueur	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

Un observateur pourrait modifier n'importe lequel de ces paquets.

Qu'est-ce qu'un "DNS chiffré" ?

Les DNS cryptés peuvent se référer à un certain nombre de protocoles, les plus courants étant DNSCrypt, DNS sur TLS, et DNS sur HTTPS.

DNSCrypt

DNSCrypt était l'une des premières méthodes de chiffrement des requêtes DNS. DNSCrypt opère sur le port 443 et fonctionne avec les protocoles de transport TCP ou UDP. DNSCrypt n'a jamais été soumis à l'IETF (Internet Engineering Task Force) et n'est pas passé par le processus de demande de commentaires (RFC) . Il n'a donc pas été largement utilisé en dehors de quelques implémentations . En conséquence, il a été largement remplacé par le plus populaire DNS sur HTTPS.

DNS sur TLS (DoT)

DNS sur TLS est une autre méthode de chiffrement des communications DNS qui est définie dans RFC 7858. La prise en charge a été mise en œuvre pour la première fois dans Android 9, iOS 14 et sous Linux dans systemd-resolved dans la version 237. Ces dernières années, l'industrie a délaissé DoT au profit de DoH, car DoT est un protocole complexe dont la conformité au RFC varie d'une implémentation à l'autre. Le DoT fonctionne également sur un port dédié 853 qui peut être facilement bloqué par des pare-feu restrictifs.

DNS sur HTTPS (DoH)

DNS sur HTTPSLe DNS over HTTPS, tel que défini dans la RFC 8484, intègre les requêtes dans le protocole HTTP/2 et assure la sécurité avec HTTPS. La prise en charge a d'abord été ajoutée dans les navigateurs web tels que Firefox 60 et Chrome 83.

L'implémentation native de DoH est apparue dans iOS 14, macOS 11, Microsoft Windows et Android 13 (cependant, elle ne sera pas activée par défaut). Sous Linux la prise en charge sera assurée par l'implémentation dans systemd donc l'installation de logiciels tiers est encore nécessaire.

Prise en charge native des systèmes d'exploitation

Android

Android 9 et supérieur prennent en charge DNS via TLS. Les paramètres peuvent être trouvés dans : Paramètres → Réseau & Internet → DNS Privé.

Appareils Apple

Les dernières versions d'iOS, iPadOS, tvOS et macOS prennent en charge à la fois DoT et DoH. Les deux protocoles sont pris en charge nativement par l'intermédiaire des profils de configuration ou par l'intermédiaire de l'API de Paramètres DNS.

Après l'installation d'un profil de configuration ou d'une application qui utilise l'API des Paramètres DNS, la configuration DNS peut être sélectionnée. Si un VPN est actif, la résolution au sein du tunnel VPN utilisera les paramètres DNS du VPN et non les paramètres de votre système.

Apple ne fournit pas d'interface native pour la création de profils DNS chiffrés. Le créateur de profil DNS Sécurisé est un outil non officiel permettant de créer vos propres profils DNS chiffrés, mais ils ne seront pas signés. Les profils signés sont préférables ; la signature valide l'origine d'un profil et contribue à garantir l'intégrité des profils. Un label vert "Vérifié" est attribué aux profils de configuration signés. Pour plus d'informations sur la signature de code, voir A propos de la signature de code.

Linux

systemd-resolved, que de nombreuses distributions Linux utilisent pour effectuer leurs recherches DNS, ne prend pas encore en charge DoH. Si vous souhaitez utiliser le DNS-over-HTTPS, vous devez installer un proxy tel que dnscrypt-proxy et le configurer pour qu'il prenne toutes les requêtes DNS de votre résolveur système et les transmette via HTTPS.

Que peut voir un tiers ?

Dans cet exemple, nous allons enregistrer ce qui se passe lorsque nous faisons une requête DoH :

Tout d'abord, lancez tshark:

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

Deuxièmement, faites une requête avec curl:

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

Après avoir fait la demande, nous pouvons arrêter la capture de paquets avec CTRL + C.
Analysez les résultats dans Wireshark :
```
wireshark -r /tmp/dns_doh.pcap
```

Nous pouvons voir l'établissement de la connexion et la poignée de main TLS qui se produit avec toute connexion chiffrée. Lorsque l'on regarde les paquets de "données d'application" qui suivent, aucun d'entre eux ne contient le domaine que nous avons demandé ou l'adresse IP renvoyée.

Pourquoi ne devrais-je pas utiliser un DNS chiffré ?

Dans les endroits où il existe un filtrage (ou une censure) de l'Internet, la visite de ressources interdites peut avoir ses propres conséquences que vous devez prendre en compte dans votre modèle de menace. Nous ne suggérons pas l'utilisation de DNS chiffrés à cette fin. Utilisez plutôt Tor ou un VPN. Si vous utilisez un VPN, vous devez utiliser les serveurs DNS de votre VPN. En utilisant un VPN, vous lui confiez déjà toute votre activité réseau.

Lorsque nous effectuons une recherche DNS, c'est généralement parce que nous voulons accéder à une ressource. Nous examinerons ci-dessous certaines des méthodes susceptibles de divulguer vos activités de navigation, même lorsque vous utilisez un DNS chiffré :

Adresse IP

Le moyen le plus simple de déterminer l'activité de navigation est de regarder les adresses IP auxquelles vos appareils accèdent. Par exemple, si l'observateur sait que privacyguides.org est à 198.98.54.105, et que votre appareil demande des données à 198.98.54.105, il y a de fortes chances que vous visitiez Privacy Guides.

Cette méthode n'est utile que lorsque l'adresse IP appartient à un serveur qui n'héberge que quelques sites web. Elle n'est pas non plus très utile si le site est hébergé sur une plateforme partagée (par exemple, Github Pages, Cloudflare Pages, Netlify, WordPress, Blogger, etc.). Il n'est pas non plus très utile si le serveur est hébergé derrière un proxy inverse, ce qui est très courant actuellement sur Internet.

Server Name Indication (SNI)

La Server Name Indication (indication du nom du serveur) est généralement utilisée lorsqu'une adresse IP héberge de nombreux sites web. Il peut s'agir d'un service comme Cloudflare, ou d'une autre protection contre les attaques par déni de service.

Recommencez à capturer avec tshark. Nous avons ajouté un filtre avec notre adresse IP pour que vous ne capturiez pas beaucoup de paquets :
```
tshark -w /tmp/pg.pcap port 443 et hôte 198.98.54.105
```
Ensuite, nous visitons https://privacyguides.org.
Après avoir visité le site web, nous voulons arrêter la capture de paquets avec CTRL + C.
Ensuite, nous voulons analyser les résultats :
```
wireshark -r /tmp/pg.pcap
```
Nous verrons l'établissement de la connexion, suivi du TLS handshake pour le site web Privacy Guides. Au niveau de l'image 5, vous verrez un "Client Hello".

Développez le triangle ▸ à côté de chaque champ :

▸ Transport Layer Security
  ▸ TLSv1.3 Record Layer : Handshake Protocol : Client Hello
    ▸ Handshake Protocol : Client Hello
      ▸ Extension : server_name (len=22)
        ▸ Server Name Indication extension

Nous pouvons voir la valeur SNI qui révèle le site web que nous visitons. La commande tshark peut vous donner directement la valeur pour tous les paquets contenant une valeur SNI :
```
tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
```

Cela signifie que même si nous utilisons des serveurs "DNS chiffrés", le domaine sera probablement divulgué par le SNI. Le protocole TLS v1.3 intègre le protocole Encrypted Client Hello, qui empêche ce type de fuite.

Les gouvernements, en particulier la Chine et la Russie, ont déjà commencé à le bloquer ou ont exprimé le souhait de le faire. Récemment, la Russie a commencé à bloquer les sites web étrangers qui utilisent le standard HTTP/3. En effet, le protocole QUIC qui fait partie de HTTP/3 exige que ClientHello soit également chiffré.

Online Certificate Status Protocol (OCSP)

Une autre façon dont votre navigateur peut divulguer vos activités de navigation est avec l'Online Certificate Status Protocol (protocole de vérification de certificat en ligne). Lors de la visite d'un site Web HTTPS, le navigateur peut vérifier si le certificat du site Web a été révoqué. Cela se fait généralement via le protocole HTTP, ce qui signifie qu'il n'est pas chiffré.

La requête OCSP contient le certificat "serial number", qui est unique. Il est envoyé au "OCSP responder" afin de vérifier son statut.

Nous pouvons simuler ce que ferait un navigateur en utilisant la commande openssl.

Obtenez le certificat du serveur et utilisez sed pour ne garder que la partie importante et l'écrire dans un fichier :

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

Obtenez le certificat intermédiaire. Les Autorités de certification (CA) ne signent normalement pas directement un certificat ; elles utilisent ce que l'on appelle un certificat "intermédiaire".
```
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 |
    sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert
```
Le premier certificat dans pg_and_intermediate.cert est en fait le certificat du serveur de l'étape 1. Nous pouvons utiliser à nouveau sed pour tout supprimer jusqu'à la première instance de END :
```
sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \
    /tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
```
Obtenir le répondeur OCSP pour le certificat du serveur :
```
openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
```
Notre certificat montre le répondeur du certificat Lets Encrypt. Si nous voulons voir tous les détails du certificat, nous pouvons utiliser :
```
openssl x509 -text -noout -in /tmp/pg_server.cert
```

Démarrer la capture de paquets :

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

Faites la demande OCSP :

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

Ouvrez la capture :

wireshark -r /tmp/pg_ocsp.pcap

Il y aura deux paquets avec le protocole "OCSP" : un "Demande" et un "Réponse". Pour la "Demande", nous pouvons voir le "numéro de série" en développant le triangle ▸ à côté de chaque champ :

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

Pour la "Réponse", nous pouvons également voir le "numéro de série" :

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

Ou utilisez tshark pour filtrer les paquets du numéro de série :

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

Si l'observateur du réseau dispose du certificat public, qui est accessible au public, il peut faire correspondre le numéro de série à ce certificat et donc déterminer le site que vous visitez à partir de celui-ci. Le processus peut être automatisé et permet d'associer des adresses IP à des numéros de série. Il est également possible de vérifier les journaux de Certificate Transparency (en anlais) pour le numéro de série.

Devrais-je utiliser un DNS chiffré ?

Nous avons créé cet organigramme pour décrire quand vous devriez utiliser des DNS chiffrés:

graph TB
    Start[Démarrage] --> anonymous{Essayez-vous<br>d'être<br>anonyme ?}
    anonymous--> | Oui | tor(Utilisez Tor)
    anonymous --> | Non | censorship{Essayez-vous<br>d'eviter la<br>censure ?}
    censorship --> | Oui | vpnOrTor(Utilisez un<br>VPN ou Tor)
    censorship --> | Non | privacy{Essayez-vous de<br>protéger votre vie<br>privée du FAI ?}
    privacy --> | Oui | vpnOrTor
    privacy --> | Non | obnoxious{Votre<br>FAI fait des<br> redirections<br> nuisibles ?}
    obnoxious --> | Oui | encryptedDNS(Utilisez un<br>DNS chiffré<br>tiers)
    obnoxious --> | Non | ispDNS{Votre<br>FAI supporte<br>les DNS<br>chiffrés ?}
    ispDNS --> | Oui | useISP(Utilisez le<br>DNS chiffré<br>de votre FAI)
    ispDNS --> | Non | nothing(Ne faites rien)

Le DNS chiffré avec des serveurs tiers ne doit être utilisé que pour contourner le blocage DNS de base lorsque vous êtes certain qu'il n'y aura pas de conséquences ou que vous êtes intéressés par un fournisseur qui effectue un filtrage rudimentaire.

Liste des serveurs DNS recommandés

Qu'est-ce que le DNSSEC ?

Domain Name System Security Extensions (extension de SECurité du Système de Nom de Domaine) est une fonctionnalité du DNS qui authentifie les réponses aux recherches de noms de domaine. Il ne fournit pas de protection de la vie privée pour ces recherches, mais empêche les attaquants de manipuler ou d'empoisonner les réponses aux requêtes DNS.

En d'autres termes, le DNSSEC signe numériquement les données afin de garantir leur validité. Afin de garantir une recherche sécurisée, la signature a lieu à chaque niveau du processus de consultation du DNS. Par conséquent, toutes les réponses du DNS sont fiables.

Le processus de signature DNSSEC est similaire à celui d'une personne qui signe un document juridique avec un stylo ; cette personne signe avec une signature unique que personne d'autre ne peut créer, et un expert judiciaire peut examiner cette signature et vérifier que le document a été signé par cette personne. Ces signatures numériques garantissent que les données n'ont pas été altérées.

DNSSEC met en œuvre une politique de signature numérique hiérarchique à travers toutes les couches du DNS. Par exemple, dans le cas d'une consultation de privacyguides.org, un serveur DNS racine signe une clé pour le serveur de noms .org, et le serveur de noms .org signe ensuite une clé pour le serveur de noms faisant autorité privacyguides.org.

Adapté de DNS Security Extensions (DNSSEC) overview par Google et DNSSEC : An Introduction par Cloudflare, tous deux sous licence CC BY 4.0.

Qu'est-ce que la minimisation QNAME ?

Un QNAME est un "nom qualifié", par exemple discuss.privacyguides.net. Auparavant, lors de la résolution d'un nom de domaine, le résolveur DNS demandait à chaque serveur de la chaîne de fournir toutes les informations dont il disposait au sujet de votre requête complète. Dans l'exemple ci-dessous, votre demande pour trouver l'adresse IP de discuss.privacyguides.net est demandée à tous les fournisseurs de serveurs DNS :

Serveur	Question posée	Réponse
Serveur racine	Quelle est l'adresse IP de discuss.privacyguides.net ?	Je ne sais pas, demandez au serveur de .net...
Serveur .net	Quelle est l'adresse IP de discuss.privacyguides.net ?	Je ne sais pas, demandez au serveur de Privacy Guides...
Serveur de Privacy Guides	Quelle est l'adresse IP de discuss.privacyguides.net ?	5.161.195.190!

Grâce à la "minimisation QNAME", votre résolveur DNS demande juste assez d'informations pour trouver le serveur suivant dans la chaîne. Dans cet exemple, le serveur racine ne reçoit que les informations nécessaires pour trouver le serveur de noms approprié pour le TLD .net, et ainsi de suite, sans jamais connaître le domaine complet que vous essayez de visiter :

Serveur	Question posée	Réponse
Serveur racine	Quel est le serveur de noms pour .net ?	Fournit le serveur .net
Serveur .net	Quel est le serveur de noms de privacyguides.net ?	Fournit le serveur de Privacy Guides
Serveur de Privacy Guides	Quel est le serveur de noms de discuss.privacyguides.net ?	Ce serveur !
Serveur de Privacy Guides	Quelle est l'adresse IP de discuss.privacyguides.net ?	5.161.195.190

Bien que ce processus puisse être légèrement plus inefficace, dans cet exemple ni les serveurs de noms de la racine centrale ni les serveurs de noms du TLD ne reçoivent jamais d'informations sur votre requête complète, ce qui réduit la quantité d'informations transmises sur vos habitudes de navigation. Une description technique plus détaillée est définie dans RFC 7816.

Qu'est-ce que le sous-réseau client EDNS (ECS) ?

Le EDNS Client Subnet est une méthode permettant à un résolveur DNS récursif de spécifier un sous-réseau pour l'hôte ou le client qui effectue la requête DNS.

Il est destiné à "accélérer" la transmission des données en donnant au client une réponse qui appartient à un serveur proche de lui, comme un réseau de diffusion de contenu, souvent utilisé pour la diffusion de vidéos en continu et pour servir des applications Web JavaScript.

Cette fonction a un coût en termes de confidentialité, car elle fournit au serveur DNS des informations sur la localisation du client, généralement votre réseau IP. Par exemple, si votre adresse IP est 198.51.100.32, le fournisseur DNS peut partager 198.51.100.0/24 avec le serveur faisant autorité. Certains fournisseurs de DNS rendent ces données anonymes en fournissant une autre adresse IP qui est approximativement proche de votre emplacement.

Si vous avez installé dig, vous pouvez tester si votre fournisseur DNS transmet les informations EDNS aux serveurs de noms DNS à l'aide de la commande suivante :

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

Notez que cette commande contactera Google pour le test et renverra votre IP ainsi que les informations de sous-réseau du client EDNS. Si vous souhaitez tester un autre résolveur DNS, vous pouvez spécifier son IP, pour tester 9.9.9.11 par exemple :

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

Si les résultats comprennent un deuxième enregistrement TXT edns0-client-subnet (comme indiqué ci-dessous), votre serveur DNS transmet des informations EDNS. L'IP ou le réseau indiqué ci-dessous est l'information précise qui a été communiquée à Google par votre fournisseur de DNS.

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

None Visit Crowdin

You're viewing the None 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!