Vérification DNS inversée : est-elle sécuritaire à utiliser?

SHARE WITH YOUR NETWORK!

Table of Contents

Vérification DNS inversée : est-elle sécuritaire à utiliser?

Chaque fois que je fais une configuration avec un client, la question revient toujours : devrions-nous utiliser ou non la vérification DNS inverse lors de la configuration des mesures de sécurité de blocage au niveau de la connexion?

Qu’est-ce que la recherche DNS inversée?

Voici un extrait tiré de la description de Wikipédia :

« Les recherches DNS inverses pour les adresses IPv4 utilisent une entrée IN-ADDR inverse dans le domaine spécial in-addr.arpa. Dans ce domaine, une adresse IPv4 est représentée par une séquence d’octets dans l’ordre inverse, encodés en nombres décimaux et séparés par des points (point) avec le suffixe de domaine de deuxième niveau .in-addr.arpa.

Par exemple, un enregistrement d’adresse (A) pour mail.example.com pointe vers l’adresse IP 192.0.2.5. Dans les enregistrements de pointeur de la base de données inversée, cette adresse IP est stockée en tant que nom de domaine 5.2.0.192.in-addr.arpa pointant vers son nom d’hôte désigné mail.example.com.

Ainsi, lorsqu’un serveur DNS essaie de résoudre votre adresse IP, il recherche votre adresse IP en notation inverse avec le suffixe .in-addr.arpa pour trouver le nom d’hôte associé.

Ce qu’un MTA fait habituellement, c’est de voir s’ils correspondent dans les deux sens :

mail.example.com -> 192.0.2.5
devrait également correspondre à l’inverse :
192.0.2.5 -> mail.example.com

C’est ce qu’on appelle le « DNS inverse confirmé ».

Alors, devrions-nous l’utiliser?

En 1996, la RFC 1912 stipulait que chaque hôte devait avoir un enregistrement de RPP inversé. La section 2.1 de cette RFC stipule : « Assurez-vous que vos enregistrements PTR et
A correspondent. Pour chaque adresse IP, il devrait y avoir un enregistrement PTR correspondant dans le domaine in-addr.arpa.

En d’autres termes, toutes vos machines destinées au public devraient avoir un enregistrement RPT inversé, y compris votre MTA.

Cela étant dit, tous les administrateurs n’ont pas suivi le mouvement lorsque la RFC est sortie, ni pendant plusieurs années après sa publication. De plus, dans les premières années d’utilisation des outils anti-pourriel, l’utilisation de recherches DNS inversées était généralement une mauvaise idée en raison du nombre de MTA qui n’avaient pas d’enregistrement PTR.

De nos jours, cependant, il est devenu beaucoup plus sûr d’utiliser la recherche inverse comme mesure anti-pourriel, car si vous n’avez PAS votre propre enregistrement PTR, vous rencontrerez inévitablement des problèmes de livraison – même aux très grands FAI et aux sociétés d’hébergement de messagerie – qui vérifient le DNS inverse.

Donc, si les grands fournisseurs de courrier l’utilisent, il ne devrait y avoir aucune raison pour que vous ne puissiez pas le faire.

Par mesure de précaution, si vous vous inquiétez de ce qui pourrait être rejeté au niveau de la connexion, la plupart des passerelles anti-pourriel peuvent mettre en quarantaine les messages dont la source n’a pas d’entrée DNS inverse appropriée.

Explore our Advanced Email Security Solutions

Protect your clients and simplify your operations with reliable, scalable email security solutions. Get in touch today to learn how we can support your success.

SHARE WITH YOUR NETWORK!

Ready to See the Difference?
Discover our advanced security products today.

Faire défiler vers le haut

Joignez-vous à nous au MSP Summit Orlando, du 15 au 17 septembre – Code : Vircom