Changer le DNS pour accélérer la navigation : les réglages qui comptent (et ceux qui n’en valent pas la peine)

DNS en termes simples (et pourquoi ça donne l’impression d’être « plus rapide »)

Le DNS, c’est l’annuaire téléphonique de l’internet : un nom entre, une adresse IP sort. Quand votre navigateur a besoin de example.com, il demande à un résolveur, reçoit une adresse (ou plusieurs), puis établit la connexion.

Pourquoi cela compte-t-il pour la « vitesse » ? Parce que le DNS intervient souvent au tout début du chargement d’une page, quand vous regardez un écran vide. Même un délai de 150–300 ms peut donner l’impression que tout l’internet est lent, alors que le reste de la page chargerait rapidement une fois les connexions établies.

Les pages modernes déclenchent aussi de nombreuses résolutions DNS : le site principal, les CDN, images, polices, analytics, réseaux publicitaires, vidéos intégrées, popups de « consentement » qui demandent apparemment trois fournisseurs différents. Un seul résolveur lent peut ajouter beaucoup de petits blocages.

Faits intéressants et contexte historique (court et concret)

• Le DNS a été normalisé au début des années 1980 pour remplacer un fichier hosts partagé unique. Les fichiers centraux ne montent pas en charge ; surprise.
• Le système racine DNS est servi par 13 serveurs « logiques » (A–M), mais chacun est anycasté vers de nombreux sites physiques dans le monde.
• Le TTL existe parce que le DNS est conçu pour être mis en cache : la plupart des requêtes ne devraient pas atteindre les serveurs autoritaires à répétition.
• EDNS0 a étendu le DNS au‑delà des limites de petite taille des messages UDP originaux — important pour les fonctionnalités modernes et DNSSEC.
• DNSSEC ajoute l’authenticité aux réponses DNS mais augmente la taille des réponses et le travail de validation ; bien fait c’est utile, mal fait ça casse.
• L’anycast est devenu une superpuissance pour le DNS : les grands résolveurs publics annoncent la même IP depuis de nombreux endroits pour que vous tombiez généralement sur un nœud proche.
• Le cache négatif (mise en cache de « ce nom n’existe pas ») existe car ne pas trouver quelque chose peut aussi coûter cher.
• DoH/DoT sont devenus courants à la fin des années 2010 avec la montée des préoccupations sur la vie privée et l’interception ; ils concernent la confidentialité, pas la vitesse magique.

Une maxime de fiabilité mérite d’être gardée à portée de main. Voici une idée paraphrasée attribuée à Werner Vogels (CTO d’Amazon) : Tout échoue, tout le temps — conçois et exploite comme si l’échec était normal. Le DNS est un endroit parfait pour appliquer ce principe, car les échecs DNS ressemblent à « l’internet est en panne » même quand votre réseau fonctionne.

Blague n°1 : Le DNS, c’est comme demander son chemin dans une ville — parfois l’itinéraire le plus rapide, c’est « demande à quelqu’un qui habite ici », pas au kiosque à touristes.

Ce que changer le DNS peut faire — et ce qu’il ne peut pas

Ça peut aider quand…

• Le résolveur de votre FAI est lent ou surchargé. Vous verrez des temps de requête DNS élevés, des timeouts ou des échecs intermittents.
• Le résolveur de votre FAI est « aidant » dans le mauvais sens. Certains réécrivent les NXDOMAIN (domaines inexistants) en pages publicitaires, ou injectent une « assistance de recherche ». Cela ajoute de la latence et casse des hypothèses de sécurité.
• Vous êtes loin de votre résolveur actuel. Si vous utilisez un DNS d’entreprise via un VPN depuis un hôtel de l’autre côté d’un océan, chaque résolution paie le trajet aller‑retour.
• Votre résolveur a un mauvais cache ou un mauvais peering. Des résolveurs publics bien anycastés et avec de bons taux de cache peuvent réduire la latence répétée.
• Votre réseau local intercepte DNS de façon problématique. Certains portails captifs ou « appliances de sécurité » retardent ou cassent les requêtes.

Ça n’aidera pas quand…

• Le goulot d’étranglement est la bande passante ou la perte de paquets. Si vous saturiez un lien à 10 Mbps, le DNS n’est pas le coupable.
• Le site est lent. Le DNS résout rapidement, puis le serveur met 2 secondes à répondre. Ce n’est pas un problème DNS ; c’est un problème serveur/application/CDN.
• Votre navigateur est bloqué par autre chose. Retards de handshake TLS, problèmes QUIC, pics CPU, mauvais paramètres de proxy — DNS n’est souvent que la première hypothèse des utilisateurs.
• Vous utilisez déjà un bon résolveur avec cache. Certaines modifications ne font que remplacer un fournisseur compétent par un autre.

