Changer de serveur DNS ne modifie ni le débit de la connexion ni la bande passante disponible. Cela raccourcit une seule étape, la traduction du nom de domaine en adresse IP, et ce gain se compte en dizaines de millisecondes par domaine jamais visité.
Points clés
- Un changement de résolveur agit sur la résolution des noms, pas sur le débit : une page lente à cause du serveur distant restera lente.
- Une mesure 2026 portant sur 845 hébergeurs situe la résolution à 47 ms de médiane, soit environ 12 % du temps écoulé avant le premier octet reçu.
- Les résolveurs publics les plus utilisés sont 1.1.1.1 et 1.0.0.1 chez Cloudflare, 8.8.8.8 et 8.8.4.4 chez Google Public DNS, 9.9.9.9 chez Quad9.
- Windows 11 sait chiffrer les requêtes en DNS over HTTPS, à condition que l’adresse saisie figure dans la liste des serveurs reconnus.
- Le vrai bénéfice mesurable est ailleurs : filtrage des domaines malveillants, résolution qui répond quand celle du fournisseur d’accès tombe, journalisation réduite.
- Un poste derrière un VPN ou une box qui impose ses propres serveurs peut ignorer le réglage : le placebo vient souvent de là.
Ce que le résolveur change, et ce qu’il ne change pas
Le serveur DNS traduit azertytech.com en adresse IP. Cette traduction arrive une fois par domaine, puis le résultat est gardé en cache par Windows et par le navigateur pendant la durée de vie annoncée par la zone. Sur une page qui charge trente ressources réparties sur cinq noms de domaine, il y a cinq résolutions, pas trente.
Sur le total du temps passé avant l’affichage, la part de cette étape reste modeste. Une mesure publiée en 2026 sur 845 hébergeurs décompose le budget avant premier octet en quatre phases : résolution des noms 47 ms de médiane, connexion TCP 80 ms, négociation TLS 88 ms, traitement par le serveur le reste. La résolution y pèse environ 12 %, et le traitement côté serveur presque la moitié.
Conclusion pratique : sur une connexion dont le résolveur du fournisseur répond en 20 ms, passer à un résolveur public qui répond en 12 ms fait gagner 8 ms sur la première visite d’un nom de domaine. Personne ne le perçoit. Sur une connexion où le résolveur du fournisseur répond en 300 ms ou renvoie des erreurs intermittentes, le même changement est immédiatement visible.
Mesurer avant de changer
Deux commandes suffisent à savoir si le résolveur actuel est en cause. Dans un terminal, nslookup exemple-de-domaine.fr affiche le serveur interrogé et sa réponse. En PowerShell, Resolve-DnsName azertytech.com donne le même résultat avec la durée de vie des enregistrements.
Pour comparer deux serveurs honnêtement, il faut vider le cache local entre deux essais, sinon la seconde mesure lit une réponse déjà stockée. La commande est ipconfig /flushdns. Videz le cache DNS de Windows, testez un nom de domaine jamais visité, notez le temps, changez de serveur, videz de nouveau, retestez le même nom. Un écart inférieur à 20 ms ne justifie aucune manipulation.
ipconfig /displaydns liste ce que le client garde en mémoire. C’est aussi la commande qui explique pourquoi un site déplacé continue de pointer vers l’ancienne adresse IP après un changement de résolveur.
Changer les serveurs DNS dans les paramètres de Windows 11
La manipulation se fait par interface réseau, et elle ne demande aucun outil tiers.
- Ouvrez les paramètres, section Réseau et Internet.
- Sélectionnez Wi-Fi ou Ethernet selon la connexion en cours, puis la carte réseau concernée.
- Descendez jusqu’à Attribution de serveur DNS et cliquez sur Modifier.
- Dans la liste déroulante, remplacez Automatique (DHCP) par Manuel.
- Activez l’interrupteur IPv4, saisissez le serveur DNS préféré et le serveur DNS auxiliaire. Faites de même pour IPv6 si le réseau l’utilise.
- Cliquez sur Enregistrer, puis videz le cache local avant de tester.
Le réglage vaut pour cette carte réseau uniquement. Un portable qui alterne entre Wi-Fi du bureau et partage de connexion mobile doit être configuré deux fois, ou une seule fois sur le routeur du domicile pour couvrir tous les appareils.
La même opération en ligne de commande
Sur un parc de postes, l’interface graphique n’a aucun intérêt. Deux syntaxes existent.
Avec netsh, dans une invite de commandes en administrateur :
netsh interface ipv4 set dnsservers name="Ethernet" source=static address=1.1.1.1 validate=no
netsh interface ipv4 add dnsservers name="Ethernet" address=1.0.0.1 index=2Avec PowerShell, le module client DNS fait la même chose en une ligne :
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("1.1.1.1","1.0.0.1")Pour revenir à l’attribution automatique du réseau, netsh interface ipv4 set dnsservers name="Ethernet" source=dhcp rend la main au serveur DHCP de la box. Microsoft documente aussi netsh dnsclient, qui gère les réglages de chiffrement et les options globales du client.
Quel résolveur choisir
| Service | Adresses IPv4 | Particularité annoncée |
|---|---|---|
| Cloudflare | 1.1.1.1 · 1.0.0.1 | Aucune revente de données, adresse source non conservée en stockage durable sauf échantillonnage réseau à 0,05 % du trafic |
| Cloudflare pour les familles | 1.1.1.2 · 1.0.0.2 | Blocage des domaines liés aux logiciels malveillants et au hameçonnage, réponse forcée à 0.0.0.0 |
| Google Public DNS | 8.8.8.8 · 8.8.4.4 | Validation DNSSEC, documentation d’intégration très fournie |
| Quad9 | 9.9.9.9 | Fondation suisse, filtrage des domaines réputés malveillants |
Le choix se joue sur le modèle de confidentialité et sur le filtrage, pas sur un classement de vitesse valable partout : la latence dépend du point de présence le plus proche de votre accès. Un résolveur associatif français comme celui de FDN, ou un service comme OpenDNS chez Cisco, ont aussi leurs partisans dans les réseaux d’entreprise pour des raisons de politique de filtrage.
La méthode classique par les propriétés de la carte réseau
L’ancien chemin existe toujours sous Windows 11, et il rend service quand la page moderne des paramètres refuse d’enregistrer le choix. Il passe par le Centre Réseau et partage.
- Ouvrez la fenêtre Exécuter avec les touches Windows et R, saisissez
ncpa.cpl, puis validez. - Dans la fenêtre des connexions réseau, faites un clic droit sur votre ordinateur sur la carte active, puis sélectionnez Propriétés.
- Dans la liste des services et protocoles, sélectionnez Protocole Internet version 4 (TCP/IPv4) et cliquez sur le bouton Propriétés.
- Cochez l’option Utiliser l’adresse de serveur DNS suivante, saisissez le serveur préféré puis le serveur secondaire.
- Cochez au besoin la case de validation des paramètres en quittant, cliquez sur OK, fermez chaque fenêtre avec le bouton de validation.
La même étape se répète sur le protocole Internet version 6 si le réseau distribue de l’IPv6. Un poste configuré en IPv4 seulement continue sinon d’utiliser les serveurs IPv6 du fournisseur d’accès, ce qui rend le résultat du changement incohérent d’un site web à l’autre.
Le choix du service selon l’usage
Trois profils reviennent. Pour un ordinateur personnel, le critère décisif est la protection : un service qui bloque les domaines de hameçonnage évite une partie des mauvaises surprises de navigation, sans logiciel supplémentaire. Pour un poste en entreprise, le critère est la politique de filtrage et la journalisation, ce qui explique la présence d’OpenDNS chez Cisco et de Comodo SecureDNS dans les configurations gérées. Pour un usage sensible à la confidentialité, ce sont les engagements écrits du fournisseur sur les requêtes conservées qui tranchent, et le chiffrement de bout en bout.
Dans tous les cas, notez la configuration d’origine avant de changer. Un menu déroulant remis sur l’attribution automatique et le cache vidé suffisent à revenir en arrière, mais encore faut-il savoir quelles adresses étaient en place, en particulier sur un réseau d’entreprise où le serveur DNS interne assure aussi la résolution des noms de machines.
Sécurité : ce qu’un résolveur filtrant bloque vraiment
Le gain de sécurité est le seul argument mesurable qui tienne face au gain de vitesse. Un résolveur filtrant compare chaque nom demandé à une liste de domaines réputés malveillants, et refuse de renvoyer l’adresse quand le nom y figure. Cloudflare renvoie l’adresse 0.0.0.0 sur ses serveurs 1.1.1.2 et 1.0.0.2, ce qui empêche l’ordinateur d’ouvrir la connexion vers les sites web concernés. Quad9 applique le même principe de protection sur son serveur 9.9.9.9.
Cette protection s’arrête à la résolution du nom. Elle ne remplace ni un antivirus ni le filtrage des pièces jointes : un fichier malveillant déjà présent sur le disque, ou un domaine créé le matin même, passent au travers. Elle réduit en revanche la surface d’attaque du hameçonnage, où l’utilisateur clique sur un lien vers un domaine connu des listes depuis plusieurs jours.
Deux réglages complètent utilement le dispositif. La validation DNSSEC, activée par défaut chez les grands services publics, vérifie la signature des réponses et écarte les réponses falsifiées en cours de route. Le chiffrement des requêtes, lui, empêche un tiers sur le réseau de lire la liste des noms demandés. Ni l’un ni l’autre n’accélère la navigation : ils réduisent le risque, ce qui n’est pas la même promesse.
Dernier détail de sécurité souvent oublié : le serveur secondaire doit appartenir au même service que le serveur principal. Mélanger un résolveur filtrant en principal et un résolveur non filtrant en secondaire annule le filtrage dès que le premier ne répond pas.
Activer le DNS chiffré
Une requête classique circule en clair. N’importe quel équipement sur le trajet voit la liste des domaines demandés, même quand les sites web visités sont en HTTPS. Le protocole DNS over HTTPS encapsule la requête dans une session TLS, ce qui la protège de l’écoute et de la modification en cours de route.
Dans les paramètres de la carte réseau, une fois le mode manuel activé, un menu Chiffrement DNS préféré apparaît sous chaque champ. Il propose de n’utiliser que le trafic non chiffré, d’autoriser le chiffré avec repli sur le clair, ou d’exiger le chiffré. Point important : Windows ne propose le chiffrement que si l’adresse saisie appartient à sa liste de serveurs reconnus. Les grands résolveurs publics y sont ; un serveur interne ne l’est pas, et il faut alors l’ajouter avec la commande Add-DnsClientDohServerAddress en précisant le modèle d’URL.
Exiger le chiffrement sur un portable est à tester avant de le généraliser : certains portails d’accès Wi-Fi publics interceptent la résolution des noms pour afficher leur page de connexion, et bloquent tout si la requête chiffrée ne peut pas aboutir.
Où se cache le placebo
Quatre situations font croire à un gain qui n’existe pas, ou annulent le réglage sans avertissement.
- Le navigateur a son propre résolveur. Chrome et Edge embarquent une option de DNS sécurisé indépendante des paramètres réseau de Windows. Tant qu’elle est active avec un fournisseur imposé, le réglage système ne s’applique pas au navigateur.
- La box impose ses serveurs. Certains équipements de fournisseur d’accès redirigent le trafic sortant sur le port 53 vers leur propre résolveur, quel que soit le réglage du poste.
- Un VPN reprend la main. Une fois le tunnel monté, la résolution passe par les serveurs annoncés par le client VPN. C’est voulu, et c’est ce qui évite les fuites de requêtes.
- Le cache n’a pas été vidé. Comparer deux résolveurs sans purger le cache du client puis celui du navigateur produit des chiffres qui ne veulent rien dire.
Les cas où le changement règle un vrai problème
La manipulation devient utile, et non cosmétique, dans trois situations précises. Quand le résolveur du fournisseur d’accès ne répond plus, ce qui produit le message d’erreur détaillé dans notre article sur le serveur DNS qui ne répond pas. Quand la navigation tombe par intermittence alors que la connexion reste établie, symptôme voisin de ceux traités dans Internet qui se déconnecte. Et quand un domaine récemment déplacé renvoie une réponse périmée, cas qui produit parfois des boucles de redirection comme celles décrites pour l’erreur ERR_TOO_MANY_REDIRECTS.
Dans ces trois cas, le changement de serveur n’accélère rien : il remplace un composant défaillant par un composant qui fonctionne. C’est un dépannage, pas une optimisation.
Questions fréquentes
Changer de DNS augmente-t-il le débit de la connexion ?
Non. Le débit dépend de l’accès et du serveur distant. Le résolveur n’intervient que sur la traduction des noms de domaine.
Faut-il renseigner un serveur auxiliaire ?
Oui. Sans second serveur, une indisponibilité du premier coupe toute résolution. Les services publics fournissent systématiquement deux adresses.
Vaut-il mieux configurer le poste ou le routeur ?
Le routeur couvre tous les appareils du réseau local en une fois, y compris ceux qui n’ont pas d’interface de configuration. Le réglage par poste sert aux machines nomades et aux tests.
Le DNS chiffré ralentit-il la navigation ?
La session TLS ajoute un coût à la première requête, puis la connexion est réutilisée. L’écart reste dans le bruit de mesure face au bénéfice de confidentialité.
Comment revenir en arrière sans risque ?
Repasser l’attribution de serveur DNS sur Automatique (DHCP), ou lancer la commande netsh avec source=dhcp, puis vider le cache local.
Photo d’en-tête : Livebox Orange V4, photo Poudou99, CC BY-SA 4.0, via Wikimedia Commons. Le modèle photographié illustre le type d’équipement qui distribue les serveurs DNS par DHCP, il ne correspond à aucune configuration décrite ici.
Sources : Microsoft Learn, Secure DNS Client over HTTPS (DoH) · Microsoft Learn, netsh dnsclient · Cloudflare, Set up the 1.1.1.1 resolver · Cloudflare, engagement de confidentialité du résolveur public · Google Public DNS, Get Started · Quad9, adresses et fonctionnalités · The State of Web Hosting Performance 2026, décomposition du temps avant premier octet. Données vérifiées le 30 août 2026.
Michel, dirigeant d’une PME informatique et formateur, expert en logiciels professionnels tels que CRM et ERP. Sa connaissance approfondie des outils de gestion d’entreprise lui permettant de conseiller et former efficacement d’autres sociétés à leur utilisation.
