Recherche DNS inverse
Saisissez une adresse IPv4 ou IPv6 et découvrez instantanément à qui appartient l'IP : enregistrement PTR, vérification FCrDNS, ASN et organisation d'origine. La vérification la plus importante avant de mettre une IP sur Internet, en particulier pour la messagerie. La recherche s'exécute depuis Frankfurt FRA01, sans journalisation.
Qu'est-ce que le DNS inverse ?
Le DNS inverse (rDNS) est le sens inverse du DNS normal. Là où le DNS direct associe un nom (kernelhost.com) à une adresse IP, le DNS inverse associe l'IP à un nom. Le type d'enregistrement utilisé est PTR (Pointer). Les noms inverses résident dans deux espaces de noms dédiés : in-addr.arpa pour IPv4 et ip6.arpa pour IPv6, chacun construit à partir de l'IP en ordre inversé d'octets ou de nibbles.
Exemple : l'IP 8.8.8.8 devient 8.8.8.8.in-addr.arpa. Une requête PTR sur ce nom renvoie le nom d'hôte (dns.google en l'occurrence). Pour IPv6, l'adresse 2001:db8::1 devient 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa, chaque nibble hexadécimal de l'adresse étant affiché séparément et inversé.
Qui contrôle un enregistrement PTR ? Le propriétaire de la plage IP, généralement le fournisseur en amont, l'hébergeur ou le FAI. Les propriétaires de domaines ne peuvent pas définir eux-mêmes les enregistrements PTR, sauf s'ils obtiennent la délégation de la plage IP (rare, possible pour des blocs /24 ou plus). Pour un VPS unique, le PTR se définit dans le panneau de contrôle de l'hébergeur ou via un ticket de support.
FCrDNS : DNS inverse confirmé en direct
FCrDNS est la raison la plus importante de se soucier des enregistrements PTR. L'idée est simple : l'enregistrement PTR vous donne un nom d'hôte, puis vous résolvez ce nom d'hôte en direct via A ou AAAA, et l'IP renvoyée doit correspondre à l'IP d'origine. Si c'est le cas, le PTR est considéré comme fiable. Sinon, le PTR est considéré comme usurpé et ignoré par la plupart des contrôles modernes.
Les serveurs de messagerie (Postfix, Exim, OpenSMTPD) et les filtres antispam (SpamAssassin, rspamd, Postscreen) vérifient FCrDNS à chaque connexion entrante. Un échec FCrDNS ajoute typiquement 1,0 à 3,5 points au score de spam (souvent suffisant pour finir en courrier indésirable), et de nombreux grands fournisseurs (Google, Microsoft, Yahoo) rejettent purement et simplement la connexion avec une erreur 550. Sans FCrDNS valide, votre serveur de messagerie n'existe pour ainsi dire pas.
Vérification FCrDNS par cet outil : nous lisons l'enregistrement PTR, puis résolvons chaque nom d'hôte renvoyé en direct via A (IPv4) ou AAAA (IPv6) et comparons les IP renvoyées à l'IP d'origine. Le badge vous l'indique immédiatement : vert pour vérifié, jaune s'il n'y a aucun enregistrement direct, rouge en cas d'incohérence avec la liste des destinations réelles.
Cas d'usage courants
Voici à quoi sert réellement cet outil au quotidien :
- Mise en service d'un serveur de messagerie : Avant d'envoyer le premier courriel depuis une nouvelle IP, le PTR doit être défini et FCrDNS doit être vert. Sinon Gmail, Outlook et d'autres rejetteront ou classeront en indésirable chaque message envoyé. Vérifiez ici, corrigez dans le panneau de contrôle de votre fournisseur, vérifiez à nouveau.
- Analyse de spam : Lorsque vous recevez du spam, consultez le PTR de l'IP source. Un PTR manquant ou cassé est un signal fort de spam. Un PTR pointant vers un nom de pool FAI générique (dsl-broadband-pool-... etc.) est un autre indicateur classique.
- Analyse de logs et forensique : Une IP apparaît dans vos journaux. De qui s'agit-il ? Le rDNS vous donne le nom d'hôte (souvent quelque chose comme ec2-..., crawler-..., cdn-...) et, combiné à l'ASN, vous indique le fournisseur cloud, le pays et l'organisation. Décidez en quelques secondes s'il s'agit d'un bot légitime, d'un client cloud connu ou de quelque chose à bloquer.
- Opérations réseau : Lors du débogage d'un traceroute, les sauts intermédiaires sont identifiés par PTR. Les routeurs le long du chemin ont généralement des PTR descriptifs (frankfurt-edge1.isp.net, lhr-core2.example.com etc.) qui vous indiquent le trajet géographique et topologique emprunté par votre paquet.
- Signalements d'abus : Besoin de déposer un signalement d'abus ? Le PTR et l'ASN vous indiquent quel fournisseur contacter (abuse@<org>). Sans rDNS, vous devriez chercher l'IP dans les bases whois de RIPE/ARIN, ce qui est plus lent.
Comment définir un enregistrement PTR
Les enregistrements PTR ne se définissent pas sur votre serveur de noms faisant autorité pour la zone directe. Ils se définissent sur la zone inverse, qui est déléguée par le propriétaire de l'IP (ARIN, RIPE, APNIC, LACNIC, AfriNIC) jusqu'à l'entreprise détenant le bloc d'IP. Pour un VPS unique ou un serveur dédié, cela signifie : demandez à l'hébergeur de définir le PTR, n'essayez pas de le configurer dans votre propre panneau DNS.
La plupart des hébergeurs proposent une gestion en libre-service des PTR dans le portail client. Pour les VPS et serveurs dédiés KernelHost, le champ rDNS est disponible directement dans le panneau de gestion du serveur et les modifications de PTR sont effectives en 5 à 10 minutes. Pour les IP en colocation, la procédure standard consiste à ouvrir un ticket de support indiquant le nom d'hôte souhaité par IP.
Bonne pratique pour la messagerie : PTR et HELO doivent correspondre. Si votre serveur de messagerie s'annonce comme mail.example.com (HELO mail.example.com), alors le PTR de l'IP doit être mail.example.com, et mail.example.com doit se résoudre via A vers la même IP. Les trois alignés = FCrDNS vert = réputation saine.
Le rDNS chez KernelHost
Chaque VPS, serveur dédié, serveur mail et serveur Minecraft KernelHost est livré avec une gestion en libre-service du PTR, à la fois pour IPv4 et IPv6. Vous définissez le nom d'hôte par IP dans le panneau de contrôle et la modification est effective en quelques minutes, sans ticket de support. Pour les blocs d'IP (/29 ou plus), l'intégralité de la zone inverse peut être déléguée à vos propres serveurs de noms.
Notre infrastructure DNS fonctionne en Anycast signé DNSSEC à Frankfurt et Vienne, de sorte que les recherches PTR depuis n'importe où dans le monde se résolvent en quelques dizaines de millisecondes. Si vous êtes sur le point de mettre en service un serveur de messagerie sur une nouvelle IP et souhaitez la réputation la plus propre possible dès le premier jour, la combinaison rDNS KernelHost + DKIM/SPF/DMARC dans le même panneau vous épargne le cycle de débogage typique du premier jour.
Questions fréquentes
Quelle est la différence entre une recherche DNS et une recherche DNS inverse ?
Une recherche DNS directe prend un nom d'hôte (kernelhost.com) et renvoie une IP via les enregistrements A ou AAAA. Une recherche DNS inverse prend une IP et renvoie un nom d'hôte via les enregistrements PTR. Les deux sont indépendants : on peut modifier l'un sans l'autre. FCrDNS est le contrôle croisé qui vérifie leur cohérence.
Pourquoi mon IP n'a-t-elle pas d'enregistrement PTR ?
Parce que personne ne l'a défini. Les enregistrements PTR n'ont pas de valeur par défaut, le détenteur du bloc d'IP (votre fournisseur) doit les définir par IP. Pour les connexions grand public, le FAI configure généralement un nom de pool générique automatiquement (quelque chose comme dsl-host-...-isp.net). Pour les clients d'hébergement, la gestion du PTR se fait dans le panneau de contrôle du fournisseur ou est disponible via le support.
Pourquoi FCrDNS indique-t-il une incohérence alors que le PTR est défini ?
Parce que le nom d'hôte du PTR ne se résout pas en direct vers la même IP. Soit A ou AAAA est manquant pour ce nom d'hôte, soit il pointe vers une IP différente. Pour corriger : assurez-vous que le PTR correspond exactement au nom d'hôte vers lequel pointent vos A/AAAA, par exemple PTR = mail.example.com et A mail.example.com = la même IP.
La recherche est-elle journalisée ?
Non. Nous ne journalisons pas l'IP interrogée, ne posons pas de cookies de suivi et n'appelons aucune API tierce, à l'exception du service Team-Cymru DNS-Whois, qui est une requête DNS-TXT standard vers origin.asn.cymru.com (pas de HTTP, pas de clé API). Cymru voit l'IP de notre résolveur et l'IP recherchée, pas votre IP.
L'outil prend-il en charge IPv6 ?
Oui, intégralement. Saisissez une adresse IPv6 dans n'importe quelle notation standard (compressée comme 2001:db8::1 ou étendue), l'outil construit automatiquement le nom ip6.arpa correct (avec nibbles inversés) et effectue la résolution AAAA directe pour FCrDNS.
Puis-je effectuer une recherche DNS inverse sur des IP privées (10.x.x.x, 192.168.x.x) ?
Non. Les plages d'adresses privées et réservées (10/8, 172.16/12, 192.168/16, 127/8, link-local, multicast) ne peuvent pas être interrogées via le DNS public, car leurs zones inverses ne sont pas déléguées à la racine publique. Le PTR des IP privées n'est résolvable qu'à l'intérieur du réseau qui les détient, sur le résolveur local.
Pourquoi y a-t-il plusieurs enregistrements PTR pour une seule IP ?
Il est techniquement légal d'avoir plusieurs enregistrements PTR par IP (une seule IP servant plusieurs noms d'hôte) et c'était courant à l'époque de l'hébergement mutualisé. Aujourd'hui, c'est déconseillé pour les serveurs de messagerie (un seul des PTR passera FCrDNS pour un HELO donné), toléré pour les serveurs web et globalement rare. Si votre IP a plus d'un PTR, décidez lequel est canonique et supprimez les autres.
Le rDNS / PTR est-il obligatoire ?
Pour les serveurs de messagerie : oui, de fait obligatoire. Sans PTR FCrDNS-propre, votre courrier finit en spam ou est rejeté. Pour les serveurs web : non obligatoire mais recommandé (les journaux sont plus propres, les signalements d'abus plus faciles). Pour les services internes ou les charges de travail cloud éphémères : facultatif.
Tous les produits KernelHost
Besoin de plus que des outils ? Découvrez notre offre d'hébergement commercial.