Cadre important : « navigation plus rapide » signifie généralement réduire le time-to-first-byte (TTFB) ou la « pause onglet vide ». Le DNS influe sur la phase pré‑connexion, pas sur la phase de téléchargement. Ce n’est pas un bouton turbo. C’est un ensemble de choix sur l’endroit où la résolution de noms se produit, comment elle est chiffrée, et comment elle échoue.

Les réglages qui comptent vraiment

1) Quel résolveur vous utilisez (et à quelle distance il est)

C’est l’évidence. Un résolveur avec meilleure couverture anycast, meilleur cache et moins d’incidents peut réduire le temps de résolution et les échecs.

Mais « meilleur » dépend de la géographie et du réseau. Le résolveur le plus rapide pour votre voisin peut être médiocre pour le routage de votre FAI. Mesurez sur votre réseau.

2) Où vous définissez le DNS : routeur vs appareil vs VPN

Configurer le DNS sur le routeur rend l’ensemble du foyer cohérent. Le définir par appareil est utile si vous voulez des comportements différents (ordinateur pro vs téléphone perso).

Les VPN compliquent les choses : beaucoup de clients VPN poussent des paramètres DNS. Si votre navigation est lente uniquement en VPN, le choix du résolveur à l’intérieur du tunnel peut dominer. Un résolveur public « rapide » n’aidera pas si toutes les requêtes passent par le DNS d’entreprise situé dans une autre région.

3) Le comportement de cache DNS (stub local, cache OS, cache navigateur)

Le cache est la victoire silencieuse pour la performance. Si le cache DNS est désactivé ou constamment vidé, vous payez le coût complet des résolutions à répétition. Certains outils « vie privée » effacent agressivement les caches, ce qui peut rendre le web lent par accumulation de nombreuses résolutions.

4) DNS over HTTPS (DoH) / DNS over TLS (DoT) : compromis confidentialité vs performance

DoH/DoT chiffrent les requêtes DNS pour empêcher un observateur sur le chemin de voir ce que vous résolvez. Cela peut améliorer la fiabilité sur des réseaux hostiles (Wi‑Fi d’hôtel, portails captifs, middleboxes douteux). Cela peut aussi ajouter un surcoût : nouvelles sessions TLS, routage différent, parfois latence plus élevée que l’UDP simple vers un résolveur ISP proche.

En pratique :

• DoH peut être rapide lorsqu’il est implémenté avec une bonne réutilisation de connexion et un point de terminaison proche.
• DoT peut être plus simple pour la configuration au niveau OS, et a souvent un comportement prévisible.
• Le DNS non chiffré peut être le plus rapide sur un réseau ISP bien administré, mais il est facile à intercepter.

5) EDNS Client Subnet (ECS) et localité des CDN

Celle‑ci est insidieuse. Les CDN choisissent des serveurs « proches » en se basant en partie sur la localisation réseau du client. Si votre résolveur est loin et utilise ECS d’une manière qui vous mal représente (ou ne l’utilise pas du tout), vous pouvez être dirigé vers un endpoint CDN qui n’est pas réellement proche. Cela peut ralentir la livraison réelle du contenu même si le DNS est rapide.

Certaines résolveurs publics utilisent ECS sélectivement ; d’autres le minimisent pour la confidentialité. C’est un compromis : cartographie CDN plus précise vs fuite d’un signal de localisation. Mesurez le chargement réel des pages et le TTFB, pas seulement le temps de requête DNS.

6) Comportement en cas d’échec : timeouts, basculement, et résolveurs multiples

Les résolveurs tombent en panne. Les réseaux tombent en panne. Votre portable se promène entre des Wi‑Fi configurés par quelqu’un qui pense qu’« invité » est une excuse pour casser les fondamentaux.

Utiliser plusieurs résolveurs peut aider, mais cela peut aussi ajouter des bizarreries. Beaucoup de clients essaient le « secondaire » seulement après un timeout, ce qui signifie qu’un primaire lent peut provoquer des blocages répétés avant basculement. Un mauvais premier choix peut empoisonner l’expérience même si le second est bon.

Opérationnellement, vous souhaitez :

• Un primaire rapide et fiable.
• Un secondaire suffisamment indépendant pour être utile quand le premier est malade.
• Des timeouts qui basculent rapidement (lorsque configurable).

Les réglages que les gens modifient sans grand effet

