La limite de recherche 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.comet que ces trois domaines ont chacun des enregistrements SPF qui ont également 3 includeentrées, nous avons maintenant jusqu'à 3 + 3 + 3 + 3 = 12 recherches DNS.

1. ma compréhension ci-dessus est-elle correcte?

2. J'utilise seulement 2 ou 3 services pour mon domaine et j'ai déjà dépassé cette limite. Cette limite est-elle généralement (ou jamais) appliquée par les principaux fournisseurs de messagerie?

Les deux libspf2(C) et Mail::SPF::Query(perl, utilisé dans sendmail-spf-milter ) mettre en œuvre une limite de 10 mécanismes causant DNS , mais celui - ci ne s'applique pas (AFAICT) les limites MX ou PTR. libspf2limite 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 .)

pyspfa des limites de 10 sur tous les éléments suivants: "recherches", 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 sur ci-dessous), donner ou prendre, bien que dans la plupart des cas, il puisse être annulé lors de l'exécution - temps.

Dans votre cas spécifique, vous avez raison, il s'agit de 12 inclusions et cela dépasse la limite de 10. Je m'attends à ce que la plupart des logiciels SPF renvoient «PermError», cependant , les échecs n'affecteront que le ou les fournisseurs finaux «inclus» car le nombre sera calculé comme un total cumulé: les mécanismes SPF sont évalués de gauche à droite et les vérifications seront "anticipées" 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 ip4et ip6, puis à utiliser mxsi possible car cela vous permet d'obtenir jusqu'à 10 autres noms, chacun pouvant avoir plusieurs adresses 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 mécanismes + le modificateur "rediriger") provoquant des 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).

RFC 4408 §10.1 :

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.)

Le §5.4 pour le mécanisme mx et le §5.5 pour le mécanisme ptr ont chacun 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 pendant 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 DNS MX + 10 A chacune) pour un total de 200. C'est similaire pour ptr ou % {p} , vous peuvent rechercher 10 ptr mécanismes, donc 10x10 REE, chaque PTR exige également une une recherche, encore une fois un total de 200.

C'est exactement ce que la suite de tests 2009.10 vérifie, voir les tests " Limites de traitement ".

Il n'y a pas de limite supérieure clairement indiquée sur le nombre total d'opérations de recherche DNS client par SPF-check, 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 (ce qui est malheureusement partagé avec tous les autres enregistrements TXT), mais le total pourrait dépasser 100 Ko si vous êtes généreux. Ces deux valeurs sont clairement ouvertes 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 le maintenir à 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 (les rapports DMARC peuvent cependant aider à cela).

La FAQ OpenSPF perpétue la limite d'un total de "10 recherches DNS", plutôt que les "10 mécanismes ou redirections DNS provoquant plus de précision". Cette FAQ est sans doute erronée car elle 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. La FAQ impliquerait que vous redémarrez le décompte lorsque vous traitez une "inclusion" car il s'agit d'un nouvel enregistrement SPF. Quel bordel.

Recherches DNS

Qu'est-ce qu'une "recherche DNS" de toute façon? En tant qu'utilisateur . Je considérerais que " ping www.microsoft.com" implique une seule "recherche" DNS: il y a un nom que je m'attends à transformer en une seule IP. Simple? Malheureusement pas.

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 d'une autre recherche discrète pour obtenir un enregistrement A, bien que celui que 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 suivre son chemin vers le bas: . → com→ microsoft.com→ www.microsoft.comdemander 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 la même réponse exacte en raison de la supercherie de géolocalisation (exemple ici ). (Il y a même un peu plus à cette complexité depuis les ferroutages SPF sur les enregistrements TXT, et les 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? C'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 réellement compter les datagrammes ou les connexions DNS individuels).

Comme vous l'avez noté, la RFC4408 s10.1 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. Il n'est pas trop difficile de trouver des exemples de personnes pour lesquelles 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 leur courrier électronique sortant. 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 en permanence tous les enregistrements SPF vous auriez voulu inclure les exprime comme une série de ip4:et ip6:mécanismes (le nombre dont il n'y a pas de limite) et republie le résultat en tant qu'enregistrement SPF.

N'oubliez pas de terminer avec un -all, ou tout l'exercice était inutile.