Le DNS (Domain Name System) est le système qui permet de traduire un nom de domaine lisible – comme monentreprise.fr – en une adresse IP que les machines comprennent. Sans lui, il faudrait retenir des suites de chiffres pour accéder au moindre site.
Mais le DNS ne se limite pas à cette traduction. Il joue le rôle d’aiguilleur central de toute l’infrastructure en ligne d’une entreprise : c’est lui qui décide où arrive le site web, par quel serveur transitent les emails, quels services tiers sont autorisés à envoyer des messages au nom de l’entreprise. Quand tout fonctionne, personne n’y pense. Quand un enregistrement est mal configuré, c’est la panique : site inaccessible, emails qui partent en spam, newsletter bloquée.
Le DNS est invisible par nature, ce qui explique qu’il soit si souvent négligé. Pourtant, chaque prestataire web ou informatique qui intervient sur l’infrastructure d’une entreprise finit tôt ou tard par toucher à la zone DNS. C’est un sujet qui mérite d’être compris, au moins dans ses grandes lignes.
Une zone DNS est un fichier qui contient l’ensemble des enregistrements associés à un nom de domaine. Chaque enregistrement a un rôle précis. Les enregistrements A (et AAAA pour l’IPv6) pointent le domaine vers l’adresse IP du serveur qui héberge le site. Les enregistrements MX indiquent quel serveur gère les emails. Les enregistrements TXT servent à prouver la légitimité de l’expéditeur via des protocoles comme SPF, DKIM et DMARC – indispensables pour que les emails et newsletters arrivent en boîte de réception et non en spam.
S’ajoutent les enregistrements NS (qui désignent les serveurs DNS faisant autorité sur le domaine), les CNAME (alias qui redirigent un sous-domaine vers un autre nom) et le TTL (Time To Live), qui définit la durée pendant laquelle un enregistrement est mis en cache avant d’être redemandé. Chaque ligne de cette zone a un impact direct sur le fonctionnement du site, de la messagerie ou des outils connectés. Modifier un enregistrement sans comprendre l’ensemble, c’est risquer de couper un service sans le savoir.
Héberger un site web est le cas le plus évident : l’enregistrement A ou AAAA pointe le domaine vers le serveur d’hébergement. Lors d’une migration vers un nouvel hébergeur, c’est cet enregistrement qu’il faut modifier – et la propagation peut prendre de quelques minutes à 72 heures selon le TTL configuré et les caches des fournisseurs d’accès. Un TTL trop élevé avant une migration, et l’ancien site reste visible bien plus longtemps que prévu.
Envoyer des emails fiables repose entièrement sur le DNS. Les enregistrements MX dirigent les messages entrants vers le bon serveur. Mais c’est surtout côté envoi que ça se complique : chaque service qui expédie des emails au nom de l’entreprise – messagerie classique, CRM, outil de newsletter comme Brevo ou Mailjet – doit être déclaré dans les enregistrements TXT via les protocoles SPF et DKIM. Sans cette déclaration, les emails risquent d’être rejetés ou classés en spam par les destinataires.
Connecter des services tiers passe aussi par le DNS. Vérifier la propriété d’un domaine pour Google Search Console, activer un certificat SSL par validation DNS, configurer un sous-domaine pour une application métier : à chaque fois, c’est un enregistrement à ajouter ou modifier dans la zone.
Passer à l’IPv6 devient progressivement nécessaire. L’IPv4, avec ses adresses à 4 blocs de chiffres (comme 91.198.174.192), arrive à saturation. L’IPv6 offre un espace d’adressage quasi illimité, et les enregistrements AAAA dans le DNS permettent au domaine de répondre sur les deux protocoles simultanément.
Documenter chaque enregistrement est la première règle. Une zone DNS accumule des lignes au fil des années : anciens prestataires, services abandonnés, tests oubliés. Sans documentation, personne ne sait si un enregistrement TXT sert encore ou s’il date d’un outil qu’on n’utilise plus depuis trois ans. Un audit régulier de la zone évite cette dette technique invisible.
Centraliser la gestion DNS facilite le travail quand plusieurs intervenants touchent à l’infrastructure. Si le prestataire web, le prestataire informatique et l’hébergeur de messagerie interviennent chacun de leur côté sans visibilité sur l’ensemble, les conflits sont inévitables. Un service comme Cloudflare permet de regrouper la gestion DNS en un point unique, même si le domaine reste enregistré ailleurs.
Coordonner les interventions entre prestataires est essentiel. Le prestataire web a besoin que les enregistrements A pointent vers le bon serveur. Le prestataire informatique gère les MX et la messagerie. L’outil de newsletter exige ses propres enregistrements DKIM. Chaque modification doit être faite en connaissance de cause, idéalement par une seule personne qui a la vision d’ensemble de la zone.
Baisser le TTL avant une migration est un réflexe trop souvent oublié. Passer le TTL de 86 400 secondes (24 heures) à 300 secondes (5 minutes) un ou deux jours avant un changement d’hébergeur permet d’accélérer considérablement la propagation le jour J.
Confondre nom de domaine et DNS est l’erreur la plus fréquente. Le nom de domaine est l’adresse que l’on achète (monentreprise.fr). Le DNS est le système d’aiguillage qui lui donne vie. Posséder un domaine sans maîtriser sa zone DNS, c’est comme avoir une adresse postale sans boîte aux lettres – le courrier ne peut pas arriver.
Laisser des enregistrements obsolètes dans la zone est un piège courant. Un ancien enregistrement SPF qui référence un service abandonné, un CNAME qui pointe vers un serveur décommissionné, des enregistrements TXT de vérification devenus inutiles : tout cela encombre la zone et peut provoquer des comportements imprévisibles, notamment sur la délivrabilité des emails.
Dépasser la limite SPF passe souvent inaperçu. Le protocole SPF impose un maximum de 10 résolutions DNS par vérification. Quand une entreprise utilise plusieurs services d’envoi – messagerie Google, CRM, Brevo, outil de facturation – cette limite est vite atteinte. Au-delà, la vérification SPF échoue silencieusement et les emails sont rejetés sans que personne ne comprenne pourquoi.
Ne pas savoir qui gère le DNS est un problème plus fréquent qu’on ne le pense. Le domaine est chez un registrar, le DNS est peut-être chez l’hébergeur, ou chez un ancien prestataire, ou dans un compte Cloudflare dont plus personne n’a les accès. Le jour où il faut intervenir en urgence, cette confusion coûte des heures – parfois des jours. Chaque entreprise devrait savoir précisément où est gérée sa zone DNS et qui en détient les accès.
