DNS (Domain Name System)

Le DNS (Domain Name System, système de noms de domaine) est le service qui traduit un nom de domaine lisible par un humain, comme abondance.com, en adresse IP exploitable par une machine. Spécifié en 1987 par les RFC 1034 et 1035, il repose sur une hiérarchie de serveurs et sur des enregistrements (A, AAAA, CNAME, MX, TXT...) mis en cache pendant une durée appelée TTL. En SEO, il intervient dans le temps de réponse du site, dans la validation de propriété de la Search Console et dans toute migration d'hébergement.

Définition détaillée du DNS

Chaque machine connectée à Internet est identifiée par une adresse IP, numérique (192.0.2.10 en IPv4) ou alphanumérique (2001:db8::1 en IPv6). Les humains, eux, retiennent des noms. Le DNS fait le lien entre les deux : quand un navigateur doit charger www.exemple.fr, il demande d'abord au DNS quelle adresse IP se cache derrière ce nom, puis établit la connexion avec le serveur correspondant. Cloudflare le résume par une image : « le DNS est l'annuaire téléphonique d'Internet ».

Le système a été décrit par Paul Mockapetris dans deux documents de l'IETF publiés en novembre 1987, la RFC 1034 (« Domain names, concepts and facilities ») et la RFC 1035 (« Domain names, implementation and specification »). Ils remplaçaient un fichier unique, HOSTS.TXT, que chaque machine devait télécharger et qui ne passait plus à l'échelle. Le DNS est conçu comme une base de données distribuée et hiérarchique : personne ne détient la liste complète, chaque organisation fait autorité sur sa propre zone.

La hiérarchie se lit de droite à gauche dans un nom. Dans www.exemple.fr, la racine (un point implicite) délègue au domaine de premier niveau .fr, qui délègue à exemple.fr, dont le titulaire gère lui-même www et ses autres sous-domaines. Les extensions nationales comme .fr sont des ccTLD.

Comment fonctionne une résolution DNS

Quatre types de serveurs interviennent dans la résolution d'un nom, selon la description qu'en fait Cloudflare :

• Le résolveur récursif : le serveur que le navigateur interroge, en général celui du fournisseur d'accès, de l'entreprise, ou un résolveur public (1.1.1.1 de Cloudflare, 8.8.8.8 de Google). C'est lui qui mène l'enquête pour le compte du client.
• Le serveur racine : première étape, il indique où trouver les serveurs de l'extension demandée.
• Le serveur du TLD (.com, .fr...) : il indique quels serveurs font autorité pour le domaine demandé.
• Le serveur faisant autorité : celui qui détient réellement les enregistrements du domaine et renvoie la réponse finale, l'adresse IP.

Sans aucun cache, une résolution complète compte huit échanges entre le navigateur, le résolveur et ces serveurs, avant même que la première requête HTTP ne parte vers le site. En pratique, la plupart de ces étapes sont sautées grâce au cache : le navigateur, le système d'exploitation et le résolveur récursif conservent chacun les réponses récentes pendant la durée fixée par le TTL de l'enregistrement. Une résolution mise en cache prend une fraction de milliseconde ; une résolution complète peut prendre plusieurs dizaines de millisecondes, davantage sur un réseau mobile.

Les enregistrements DNS

Les enregistrements (resource records) sont les instructions stockées sur les serveurs faisant autorité pour un domaine. Chacun porte un type, une valeur et un TTL (time to live), la durée en secondes pendant laquelle un cache peut le conserver avant de le redemander. Les types les plus courants :

• A : associe un nom à une adresse IPv4. AAAA : la même chose en IPv6.
• CNAME (canonical name) : fait d'un nom l'alias d'un autre nom, sans donner d'adresse IP. C'est ainsi que www.exemple.fr pointe souvent vers exemple.fr, ou qu'un sous-domaine pointe vers un CDN ou un hébergeur de plateforme.
• MX (mail exchange) : désigne les serveurs qui reçoivent le courrier du domaine.
• TXT : stocke du texte libre. C'est l'enregistrement des preuves et des politiques : validation de propriété (Search Console, Google Workspace, Microsoft 365), SPF, DKIM et DMARC pour l'authentification des emails.
• NS : indique les serveurs de noms qui font autorité pour la zone. SOA : les informations administratives de la zone.
• CAA : liste les autorités de certification autorisées à émettre un certificat HTTPS pour le domaine.

