Akamai est l'entreprise de cybersécurité et de Cloud Computing qui soutient et protège l'activité en ligne. Nos solutions de sécurité leaders du marché, nos informations avancées sur les menaces et notre équipe opérationnelle internationale assurent une défense en profondeur pour protéger les données et les applications des entreprises du monde entier. Les solutions de Cloud Computing complètes d'Akamai offrent des performances de pointe à un coût abordable sur la plateforme la plus distribuée au monde. Les grandes entreprises du monde entier font confiance à Akamai pour bénéficier de la fiabilité, de l'évolutivité et de l'expertise de pointe nécessaires pour développer leur activité en toute sécurité.
Le DNS inversé (rDNS) est le processus de découverte d'un nom à partir d'une entrée d'adresse IP, tandis que les requêtes DNS « traditionnelles » effectuent l'opération inverse et convertissent un nom d'hôte en adresse IP.
dig -x 24.117.59.59
Exemple de requête DNS inversée sur un Mac (à l'aide d'un terminal)
nslookup 24.117.59.59
Exemple de requête DNS inversée pour Windows et Linux
Plus précisément, le rDNS consiste à résoudre la valeur IP en sens inverse, avec « in-addr.arpa » ajouté à la fin1. Ainsi, la commande dans l'exemple ci-dessus recherchera en réalité « 59.59.117.24.in-addr.arpa ». Si le propriétaire de l'adresse IP a correctement configuré le rDNS, cette requête renverra un enregistrement de type « pointer » (PTR), qui associe l'adresse IP à un domaine :
59.59.117.24.in-addr.arpa. 43200 IN PTR 24-117-59-59.cpe.sparklight.net.
Pourquoi le DNS inversé est-il important ?
Bien que le rDNS ne soit pas universellement adopté pour le trafic Web traditionnel, les enregistrements PTR sont particulièrement importants pour les serveurs de messagerie, qui effectuent souvent des requêtes rDNS pour bloquer ou filtrer le courrier indésirable. Pour veiller à ce que les messages soient reçus sans signalement, les fournisseurs de messagerie légitimes doivent mettre en œuvre le rDNS correctement pour les adresses IP et les noms d'hôte correspondants. Cela est nécessaire pour empêcher les spammeurs d'envoyer des e-mails depuis des machines compromises, car généralement, ces adresses IP ne disposent pas d'enregistrements rDNS. Et lorsqu'elles en ont, la réponse prend souvent la forme d'une sortie générique et dynamique, ce qui suggère que le client n'est pas un service de messagerie légitime.
Comme indiqué ci-dessus, l'adresse IP résidentielle 24.117.59.59 pointe vers un enregistrement PTR 24-117-59-59.cpe.sparklight.net. Il s'agit d'une sortie dynamique, puisqu'elle comprend simplement l'adresse IP avec le domaine sparklight ajouté. Ainsi, si un spammeur pirate la machine et envoie un e-mail à partir de l'adresse IP résidentielle, le récepteur bloquera ou filtrera probablement le message, car les réponses dynamiques indiquent bien souvent un spam (à titre d'exemple, une réponse acceptable ressemblerait plutôt à « email.sparklight.net »). En résumé, un spammeur devrait posséder son propre espace d'adresses IP pour pouvoir configurer les paramètres DNS nécessaires afin que ses messages soient acceptés. Cela représente un coût prohibitif pour la plupart des acteurs malveillants.
Enfin, certains serveurs de messagerie s'appuient sur des paramètres rDNS plus nuancés avec l'aide du protocole SMTP (Simple Mail Transfer Protocol), un protocole de communication standardisé pour la transmission des e-mails. Par exemple, les serveurs de messagerie peuvent être configurés pour rejeter des e-mails lorsque la requête rDNS ne correspond pas à la commande HELO, un message qui démarre la session SMTP. Ainsi, si un botnet parvenait à envoyer des milliers d'e-mails depuis des centaines, voire des milliers de machines piratées appartenant à différents réseaux, il serait difficile pour l'acteur malveillant d'annoncer le bon domaine dans chaque message HELO, même si le rDNS était correctement configuré pour l'adresse IP.
Client : HELO mail.example.com
Serveur : 250 mail.example.com Hello
Comment configurer le DNS inversé ?
Pour qu'une requête rDNS renvoie une réponse valide, un fichier de zone rDNS in-addr.arpa doit être créé et refléter la plage de réseau fixe allouée au propriétaire de l'adresse IP. Concrètement, l'administrateur de la zone doit supprimer le dernier groupe de quatre octets séparés par des points, qui contient les valeurs explicitement sous son contrôle, inverser l'ordre des octets restants, puis ajouter « .in-addr.arpa ».
Étant donné que Sparklight possède une adresse de classe B, son nom de fichier de zone rDNS est « 117.24.in-addr.arpa ». En examinant le processus complet de résolution, ARPA possède les adresses de classe A 24.0.0.0/82, mais délègue les requêtes 117.24 à Sparklight :
Zone |
Commentaires |
|
|---|---|---|
Serveurs racine |
j.root-servers.net. |
Comme toutes les requêtes DNS, la requête commence au niveau du serveur racine |
Délégation à l'ICANN |
in-addr.arpa. |
Les serveurs racine sont délégués à un ensemble de serveurs ICANN responsables de la gestion de la zone ARPA |
Autre délégation à l'ICANN/ARPA |
24.in-addr.arpa. |
L'ICANN délègue à ARPA, qui détient l'adresse de classe A 24.0.0.0/8 |
Délégation à Sparklight |
117.24.in-addr.arpa. |
La requête est ensuite déléguée à Sparklight, qui possède cette plage |
Réponse |
59.59.117.24.in-addr.arpa. |
Enregistrement PTR renvoyé |
Tout comme pour les requêtes DNS directes, chaque « point » dans un nom d'hôte rDNS est un point de délégation potentiel. L'ICANN gère la zone in-addr.arpa et délègue les sous-zones aux propriétaires d'un espace IP.
Dans le fichier de zone, les enregistrements PTR pertinents doivent être publiés et, comme pour toute autre zone, les enregistrements de serveurs de noms (NS) doivent également être définis.
59.59.117.24.in-addr.arpa. 43200 IN PTR 24-117-59-59.cpe.sparklight.net.
117.24.in-addr.arpa. 43200 IN NS ns2.cableone.net.
117.24.in-addr.arpa. 43200 IN. NS ns4.cableone.net.
117.24.in-addr.arpa. 43200 IN NS ns3.cableone.net.
117.24.in-addr.arpa. 43200 IN NS ns1.cableone.net.
Conclusion
Bien que le rDNS ne soit pas toujours nécessaire pour le bon fonctionnement d'une application Web ou native classique sur Internet, il constitue un élément important pour tout service de messagerie fonctionnel. Une requête inversée peut également être employée pour l'analyse et le dépannage, car les propriétaires d'applications peuvent déterminer si une adresse IP appartient à un FAI commercial, à un fournisseur de services cloud ou à une autre entreprise/entité commerciale. Ces informations sont souvent utiles pour identifier des prospects, en particulier pour les entreprises B2B qui souhaitent mieux comprendre qui visite leur site. De même, connaître le propriétaire d'une adresse IP peut aider les outils de sécurité à déterminer si la demande est émise par un attaquant ou par une source légitime.
Bien qu'il ne soit pas aussi répandu ou connu que le DNS direct, le rDNS joue un rôle important dans l'écosystème Internet d'aujourd'hui. Il est donc impératif pour les administrateurs de messagerie, les analystes marketing B2B et les experts en cybersécurité de comprendre cette nuance du protocole.
1 ip6.arpa est la zone des adresses IPv6.
2 Les adresses de classe A sont destinées aux réseaux comportant un grand nombre d'hôtes. La classe A permet de créer 126 réseaux en utilisant le premier octet pour identifier le réseau. Les adresses de classe B sont destinées aux réseaux de moyenne à grande taille. La classe B permet de créer 16 384 réseaux en utilisant les deux premiers octets pour identifier le réseau.