Le DNS inverse en IPv6 (RFC 8501) et l’email

La RFC 8501 (Reverse DNS in IPv6 for Internet Service Providers, novembre 2018, informative) analyse comment les opérateurs peuvent alimenter ip6.arpa lorsque l’habitude héritée d’IPv4 (créer à l’avance un enregistrement PTR pour chaque adresse) devient mathématiquement impossible. L’email est le cas d’usage phare de la RFC, car c’est dans SMTP qu’un DNS inverse absent ou incohérent bloque réellement le trafic.

Pourquoi un PTR par adresse ne tient pas à l’échelle d’IPv6

• En IPv4, un fournisseur d’accès qui dispose d’un /24 écrit 256 enregistrements PTR, souvent générés automatiquement, et passe à autre chose. Le direct et l’inverse correspondent, conformément à l’attente de la RFC 1912 selon laquelle « chaque hôte joignable depuis Internet devrait avoir un nom » (every Internet-reachable host should have a name) dont les entrées directe et inverse concordent.
• Un seul /64 IPv6 (un réseau local) contient 2^64 adresses ; un /48 de client en contient 2^80. Le calcul de la RFC 8501 : à raison de 1 000 entrées de fichier de zone écrites par seconde, remplir un seul /48 « ne serait toujours pas terminé au bout de 38 000 milliards d’années » (would still not be complete after 38 trillion years).
• Les hôtes s’attribuent aussi eux-mêmes leurs adresses (SLAAC, adresses de confidentialité qui changent régulièrement) : l’opérateur ne sait souvent pas quelles adresses sont utilisées, si bien que même un pré-remplissage sélectif ne peut pas suivre la réalité.

Un opérateur IPv6 doit donc choisir une autre stratégie que des PTR statiques exhaustifs. C’est aussi une question d’infrastructure d’envoi pour un ESP : chaque adresse IPv6 sortante depuis laquelle vous émettez des emails a besoin d’un DNS inverse correct et concordant (voir les attentes des serveurs de réception plus bas), tandis que le reste de votre espace d’adresses a besoin d’une politique délibérée.

Le catalogue d’options de la RFC 8501

La conclusion de la RFC 8501 : « Lorsque l’attribution des adresses et le nom relèvent de la même autorité, ou lorsqu’un hôte a une adresse et un nom statiques, les enregistrements AAAA et PTR devraient exister et concorder » (When address assignment and name are under the same authority, or when a host has a static address and name, AAAA and PTR records should exist and match). Pour tout le reste (pools de type résidentiel), le choix réaliste se limite aux wildcards, aux réponses négatives (là où rien n’a besoin d’un PTR) ou à la génération à la volée.

Ce que les serveurs de réception attendent (FCrDNS)

• La RFC le dit sans détour : « la plupart des fournisseurs de messagerie n’acceptent pas de connexions entrantes sur le port 25 si les entrées DNS directe et inverse ne concordent pas » (most email providers will not accept incoming connections on port 25 unless forward and reverse DNS entries match). C’est le DNS inverse confirmé par le direct (FCrDNS) : le PTR de l’adresse qui se connecte donne un nom, et l’enregistrement AAAA (ou A) de ce nom contient l’adresse qui se connecte.
• Seules les options 3 (DDNS), 4 (à la volée) et 5 (délégation) peuvent produire des paires concordantes ; les wildcards et NXDOMAIN ne le peuvent pas. Une source d’emails située derrière un wildcard ou une zone inverse vide sera rejetée ou lourdement pénalisée.
• Gmail est l’archétype de l’application de ces règles en IPv6 : les hôtes d’envoi doivent avoir un PTR dont la résolution directe confirme l’IP, et réussir l’authentification, faute de quoi les messages sont rejetés avec des erreurs 550 5.7.1 propres à IPv6 (répertoriées dans Erreurs SMTP de Gmail et dépannage ; exigences dans Exigences de Gmail envers les expéditeurs). Les récepteurs IPv6 appliquent en général des règles plus strictes qu’en IPv4, car la réputation par IP se dilue dans l’immense espace d’adresses : voir Envoyer des emails en IPv6 pour l’ensemble de la politique d’envoi.
• Comme les noms PTR génériques ou d’apparence synthétique (par exemple 2-2-2-2.pool6.example.net) signalent « pas un serveur de messagerie délibéré », les récepteurs utilisent aussi le nommage des PTR comme heuristique antispam. Recommandation du M3AAWG citée par le NIST SP 800-177 (synthèse) : les arbres inverses devraient identifier les serveurs de messagerie qui font autorité pour un domaine.

Sécurité et confidentialité (RFC 8501 §5)

• Concordance ≠ confiance : un attaquant qui contrôle sa propre zone inverse obtient facilement la concordance direct/inverse ; sans DNSSEC, elle peut être usurpée en transit. Considérez FCrDNS comme un minimum d’hygiène, pas comme une authentification (c’est le rôle de SPF, DKIM et DMARC).
• Interactions avec DNSSEC : les enregistrements ajoutés dynamiquement ou synthétisés compliquent la signature (coût de la signature en direct, exposition des clés sur les signataires en ligne) ; les zones inverses non signées sont de plus en plus lues comme un signal de confiance réduite.
• Confidentialité : les noms d’hôtes qui encodent une localisation ou l’identité d’un abonné divulguent des informations (RFC 8117) ; les noms d’hôtes fournis par les utilisateurs risquent de contenir des contenus offensants ou abusifs.
• Surface d’attaque par déni de service : les canaux de mise à jour DDNS ont besoin d’authentification et de limites de débit ; les générateurs à la volée doivent borner leur état et la taille de leur cache.

Liste de contrôle opérationnelle pour un ESP qui exploite une infrastructure email en IPv6

1. Chaque adresse IPv6 qui émet du SMTP reçoit un PTR statique, descriptif et correct au sens de FCrDNS (mtaN.esp.example ↔ AAAA), provisionné comme un actif de production : l’option « enregistrements statiques », jamais de wildcards.
2. Décidez de la politique pour le reste de vos allocations, qui n’envoie pas : NXDOMAIN est propre et honnête ; ne laissez jamais un wildcard couvrir un espace d’où du SMTP pourrait partir.
3. Vérifiez que votre fournisseur amont ou votre LIR délègue ip6.arpa pour votre préfixe à vos serveurs de noms (généralement sur des frontières de quartet : /32, /36, ... /48, /56, /64) avant le premier envoi.
4. Signez la zone inverse avec DNSSEC si possible : c’est cohérent avec la posture d’authentification du NIST SP 800-177 et attendu par les récepteurs sensibles à la sécurité.
5. Gardez un nommage des PTR cohérent avec l’identité directe utilisée dans HELO/EHLO : les récepteurs comparent les noms de HELO, du PTR et du certificat lorsqu’ils évaluent une connexion (voir Pratiques d’infrastructure d’envoi).
6. Face à un rejet soudain du type 550 5.7.1 qui cite une adresse IPv6 : vérifiez d’abord FCrDNS pour cette adresse précise (la cause classique est un serveur d’application aux adresses changeantes ou de confidentialité qui s’est mis à émettre des emails en IPv6), puis l’alignement de l’authentification ; la stratégie double pile d’ensemble est traitée dans Envoyer des emails en IPv6.