Comment configurer les paramètres réseau pour utiliser Google Public DNS

Google Public DNS est un résolveur de système de noms de domaine gratuit et distribué mondialement, exploité par Google, accessible aux adresses 8.8.8.8 (primaire) et 8.8.4.4 (secondaire). Remplacer les serveurs DNS par défaut de votre FAI par ces adresses peut réduire la latence des recherches DNS, renforcer votre résolveur contre les attaques d’empoisonnement du cache, et éliminer les points de défaillance uniques causés par les pannes régionales des FAI.

Ce guide couvre le processus de configuration complet sous Windows, macOS, Linux et les routeurs réseau — y compris les techniques de persistance permanente, les adresses IPv6, les commandes de vérification, et les pièges courants que la plupart des tutoriels omettent.

Ce que fait réellement Google Public DNS

Lorsque vous saisissez un nom de domaine dans un navigateur, votre système d’exploitation envoie une requête à un résolveur DNS. Ce résolveur traduit le nom d’hôte lisible par l’homme en une adresse IP routable. Par défaut, ce résolveur est assigné par votre FAI via DHCP — et les résolveurs des FAI sont fréquemment plus lents, moins sécurisés, et parfois manipulés pour l’interception du trafic ou l’injection de publicités.

Google Public DNS exploite un réseau anycast couvrant plusieurs points de présence dans le monde entier. Chaque requête reçoit une réponse du nœud disponible le plus proche, minimisant le temps d’aller-retour. Google implémente également la validation DNSSEC, le DNS-over-HTTPS (DoH) et le DNS-over-TLS (DoT) — des protocoles qui chiffrent le canal de requête DNS et empêchent les attaquants sur le chemin de lire ou de falsifier vos recherches.

Adresses Google Public DNS (IPv4 et IPv6)

Si votre pile réseau est double pile (IPv4 + IPv6), configurez les deux lignes. Laisser le DNS IPv6 pointer vers votre FAI tandis que l’IPv4 utilise Google crée un comportement de résolution asymétrique qui peut provoquer des défaillances intermittentes lors des recherches d’enregistrements AAAA.

Google Public DNS vs. les résolveurs publics concurrents

Point clé : Le 1.1.1.1 de Cloudflare affiche systématiquement un temps de requête moyen plus faible pour les utilisateurs résidentiels en Amérique du Nord et en Europe occidentale. Le 8.8.8.8 de Google tend à surpasser en Asie-Pacifique et en Amérique latine en raison de la plus grande empreinte d’infrastructure de Google. Exécutez `namebench` ou `DNS Benchmark` sur votre réseau spécifique avant de vous engager avec un résolveur.

Configuration de Google Public DNS sur Windows

Étape 1 : Ouvrir les paramètres de l’adaptateur réseau

1. Appuyez sur `Win + R`, tapez `ncpa.cpl`, et appuyez sur Entrée. Cela ouvre directement Connexions réseau, en contournant la chaîne de navigation du Panneau de configuration.
2. Alternativement : Panneau de configuration > Centre Réseau et partage > Modifier les paramètres de l’adaptateur.

Étape 2 : Accéder aux propriétés IPv4

1. Faites un clic droit sur l’adaptateur actif — Ethernet ou Wi-Fi — et sélectionnez Propriétés.
2. Faites défiler la liste des composants, sélectionnez Protocole Internet version 4 (TCP/IPv4), et cliquez sur Propriétés.

Étape 3 : Saisir les adresses DNS Google

1. Sélectionnez Utiliser les adresses de serveur DNS suivantes.
2. Définissez :

• Serveur DNS préféré : `8.8.8.8`
• Serveur DNS auxiliaire : `8.8.4.4`

1. Cliquez sur OK, puis sur Fermer.

Étape 4 : Configurer le DNS IPv6 (Recommandé)

Répétez le processus pour Protocole Internet version 6 (TCP/IPv6) :

• Serveur DNS préféré : `2001:4860:4860::8888`
• Serveur DNS auxiliaire : `2001:4860:4860::8844`