Deux rôles sont souvent confondus : le bureau d'enregistrement (registrar), auprès de qui le nom de domaine est loué, et l'hébergeur DNS, qui fait tourner les serveurs faisant autorité. Ce peut être la même entreprise ou non. Les enregistrements NS déposés chez le registrar désignent l'hébergeur DNS ; c'est chez ce dernier que se modifient les enregistrements A, CNAME ou TXT.

Ce que le DNS change en SEO

Le temps de réponse

La résolution DNS est la première étape de toute visite, avant la connexion TCP, la négociation TLS et la requête HTTP. Elle entre donc dans le TTFB (Time To First Byte), dont web.dev liste les composantes : redirections, démarrage du service worker, résolution DNS, connexion et TLS, puis attente du premier octet. Un serveur DNS lent ou éloigné, ou un TTL trop court qui force des résolutions répétées, ajoute des dizaines de millisecondes à chaque nouvelle visite. À l'inverse, les grands hébergeurs DNS répondent depuis des réseaux anycast répartis dans le monde, et web.dev note que les fournisseurs de CDN « offrent généralement des temps de résolution DNS extrêmement rapides ».

Ce délai touche surtout la première visite et les visites après expiration du cache. Il ne pèse pas sur les visites répétées, ce qui explique qu'il passe inaperçu dans les tests menés depuis un poste habitué au site.

La validation de propriété dans la Search Console

La Search Console propose deux sortes de propriétés. La propriété « préfixe d'URL » couvre un seul protocole et un seul hôte (https://www.exemple.fr/) et se valide par fichier HTML, balise meta, Google Analytics ou Google Tag Manager. La propriété « domaine » couvre tous les sous-domaines et tous les protocoles d'un nom, et ne se valide que par le DNS : Google fournit une chaîne de la forme google-site-verification=..., à déposer dans un enregistrement TXT du domaine (ou, chez certains hébergeurs, un enregistrement CNAME). L'API Site Verification de Google documente ces deux méthodes sous les noms DNS_TXT et DNS_CNAME. L'enregistrement doit rester en place : le retirer fait perdre la validation.

La propriété domaine est la plus complète pour un site, puisqu'elle agrège les données de www, de la version sans www, de HTTP et de HTTPS, et de tous les sous-domaines.

Les migrations d'hébergement

Changer d'hébergeur ou passer derrière un CDN sans changer d'URL se fait par le DNS : on modifie l'enregistrement A (ou CNAME) pour pointer vers la nouvelle infrastructure. Dans son guide « Changing your hosting », Google demande de préparer ce basculement en abaissant le TTL des enregistrements « à une valeur prudemment basse (par exemple quelques heures), au moins une semaine avant le déplacement », afin que les caches des fournisseurs d'accès se rafraîchissent plus vite. Après le changement, les journaux des deux serveurs montrent le trafic qui se déplace de l'ancien vers le nouveau, à mesure que les caches expirent ; c'est ce que l'on appelle, par abus de langage, la « propagation DNS ». Rien ne se propage : chaque cache attend simplement la fin de son TTL.

Google prévient aussi qu'une baisse temporaire du rythme de crawl est normale juste après un changement d'hébergement, suivie d'une remontée progressive sur les jours suivants. Un changement de domaine, lui, relève de la migration SEO avec redirections, et non du seul DNS.

Les erreurs DNS

Un nom qui ne se résout pas rend le site inaccessible, pour les visiteurs comme pour Googlebot. La Search Console signale ces cas dans le rapport « Statistiques sur l'exploration », sous la rubrique de disponibilité de l'hôte. Les causes classiques : un domaine expiré, des enregistrements NS mal recopiés lors d'un changement d'hébergeur DNS, un CNAME qui pointe vers une cible disparue, ou une zone DNSSEC dont les signatures ne sont plus valides. Derrière un CDN, une erreur 522 signale que le DNS a bien fonctionné mais que le serveur d'origine ne répond pas.

Mesurer et diagnostiquer

