La limite de recherche de 10 DNS dans la spécification SPF est-elle généralement appliquée?
Ma compréhension est que la spécification SPF spécifie qu'un récepteur de messagerie ne devrait pas avoir à faire plus de 10 recherches DNS afin de rassembler toutes les adresses IP autorisées pour un expéditeur. Donc, si un enregistrement SPF a include:foo.com include:bar.com include:baz.com et ces trois domaines ont chacun des enregistrements SPF qui ont également 3 include entrées, nous en sommes maintenant à 3 + 3 + 3 + 3 = 12 recherches DNS.
ma compréhension ci-dessus est-elle correcte?
J'utilise seulement 2 ou 3 services pour mon domaine et j'ai déjà largement dépassé cette limite. Cette limite est-elle généralement (ou jamais) appliquée par les principaux fournisseurs de messagerie?
Tous les deux libspf2 (C) et Mail::SPF::Query (Perl, utilisé dans sendmail-spf-milter ) implémente une limite de 10 DNS- provoquant des mécanismes , mais ce dernier n'applique pas (AFAICT) les limites MX ou PTR. libspf2 limite chacun de mx et ptr à 10 également.
Mail::SPF (Perl) a une limite de 10 mécanismes à l'origine du DNS et une limite de 10 recherches par mécanisme, par MX et par PTR. (Les deux packages Perl sont couramment, mais pas par défaut, utilisés dans MIMEDefang .)
pyspf a des limites de 10 sur tous: "lookups", MX, PTR, CNAME; mais il multiplie explicitement MAX_LOOKUPS par 4 pendant le fonctionnement. Sauf en mode "strict", il multiplie également MAX_MX et MAX_PTR par 4.
Je ne peux pas commenter les implémentations commerciales/propriétaires, mais ce qui précède (sauf pyspf) implémente clairement une limite supérieure de 10 mécanismes de déclenchement DNS (plus de détails ci-dessous), donner ou prendre, bien que dans la plupart des cas, cela peut être remplacé au moment de l'exécution.
Dans votre cas spécifique, vous avez raison, il s'agit de 12 inclusions et cela dépasse la limite de 10. Je m'attendrais à ce que la plupart des logiciels SPF renvoient "PermError", cependant , les échecs n'affecteront que le (s) dernier (s) fournisseur (s) "inclus" car le nombre sera calculé comme un total cumulé: SPF les mécanismes sont évalués de gauche à droite et les contrôles seront "précoces" lors d'une passe, cela dépend donc de l'endroit dans la séquence où le serveur d'envoi apparaît.
La solution consiste à utiliser des mécanismes qui ne déclenchent pas de recherches DNS, par exemple ip4 et ip6, puis utilisez mx si possible car cela vous donne jusqu'à 10 autres noms, chacun pouvant avoir plus d'une adresse IP.
Étant donné que SPF entraîne des requêtes DNS arbitraires avec une mise à l'échelle potentiellement exponentielle, il pourrait facilement être exploité pour des attaques DOS/d'amplification. Il a délibérément des limites basses pour éviter cela: il ne se met pas à l'échelle comme vous le souhaitez.
10 mécanismes (strictement les mécanismes + le modificateur "rediriger") provoquant les recherches DNS ne sont pas exactement la même chose que 10 recherches DNS cependant. Même les "recherches DNS" sont sujettes à interprétation, vous ne savez pas à l'avance combien de recherches discrètes sont nécessaires et vous ne savez pas combien de recherches discrètes votre résolveur récursif peut avoir besoin d'effectuer (voir ci-dessous).
Les implémentations SPF DOIVENT limiter le nombre de mécanismes et de modificateurs qui effectuent des recherches DNS à 10 au maximum par vérification SPF, y compris toutes les recherches provoquées par l'utilisation du mécanisme "include" ou du modificateur "redirect". Si ce nombre est dépassé lors d'une vérification, une PermError DOIT être retournée. Les mécanismes "include", "a", "mx", "ptr" et "exist" ainsi que le modificateur "redirect" sont pris en compte dans cette limite. Les mécanismes "tous", "ip4" et "ip6" ne nécessitent pas de recherches DNS et ne sont donc pas pris en compte dans cette limite.
[...]
Lors de l'évaluation des mécanismes "mx" et "ptr", ou de la macro% {p}, il NE DOIT PAS y avoir plus de 10 RR MX ou PTR recherchés et vérifiés.
Vous pouvez donc utiliser jusqu'à 10 mécanismes/modificateurs qui déclenchent des recherches DNS. (Le libellé ici est médiocre: il semble indiquer uniquement la limite supérieure de la limite, une mise en œuvre confirmante pourrait avoir une limite de 2.)
§5.4 pour le mécanisme mx , et §5.5 pour le mécanisme ptr chacun a une limite de 10 recherches de ce type de nom, et cela s'applique uniquement au traitement de ce mécanisme, par exemple:
Pour empêcher les attaques par déni de service (DoS), plus de 10 noms MX NE DOIVENT PAS être recherchés lors de l'évaluation d'un mécanisme "mx" (voir la section 10).
c'est-à-dire que vous pouvez avoir 10 mécanismes mx, avec jusqu'à 10 noms MX, donc chacun de ceux-ci peut provoquer 20 opérations DNS (10 recherches MX + 10 A chacune) pour un total de 200. C'est similaire pour ptr ou % {p} , vous pouvez rechercher 10 ptr mécanismes, donc 10x10 PTR, chaque PTR nécessite également une recherche A, encore 200 au total.
C'est exactement ce que le 2009.10 test suite vérifie, voir les tests " Processing Limits ".
Il n'y a pas de limite supérieure clairement indiquée sur le nombre total d'opérations de recherche DNS client par contrôle SPF, je le calcule implicitement 210, donner ou prendre . Il est également suggéré de limiter le volume de données DNS par contrôle SPF, mais aucune limite réelle n'est suggérée. Vous pouvez obtenir une estimation approximative car les enregistrements SPF sont limités à 450 octets (qui sont malheureusement partagés avec tous les autres TXT), mais le total peut dépasser 100 Ko si vous êtes généreux. Ces deux valeurs sont clairement ouverts aux abus potentiels en tant qu'attaque d'amplification, ce qui est exactement ce que le §10.1 dit que vous devez éviter.
Des preuves empiriques suggèrent qu'un total de 10 mécanismes de recherche est généralement implémenté dans les enregistrements (consultez le SPF pour Microsoft.com qui semble avoir fait des efforts pour garder à exactement 10). Il est difficile de collecter des preuves de l'échec d'un trop grand nombre de recherches car le code d'erreur obligatoire est simplement "PermError", qui couvre toutes sortes de problèmes ( DMARC aider à cela cependant).
L'OpenSPF FAQ perpétue la limite d'un total de "10 recherches DNS", plutôt que le "10 DNS provoquant des mécanismes ou des redirections" plus précis. Ceci FAQ est sans doute faux car il dit en fait:
Puisqu'il y a une limite de 10 recherches DNS par enregistrement SPF, en spécifiant une adresse IP [...]
qui est en désaccord avec la RFC qui impose les limites d'une opération de "vérification SPF", ne limite pas les opérations de recherche DNS de cette manière, et indique clairement qu'un enregistrement SPF est un RR de texte DNS unique. Le FAQ impliquerait que vous redémarrez le décompte lorsque vous traitez un "include" car il s'agit d'un nouvel enregistrement SPF. Quel gâchis.
Recherches DNS
Qu'est-ce qu'une "recherche DNS" de toute façon? En tant qu'utilisateur . Je considérerais "ping www.Microsoft.com "pour impliquer une seule" recherche "DNS: il y a un nom que je m'attends à transformer en une IP. Simple? Malheureusement non.
En tant qu'administrateur je sais que www.Microsoft.com n'est peut-être pas un simple enregistrement A avec une seule IP, il peut s'agir d'un CNAME qui à son tour a besoin une autre recherche discrète pour obtenir un enregistrement A, même si mon résolveur en amont effectuera probablement plutôt que le résolveur sur mon bureau. Aujourd'hui, pour moi, www.Microsoft.com est une chaîne de 3 CNAME qui finit par devenir un enregistrement A sur akamaiedge.net, c'est (au moins) 4 opérations de requête DNS pour quelqu'un. SPF peut voir des CNAME avec le mécanisme "ptr", un enregistrement MX ne doit cependant pas être un CNAME.
Enfin, en tant qu'administrateur DNS je sais que répondre (presque) à n'importe quelle question implique de nombreuses opérations DNS discrètes, des questions individuelles et des transactions de réponse (datagrammes UDP) - en supposant un cache vide, un résolveur récursif doit commencer à la racine DNS et descendre: . → com → Microsoft.com → www.Microsoft.com demander des types spécifiques d'enregistrements (NS, A, etc.) selon les besoins et traiter les CNAME. Vous pouvez le voir en action avec Dig +trace www.Microsoft.com, bien que vous n'obtiendrez probablement pas exactement la même réponse en raison de la supercherie de géolocalisation (exemple ici ). (Il y a même un peu plus à cette complexité puisque les ferroutages SPF sur TXT enregistrements, et des limites obsolètes de 512 octets sur les réponses DNS pourraient signifier une nouvelle tentative de requêtes sur TCP.)
Alors, qu'est-ce que SPF considère comme une recherche? Il est vraiment le plus proche du point de vue de l'administrateur , il doit être conscient des spécificités de chaque type de requête DNS (mais pas au point où il doit en fait compter les datagrammes ou connexions DNS individuels).
RFC4408 s10.1 , comme vous l'avez noté, limite certaines activités DNS. Plus précisément:
Les implémentations SPF DOIVENT limiter le nombre de mécanismes et de modificateurs qui effectuent des recherches DNS à 10 au maximum par vérification SPF, y compris toutes les recherches provoquées par l'utilisation du mécanisme "include" ou du modificateur "redirect". Si ce nombre est dépassé lors d'une vérification, une PermError DOIT être retournée. Les mécanismes "include", "a", "mx", "ptr" et "exist" ainsi que le modificateur "redirect" sont pris en compte dans cette limite. Les mécanismes "tous", "ip4" et "ip6" ne nécessitent pas de recherches DNS et ne sont donc pas pris en compte dans cette limite. Le modificateur "exp" ne compte pas dans cette limite car la recherche DNS pour récupérer la chaîne d'explication se produit après que l'enregistrement SPF a été évalué.
et de plus
Lors de l'évaluation des mécanismes "mx" et "ptr", ou de la macro% {p}, il NE DOIT PAS y avoir plus de 10 RR MX ou PTR recherchés et vérifiés.
Notez que le premier est une limite sur le nombre de mécanismes, pas le nombre de recherches effectuées; mais c'est quand même une limite.
Pour autant que je sache, oui, ces limites sont appliquées assez durement. Ils sont conçus pour empêcher les gens de créer des enregistrements SPF arbitrairement complexes et d'utiliser ceux des serveurs DoS qui vérifient leur enregistrement en les arrêtant dans une énorme chaîne de recherches DNS, il est donc dans l'intérêt de quiconque implémente un vérificateur SPF de honorez-les.
Vous avez raison de noter que les inclusions imbriquées sont susceptibles de causer le plus gros problème avec ces limites, et si vous décidez d'inclure plusieurs domaines dont chacun fait un usage intensif des inclusions elles-mêmes, vous pouvez les parcourir assez rapidement. Ce n'est pas trop difficile à trouver exemples de personnes pour qui cela a créé des problèmes concrets .
Le résultat semble être que les problèmes surviennent généralement lorsque les gens décident d'utiliser à la fois SPF et plusieurs sociétés distinctes et disparates pour gérer leurs e-mails sortants. Je déduis de votre question que vous vous situez dans cette catégorie. SPF ne semble pas être conçu pour servir les personnes qui choisissent de le faire . Si vous insistez pour le faire, vous devrez probablement avoir une sorte de tâche cron sur votre serveur DNS qui évalue constamment tous les enregistrements SPF que vous auriez souhaité inclure, les exprime sous la forme d'une série de ip4: et ip6: mécanismes (dont le nombre est illimité) et republie le résultat en tant qu'enregistrement SPF.
N'oubliez pas de terminer par un -all, ou tout l'exercice était inutile.