Étape 5 : Vider le cache DNS et vérifier

Ouvrez l’Invite de commandes en tant qu’Administrateur et exécutez :

“`cmd

ipconfig /flushdns

nslookup google.com

“`

La sortie de `nslookup` devrait afficher `Server: dns.google` et `Address: 8.8.8.8` ou `8.8.4.4`. Si elle affiche toujours l’adresse du résolveur de votre FAI, la modification de l’adaptateur n’a pas été appliquée — vérifiez qu’aucun VPN ou client DNS tiers (par exemple, DNSCrypt-proxy) ne remplace le résolveur système.

Piège : Windows 11 a introduit le DNS-over-HTTPS au niveau du système d’exploitation. Pour l’activer, allez dans Paramètres > Réseau et Internet > [Adaptateur] > Attribution du serveur DNS > Modifier, définissez le DNS sur Manuel, entrez `8.8.8.8`, et définissez le menu déroulant DNS sur HTTPS sur Activé (modèle automatique). Sans cette étape, les requêtes transitent en texte clair même lors de l’utilisation des serveurs de Google.

Configuration de Google Public DNS sur macOS

Étape 1 : Ouvrir les paramètres réseau

• macOS Ventura et versions ultérieures : Réglages système > Réseau.
• macOS Monterey et versions antérieures : Préférences Système > Réseau.

Étape 2 : Sélectionner l’interface active

Choisissez Wi-Fi ou Ethernet dans la barre latérale, puis cliquez sur Détails (Ventura+) ou Avancé (versions antérieures).

Étape 3 : Configurer les serveurs DNS

1. Accédez à l’onglet DNS.
2. Cliquez sur le bouton + sous la liste des serveurs DNS.
3. Ajoutez `8.8.8.8`, puis ajoutez `8.8.4.4`.
4. Pour IPv6 : ajoutez `2001:4860:4860::8888` et `2001:4860:4860::8844`.
5. Cliquez sur OK, puis sur Appliquer.

Étape 4 : Vider le cache DNS macOS et vérifier

“`bash

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

nslookup google.com

“`

Piège : macOS respecte l’ordre des serveurs DNS dans la liste. Si vous avez un profil VPN d’entreprise qui injecte son propre serveur DNS en position 1, vos entrées Google DNS seront déprioritisées pour les domaines en tunnel divisé. Vérifiez Réglages système > VPN > DNS si la résolution se comporte de manière inattendue sur une machine gérée.

Configuration de Google Public DNS sur Linux

La configuration DNS sous Linux varie considérablement selon la distribution, le système init et le démon de gestion réseau. Trois méthodes distinctes couvrent la majorité des déploiements réels.

Méthode 1 : NetworkManager (GUI — La plupart des distributions de bureau)

1. Ouvrez Paramètres > Réseau.
2. Cliquez sur l’icône d’engrenage à côté de votre connexion active.
3. Allez dans l’onglet IPv4, définissez DNS sur Manuel, et entrez :

• `8.8.8.8, 8.8.4.4`

1. Répétez dans l’onglet IPv6 avec `2001:4860:4860::8888, 2001:4860:4860::8844`.
2. Désactivez et réactivez la connexion pour appliquer.

Méthode 2 : NetworkManager via nmcli (Serveurs sans interface graphique)

C’est l’approche correcte pour un environnement d’Hébergement VPS ou tout serveur Linux sans interface graphique exécutant NetworkManager :

“`bash

Identify the active connection name

nmcli connection show

Set DNS servers (replace "Wired connection 1" with your connection name)

nmcli connection modify "Wired connection 1" ipv4.dns "8.8.8.8 8.8.4.4"

nmcli connection modify "Wired connection 1" ipv4.ignore-auto-dns yes

nmcli connection modify "Wired connection 1" ipv6.dns "2001:4860:4860::8888 2001:4860:4860::8844"

nmcli connection modify "Wired connection 1" ipv6.ignore-auto-dns yes

Apply changes

nmcli connection up "Wired connection 1"

“`