« J’ai changé le DNS et ma vitesse de téléchargement a doublé »

Non, vous ne l’avez pas fait. Le DNS ne change pas combien de bits votre FAI délivre. Ce qui peut arriver : vous avez été mappé vers un meilleur endpoint CDN, donc les téléchargements depuis ce service spécifique se sont améliorés. Ce n’est pas « le DNS qui est plus rapide », c’est « un serveur différent choisi ».

Listes aléatoires de « gagnants de benchmarks DNS »

Les benchmarks sont souvent des tests de latence pour une seule requête, parfois effectués sans comportement de cache qui correspond à la navigation réelle. La navigation réelle c’est : réponses en cache, requêtes parallèles, réutilisation de connexions, et validation DNSSEC occasionnelle. Traitez les listes des « 10 serveurs DNS les plus rapides » comme des boissons énergétiques : principalement du marketing et un léger sentiment d’urgence.

Changer les TTL sur votre machine locale

La plupart des réglages TTL côté client sont soit non exposés, soit non respectés comme les gens le pensent, ou sont un excellent moyen de créer des bugs étranges. Navigateurs, stubs OS et résolveurs locaux ont chacun leurs propres politiques.

Éditer manuellement /etc/hosts pour la performance

Les entrées du fichier hosts servent à pinning ou aux tests, pas à la performance. Vous pouvez « accélérer » la résolution en hardcodant, oui — jusqu’à ce que l’IP du site change ou qu’il utilise un routage géographique. Alors vous vous êtes construit une petite génératrice de panne.

Blague n°2 : Hardcoder des IP pour « éviter le DNS » c’est comme enlever l’alarme incendie parce qu’elle est bruyante.

Mode d’emploi pour un diagnostic rapide

Si la navigation semble lente, ne commencez pas par changer les résolveurs comme si vous choisissiez des numéros de loterie. Faites ceci :

Première étape : décidez si c’est le DNS ou pas (30–60 secondes)

• Vérifiez le temps de résolution DNS pour quelques domaines courants.
• Vérifiez si le délai se situe avant la connexion (onglet vide) ou pendant le transfert (progrès lent).
• Comparez le comportement avec et sans VPN (si applicable).

Deuxième étape : localisez où le DNS est résolu

• L’appareil utilise‑t‑il le DNS du routeur, du FAI, d’un résolveur public, ou du DNS d’entreprise via VPN ?
• DoH est‑il activé dans le navigateur en train d’outrepasser les paramètres OS ?
• Y a‑t‑il une couche de cache locale (systemd-resolved, dnsmasq, Unbound, Pi-hole) ?

Troisième étape : testez deux résolveurs candidats et mesurez l’impact sur les pages

• Mesurez la latence DNS brute et les taux de timeout.
• Mesurez les différences de mapping CDN pour quelques gros sites (vérifiez quelles IPs vous obtenez).
• Chargez quelques pages représentatives et comparez le « début de rendu » et le TTFB.

Quatrième étape : changez une chose, puis observez

• Privilégiez les changements au niveau routeur pour un foyer.
• Privilégiez les paramètres OS pour une seule machine.
• Méfiez‑vous d’activer DoH à plusieurs endroits (navigateur + OS + routeur) sauf si vous avez l’intention de ce chevauchement.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici les tâches que j’exécute réellement quand quelqu’un dit « l’internet est lent ». Chacune inclut (1) la commande, (2) ce que la sortie signifie, (3) la décision que vous en tirez.

Task 1: See what DNS server your Linux box is actually using (systemd-resolved)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1 1.1.1.1
DNS Domain: ~.

Signification : Le résolveur actif est le routeur (192.168.1.1) avec un résolveur public secondaire listé. DNS-over-TLS est désactivé.

Décision : Si le DNS est lent, vous dépendez probablement du routeur/chemin ISP. Testez 192.168.1.1 contre un résolveur public directement avec dig.

Task 2: See what’s in /etc/resolv.conf (and whether something is rewriting it)

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Feb  5 09:12 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Signification : Votre système utilise le stub resolver de systemd. Le nameserver à l’intérieur de ce fichier sera probablement 127.0.0.53.

Décision : Ne modifiez pas ce fichier en pensant que le changement tiendra. Configurez le DNS via NetworkManager/systemd-resolved à la place.

Task 3: Measure DNS query time to your current resolver

cr0x@server:~$ dig +stats example.com
; <<>> DiG 9.18.24-1ubuntu1.3-Ubuntu <<>> +stats example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38451
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.            2600    IN      A       93.184.216.34

