3. SPF Records (Enregistrements SPF)

Un enregistrement SPF est un enregistrement DNS qui déclare quels hôtes sont autorisés (et lesquels ne le sont pas) à utiliser le nom de domaine dans les identités "HELO" et "MAIL FROM". Grossièrement, l'enregistrement divise les hôtes en ensembles autorisés et non autorisés (bien que certains hôtes puissent ne appartenir à aucune des deux catégories).

Les enregistrements SPF sont représentés comme une seule chaîne de texte trouvée dans le RDATA d'un seul enregistrement de ressource DNS TXT; plusieurs enregistrements SPF avec le même nom de propriétaire ne sont pas autorisés. Le format de l'enregistrement et le processus de sélection des enregistrements sont décrits ci-dessous dans la section 4. Un exemple d'enregistrement est le suivant:

v=spf1 +mx a:colo.example.com/28 -all

Cet enregistrement a la version "spf1" et contient trois directives: "+mx", "a:colo.example.com/28" (implicite "+"), et "-all".

Chaque enregistrement SPF est placé dans l'arbre DNS au nom de propriétaire auquel il appartient, et non dans un sous-domaine sous le nom de propriétaire. Ceci est similaire aux enregistrements SRV [RFC2782].

L'exemple de cette section pourrait être publié par la ligne suivante dans un fichier de zone de domaine:

example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"

Comme les enregistrements TXT ont plusieurs usages, notez les autres enregistrements TXT publiés là pour d'autres usages. Ils peuvent causer des problèmes de limites de taille (voir section 3.4), et il faut veiller à s'assurer que seuls les enregistrements SPF sont utilisés pour le traitement SPF.

Les ADMD qui publient des enregistrements SPF devraient maintenir au minimum la quantité d'informations DNS nécessaires pour évaluer l'enregistrement. Les sections 4.6.4 et 10.1.1 donnent quelques conseils sur le mécanisme "include" et les modificateurs "redirect" chaînés.

3.1 DNS Resource Records (Enregistrements de ressources DNS)

Les enregistrements SPF doivent être publiés uniquement en tant qu'enregistrements de ressources (RR) DNS TXT (type 16) [RFC1035]. Le contenu en caractères de l'enregistrement est encodé en [US-ASCII]. La phase d'expérimentation SPF prenait en charge l'utilisation d'un type de RR DNS alternatif, mais cela a maintenant été abandonné.

En 2003, lorsque SPF a été développé pour la première fois, les exigences pour l'attribution d'un nouveau type de RR DNS étaient plus strictes qu'aujourd'hui. De plus, le support pour le déploiement facile de nouveaux types de RR DNS dans les serveurs DNS et les systèmes de configuration n'était pas largement déployé. Par conséquent, les développeurs de SPF ont trouvé plus facile et plus pratique d'utiliser le type de RR TXT pour stocker les enregistrements SPF.

Lors de l'examen de [RFC4408], le groupe de travail SPFbis a conclu que son modèle de transition à double type de RR était fondamentalement défectueux car il ne contenait pas de type de RR universel que les implémenteurs devaient fournir et vérifier. De nombreuses alternatives ont été envisagées pour résoudre ce problème, mais finalement le groupe de travail a conclu que la probabilité d'une migration vers le type de RR SPF dans un avenir prévisible était très faible et que la meilleure solution à ce problème d'interopérabilité était de retirer le support du type de RR SPF de SPF version 1. Pour plus d'informations, voir l'annexe A de [RFC6686].

Les circonstances entourant le déploiement initial de SPF il y a une décennie étaient uniques. Si une mise à jour de SPF qui ne réutilise pas les enregistrements SPF existants est développée à l'avenir, elle pourrait utiliser le type de RR SPF. L'utilisation par SPF du type de RR TXT pour stocker des 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 de RR DNS peut être trouvée dans [RFC5507].

3.2 Multiple DNS Records (Enregistrements DNS multiples)

Un nom de domaine ne doit jamais avoir plusieurs enregistrements qui entraîneraient une vérification d'autorisation à sélectionner plusieurs enregistrements. Voir la section 4.5 pour les règles de sélection.

3.3 Multiple Strings in a Single DNS Record (Chaînes multiples dans un seul enregistrement DNS)

Comme défini dans [RFC1035] sections 3.3 et 3.3.14, un seul enregistrement DNS de texte peut être composé de plusieurs chaînes. Si un enregistrement publié contient plusieurs chaînes de caractères, l'enregistrement doit être traité comme ces chaînes concaténées sans ajout d'espaces. Par exemple:

IN TXT "v=spf1 .... first" "second string..."

est équivalent à:

IN TXT "v=spf1 .... firstsecond string..."

Les enregistrements TXT contenant plusieurs chaînes sont utiles pour construire des enregistrements qui dépassent la longueur maximale de 255 octets pour une chaîne de caractères dans un seul enregistrement TXT.

3.4 Record Size (Taille d'enregistrement)

Les enregistrements SPF publiés pour un nom de domaine donné devraient être maintenus suffisamment petits pour que le résultat de requête pour celui-ci tienne dans 512 octets. Sinon, il est possible de dépasser les limites du protocole DNS. Cette limite UDP est définie dans [RFC1035] section 2.3.4, bien qu'elle ait été augmentée par [RFC2671]. Rester en dessous de 512 octets devrait empêcher les anciennes implémentations DNS de basculer vers TCP et permettre l'utilisation d'UDP sans support EDNS0 [RFC6891]. Comme la taille de réponse dépend de nombreuses choses en dehors de la portée de ce document, seuls les conseils suivants peuvent être donnés: si la taille du message DNS, la longueur combinée des noms DNS et du texte de tous les enregistrements d'un type donné est inférieure à 450 octets, alors la réponse DNS devrait tenir dans un paquet UDP. En raison des pare-feu et d'autres problèmes qui interfèrent avec le fonctionnement DNS sur TCP ou l'utilisation d'EDNS0, les enregistrements trop longs pour tenir dans un seul paquet UDP peuvent être silencieusement ignorés par les validateurs SPF.

Notez que lors du calcul de la taille de réponse pour une requête au format TXT, tous les autres enregistrements TXT publiés au nom de domaine doivent être pris en compte. De même, les tailles de réponse de toutes les requêtes liées à SPF doivent être évaluées pour tenir dans un seul paquet UDP de 512 octets (c'est-à-dire, taille de message DNS limitée à 450 octets).

3.5 Wildcard Records (Enregistrements génériques)

L'utilisation d'enregistrements génériques pour la publication est découragée, et si elles sont utilisées, il faut faire preuve de prudence. Si une zone contient des enregistrements MX génériques, elle peut souhaiter publier une déclaration générique, mais doit être soumise aux mêmes exigences et problèmes. En particulier, la déclaration doit être répétée pour tout hôte avec des enregistrements RR quelconques et leurs sous-domaines. Considérez l'exemple de [RFC1034] section 4.3.3. Sur cette base, nous pouvons faire ce qui suit:

EXAMPLE.COM. MX 10 A.EXAMPLE.COM
EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"

*.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
*.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"

A.EXAMPLE.COM. A 203.0.113.1
A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"

*.A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
*.A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"

Pour chaque nom dans la zone, l'enregistrement SPF doit être listé deux fois: une fois pour ce nom et une fois avec un générique pour couvrir l'arbre sous ce nom, afin de couvrir tous les domaines utilisés dans le courrier sortant.