Soluções alternativas para o limite máximo de termos interativos do DNS excedido no registro SPF?

Question

Como um provedor de hospedagem, enviamos e-mails em nome de nossos clientes, por isso os ajudamos a configurar os registros de e-mail DKIM e SPF em seu DNS para obter a capacidade de entrega de e-mails da maneira correta. Nós os aconselhamos a usar o link para testar se eles não perderam nada, e eu gosto muito dessa ferramenta.

Um problema que encontramos algumas vezes, e não tenho certeza, é o "limite" de DNS no registro SPF com base no nome de domínio. Então, se você tem isso:

v=spf1 a include:aspmx.googlemail.com include:campaignmonitor.com include:authsmtp.com include:mail.zendesk.com include:salesforce.com include:_hostedspf.discourse.org ~all

Você terá

example.com ... campaignmonitor.com: Maximum DNS-interactive term limit (10) exceeded

Assim:

Eutenhoalgumasperguntassobreisso.

1. Eucontoseisnomesdedomínioaqui,não10,entãoporqueestáatingindo"dez" solicitações de DNS aqui? Respondido aqui

2. Esse limite interativo de 10 termos do DNS é um aviso ou um erro real? , por exemplo devemos nos importar? Está incomodando nossos clientes um pouco e eles nos enviam um email para obter suporte. Respondido aqui

3. Esse limite interativo de 10 DNS limita um problema real na Web de hoje? Como você pode ver, esse cliente tem um lote de serviços enviando e-mail para eles e todos são legítimos. Talvez esse limite de DNS tenha sido definido no ano 2000, quando a delegação de serviços de e-mail como esse não era comum?

Sim, podemos fazer com que nossos clientes alterem a inclusão para IPs no registro SPF , mas isso nos coloca em uma situação difícil, se mudarmos os IPs, um monte de coisas dos clientes será interrompido. Realmente não quero fazer isso ..

Quais soluções alternativas existem para isso?

    

Answer 1

1. Supondo que as redundâncias (como várias referências a _spf.google.com e os registros a que se referem) sejam contadas apenas uma vez, eu conto 17 pesquisas do ponto em que você já consultou o registro inicial. (Veja abaixo).

2. Recusa-se a procurar todos os registros necessários para avaliar seu registro SPF porque seria "muito trabalho". Presumivelmente, isso significa que ele tratará seu domínio como se não tivesse nenhum registro SPF (ou possivelmente o rejeitasse). A especificação diz que isso resulta em permerror , que deixa bastante aberto para o destinatário decidir o que fazer .

3. Eu acho que o abuso tem aumentado em vez de diminuir, geralmente. Esse limite parece ter o objetivo de impedir que domínios de remetentes abusivos possam, de outra forma, sobrecarregar o destinatário com enormes cadeias de SPF, o que pode levar a DoS.

Acho que, embora a terceirização de e-mails seja comum, na verdade não é comum terceirizar o e-mail para seis provedores diferentes. Você terá que otimizar o registro SPF de alguma forma. (Por um lado, a referência a aspmx.googlemail.com parece um desperdício, já que imediatamente redireciona para um nome diferente.)