;; Query time: 18 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Wed Feb 05 09:20:12 UTC 2026
;; MSG SIZE  rcvd: 56

Signification : 18 ms, c’est correct. Si vous voyez 150+ ms ou des timeouts, le DNS peut être la cause du délai « onglet vide ».

Décision : Si le temps de requête est constamment faible, arrêtez d’accuser le DNS et montez la pile (TLS, routage, perte de paquets).

Task 4: Compare resolvers side-by-side (public vs ISP/router)

cr0x@server:~$ for s in 192.168.1.1 1.1.1.1 8.8.8.8; do echo "== $s =="; dig +tries=1 +time=1 @${s} www.cloudflare.com | grep -E "Query time:|SERVER:"; done
== 192.168.1.1 ==
;; Query time: 24 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
== 1.1.1.1 ==
;; Query time: 13 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
== 8.8.8.8 ==
;; Query time: 31 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)

Signification : Ici, 1.1.1.1 est le plus rapide pour ce réseau. Ce n’est pas universel.

Décision : Si le routeur/FAI est constamment plus lent ou instable, envisagez de changer au niveau routeur ou OS.

Task 5: Detect intermittent timeouts (the problem users feel)

cr0x@server:~$ for i in $(seq 1 20); do dig +tries=1 +time=1 @192.168.1.1 www.google.com >/dev/null || echo "timeout on attempt $i"; done
timeout on attempt 7
timeout on attempt 12

Signification : Deux timeouts sur 20 requêtes, c’est mauvais. Cela se traduit par « parfois les pages bloquent ».

Décision : N’optimisez pas pour 10 ms. Corrigez la fiabilité d’abord : changez de résolveur, corrigez la charge du routeur, ou adressez le lien problématique.

Task 6: Check whether DoH is bypassing your OS settings (Firefox example)

cr0x@server:~$ ps aux | grep -i firefox | head -n 2
cr0x    2134  6.2  3.1 3021456 512344 ?      Sl   09:10   1:22 /usr/lib/firefox/firefox
cr0x    4982  0.0  0.0   9220  2432 pts/0    S+   09:31   0:00 grep -i firefox

Signification : Cela ne prouve pas DoH, mais indique que Firefox tourne et pourrait avoir ses propres réglages DNS.

Décision : Si les changements OS n’affectent pas le comportement, vérifiez les paramètres DNS du navigateur (mode DoH) et les politiques d’entreprise.

Task 7: Confirm which IP a domain resolves to (CDN mapping clue)

cr0x@server:~$ dig @1.1.1.1 www.netflix.com +short
203.0.113.41
203.0.113.52

Signification : Vous avez reçu deux enregistrements A. Un autre résolveur peut retourner d’autres IPs, potentiellement en vous mappant vers des bords CDN différents.

Décision : Si changer le DNS change ces IPs, testez la performance réelle (ping/traceroute/TTFB) avant de vous réjouir.

Task 8: Measure connection setup and TTFB (DNS vs TLS vs server)

cr0x@server:~$ curl -o /dev/null -s -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' https://www.wikipedia.org/
dns:0.014 connect:0.041 tls:0.112 ttfb:0.238 total:0.402

Signification : Le DNS a pris 14 ms ; TLS et la réponse serveur dominent. Changer le DNS n’améliorera pas beaucoup le temps total ici.

Décision : Si time_namelookup est élevé (par exemple 0.2–1.0s), le DNS est un vrai contributeur. Sinon, cherchez ailleurs.

Task 9: Check packet loss/latency to the resolver (is the path bad?)

cr0x@server:~$ ping -c 5 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=12.4 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=13.1 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=12.7 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=12.9 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=55.2 ms

--- 1.1.1.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 12.4/21.3/55.2/16.8 ms

Signification : Pas de perte, mais il y a de la gigue (un pic à 55 ms). Des pics occasionnels sont normaux ; une perte persistante ne l’est pas.

Décision : S’il y a perte vers le résolveur, changer de résolveur peut aider — mais suspectez aussi la qualité du Wi‑Fi, le bufferbloat, ou des problèmes en amont.

Task 10: Flush caches when testing (so you don’t test your cache)

cr0x@server:~$ sudo resolvectl flush-caches
cr0x@server:~$ resolvectl statistics
DNSSEC supported: no
Transactions: 146
Cache size: 0
Cache hits: 0
Cache misses: 12

Signification : Le cache est vidé ; les requêtes suivantes seront « froides » et refléteront mieux le comportement du résolveur/réseau.

Décision : Utilisez des tests en cold-cache pour le dépannage ; utilisez le comportement warm-cache pour comprendre la navigation quotidienne.

