Les enregistrements A et AAAA mappent un nom d'hôte aux adresses IPv4 et IPv6 . Ce sont des dépendances d'un service de messagerie, et non des déclarations que le service est prêt ou autorisé à envoyer. La publication d'une adresse peut exposer un itinéraire que les clients essaient réellement. Vérifiez donc chaque famille et point de terminaison annoncés.
Suivez le nom utilisé par le protocole
Références : RFC 5321 §5.1, RFC 7208 §5.3, RFC 7208 §5.4.
Pour SMTP entrant, résolvez les noms d'hôtes d'échange renvoyés par MX . L'adresse du site Internet du domaine destinataire ne remplace pas lorsque les échanges explicites sont inutilisables. Si aucun MX n'existe, la règle implicite-MX de SMTP peut rendre les propres enregistrements A ou AAAA du domaine destinataire pertinents à la place.
Pour les sorties SPF, examinez la politique actuelle et l'identité évaluée. Un a le mécanisme peut autoriser les adresses renvoyées pour son nom spécifié ; une plaine Un record n'autorise rien par lui-même. De même, changer un nom d'hôte utilisé par un SPF MX Le mécanisme peut modifier les adresses évaluées comme autorisées. Enregistrez ces références avant de traiter une modification d’adresse DNS comme une modification de site Web uniquement.
Traitez la double pile comme deux chemins de fonctionnement
Références : RFC 1035 §3.4.1, RFC 3596 §2.1, RFC 3596 §2.3.
Un nom d'hôte peut avoir plusieurs enregistrements A et plusieurs enregistrements AAAA. Leur présence ne garantit pas l'accessibilité, le service SMTP , le certificat correct ou une politique équivalente. Un point de terminaison IPv4 sain n’établit pas que IPv6 fonctionne. À l’inverse, un échec sur un chemin client ne prouve pas que tous les expéditeurs utilisent ce chemin.
Capturez l'adresse de destination réellement tentée, la famille d'adresses, le résultat de la connexion et la réponse SMTP . Si vous étudiez le trafic sortant, capturez l’adresse source observée en externe plutôt que de supposer qu’elle correspond à l’adresse utilisée dans l’application. Les pools de sortie NAT et fournisseur peuvent rendre ces valeurs différentes.
Reproduire une erreur adresse-famille
Fixation synthétique : example.com. MX 10 mx.example.com.; mx.example.com. A 192.0.2.10; mx.example.com . AAAA 2001:db8::10. Dans le laboratoire, configurez le point de terminaison IPv4 pour accepter les connexions TCP sur le port 25 et laisser le point de terminaison IPv6 inaccessible. Les vérifications DNS attendues réussissent pour les deux types d'enregistrement, tandis qu'un test de connexion spécifique à une famille ne réussit que pour IPv4 .
Requête creusez @AUTH mx.example.com . Une +norécurse puis la même commande avec AAAA. Remplacez AUTH par l’autorité isolée. Enregistrez les deux réponses. Utilisez votre client SMTP de laboratoire approuvé pour épingler chaque destination indépendamment, en enregistrant les résultats de la connexion et du protocole. L'appareil illustre pourquoi le succès DNS n'est pas le succès du service ; il ne fait aucune déclaration sur le délai de repli d'un expéditeur particulier.
Un deuxième appareil change uniquement l'adresse A de 192.0.2.10 à 192.0.2.20 alors que la politique SPF est v=spf1 a:mx.example.com -all. Pour une évaluation IPv4 SPF avec des recherches par ailleurs réussies, l'adresse éligible pour correspondre à l'adresse IPv4 SPF. a changements de mécanisme. Un explicite ip4:192.0.2.10 le mécanisme resterait plutôt lié à ce réseau littéral jusqu’à ce que la politique elle-même change.
Rendre les changements d'adresse réversibles
Références : RFC 8767 §4.
Inventoriez tous les consommateurs du nom d'hôte, y compris le routage du courrier, les références SPF , la surveillance et les attentes en matière de certificat. Préparez le point de terminaison avant de le publier. Conservez l'ancien service pendant que les caches appropriés peuvent toujours y diriger le trafic, sur la base du plan de migration réel plutôt que d'une période d'attente universelle.
Après le changement, comparez les réponses faisant autorité avec des observations récursives et des preuves au niveau du message. Un point de terminaison IPv6 défaillant doit être réparé ou supprimé via une modification approuvée, et non masqué par un affaiblissement des politiques d'authentification non liées. Clôturez le travail uniquement lorsque les adresses et les chemins d'exploitation prévus correspondent à la conception de service documentée.
Gardez la portée des preuves explicite
Pour le scénario à deux familles, conservez le succès IPv4 et l’échec IPv6 attendus comme observations de laboratoire proposées jusqu’à ce qu’ils soient testés. L'exemple de changement d'adresse SPF suppose des recherches réussies et la politique déclarée ; il n'établit pas d'autorisation actuelle pour un expéditeur réel.