Un domaine répond, un serveur expédie, un message passe ou se heurte à un refus, et l’écart vient parfois d’un réglage discret. Les confusions naissent vite, puis les anomalies se multiplient aussitôt.
Un même domaine peut viser une machine, alors que cette machine cherche à faire reconnaître le nom qui lui appartient. Entre la résolution de nom, l’adresse IP publique, le nom d’hôte annoncé et les réponses du système DNS, vous pouvez croire à une correspondance. Elle ne l’est pas. Voilà.
Le sens du forward DNS dans la résolution d’un nom
Lorsqu’un internaute saisit www.exemple.fr, son navigateur cherche l’adresse du serveur qui doit répondre. Pour cela, il déclenche une requête DNS classique vers le résolveur, puis vers les serveurs autoritaires du domaine, afin d’obtenir l’IP attendue et d’afficher la page sans exposer la suite de chiffres à l’écran. Voici le chemin type.
- Le nom de domaine est demandé par le navigateur.
- Le DNS renvoie l’adresse IP associée.
- Le navigateur contacte ensuite le serveur web trouvé.
Selon la version d’IP utilisée, la réponse n’est pas la même. Pour un site en IPv4, elle prend la forme d’un enregistrement A ; avec l’IPv6, elle repose sur un enregistrement AAAA. Après migration, ces données relient le nom à la machine. Un exemple : taper www.exemple.fr mène vers l’IP du serveur qui héberge la page, non vers son nom.
Pourquoi le reverse DNS ne sert-il pas au même usage ?
Le reverse DNS part d’une adresse IP publique et tente d’en retrouver le nom d’hôte déclaré. Au lieu de suivre le trajet habituel d’un domaine, le serveur lance une résolution inverse et effectue une recherche inverse pour vérifier quelle désignation a été publiée dans la zone dédiée.
À retenir : le reverse DNS sert surtout aux échanges entre serveurs et pèse nettement sur la confiance accordée à une IP d’envoi.
Ici, la réponse ne sert pas à ouvrir une page web. Elle prend la forme d’un enregistrement PTR, associé à l’IP par l’opérateur qui gère le bloc d’adresses. Cette donnée sert à l’identification du serveur par d’autres machines, pour la messagerie, les journaux réseau, des contrôles anti-spam ou des tests en ligne de commande, et explique pourquoi son usage diffère de celui du DNS direct.
Une relation inverse entre nom de domaine et adresse IP
Le forward DNS part du nom de domaine pour trouver l’adresse IP qui mène au bon service. À l’inverse, le reverse DNS remonte depuis une IP vers un nom déclaré dans un PTR, ce qui change le sens de résolution sans créer le même usage pour toutes les machines ni la même lecture côté serveur.
Cette symétrie apparente trompe parfois. Une correspondance DNS valable dans un sens n’impose pas le retour exact dans l’autre, et le lien nom IP peut rester partiel. Votre site répond très bien par son domaine, alors que l’adresse renvoie vers un nom technique, mutualisé, ou vers un hôte générique défini par l’hébergeur ou l’opérateur réseau selon la façon dont l’IP a été publiée.
À quel moment votre serveur utilise-t-il l’un ou l’autre ?
Lorsqu’un visiteur saisit votre domaine, le forward DNS traduit ce nom vers l’adresse du serveur web pour afficher la page demandée. Ce mécanisme permet l’accès au site, mais il intervient aussi quand une application joint une API, un espace client ou un sous-domaine précis. Côté courrier, un hôte distant peut consulter le reverse avant d’accepter la connexion entrante.
Sur le plan technique, le reverse apparaît aussi dans les traces. Dans un journal réseau, un nom d’hôte lisible aide à relier une IP à une machine, alors qu’un serveur de messagerie s’en sert pour qualifier l’émetteur. Certains systèmes de filtrage l’ajoutent au contrôle d’accès, sans remplacer la vérification directe de l’adresse dans leurs règles, journaux ou leurs alertes quand une connexion paraît suspecte.
Les zones DNS et les enregistrements impliqués
Pour un même domaine, la recherche directe relie un nom d’hôte à une adresse IP. Dans la zone directe, l’arborescence DNS porte des enregistrements A pour IPv4, AAAA pour IPv6, ainsi qu’un enregistrement CNAME lorsqu’un alias doit viser un autre nom canonique plutôt qu’une IP.
| Type | Code DNS | Zone utilisée | Rôle |
|---|---|---|---|
| A | 1 | Recherche directe | Associe un nom à une adresse IPv4 |
| AAAA | 28 | Recherche directe | Associe un nom à une adresse IPv6 |
| CNAME | 5 | Recherche directe | Crée un alias vers un nom canonique |
| PTR | 12 | Recherche inverse | Associe une adresse IP à un nom d’hôte |
Le mouvement inverse suit une autre logique, car il part de l’adresse pour retrouver le nom publié. Dans la zone inverse, l’enregistrement PTR répond à cette question, sans remplacer les A ou AAAA. Un serveur web peut donc résoudre aisément son nom sans difficulté, alors qu’un test de reverse retourne un résultat absent, ancien ou différent, ce qui crée une lecture incohérente du même hôte.
Pourquoi le reverse DNS dépend-il souvent de l’hébergeur ou du fournisseur d’accès ?
Quand vous gérez un domaine, l’interface DNS ne contrôle pas forcément chaque donnée liée au serveur. Le reverse dépend de l’adresse publique attribuée et donc du bloc d’adresses IP administré par un tiers. Selon l’offre, le gestionnaire IP peut être l’hébergeur, un opérateur cloud ou votre fournisseur d’accès. Les situations les plus courantes sont les suivantes.
- Sur un serveur dédié, le reverse se règle parfois dans la console de l’hébergeur.
- Sur une IP mutualisée, la modification passe par le support du prestataire.
- Sur certaines plages, le fournisseur délègue la gestion au client final.
Cette répartition vient de la chaîne d’attribution des ressources Internet. La délégation réseau passe des registres vers les opérateurs qui annoncent leurs plages et publient la zone inverse correspondante. Vous pouvez donc modifier un A ou un AAAA chez votre prestataire DNS, sans disposer du droit de changer le PTR tant que l’IP reste sous contrôle d’un autre acteur.
Le reverse DNS pèse sur la délivrabilité des e-mails
À la réception d’un e-mail, le serveur distant ne lit pas que l’expéditeur affiché. Parmi les signaux observés, le PTR lié à l’IP nourrit la réputation d’envoi et éclaire le jugement du système receveur. Un nom cohérent, stable et rattaché au domaine de messagerie inspire davantage confiance qu’une réponse absente, générique ou discordante.
À retenir : un PTR cohérent ne place pas seul vos messages en boîte de réception, mais son absence reste un signal défavorable pour de nombreux serveurs.
Face aux contrôles de messagerie, la cohérence technique pèse dans l’évaluation globale. Quand un serveur SMTP présente une identité qui correspond à son nom d’hôte, à son IP et à son PTR, il paraît plus crédible pour un filtre anti-spam. L’absence de reverse n’entraîne pas mécaniquement un blocage, mais elle alourdit le dossier chez plusieurs opérateurs de messagerie majeurs.
Comment vérifier un forward DNS et un reverse DNS sans se tromper ?
Le plus sûr consiste à vérifier le nom puis l’adresse IP, et à refaire le trajet en sens inverse. Avec la commande nslookup ou l’outil dig, vous interrogez d’abord le domaine pour obtenir un A ou un AAAA, puis l’IP pour lire le PTR renvoyé. Pour éviter une lecture partielle, voici les points à contrôler sur votre terminal ou en ligne.
- Relevez l’adresse IP obtenue via l’enregistrement A ou AAAA.
- Interrogez cette adresse IP pour récupérer la réponse PTR.
- Vérifiez que le nom renvoyé pointe à nouveau vers la même IP.
- Comparez le résultat depuis un terminal et un service en ligne.
Le contrôle ne s’arrête pas à la première réponse. Une vérification DNS utile confirme que le nom retourné par le PTR possède lui-même un enregistrement qui revient vers la même IP. Lors d’un test de résolution, comparez le nom demandé, l’adresse obtenue et la réponse inverse ; si la chaîne se casse à une étape, la configuration mérite une correction ciblée rapidement.
Les écarts de configuration qui créent des incohérences
Un domaine peut viser la bonne adresse et afficher un site qui répond sans erreur apparente. Le décalage apparaît quand le PTR de cette machine renvoie vers un autre serveur, signe d’une IP non alignée ou d’un nom d’hôte incohérent entre la zone directe, la zone inverse et le nom déclaré par le système.
Le problème reste discret au premier contrôle, car le web fonctionne alors que la réputation technique se dégrade. Un filtre mail, un outil de supervision ou un journal de sécurité peut signaler l’écart, tandis qu’un cache DNS conserve l’ancienne réponse et que la propagation DNS retarde la lecture de la correction selon le TTL appliqué, pendant quelques heures, voire plus.
Que faut-il aligner entre A, AAAA, PTR et nom d’hôte ?
Sur un serveur, le même nom doit mener vers les adresses publiées, sans variante cachée dans l’administration. Vous cherchez une cohérence des enregistrements entre l’A pour l’IPv4, l’AAAA pour l’IPv6 et le hostname du serveur, afin que le nom annoncé par la machine corresponde au nom réellement publié par les DNS publics et privés externes.
Si une pile double est active, le PTR doit renvoyer vers ce même nom, puis ce nom doit résoudre vers l’IP attendue. Le même principe vaut pour l’IPv4 et pour l’adresse IPv6, afin d’obtenir une résolution bidirectionnelle propre, utile aux outils de contrôle distants, aux journaux système et aux serveurs de messagerie dès leur déploiement initial.
Un duo technique à traiter séparément pour éviter les confusions
Quand on parle de DNS, la confusion vient du miroir entre deux requêtes. Le forward DNS part du nom de domaine pour rejoindre l’adresse IP, ce qui répond à des usages distincts de ceux du reverse. Celui-ci remonte depuis l’IP vers un nom d’hôte, afin de garder une configuration réseau lisible et cohérente pour les services, les journaux et les traces techniques du serveur.
Pour un domaine, le contrôle ne se fait donc pas au même moment. Vérifiez le forward DNS lors d’une mise en ligne de site, d’API ou d’application liée à votre présence en ligne publique. Vérifiez le reverse DNS quand un serveur envoie des e-mails, passe un audit ou alimente des logs. L’un rend le service joignable, l’autre confirme l’identité technique de l’IP.