Task 11: Check for DNS failures in system logs (Linux)

cr0x@server:~$ sudo journalctl -u systemd-resolved --since "30 minutes ago" | tail -n 8
Feb 05 09:07:41 server systemd-resolved[812]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 192.168.1.1.
Feb 05 09:08:03 server systemd-resolved[812]: DNS server 192.168.1.1 does not support DNSSEC, disabling validation.
Feb 05 09:10:22 server systemd-resolved[812]: Server returned error NXDOMAIN, retrying transaction 21961.
Feb 05 09:11:05 server systemd-resolved[812]: Timeout reached while resolving 'fonts.gstatic.com'.

Signification : EDNS0 dégradé et timeouts suggèrent que le forwarder DNS du routeur est instable ou cassé.

Décision : Contournez le résolveur du routeur et pointez les clients vers un résolveur reconnu, ou réparez/remplacez le composant DNS du routeur.

Task 12: Inspect your router’s DNS behavior from a client (is it forwarding or resolving?)

cr0x@server:~$ dig +norecurse @192.168.1.1 example.com | grep -E "ra;|flags:"
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

Signification : Le drapeau ra indique que la récursion est disponible ; le routeur agit comme résolveur récursif/forwarder.

Décision : Si le routeur est lent, soit (a) changez son DNS en amont, soit (b) arrêtez de l’utiliser pour le DNS et pointez directement vers des résolveurs publics.

Task 13: Test DNS over TLS latency (if you run a local stub like Unbound)

cr0x@server:~$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com
;; TLS session (TLS1.3)-(ECDHE)-(RSA)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 12345
;; QUESTION SECTION:
;; example.com. IN A
;; ANSWER SECTION:
example.com. 2600 IN A 93.184.216.34
;; Received 56 B
;; Time 29 ms

Signification : DoT fonctionne et est légèrement plus lent que l’UDP dans cet exemple (commun). Le coût peut disparaître avec la réutilisation des sessions.

Décision : Choisissez DoT/DoH pour la confidentialité et l’intégrité sur des réseaux non fiables ; n’en attendez pas un gain de vitesse par défaut.

Task 14: Check whether your VPN is forcing DNS

cr0x@server:~$ resolvectl dns tun0
Link 7 (tun0): 10.60.0.53

Signification : Le DNS pour l’interface VPN est défini sur un résolveur d’entreprise. Même si vous avez changé le DNS du Wi‑Fi, le trafic VPN peut toujours utiliser celui‑ci.

Décision : Si les performances chutent en VPN, vous avez besoin de modifications de politique split‑DNS/split‑tunnel ou d’un résolveur d’entreprise plus proche — pas d’un autre DNS public.

Trois mini‑histoires d’entreprise issues du terrain

Histoire 1 : L’incident causé par une mauvaise hypothèse (le cache DNS « va gérer »)

Une entreprise SaaS de taille moyenne a migré une partie de sa stack vers une nouvelle couche d’équilibrage de charge. Sur le papier, ils ont fait la chose prudente : ils ont abaissé le TTL DNS pour api.company.tld « afin de basculer rapidement ». L’hypothèse était que les clients respecteraient le nouveau TTL et que la coupure se ferait proprement.

Le jour de la bascule est arrivé. Les taux d’erreur ont grimpé, puis oscillé. Certains clients touchaient le nouveau VIP, d’autres restaient sur l’ancien. Les ingénieurs regardaient des graphiques qui ressemblaient à un mauvais moniteur cardiaque. Les load balancers allaient bien. Les serveurs applicatifs allaient bien. Le réseau allait bien. « Internet » n’allait pas bien — mais seulement pour certains utilisateurs, et seulement de temps en temps.

Ce qui s’est passé : une partie significative des clients n’a jamais vu le nouveau comportement de TTL réduit. Certains étaient derrière des résolveurs récursifs qui plafonnaient les TTL minimaux. Certains réseaux d’entreprise avaient des proxies de cache agressifs. Quelques résolveurs d’opérateurs mobiles se comportaient de façon « légalement douteuse » mais tolérée. Entre‑temps, leurs propres services internes utilisaient un chemin de résolveur différent de la majorité des clients, donc les tests internes semblaient excellents.

La correction fut ennuyeuse : traiter le DNS comme un système finalement consistant. Ils ont étendu la fenêtre de transition, gardé l’ancien VIP en bonne santé plus longtemps, et utilisé un en‑tête canari côté application pour contrôler le trafic au lieu de compter uniquement sur le TTL. Après coup, ils ont arrêté de décrire les changements DNS comme « instantanés » dans les runbooks. L’incident n’était pas une panne DNS ; c’était une panne d’hypothèses.