L’indicateur `ipv4.ignore-auto-dns yes` est essentiel — sans lui, le DNS poussé via DHCP par votre FAI ou fournisseur d’hébergement remplacera vos entrées manuelles à chaque renouvellement de bail.

Méthode 3 : Netplan (Ubuntu 18.04+ et Debian 12+)

Sur les systèmes utilisant systemd-networkd ou NetworkManager via Netplan :

“`bash

sudo nano /etc/netplan/00-installer-config.yaml

“`

Ajoutez ou modifiez le bloc DNS :

“`yaml

network:

version: 2

ethernets:

eth0:

dhcp4: true

nameservers:

addresses:

• 8.8.8.8
• 8.8.4.4
• 2001:4860:4860::8888
• 2001:4860:4860::8844

“`

Appliquez la configuration :

“`bash

sudo netplan apply

“`

Méthode 4 : Modification directe de /etc/resolv.conf (Héritage / Conteneurs)

“`bash

sudo nano /etc/resolv.conf

“`

“`

nameserver 8.8.8.8

nameserver 8.8.4.4

options edns0 trust-ad

“`

Avertissement critique : Sur la plupart des distributions modernes, `/etc/resolv.conf` est un lien symbolique géré par `systemd-resolved` ou NetworkManager. Les modifications directes sont écrasées au redémarrage ou au redémarrage du réseau. Pour rendre les modifications permanentes via `systemd-resolved` :

“`bash

sudo nano /etc/systemd/resolved.conf

“`

“`ini

[Resolve]

DNS=8.8.8.8 8.8.4.4

FallbackDNS=2001:4860:4860::8888 2001:4860:4860::8844

DNSSEC=yes

DNSOverTLS=yes

“`

“`bash

sudo systemctl restart systemd-resolved

“`

Vérification sur Linux

“`bash

resolvectl status # systemd-resolved systems

cat /etc/resolv.conf # confirm symlink target

nslookup google.com

dig google.com @8.8.8.8 # force query to Google DNS directly

“`

La commande `dig` avec `@8.8.8.8` est plus fiable que `nslookup` pour vérifier que le résolveur lui-même est accessible et retourne des réponses correctes.

Configuration de Google Public DNS sur un routeur

La configuration DNS au niveau du routeur propage le paramètre à chaque appareil du réseau via DHCP, ce qui en fait l’approche la plus efficace pour les foyers ou les petits bureaux. C’est également la méthode recommandée lors de la gestion de plusieurs appareils — y compris le matériel IoT qui n’expose pas les paramètres DNS.

Étape 1 : Accéder au panneau d’administration du routeur

Ouvrez un navigateur et accédez à l’adresse IP de la passerelle de votre routeur :

• Adresses courantes : `192.168.1.1`, `192.168.0.1`, `10.0.0.1`
• Si inconnue, exécutez `ipconfig` (Windows) ou `ip route | grep default` (Linux/macOS) et notez la Passerelle par défaut.

Connectez-vous avec vos identifiants d’administrateur. Si vous ne les avez jamais modifiés, vérifiez l’étiquette sur le châssis du routeur.

Étape 2 : Localiser les paramètres DNS

Les paramètres DNS se trouvent généralement sous l’un de ces chemins de menu selon le firmware :

• Paramètres WAN > DNS
• Internet > Serveur DNS
• Avancé > Serveur DHCP > DNS
• LAN > Paramètres DHCP > DNS

Certains routeurs séparent le DNS WAN (utilisé par le routeur lui-même pour les requêtes sortantes) du DNS DHCP (transmis aux clients). Configurez les deux si présents.

Étape 3 : Saisir les adresses DNS Google

• DNS primaire : `8.8.8.8`
• DNS secondaire : `8.8.4.4`

Enregistrez et redémarrez le routeur.

Étape 4 : Vérifier la résolution des clients

Sur tout appareil connecté, exécutez :

“`bash

nslookup google.com

“`

