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

Si vous envoyez des emails en IPv6, chaque adresse d’envoi a besoin d’un DNS inverse qui concorde avec son DNS direct, alors que l’habitude héritée d’IPv4, créer à l’avance un enregistrement PTR pour chaque adresse, devient mathématiquement impossible. La RFC 8501, Reverse DNS in IPv6 for Internet Service Providers (novembre 2018, informative), analyse comment les opérateurs peuvent alimenter ip6.arpa autrement. L’email est son cas d’usage phare, 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 à Internet (FAI) qui dispose d’un /24 écrit 256 enregistrements PTR, souvent générés automatiquement, et passe à autre chose. Le DNS direct et le DNS inverse concordent, ce qui répond à l’attente de la RFC 1912 selon laquelle « chaque hôte joignable depuis Internet devrait avoir un nom » dont les entrées directe et inverse concordent.
• Un seul /64 IPv6 (un réseau local) contient 2^64 adresses, et un /48 de client en contient 2^80. La RFC 8501 fait le calcul : à 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 ».
• Les hôtes s’attribuent aussi eux-mêmes leurs adresses, par l’autoconfiguration d’adresse sans état (SLAAC) et par des 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 enregistrements PTR statiques pour chaque adresse. Pour un fournisseur de services email (ESP), c’est aussi une question d’infrastructure d’envoi. Chaque adresse IPv6 depuis laquelle vous envoyez des emails a besoin d’un DNS inverse correct et concordant (voir plus bas ce qu’attendent les serveurs de réception), et 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. » Pour tout le reste, comme les pools résidentiels, les choix réalistes sont les wildcards, les 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 ». C’est le DNS inverse confirmé par le direct (FCrDNS) : le PTR de l’adresse qui se connecte renvoie 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 le modèle 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 doivent aussi réussir l’authentification, sinon 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, avec les exigences dans Exigences de Gmail envers les expéditeurs). Les serveurs de réception appliquent en général des règles plus strictes en IPv6 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.
• Les noms PTR d’apparence générique ou synthétique (par exemple, 2-2-2-2.pool6.example.net) signalent « pas un serveur de messagerie délibéré », si bien que les serveurs de réception utilisent aussi le nommage des enregistrements PTR comme heuristique antispam. Les recommandations du Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), citées par le NIST SP 800-177 (synthèse), indiquent que les arbres inverses devraient identifier les serveurs de messagerie qui font autorité pour un domaine.

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

• Des enregistrements concordants ne signifient pas la confiance. Un attaquant qui contrôle sa propre zone inverse peut facilement faire concorder le DNS direct et le DNS inverse, et sans DNSSEC, les réponses peuvent être usurpées en transit. Considérez FCrDNS comme un minimum d’hygiène, pas comme une authentification. SPF, DKIM et DMARC assurent l’authentification.
• Interactions avec DNSSEC : les enregistrements ajoutés dynamiquement ou synthétisés compliquent la signature (le coût de la signature en direct, et l’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, et 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 envoie du SMTP reçoit un PTR statique et descriptif qui réussit FCrDNS (mtaN.esp.example, avec un enregistrement AAAA correspondant), provisionné comme un actif de production. Utilisez l’option « enregistrements statiques », jamais les wildcards.
2. Décidez de la politique pour le reste de vos allocations, la partie qui n’envoie pas d’emails. NXDOMAIN est propre et honnête. Ne laissez jamais un wildcard couvrir un espace d’adresses d’où du SMTP pourrait partir.
3. Avant le premier envoi, vérifiez que votre fournisseur amont ou votre registre Internet local (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).
4. Signez la zone inverse avec DNSSEC si vous le pouvez. C’est cohérent avec la posture d’authentification du NIST SP 800-177, et les serveurs de réception attentifs à la sécurité l’attendent.
5. Gardez des noms PTR cohérents avec l’identité directe que vous utilisez dans HELO et EHLO. Les serveurs de réception comparent les noms de HELO, du PTR et du certificat lorsqu’ils évaluent une connexion (voir Pratiques d’infrastructure d’envoi).
6. Lorsque vous analysez 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 qui s’est mis à envoyer des emails en IPv6 depuis des adresses de confidentialité changeantes. Vérifiez ensuite l’alignement de l’authentification. La stratégie double pile d’ensemble est traitée dans Envoyer des emails en IPv6.