Route 53 - Dois-je dupliquer mes enregistrements SPF en tant qu'enregistrements TXT?

Amazon Route 53 prend en charge à la fois les «enregistrements SPF» et les «enregistrements TXT». La plupart de la documentation que je lis me dit de répertorier mon enregistrement SPF en tant qu'enregistrement TXT. Je comprends que l'enregistrement SPF est une norme plus récente. Est-il donc correct pour moi de dupliquer mes enregistrements SPF afin qu'ils soient répertoriés comme enregistrements SPF et enregistrement TXT pour assurer une compatibilité descendante tout en respectant la nouvelle norme? Je ne suis pas familier avec DNS, donc je ne sais pas si cela causerait des problèmes ou si je devrais même prendre la peine de les dupliquer?

Mes dossiers sont les suivants:

"v=spf1 include:_spf.google.com include:amazonses.com -all"
"spf2.0/pra include:_spf.google.com include:amazonses.com -all"

Il n'est pas vraiment correct que le SPFtype RR soit la nouvelle norme (dans le contexte du comportement SPF souhaité). La phase expérimentale de la spécification SPF avait un nouveau type d'enregistrement attribué mais le chemin de migration n'était pas clair et il a depuis été abandonné.

La version actuelle de la spécification SPF indique spécifiquement:

Les enregistrements SPF DOIVENT être publiés en tant qu'enregistrements de ressources (RR) DNS TXT (type 16 ) [RFC1035] uniquement . Le contenu des caractères de l'enregistrement est codé en [US-ASCII]. L'utilisation de types DNS RR alternatifs a été prise en charge dans la phase expérimentale de SPF mais a été abandonnée.

En 2003, lorsque SPF a été développé pour la première fois, les exigences d'
attribution d'un nouveau type DNS RR étaient considérablement plus strictes qu'elles ne le sont actuellement. De plus, la prise en charge d'un déploiement facile de nouveaux
types DNS RR n'a pas été largement déployée dans les serveurs DNS et les
systèmes d' approvisionnement . En conséquence, les développeurs de SPF ont trouvé plus facile et plus
pratique d'utiliser le type TXT RR pour les enregistrements SPF.

Dans son examen de la [RFC4408], le groupe de travail SPFbis a conclu que son modèle de transition de type RR double était fondamentalement défectueux car il
ne contenait aucun type RR commun que les exécutants devaient servir
et devaient vérifier. De nombreuses alternatives ont été envisagées pour résoudre
ce problème, mais finalement le groupe de travail a conclu qu'une
migration importante vers le type SPF RR dans un avenir prévisible
était très peu probable et que la meilleure solution pour résoudre ce
problème d'interopérabilité était de supprimer le support pour le type SPF RR de
SPF version 1. Voir l'annexe A de la [RFC6686] pour plus d'informations.

Les circonstances entourant le déploiement initial de SPF il y a une décennie sont uniques. Si une future mise à jour de SPF était développée qui ne
réutilisait pas les enregistrements SPF existants, elle pourrait utiliser le type RR SPF. L'utilisation par SPF du
type TXT RR pour les données structurées ne doit en aucun cas être considérée comme un
précédent pour les futurs concepteurs de protocoles. Une discussion plus approfondie des
considérations de conception lors de l'utilisation de nouveaux types DNS RR peut être trouvée dans
[RFC5507].

En tant que sidenote, il y avait aussi un enregistrement Sender ID (malheureusement appelé "spf2.0" bien qu'il s'agisse d'une spécification différente) dans votre exemple, les règles pour ce type d'enregistrement sont toujours expérimentales et correspondent à la version expérimentale du SPF spec , aucune mise à jour n'a été publiée.

Oui, dupliquez-les; Je ne sais pas par hasard quel ratio de vérificateurs SPF prend en charge la norme actuelle pour le type d'enregistrement, mais si je devais deviner, je parierais que probablement 10% des vérificateurs ne regarderont pas un SPFenregistrement seulement TXT.