• Interroger le DNS : la commande nslookup (Windows) ou dig (macOS, Linux) affiche les enregistrements et leur TTL depuis n'importe quel poste. Des outils en ligne interrogent des résolveurs répartis dans le monde pour vérifier qu'ils voient tous la même valeur après un changement.
• Mesurer le délai : l'onglet Réseau des outils de développement de Chrome décompose chaque requête, dont la phase « DNS Lookup » ; WebPageTest fait de même avec des points de test géographiques différents.
• Vérifier le cache local : Chrome expose l'état de son cache DNS à l'adresse chrome://net-internals/#dns.
• Préparer une migration : lister les enregistrements existants avant de toucher à la zone, abaisser les TTL une semaine avant, tester la nouvelle infrastructure sur un nom temporaire, puis remonter les TTL une fois le basculement stable.

Les erreurs fréquentes

• Oublier les enregistrements annexes lors d'un changement d'hébergeur DNS : les MX, les TXT de validation et d'authentification des emails, les sous-domaines. Le site fonctionne, mais le courrier ou la Search Console tombent.
• Laisser un TTL de 24 heures avant une migration, puis s'étonner que certains visiteurs voient l'ancien serveur pendant une journée.
• Fixer un TTL de quelques secondes en permanence, ce qui multiplie les résolutions et alourdit le temps de réponse sans autre bénéfice.
• Retirer l'enregistrement TXT de validation une fois la Search Console validée : la propriété est perdue à la prochaine vérification.
• Confondre registrar et hébergeur DNS, et chercher les enregistrements au mauvais endroit.

FAQ

Combien de temps dure la « propagation DNS » ?

Le temps que les caches expirent, c'est-à-dire la valeur du TTL des enregistrements modifiés, plus le temps que chaque résolveur mette à les redemander. Avec un TTL abaissé à quelques heures une semaine avant le changement, comme le recommande Google, le basculement est effectif en quelques heures. Avec un TTL de 24 ou 48 heures laissé en place, certains visiteurs voient l'ancienne valeur pendant un à deux jours.

Le DNS a-t-il un effet sur le classement Google ?

Pas directement. Le DNS n'est pas un critère de classement, mais il conditionne deux choses qui comptent : l'accessibilité du site (un nom qui ne se résout pas n'est pas crawlé) et le temps de réponse, dont la résolution DNS est la première composante. Un DNS lent ou instable dégrade donc l'exploration et l'expérience de chargement.

Quelle différence entre un enregistrement A et un CNAME ?

L'enregistrement A associe directement un nom à une adresse IPv4 (AAAA pour IPv6). Le CNAME fait d'un nom l'alias d'un autre nom, sans adresse : le résolveur doit ensuite résoudre la cible. On utilise le CNAME pour pointer un sous-domaine vers un CDN ou une plateforme dont l'adresse peut changer, et l'enregistrement A pour un serveur dont on maîtrise l'adresse.

Comment valider un domaine dans la Search Console par le DNS ?

Choisir le type de propriété « Domaine », copier la chaîne google-site-verification fournie par Google, la déposer dans un enregistrement TXT à la racine du domaine chez l'hébergeur DNS, attendre l'expiration du TTL, puis cliquer sur Valider. Certains hébergeurs proposent une variante par enregistrement CNAME. L'enregistrement doit rester en place ensuite.

Faut-il un TTL court ou long ?

Long (plusieurs heures) en régime normal, pour que les résolutions soient servies depuis le cache et n'alourdissent pas le temps de réponse. Court (quelques minutes à quelques heures) uniquement autour d'un changement d'infrastructure, abaissé au moins une semaine avant, puis remonté une fois le basculement stable.

En résumé

• DNS : le système distribué et hiérarchique qui traduit un nom de domaine en adresse IP, spécifié par les RFC 1034 et 1035 (1987).
• Résolution : résolveur récursif, serveur racine, serveur du TLD, serveur faisant autorité ; huit échanges sans cache, presque aucun avec.
• Enregistrements : A et AAAA (adresses), CNAME (alias), MX (courrier), TXT (validation, SPF, DKIM), NS, SOA, CAA ; chacun porte un TTL.
• SEO : première composante du TTFB, validation de la propriété « Domaine » dans la Search Console par enregistrement TXT, basculement d'hébergement par changement d'enregistrement.
• Migration : Google recommande d'abaisser le TTL à quelques heures au moins une semaine avant le changement d'hébergement.

Abondance c'est aussi des audits SEO, un service de contenus et des formations en e-learning !