Confirmez que le champ `Server` affiche `8.8.8.8` ou `8.8.4.4`. S’il affiche l’adresse IP LAN du routeur (par exemple, `192.168.1.1`), le routeur agit comme un proxy DNS — il transmet les requêtes à Google mais apparaît localement comme le résolveur. Il s’agit d’un comportement normal sur la plupart des routeurs grand public et n’indique pas une mauvaise configuration.

Piège : Certains FAI utilisent le détournement DNS — ils interceptent le trafic UDP sur le port 53 et redirigent toutes les requêtes DNS vers leurs propres serveurs, quelle que soit l’adresse IP que vous configurez. Si `nslookup` retourne systématiquement l’adresse du résolveur de votre FAI même après avoir modifié les paramètres, testez avec DNS-over-HTTPS ou DNS-over-TLS, qui fonctionnent sur des ports différents (443 et 853 respectivement) et sont plus difficiles à intercepter.

Activation du DNS chiffré : DoH et DoT

Configurer `8.8.8.8` sans chiffrement signifie que les requêtes transitent en texte clair via UDP sur le port 53 — lisibles par tout observateur sur le chemin. Pour les environnements de production, en particulier sur un Serveur Dédié ou toute infrastructure gérant des charges de travail sensibles, le DNS chiffré est fortement recommandé.

Point de terminaison DoH de Google : `https://dns.google/dns-query`

Nom d’hôte DoT de Google : `dns.google`

Pour configurer DoT dans `systemd-resolved` :

“`ini

[Resolve]

DNS=8.8.8.8#dns.google 8.8.4.4#dns.google

DNSOverTLS=yes

“`

Le suffixe `#dns.google` épingle le nom d’hôte du certificat TLS, empêchant les attaques de rétrogradation où un attaquant substitue un serveur différent à la même adresse IP.

Considérations de sécurité et limitations connues

• Validation DNSSEC : Google Public DNS effectue une validation DNSSEC complète. Si la chaîne DNSSEC d’un domaine est brisée, Google retournera `SERVFAIL` plutôt qu’une réponse non signée. Cela peut révéler des zones mal configurées que d’autres résolveurs acceptent silencieusement.
• Compromis sur la confidentialité : Google enregistre l’adresse IP complète de la requête pendant jusqu’à 48 heures avant anonymisation. Pour les environnements avec des exigences strictes en matière de résidence des données, Quad9 ou un résolveur auto-hébergé (Unbound, BIND) peut être préférable.
• DNS à horizon divisé : Si votre infrastructure utilise des noms d’hôtes internes (par exemple, `db.internal.corp`) qui ne sont pas résolvables publiquement, pointer tout le DNS vers Google cassera la résolution interne. Utilisez le DNS divisé — routez les domaines internes vers votre résolveur interne et les domaines externes vers Google. Cela est configurable dans NetworkManager, Unbound et la plupart des pare-feux d’entreprise.
• TTL et mise en cache : Google Public DNS respecte les valeurs TTL faisant autorité. Il n’étend pas artificiellement les TTL. Si vous dépannez un problème de propagation DNS après la mise à jour des enregistrements sur votre Enregistrement de domaine, le délai est régi par le TTL du serveur faisant autorité, et non par le comportement du résolveur de Google.

Configuration DNS pour les environnements hébergés

Lors de la gestion d’un VPS avec cPanel ou tout environnement d’hébergement basé sur un panneau de contrôle, la configuration DNS fonctionne à deux niveaux distincts :

1. Résolveur système (`/etc/resolv.conf` ou `systemd-resolved`) — contrôle la façon dont le serveur lui-même résout les noms d’hôtes pour les connexions sortantes, les téléchargements de paquets et les services internes.
2. DNS faisant autorité — contrôle la façon dont les clients externes résolvent vos domaines hébergés. Cela est géré via vos serveurs de noms, et non via le résolveur système.