Histoire 2 : L’optimisation qui a mal tourné (DoH partout, latence mystérieuse)

Une entreprise globale a déployé une « mise à niveau de confidentialité » sur les endpoints : activer DNS over HTTPS dans le navigateur, activer DNS over TLS au niveau OS, et pointer tout vers un résolveur tiers. La direction sécurité voulait arrêter l’inspection locale du DNS. L’intention était raisonnable. Le plan de déploiement ne l’était pas.

En une semaine, les tickets helpdesk ont explosé : « les sites mettent parfois longtemps à commencer à se charger ». Pas de façon cohérente. Pas pour tout le monde. Surtout dans des bureaux régionaux avec des firewalls plus anciens. Les équipes ont d’abord accusé le FAI, puis le fournisseur de résolveur, puis le navigateur, puis la phase de la Lune. La progression était lente parce que le problème ressemblait à une « lenteur générale ».

Le mode de défaillance réel : les middleboxes de sécurité réseau interféraient de façon intermittente avec les connexions HTTPS long‑range vers le point de terminaison DoH, surtout quand le point de terminaison utilisait le multiplexage HTTP/2. Quand ces connexions se bloquaient, les requêtes DNS se mettaient en file d’attente derrière elles. La couche DoT au niveau OS créait aussi plus de sessions chiffrées concurrentes que prévu, et le firewall ancien commençait à rate‑limiter ce qu’il considérait comme des rafales de trafic chiffré suspectes.

Le rollback fut chirurgical : garder DoT au niveau OS pour les appareils gérés sur réseaux non fiables, désactiver DoH au niveau navigateur là où les politiques OS fournissaient déjà du DNS chiffré, et ajouter des allowlists d’endpoints de résolveur sur le périmètre. La leçon : la redondance n’est pas toujours de la résilience. Parfois c’est juste deux endroits à mal configurer et un endroit à blâmer.

Histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (cache local + timeouts sensés)

Un détaillant exploitait des milliers de terminaux point‑de‑vente et clients légers dans des magasins, beaucoup avec une connectivité finale instable. Ils n’ont rien fait d’exotique. Ils ont exécuté un petit résolveur cache local dans chaque magasin, en le faisant forwarder vers deux résolveurs en amont sur le WAN.

Un soir, un incident chez un ISP en amont a provoqué une perte de paquets intermittente. Les magasins sans cache local (une sous‑population legacy) ont vu des blocages UI et des erreurs « impossible de se connecter » parce que chaque résolution DNS devait traverser le lien malade. Les magasins avec cache local ont continué à fonctionner pendant de longues périodes parce que les noms courants étaient déjà en cache localement. Quand le cache expirait, les échecs survenaient encore — mais moins fréquemment et avec moins de dramatique visible pour l’utilisateur.

Ce qui a fonctionné n’était pas magique. C’était : (1) un cache dimensionné pour l’ensemble de noms normal du magasin, (2) des upstreams sur des réseaux différents, et (3) des timeouts configurés pour basculer rapidement. C’est tout. Pas d’exploits. Pas d’« IA réseau ». Juste des opérations basiques et disciplinées.

Ils ont toujours eu un incident WAN. Mais ils n’en ont pas fait une panne totale d’activité. Parfois « ennuyeux » est le plus grand compliment pour des systèmes en production.

Erreurs courantes : symptôme → cause première → correction

1) Symptom: First page load stalls, reload is fast

Cause première : Cache DNS à froid + résolveur lent, ou timeouts intermittents du résolveur. Après le rechargement, le nom est en cache (OS/navigateur), donc cela semble « réparé ».

Correction : Mesurez les timeouts en cold‑query (Task 5). Passez à un résolveur fiable. Assurez‑vous que votre couche de cache locale n’est pas désactivée ou constamment vidée.

2) Symptom: Some sites are fast, some are inexplicably slow after changing DNS

Cause première : Mapping CDN différent dû à la localisation du résolveur/comportement ECS ; vous êtes envoyé vers un edge moins optimal.

Correction : Comparez les IP résolues (Task 7). Mesurez le TTFB (Task 8) et la qualité de route. Si le mapping CDN est pire, revenez en arrière ou choisissez un résolveur plus proche de votre réseau.

3) Symptom: Everything breaks only on certain Wi‑Fi networks (hotels, airports)

Cause première : Interception DNS par portail captif ou blocage des endpoints DoH/DoT, causant des timeouts.

