DNS public Google : adresses, configuration et rôle dans vos réseaux informatiques

Le dns public google, c’est ce résolveur récursif gratuit que tout le monde connaît via les adresses 8.8.8.8 et 8.8.4.4. Lancé fin 2009, il s’est imposé comme une solution simple et solide quand le DNS de votre FAI commence à faire des siennes. Dans un réseau informatique, le choix du résolveur n’est jamais anodin : il impacte la vitesse perçue, la stabilité des connexions et même un peu la surface d’attaque. Alors autant savoir précisément ce que ça apporte… et ce que ça n’apporte pas.

Qu’est-ce que le DNS public Google exactement ?

Google propose deux serveurs IPv4 principaux : 8.8.8.8 en primaire et 8.8.4.4 en secondaire. Côté IPv6, ce sont 2001:4860:4860::8888 et 2001:4860:4860::8844. Le système repose sur un réseau anycast mondial, donc votre requête part vers le point de présence le plus proche. Ça réduit la latence et améliore la résilience : si un site a un souci, les autres prennent le relais sans que vous vous en rendiez compte.

Le service respecte les standards (EDNS0, DNSSEC en validation côté client possible) et renvoie les réponses « propres », sans les redirections NXDOMAIN que certains opérateurs aiment bien injecter. En clair, quand vous tapez un nom de domaine, vous obtenez ce qu’il y a vraiment dans les zones DNS, ni plus ni moins.

Pourquoi ça change quelque chose dans un réseau ?

Le DNS de l’opérateur est souvent le maillon faible. Lent, parfois manipulé, et rarement chiffré. Passer sur le dns public google, c’est court-circuiter tout ça. Vos machines résolvent plus vite, surtout pour les services mondiaux qui utilisent des CDN. Et comme Google maintient un cache agressif, les requêtes répétées reviennent presque instantanément.

D’ailleurs, le support d’EDNS Client Subnet (ECS) permet aux CDN de mieux savoir d’où vient la requête et de servir le contenu depuis le datacenter le plus proche. Sur des gros sites ou des applications SaaS, la différence se voit.

Côté sécurité, le gros plus arrive avec le chiffrement. Google propose du DNS over TLS (DoT) sur le port 853 avec le nom d’hôte dns.google, et du DNS over HTTPS (DoH). Les requêtes ne circulent plus en clair sur le réseau local ou chez le FAI. C’est déjà une belle amélioration contre l’espionnage et le spoofing DNS.

Ce qu’il faut savoir sur les logs et la vie privée

Google est plutôt transparent. Les logs temporaires (IP source + détails de la requête) sont conservés entre 24 et 48 heures maximum, principalement pour détecter les abus et les attaques. Les logs permanents sont agrégés et anonymisés : nom de domaine demandé, type de requête, protocole utilisé (y compris TLS ou HTTPS), numéro d’AS du client et une localisation approximative au niveau région ou ville. Pas d’identification personnelle, rien de lié à un compte Google.

C’est mieux que beaucoup de FAI, mais ce n’est pas le résolveur le plus « zéro connaissance » qui existe. Si votre priorité absolue est la minimisation des traces, d’autres options existent.

Comparaison rapide avec les alternatives du moment

En 2026, trois noms reviennent tout le temps : Google, Cloudflare (1.1.1.1 / 1.0.0.1) et Quad9 (9.9.9.9).

Cloudflare gagne souvent les benchmarks de latence pure, surtout en Europe et en Amérique du Nord. Quad9 filtre les domaines malveillants par défaut, ce qui peut être intéressant pour un réseau d’entreprise ou familial. Google reste excellent sur la cohérence des réponses et l’optimisation CDN grâce à l’ECS.

Beaucoup d’administrateurs font d’ailleurs du primaire/secondaire mixte : 8.8.8.8 + 1.1.1.1 par exemple. Ça donne à la fois la performance et une redondance réelle si l’un des deux a un petit moment de faiblesse.

Configurer le dns public google sur votre infrastructure

La méthode la plus propre reste de le faire au niveau du routeur ou de la box. Tous les appareils du LAN en profitent sans rien toucher sur chaque poste.

Sur la plupart des routeurs grand public ou pros (Livebox, Freebox, Ubiquiti, pfSense, MikroTik…), vous cherchez la section DNS ou les paramètres WAN/LAN. Vous remplacez les serveurs actuels par 8.8.8.8 en primaire et 8.8.4.4 en secondaire (et les équivalents IPv6 si vous gérez du dual-stack). Validez, redémarrez le routeur, et testez depuis un poste client avec nslookup ou dig.

Sur Windows, ouvrez le Centre Réseau et partage, modifiez les paramètres de l’adaptateur, clic droit sur la connexion Ethernet ou Wi-Fi, Propriétés, puis Protocole Internet version 4 (TCP/IPv4). Cochez « Utiliser les adresses de serveur DNS suivantes » et saisissez les deux adresses. Faites la même chose pour IPv6 si besoin. Appliquez et renouvelez la configuration IP (ipconfig /renew).

Sur macOS, c’est dans Préférences Système > Réseau > votre connexion > Avancé > onglet DNS. Ajoutez les adresses dans la liste et validez.

Sous Linux, ça dépend de la distribution. Avec NetworkManager (Ubuntu, Fedora…), vous passez par l’interface graphique des connexions. Sinon, vous éditez /etc/resolv.conf (ou la configuration de systemd-resolved) et vous ajoutez les lignes nameserver 8.8.8.8 et nameserver 8.8.4.4. Sur les serveurs, pensez aussi à netplan ou à la config DHCP client si vous voulez que ça survive aux redémarrages.

Sur Android 9 et plus récent, le plus simple pour chiffrer les requêtes est d’aller dans Paramètres > Réseau et Internet > DNS privé et de saisir dns.google. Ça active automatiquement le DoT en mode strict ou opportuniste selon votre choix.

Sur iOS, par réseau Wi-Fi : touchez le (i) à côté du réseau, faites défiler jusqu’à DNS et passez en mode Manuel pour ajouter les adresses.

Activer le chiffrement DNS over TLS

Si vos terminaux le supportent, activez-le. Sur Android c’est ce que je viens de décrire. Sur les navigateurs récents (Chrome, Firefox, Edge), vous pouvez forcer le DoH vers https://dns.google/dns-query. Les requêtes deviennent invisibles pour quiconque écoute sur le réseau local.

Le service Google implémente TLS 1.3 et reste performant. Ce n’est pas parfait (le mode opportuniste peut fallback sur du clair), mais c’est largement suffisant pour la plupart des usages.

Quand est-ce que ça vaut vraiment le coup ?

Dans la plupart des réseaux de TPE, de particuliers un peu techniques, ou même en backup sur des infra plus grosses, le dns public google est un excellent choix par défaut. Il règle les lenteurs et les bizarreries des DNS d’opérateurs, il est fiable, et le déploiement est trivial.

En revanche, si vous avez un DNS interne avec des zones split, des politiques de filtrage fines, ou des exigences de traçabilité/compliance très strictes, il faudra le combiner avec un résolveur local (Unbound, BIND, ou une solution managée) qui forwarde vers Google en amont. Et si vous voulez du blocage malware ou ad/tracker sans effort, Quad9 ou des services comme NextDNS seront plus adaptés.

Bref, testez. Changez les DNS sur votre routeur un soir, mesurez la latence avant/après sur quelques sites critiques, et voyez ce que ça donne dans votre environnement réel. Souvent, le gain est immédiat et sans douleur. Et si jamais ça ne convient pas, revenir en arrière prend deux minutes. C’est ça, la beauté d’un résolveur public bien fait.