TXT vs SPF record pour les serveurs Google SPF record, soit les deux?

19

Selon la documentation de Google, https://support.google.com/a/bin/answer.py?hl=en&answer=178723

Il indique clairement Créer un enregistrement TXT contenant ce texte: v=spf1 include:_spf.google.com ~all

Pourquoi n'est-ce pas un enregistrement SPF?

RFC4408 définit les enregistrements SPF, mais il semble qu'il ne soit pas vraiment utilisé https://tools.ietf.org/html/rfc4408#section-3.1.1

Est-ce correct? Dois-je créer à la fois TXT et SPF?

Merci

dns sebastien
la source
4
Peu de bureaux d'enregistrement de domaine fournissent des outils pour créer et gérer des enregistrements SPF réels tandis que le support TXT est assez courant (juste par exemple: GoDaddy populaire). C'est, bien sûr, si vous n'exécutez pas votre propre serveur DNS. Si vous le pouvez - créez les deux. Cela sera également bénéfique pour les services qui prennent réellement en charge les enregistrements SPF (car ils vérifient d'abord SPF et s'ils sont absents - TXT).
LazyOne

Réponses:

31

Je me rends compte que c'est une question assez ancienne, mais au cas où quelqu'un d'autre tomberait dessus, voici ce que j'ai trouvé. Il semble que le type d'enregistrement SPF soit désormais obsolète. Voir:

Des études ont montré que RRTYPE 99 n'a vu aucune utilisation substantielle, et en fait son existence et son mécanisme défini dans la [RFC4408] ont conduit à des problèmes d'interopérabilité. En conséquence, son utilisation est désormais obsolète et les nouvelles implémentations ne doivent pas l'utiliser.

De: https://tools.ietf.org/html/draft-ietf-spfbis-4408bis-15#section-13.1

Voir également un article sur le forum de demande de fonctionnalités de cPanel sur ce sujet.

Dominic P
la source
8
Le RFC 7208 obsolète également le 4408 et déclare:SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only.
Stoinov
6

Veuillez lire l'état de la RFC4408 "Catégorie: Expérimental" et la définition de cet état.

Aussi, de RFC

Il est reconnu que la pratique actuelle (à l'aide d'un enregistrement TXT) n'est pas optimale, mais elle est nécessaire car il existe un certain nombre d'implémentations de serveur DNS et de résolveur couramment utilisées qui ne peuvent pas gérer le nouveau type RR.

et, après tout, SPF RR n'a aucune valeur ajoutée par rapport à la version TXT

Blaireau paresseux
la source
2

Je créerais les deux, puisque vous avez cette capacité. Après avoir terminé, vous pouvez envoyer et envoyer un e-mail à "[email protected]", il répondra automatiquement et vous donnera un diagnostic complet de l'e-mail que vous avez envoyé pour vous informer, si vous avez tout configuré correctement.

Henri
la source
-1

Considérant que cela fait maintenant 7 ans après la publication du RFC, je dis que quiconque utilise toujours des serveurs DNS qui ne peuvent pas gérer des RRtypes inconnus est fondamentalement LEUR problème pour ne pas garder les logiciels à jour. (Considérez également qu'en ne mettant pas à niveau, combien connaissent les exploits pour lesquels ils restent vulnérables). La RFC 4408 a déclaré que la surcharge du TXT RRtype était une mesure temporaire jusqu'à ce que l'IANA publie le SPF RRtype (type 99), ce qui s'est également produit il y a 7 ans.

Par conséquent, je dis que l'utilisation du TXT RRtype à des fins SPF a expiré depuis longtemps. Les personnes exécutant des résolveurs qui vérifient uniquement le type TXT sont brisées.

Je ne suis pas d'accord que le SPF RRtype n'a pas "ajouté de valeur". Il garde les données exploitables par la machine HORS d'un type RR DNS lisible par l'homme.

user29717
la source
Vous aimeriez peut-être changer d'avis compte tenu de la réponse de Dominic ?