Correction : Désactivez temporairement le DNS chiffré ou utilisez le résolveur fourni par le réseau jusqu’à authentification. Après connexion, réactivez les paramètres de confidentialité.

4) Symptom: You changed router DNS, but nothing changed

Cause première : Les appareils utilisent des DNS codés en dur (commun sur certains IoT) ou le navigateur DoH outrepassant les DNS OS/routeur.

Correction : Confirmez le résolveur actif avec resolvectl status (Task 1) ou le DNS par interface (Task 14). Ajustez les paramètres de l’appareil ou du navigateur en conséquence.

5) Symptom: Random NXDOMAIN or “site can’t be reached” for legitimate domains

Cause première : Validation DNSSEC cassée sur un résolveur, ou forwarder DNS du routeur qui maltraite EDNS0/réponses volumineuses.

Correction : Vérifiez les logs (Task 11). Essayez un autre résolveur directement (Task 4). Si le routeur ne gère pas le DNS moderne, contournez‑le ou changez le firmware/matériel.

6) Symptom: Browsing is slower on VPN

Cause première : DNS forcé via des résolveurs d’entreprise distants ; chaque requête paie la latence WAN. Parfois le split‑DNS est mal configuré, forçant toutes les requêtes à travers le tunnel.

Correction : Identifiez le DNS du VPN (Task 14). Corrigez la politique split‑tunnel/split‑DNS ; ajoutez des résolveurs régionaux ; assurez‑vous que le client VPN n’écrase pas le DNS voulu.

7) Symptom: You enabled DoH and now some internal sites don’t resolve

Cause première : Les zones DNS internes ne sont résolubles que via des résolveurs d’entreprise. DoH envoie des requêtes vers des résolveurs publics incapables de voir les zones privées.

Correction : Désactivez DoH sur les réseaux nécessitant un DNS interne, ou utilisez un DoH géré capable de résoudre les zones internes, ou appliquez des politiques OS avec split‑DNS.

8) Symptom: “DNS is fine” in a benchmark, but browsing still feels sluggish

Cause première : Le benchmark a testé en warm cache ou un seul domaine ; la navigation réelle inclut plusieurs résolutions parallèles, TCP/TLS, et la réponse serveur.

Correction : Utilisez le timing curl (Task 8) et des tests de pages réelles. Identifiez si DNS, connect, TLS ou serveur domine.

Listes de contrôle / plan pas à pas

Plan A : Vous voulez savoir si changer le DNS aidera

1. Mesurez la latence et la fiabilité DNS de base. Exécutez Task 3 et Task 5 contre votre résolveur actuel.
2. Mesurez où le temps est passé dans un chargement de page. Exécutez Task 8 pour quelques sites représentatifs.
3. Choisissez deux résolveurs candidats (un public, un votre/FAI) et comparez avec Task 4.
4. Vérifiez la sensibilité du mapping CDN. Comparez les IPs avec Task 7 pour au moins un site lourd en CDN.
5. Changez le DNS à un seul endroit (routeur ou OS, pas les deux en même temps), puis répétez les mesures.

Plan B : Vous voulez la configuration la plus sûre « installer et oublier » à la maison

1. Configurez le DNS sur le routeur pour que tous les appareils en bénéficient.
2. Utilisez un résolveur public anycast fiable ou le résolveur de votre FAI s’il teste bien et ne trafique pas les réponses.
3. Configurez un résolveur secondaire réellement indépendant.
4. Si vous avez besoin de confidentialité sur un Wi‑Fi non fiable, activez DoH/DoT au niveau OS ou navigateur — mais évitez les couches doubles de chiffrement sauf si c’est voulu.
5. Retestez après changement avec Task 4 et Task 8.

Plan C : Vous gérez un petit réseau de bureau et voulez moins de tickets

1. Exécutez un résolveur cache local (dnsmasq/Unbound) sur une machine stable ou un appliance routeur.
2. Forwardez vers deux résolveurs en amont sur des réseaux différents.
3. Gardez des timeouts basés pour basculer rapidement, mais pas si bas que la gigue brève est traitée comme une panne.
4. Journalisez les erreurs DNS et surveillez les pics (pattern Task 11, mais pour votre démon choisi).
5. Documentez « quel DNS utilisons‑nous » dans les docs d’onboarding. Ça semble évident jusqu’à un incident.

Plan D : Vous avez changé le DNS et tout est devenu étrange (retour arrière sans drame)