<lookup of example.com A>                   #1
$ dig aspmx.googlemail.com TXT +short       #2
"v=spf1 redirect=_spf.google.com"
$ dig _spf.google.com TXT +short            #3
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
$ dig _netblocks.google.com TXT +short      #4
"v=spf1 ip4:64.18.0.0/20 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:173.194.0.0/16 ip4:207.126.144.0/20 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"
$ dig _netblocks2.google.com TXT +short     #5
"v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"
$ dig _netblocks3.google.com TXT +short     #6
"v=spf1 ~all"
$ dig campaignmonitor.com TXT +short        #7
"google-site-verification=HcHoB67Mph6vl5_x4gK5MN9YwN5gMgfZYdNmsP07tIg"
"v=spf1 mx ptr ip4:23.253.29.45/29 ip4:203.65.192.250 include:cmail1.com include:_spf.google.com include:stspg-customer.com ~all"
$ dig cmail1.com TXT +short                 #8
"google-site-verification=HSJ8sL4AxQo0YHHNk9RwDqs0p3lJPGmc1nCrSsmous8"
"mailru-verification: 95d4c6eb0645b43c"
"v=spf1 ip4:103.28.42.0/24 ip4:146.88.28.0/24 ip4:163.47.180.0/22 ip4:203.55.21.0/24 ip4:204.75.142.0/24 ~all"
$ dig stspg-customer.com TXT +short         #9
"v=spf1 ip4:166.78.68.221 ip4:166.78.69.146 ip4:23.253.182.103 ip4:192.237.159.42 ip4:192.237.159.43 ip4:167.89.46.159 ip4:167.89.64.9 ip4:167.89.65.0 ip4:167.89.65.100 ip4:167.89.65.53 -all"
$ dig authsmtp.com TXT +short               #10
"v=spf1 include:spf-a.authsmtp.com include:spf-b.authsmtp.com ~all"
"google-site-verification=skc1TleK4GylDiNZUayfvWWgqZIxmmiRj4KgXlCgB8E"
$ dig spf-a.authsmtp.com TXT +short         #11
"v=spf1 ip4:62.13.128.0/24 ip4:62.13.129.128/25 ip4:62.13.136.0/22 ip4:62.13.140.0/22 ip4:62.13.144.0/22 ip4:62.13.148.0/23 ip4:62.13.150.0/23 ip4:62.13.152.0/23 ~all"
$ dig spf-b.authsmtp.com TXT +short         #12
"v=spf1 ip4:72.52.72.32/28 ip4:64.49.192.16/29 ip4:209.61.188.242 ip4:64.49.192.24 ip4:64.49.192.25 ip4:64.49.210.64/29 ip4:64.49.210.72/30 ip4:64.49.210.76 ip4:64.49.210.77 ip4:64.49.210.78 ~all"
$ dig mail.zendesk.com TXT +short           #13
"v=spf1 ip4:192.161.144.0/20 ip4:185.12.80.0/22 ip4:96.46.150.192/27 ip4:174.137.46.0/24 ~all"
$ dig salesforce.com TXT +short             #14
"adobe-idp-site-verification=898b7dda-16a9-41b7-9b84-22350b35b562"
"MS=749862C9F42827A017A6EA2D147C7E96B3006061"
"MS=ms68630177"
"v=spf1 include:_spf.google.com include:_spfblock.salesforce.com include:_qa.salesforce.com ip4:136.146.208.16/28 ip4:136.146.210.16/28 ip4:136.146.208.240/28 ip4:136.146.210.240/28 ip4:85.222.130.224/28 ip4:136.147.62.224/28 ip4:136.147.46.224/28 mx ~all"
$ dig _spfblock.salesforce.com TXT +short   #15
"v=spf1 ip4:96.43.144.0/20 ip4:182.50.76.0/22 ip4:202.129.242.0/23 ip4:204.14.232.0/21 ip4:62.17.146.128/26 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:68.232.207.20 ip4:207.67.38.45 ip4:198.245.81.1 ip4:198.245.95.4/30 ip4:136.146.128.64/27  ~all"
$ dig _qa.salesforce.com TXT +short         #16
"v=spf1 ip4:199.122.122.176/28 ip4:199.122.121.112/28 ip4:199.122.122.240/28 ip4:66.231.95.0/29 ~all"
$ dig _hostedspf.discourse.org TXT +short   #17
"v=spf1 ip4:64.71.148.0/29 ip6:2001:470:1:3c2::/64 -all"

    

Answer 2

1. Principalmente já respondidas, anote incluindo o Google dessa maneira está errado - você quer use _spf.google.com ou incorrer em uma penalidade pelo redirecionamento:

   ○ → host -t txt aspmx.googlemail.com
   aspmx.googlemail.com descriptive text "v=spf1 redirect=_spf.google.com"
   
   ○ → host -t txt _spf.google.com
   _spf.google.com descriptive text "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
   

Essa pesquisa consome 5/10 todos por conta própria - 4/10 ainda é uma droga, mas 20% a menos.

2. Ele interrompe o processamento e retorna um erro permanente - cabe ao mecanismo usar o SPF para decidir como ele deseja tratar um erro permanente.

3. Sim - sem os limites de processamento, os mecanismos SPF podem ser usados como amplificador DoS uma terceira parte ou segunda parte.

Como solução alternativa, os e-mails podem vir de um subdomínio da propriedade principal - community.largecorporation.com , por exemplo.

    

Answer 3

Como a resposta aceita para uma das perguntas vinculadas deixa claro, muitas das ferramentas subjacentes para os sistemas UNIX realmente imponha esse limite (embora não todos exatamente da mesma maneira), portanto, qualquer implementação de SPF que os utilize - que é quase tudo no UNIX - aplicará esses limites também. Os sistemas Windows são uma lei em si, e eu não posso lançar nenhuma luz sobre eles.

A solução é ter uma tarefa cron que avalie sua cadeia de registros SPF terceirizados, expresse-os todos como netblocks ipv4 e ipv6 e faça isso no seu registro. Não se esqueça do -all .

No seu caso, você deseja que os clientes possam publicar um registro SPF que eles não precisam manter. Uma possibilidade seria fazer com que cada cliente publicasse um registro contendo redirect=spf.client1.jeffs-company.example , e você faria o trabalho de manutenção da lista de netblocks em jeffs-company.example .

Perhaps this DNS limit was set in the year 2000 when delegating email services like this were not common?

O limite dificulta a terceirização do seu email para seis ou sete grandes operações; mas, sem dúvida, se você está fazendo isso, você tem, para todos os propósitos práticos, o controle do seu e-mail de qualquer maneira.

Algum lugar, algum dia, algum programador subcontratado de cuja existência você desconhecia completamente e sobre quem você não tem controle vai colocar um ponto-e-vírgula, e uma tonelada de e-mail falso será enviada com o seu SPF imprimatur isto. O controle total do seu e-mail requer controle total da sua infraestrutura de e-mail, e isso é, na minha opinião, totalmente inconsistente com essa grande terceirização.