Changer le résolveur système en `8.8.8.8` n’affecte que la couche 1. Cela n’a aucun effet sur la façon dont vos domaines hébergés sont résolus par les visiteurs. Pour la gestion du DNS faisant autorité, configurez vos enregistrements de zone via votre bureau d’enregistrement ou votre panneau d’hébergement DNS.

De même, si vous exécutez des services de messagerie sur une infrastructure d’Hébergement Email, assurez-vous que vos enregistrements SPF, DKIM et DMARC sont correctement publiés dans votre zone DNS faisant autorité — ceux-ci sont indépendants du résolveur récursif utilisé par votre serveur.

Matrice de décision technique : Quand utiliser Google Public DNS

Liste de contrôle pratique avant et après la configuration

Avant de modifier le DNS :

• Notez vos adresses de serveur DNS actuelles (`ipconfig /all` sur Windows, `resolvectl status` sur Linux)
• Testez la vitesse de résolution de base : `dig google.com` et enregistrez le temps de requête
• Identifiez si votre réseau utilise le DNS à horizon divisé pour les noms d’hôtes internes
• Vérifiez si un client VPN gère le DNS indépendamment

Après avoir modifié le DNS :

• Videz le cache DNS du système d’exploitation
• Exécutez `nslookup google.com` et confirmez l’adresse du serveur
• Exécutez `dig google.com @8.8.8.8` pour vérifier l’accessibilité directe
• Testez un nom d’hôte interne si le DNS divisé est utilisé
• Confirmez la validation DNSSEC : `dig dnssec-failed.org` devrait retourner `SERVFAIL`
• Sur les serveurs Linux, vérifiez que la modification survit à un redémarrage réseau : `sudo systemctl restart NetworkManager && resolvectl status`

FAQ

Le passage à Google Public DNS affecte-t-il les enregistrements DNS ou l’hébergement de mon site web ?

Non. Votre résolveur système détermine la façon dont votre machine recherche d’autres domaines. Cela n’a aucun effet sur la façon dont les enregistrements de votre propre domaine sont publiés ou résolus par les visiteurs externes. Vos serveurs de noms faisant autorité contrôlent cela.

Google Public DNS fonctionnera-t-il sur un VPS ou un serveur dédié ?

Oui. Le processus de configuration est identique à celui d’une machine locale. Sur les serveurs sans interface graphique, utilisez `nmcli` ou modifiez `/etc/systemd/resolved.conf` pour des modifications permanentes. Sachez que certains fournisseurs d’hébergement poussent le DNS via DHCP — utilisez `ipv4.ignore-auto-dns yes` dans NetworkManager pour éviter les remplacements.

Pourquoi nslookup affiche-t-il l’adresse IP de mon routeur au lieu de 8.8.8.8 ?

La plupart des routeurs grand public agissent comme des proxies DNS — ils reçoivent votre requête, la transmettent au résolveur en amont (Google) et retournent la réponse. L’adresse IP locale affichée est le proxy, et non le résolveur en amont. Il s’agit d’un comportement attendu. Pour confirmer que Google est bien le résolveur en amont, vérifiez les paramètres DNS WAN du routeur ou exécutez `dig google.com` et inspectez la réponse complète.

Comment tester si mes requêtes DNS sont chiffrées ?

Utilisez le test de navigateur de Cloudflare sur `1.1.1.1/help` pour DoH, ou exécutez `kdig -d @8.8.8.8 +tls-ca google.com` en utilisant le package `knot-dnsutils` pour vérifier une poignée de main DoT. Une poignée de main TLS réussie confirme le transport chiffré.

Google Public DNS peut-il ralentir la résolution pour certaines régions ?

Dans de rares cas, oui. Le routage anycast dirige votre requête vers le nœud Google le plus proche, mais la topologie réseau ne s’aligne pas toujours avec la proximité géographique. Si vous observez une latence plus élevée que prévu, effectuez des tests comparatifs avec `namebench` ou `DNS Benchmark` pour comparer Google, Cloudflare et le résolveur de votre FAI depuis votre emplacement réseau spécifique avant d’effectuer un changement permanent.