1. Annulez d’abord DoH au niveau navigateur (c’est le plus susceptible de vous surprendre).
2. Puis restaurez le DNS OS aux paramètres fournis par DHCP et retestez.
3. Enfin, remettez les modifications DNS du routeur si nécessaire.
4. Confirmez le résolveur actif (Task 1) et refaites Task 8 pour vérifier l’amélioration.

FAQ

1) Le fait de changer le DNS augmentera‑t‑il ma vitesse Internet ?

Non. Cela peut réduire le délai de « début de chargement » en accélérant les résolutions de noms ou en évitant des timeouts. Ça n’augmentera pas la bande passante brute.

2) Pourquoi la navigation semble‑t‑elle plus rapide après un changement de DNS même si les benchmarks sont similaires ?

Parce que la fiabilité et le cache comptent plus qu’un seul chiffre de latence. Moins de timeouts et de meilleurs taux de cache donnent l’impression de rapidité. De plus, un mapping CDN différent peut améliorer la performance réelle de téléchargement.

3) Dois‑je configurer le DNS sur le routeur ou sur chaque appareil ?

Sur le routeur si vous voulez de la cohérence et moins de configuration par appareil. Sur l’appareil si vous avez besoin d’exceptions (ordinateur pro, tests, contrôle parental). N’oubliez pas que DoH au niveau navigateur peut outrepasser les deux.

4) Le DNS over HTTPS est‑il toujours meilleur ?

Mieux pour la confidentialité contre l’espionnage sur le réseau local, souvent mieux contre l’interception. Pas toujours plus rapide, et peut casser les portails captifs ou le DNS interne si mal configuré.

5) Ai‑je besoin de DNSSEC ?

En tant qu’utilisateur, vous avez surtout besoin d’un résolveur qui valide correctement DNSSEC. DNSSEC n’a rien à voir avec la vitesse ; il empêche certaines formes d’usurpation DNS. Si la validation est cassée, cela peut provoquer des échecs — choisissez donc un résolveur fiable.

6) Mon FAI peut‑il encore voir les sites que je visite si j’utilise un résolveur public ?

Votre FAI peut toujours voir les IPs vers lesquelles vous vous connectez, et avec SNI/ESNI/ECH selon le déploiement, il peut inférer des destinations. La confidentialité DNS aide, mais ne vous rend pas invisible.

7) Pourquoi certains appareils ignorent mes réglages DNS ?

Certains hardcodent des résolveurs, d’autres ont DoH intégré dans des apps, et certains priorisent le DNS IPv6 appris via les annonces routeur. Diagnostiquez en vérifiant quel résolveur est réellement utilisé (Task 1/14) et en testant depuis l’appareil lui‑même.

8) Changer le DNS aide‑t‑il pour le jeu en ligne ?

Généralement pas pour la latence en jeu. Le DNS affecte la connexion aux services et le matchmaking, pas le ping stable vers un serveur de jeu. Ça peut aider si vous subissez des timeouts DNS ou des connexions initiales lentes.

9) Quel est le changement le plus simple et sûr pour la plupart des gens ?

Passez d’un résolveur routeur/FAI instable à un résolveur public anycast réputé sur le routeur, gardez un secondaire, et vérifiez avec quelques mesures (Task 4 et Task 8).

10) Pourquoi j’obtiens des IP différentes pour le même domaine selon les résolveurs ?

Les CDN adaptent les réponses en fonction de la localisation perçue du client, de la localisation du résolveur et des politiques. C’est normal. L’impact sur la performance peut être positif ou négatif — testez plutôt que supposer.

Prochaines étapes réalisables aujourd’hui

1. Faites une mesure qui coupe court aux suppositions : utilisez la ligne de timing curl (Task 8). Si le DNS est < 30 ms et stable, ne perdez pas la journée à chercher un résolveur.
2. Si le DNS est lent ou instable, prouvez‑le : lancez la boucle de 20 essais (Task 5) contre votre résolveur actuel.
3. Testez deux alternatives : comparez les temps de requête (Task 4) et vérifiez les timeouts. Choisissez le résolveur qui est rapide et fiable sur votre réseau.
4. Changez le DNS en un seul endroit : routeur pour les foyers, OS pour une seule machine, politique VPN pour les environnements d’entreprise. Évitez d’empiler DoH navigateur en haut sauf si c’est intentionnel.
5. Retestez après changement : videz les caches (Task 10) et relancez Task 8 pour quelques sites que vous utilisez réellement.

Si vous ne faites rien d’autre, faites ceci : arrêtez de traiter le DNS comme une superstition. Mesurez, changez une variable, mesurez à nouveau. C’est ainsi que vous éviterez que des « optimisations de vitesse » ne deviennent des appels d’incident nocturnes.