Trop de recherches DNS dans un enregistrement SPF
Mon site Web doit envoyer des courriels avec les services Google Apps, SendGrid et MailChimp. Google Apps est utilisé pour recevoir et lire les e-mails entrants sur mon domaine.
Je dois définir l'enregistrement SPF pour mon domaine. Ce qui suit est correct du point de vue de la syntaxe (pas sûr des jetons A et MX):
"v = spf1 un mx inclure: _spf.google.com inclure: servers.mcsv.net inclure: sendgrid.net ~ all"
Mais si je le teste avec http://www.kitterman.com/getspf2.py je reçois
PermError Erreur permanente SPF: trop de recherches DNS
Problème similaire à http://www.onlineaspect.com/2009/03/20/too-many-dns-lookups-in-an-spf-record/
Comment puis-je optimiser/réécrire mon enregistrement SPF?
Donc, je n'ai jamais eu à faire cela auparavant, mais d'après l'article que vous avez envoyé, voici ce que j'ai proposé.
Nous avons commencé avec:
v=spf1 a mx include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all
Nous obtenons un total de 10 recherches avant de générer l'erreur Too many DNS lookups:
2 (Initial TXT & SPF Lookups)
2 (a & mx Lookups)
1 (_spf.google.com)
1 (servers.mcsv.net)
+1 (sendgrid.net)
-----------------
7 Lookups
Donc, sans même suivre les enregistrements SPF inclus, nous avons 7 recherches.
Maintenant, plongons un niveau plus profond.
1. _spf.google.com
L'enregistrement google SPF est évalué à:
v=spf1 include:_netblocks.google.com include:_netblocks6.google.com ?all
Chacun de ces résoudre aux valeurs suivantes:
# _netblocks.google.com
v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all
# _netblocks6.google.com
v=spf1 ip6:2607:f8b0:4000::/36 ip6:2a00:1450:4000::/36 ?all
Donc, Google nous donne 2 autres recherches, ce qui porte le total à 9 Recherches .
2. serveurs.mcsv.net
Mailchimp est un peu un doosey parce qu'il ajoute un total de 3 recherches supplémentaires:
v=spf1 include:spf1.mcsv.net include:spf2.mcsv.net include:spf.mandrillapp.com ?all
J'imagine que selon ce que vous envoyez via Mailchimp, vous pourrez peut-être supprimer un ou deux de ces enregistrements (mais vous devrez évaluer cela vous-même).
Quoi qu'il en soit, ceux-ci résolvent à ce qui suit:
# spf1.mcsv.net
v=spf1 ip4:207.97.237.194/31 ip4:207.97.238.88/29 ip4:207.97.240.168/29 ip4:69.20.10.80/29 ip4:69.20.41.72/27 ip4:74.205.22.1/27 ip4:69.20.90.0/26 ?all
# spf2.mcsv.net
v=spf1 ip4:204.232.163.0/24 ip4:72.26.195.64/27 ip4:74.63.47.96/27 ip4:173.231.138.192/27 ip4:173.231.139.0/24 ip4:173.231.176.0/20 ip4:205.201.128.0/24 ?all
# spf.mandrillapp.com
v=spf1 ip4:205.201.136.0/24 ip4:205.201.137.0/24 ?all
Cela nous amène à un total de 12 recherches (ce qui représente déjà deux dépassements de la limite).
2. sendgrid.net
SendGrid finit par être le plus petit nombre de recherches supplémentaires pour nous.
v=spf1 ip4:208.115.214.0/24 ip4:74.63.202.0/24 ip4:75.126.200.128/27 ip4:75.126.253.0/24 ip4:67.228.50.32/27 ip4:174.36.80.208/28 ip4:174.36.92.96/27 ip4:69.162.98.0/24 ip4:74.63.194.0/24 ip4:74.63.234.0/24 ip4:74.63.235.0/24 include:sendgrid.biz ~all
Donc, la seule recherche supplémentaire ici est sendgrid.biz, ce qui donne:
v=spf1 ip4:208.115.235.0/24 ip4:74.63.231.0/24 ip4:74.63.247.0/24 ip4:74.63.236.0/24 ip4:208.115.239.0/24 ip4:173.193.132.0/24 ip4:173.193.133.0/24 ip4:208.117.48.0/20 ip4:50.31.32.0/19 ip4:198.37.144.0/20 ~all
Ceci porte notre total à 14 recherches.
Donc, notre grand total est 14 Lookups . Nous avons réduit ce nombre à 10. J'ai présenté quelques options ci-dessous. Vous devrez peut-être en utiliser plus d'une pour la réduire.
Incluez directement certains des enregistrements spf redirigés. Maintenant que nous savons à quels serveurs les enregistrements spf sont redirigés, vous pouvez supprimer l’intermédiaire et les inclure directement. Remarque: Si l'un des services modifie ses enregistrements SPF, vous devrez procéder à la mise à jour manuelle des vôtres.
Supprimez certains des services que vous utilisez. Vous n'êtes pas sûr de savoir quel est votre cas d'utilisation de tous ces services, mais il est certain que vous pourriez utiliser des chevauchements. Par exemple, SendGrid prend en charge (1) le courrier sortant transactionnel, (2) les e-mails de newsletter/marketing et (3) le courrier entrant. Il peut donc y avoir une redondance réductible.
Supprimez l'enregistrement MX s'il est redondant. Selon votre configuration, la recherche MX peut être redondante.
J'espère que cela t'aides!
La réponse de Swift est excellente.
Une technique non mentionnée ci-dessus consiste à déterminer si des sous-domaines distincts dotés de leurs propres enregistrements SPF peuvent être utilisés pour les systèmes qui envoient des messages via ces différentes routes.
Par exemple. si le domaine est example.com, demandez à Google Apps d’envoyer des adresses telles que [email protected]. Ensuite, il peut y avoir un enregistrement SPF pour gapps.example.com qui comprend _spf.google.com, et _spf.google.com peut être supprimé de l'enregistrement example.com SPF principal, ce qui réduit le nombre de recherches de 3.
Jetez un coup d'œil à SPF-tools * qui aident à réassembler l'enregistrement SPF de celui qui utilise l'original avec une inclusion statique dans un champ contenant uniquement les champs ip4 et ip6. Il peut être facilement couplé à un serveur DNS exécuté localement ou à un service DNS hébergé à l'aide de leur API afin de tout synchroniser avec les inclusions en amont.
* Je suis l'auteur (maintenant avec d'autres contributeurs) et il est open source sous licence Apache 2.0.
Il y a quelques années, j'ai écrit hydrate-spf , un outil permettant de rechercher et de fusionner le résultat en un seul enregistrement géant. Comme indiqué dans le fichier README, cette approche n’est pas idéale; elle empêche les domaines inclus de mettre à jour leurs enregistrements. Cependant, lorsque vous vous heurtez à la limite autorisée, le problème immédiat sera résolu, et vous pourrez le maintenir maintenue grâce à des mises à jour régulières.
Nous avons envisagé de réduire les enregistrements SPF dans des adresses IP ainsi que de créer des sous-domaines. Ils semblaient tous avoir beaucoup de travail. Nous avons trouvé un service sur spfproxy.org qui prend littéralement quelques minutes à configurer. Ils masquent essentiellement les recherches DNS derrière eux à l'aide de macros SPF. Vous ne savez pas pourquoi plus d'entreprises n'offrent pas cela.
La limite de 10 recherches est une limite pour les recherches DNS. L'aplatissement de l'enregistrement SPF pour inclure moins de recherches DNS et sa substitution aux adresses IP (l'aplatissement) est un moyen de contourner la limite.
Vous pouvez le faire manuellement, mais vous devez ensuite mettre à jour vos enregistrements SPF chaque fois que l'un des fournisseurs change d'adresse IP (ce qui se produit fréquemment).
La solution idéale consiste à utiliser un service d'aplatissement SPF. Celui-ci est gratuit pour les petits volumes, ou pas cher pour plus de 500 emails/mois. Il interroge régulièrement les enregistrements SPF que vous souhaitez inclure pour les adresses IP mises à jour.
Divulgation: Je ne suis pas associé à cette société et il ne s'agit pas d'un lien de parrainage
Cette limite de 10 DNS est imposée par les implémentations SPF pour empêcher les attaques DDoS contre l'infrastructure DNS.
Avec la fonction Safe SPF de DMARCLY /, vous pouvez lever la limite sans réécrire votre enregistrement SPF.