DNS et Reverse DNS : le duo qui structure vraiment vos réseaux informatiques
Dans n’importe quelle infrastructure réseau un peu sérieuse, le DNS direct fait le gros du travail au quotidien. Il transforme un nom compréhensible en adresse IP que les machines peuvent joindre. Mais sans son inverse, le reverse DNS, beaucoup de choses restent bancales. Le truc c’est que les deux ne font pas la même chose, et pourtant ils se complètent à la perfection pour la fiabilité, la sécurité et même la délivrabilité de vos emails.
Le DNS classique, celui qu’on configure tous les jours, repose sur des enregistrements A ou AAAA. Vous déclarez que « mail.monentreprise.fr » pointe vers 203.0.113.45 et c’est bon. Les clients résolvent, les applications se connectent, tout roule. Sur un réseau interne, votre serveur DNS gère les noms de vos machines, vos services, vos conteneurs. À l’extérieur, c’est votre provider ou votre zone publique qui répond. Simple, rapide, indispensable.
Le reverse DNS, ou DNS inversé, fait le chemin exactement inverse. À partir d’une IP, il retrouve le nom d’hôte ou le FQDN associé. Pour ça, il utilise des enregistrements PTR stockés dans des zones spéciales : in-addr.arpa pour l’IPv4 et ip6.arpa pour l’IPv6. Concrètement, pour l’adresse 203.0.113.45, la requête DNS va chercher dans la zone 45.113.0.203.in-addr.arpa. Si un PTR existe, il renvoie quelque chose comme « mail.monentreprise.fr ». Sinon, rien. Ou un nom générique du genre « host-203-0-113-45.provider.net » qui ne vaut pas grand-chose.
Pourquoi ça change la donne ? Parce que de très nombreux systèmes s’appuient sur cette information pour décider de faire confiance ou non. Les serveurs de messagerie en premier lieu. Quand un autre MTA reçoit un message, il regarde souvent l’IP d’origine, fait un reverse lookup et compare avec ce que le serveur annonce dans son HELO ou EHLO. Si rien ne revient ou si ça ne colle pas, le message atterrit dans les spams ou se fait rejeter direct. Et depuis février 2024, Google et Yahoo ont durci le ton : ils exigent notamment un FCrDNS valide, c’est-à-dire que le PTR existe ET que le nom qu’il indique pointe bien en retour vers la même IP via un enregistrement A. C’est la boucle complète. Sans ça, vos envois risquent d’être beaucoup plus durement traités.
Dans un réseau d’entreprise ou d’hébergement, le reverse DNS rend aussi les logs bien plus lisibles. Au lieu de voir défiler des IPs dans vos fichiers syslog ou vos alertes firewall, vous voyez directement « backup-srv-03 » ou « web-front-02 ». Le monitoring gagne en clarté, le troubleshooting va plus vite. Et quand vous analysez un incident de sécurité, savoir quel nom d’hôte correspond réellement à une IP suspecte peut faire gagner des heures.
Configurer le tout demande un peu d’organisation, surtout pour le reverse. Le DNS direct, vous le maîtrisez généralement via votre registrar, Cloudflare, Route 53 ou votre serveur BIND/PowerDNS interne. Pour le reverse, c’est souvent le propriétaire du bloc IP qui décide. Si vous êtes chez un FAI ou un hébergeur avec une IP dédiée, vous leur demandez d’ajouter le PTR. Ils gèrent la zone et vous n’avez qu’à leur donner le nom d’hôte voulu. Si vous avez votre propre délégation reverse (via RIPE par exemple), vous créez vous-même la zone master pour « x.y.z.in-addr.arpa » sur vos serveurs DNS et vous y placez les enregistrements PTR un par un ou via des scripts quand vous déployez des machines.
Avec l’IPv6 qui devient courant, le principe ne change pas, mais la notation est plus verbeuse : chaque nibble de l’adresse est inversé et séparé par des points avant d’ajouter .ip6.arpa. La plupart des providers modernes gèrent ça correctement, mais il faut quand même vérifier.
Pour tester, rien ne vaut les outils classiques. Un dig -x 203.0.113.45 ou un nslookup 203.0.113.45 vous donne la réponse en deux secondes. Vous pouvez aussi enchaîner avec une résolution directe du nom obtenu pour valider le FCrDNS. Les outils web font le job pour un check rapide, mais sur un vrai réseau on reste sur la ligne de commande pour les diagnostics sérieux.
Les erreurs qui reviennent le plus souvent ? Oublier tout simplement de demander le reverse DNS à son provider. Ou configurer un PTR qui pointe vers un nom générique que les filtres anti-spam n’aiment pas. Ou encore avoir un mismatch entre le forward et le reverse : l’IP pointe vers « mail.monentreprise.fr » mais ce nom résout vers une autre adresse. Certains serveurs stricts bloquent dans ce cas. Et sur les IPs dynamiques, c’est rarement stable, donc mieux vaut réserver des adresses fixes pour tout ce qui touche à l’email ou aux services exposés.
Au bout du compte, le DNS et le reverse DNS ne sont pas deux fonctionnalités séparées. C’est un système bidirectionnel qui rend vos infrastructures plus lisibles, plus fiables et mieux acceptées par le reste d’internet. Prendre le temps de bien les aligner dès le départ évite pas mal de galères plus tard, surtout quand on commence à scaler ou qu’on ajoute des flux email, des API ou du monitoring externe. C’est du détail technique, oui, mais c’est le genre de détail qui fait la différence entre un réseau qui « marche à peu près » et un réseau qui inspire confiance.
