Ambos libspf2(C) e Mail::SPF::Query(perl, usado no sendmail-spf-milter ) implementam um limite de 10 mecanismos causadores de DNS , mas o último não (AFAICT) aplica os limites MX ou PTR. libspf2limita cada um de mx e ptr a 10 também.
Mail::SPF(perl) tem um limite de 10 mecanismos causadores de DNS e um limite de 10 pesquisas por mecanismo, por MX e por PTR. (Os dois pacotes perl geralmente são usados, embora não por padrão, no MIMEDefang .)
pyspftem limites de 10 em todos os: "pesquisas", MX, PTR, CNAME; mas multiplica explicitamente MAX_LOOKUPS por 4 durante a operação. A menos que no modo "estrito", ele também multiplique MAX_MX e MAX_PTR por 4.
Não posso comentar sobre implementações comerciais / proprietárias, mas as opções acima (exceto pyspf) claramente implementam um limite superior de 10 mecanismos de acionamento de DNS (mais sobre isso abaixo), mais ou menos, embora na maioria dos casos possam ser substituídos em execução. Tempo.
No seu caso específico, você está correto, são 12 inclusões e excede o limite de 10. Eu esperaria que a maioria dos softwares SPF retornasse "PermError"; no entanto , as falhas afetarão apenas os provedores "incluídos" finais, porque a contagem será calculado como um total corrente: os mecanismos SPF são avaliados da esquerda para a direita e as verificações serão antecipadas em um passe, portanto, depende de onde na sequência o servidor de envio aparece.
A maneira de contornar isso é usar mecanismos que não acionem pesquisas de DNS, por exemplo, ip4e ip6, e depois usar, mxse possível, pois você recebe até mais 10 nomes, cada um dos quais com mais de um IP.
Como o SPF resulta em solicitações arbitrárias de DNS com escala potencialmente exponencial, ele pode ser facilmente explorado para ataques de DOS / amplificação. Ele tem limites deliberadamente baixos para evitar isso: não é dimensionado da maneira que você deseja.
10 mecanismos (estritamente mecanismos + o modificador "redirecionar") que causam pesquisas de DNS não são exatamente a mesma coisa que 10 pesquisas de DNS. Até as "pesquisas de DNS" estão abertas à interpretação, você não sabe quantas pesquisas discretas são necessárias e não sabe quantas pesquisas discretas seu resolvedor recursivo pode precisar realizar (veja abaixo).
RFC 4408 §10.1 :
As implementações de SPF DEVEM limitar o número de mecanismos e modificadores que fazem pesquisas de DNS a no máximo 10 por verificação de SPF, incluindo quaisquer pesquisas causadas pelo uso do mecanismo "incluir" ou do modificador "redirecionar". Se esse número for excedido durante uma verificação, um PermError DEVE ser retornado. Os mecanismos "incluir", "a", "mx", "ptr" e "existe", bem como o modificador "redirecionar", contam para esse limite. Os mecanismos "todos", "ip4" e "ip6" não exigem pesquisas de DNS e, portanto, não são contabilizados nesse limite.
[...]
Ao avaliar os mecanismos "mx" e "ptr" ou a macro% {p}, DEVE haver um limite de não mais do que 10 MXs ou PTR RRs consultados e verificados.
Portanto, você pode usar até 10 mecanismos / modificadores que acionam pesquisas de DNS. (A redação aqui é ruim: parece indicar apenas o limite superior do limite, uma implementação de confirmação pode ter um limite de 2.)
§5.4 para o mecanismo mx e §5.5 para o mecanismo ptr têm, cada um, um limite de 10 pesquisas com esse tipo de nome, e isso se aplica apenas ao processamento desse mecanismo, por exemplo:
Para evitar ataques de negação de serviço (DoS), mais de 10 nomes MX NÃO devem ser consultados durante a avaliação de um mecanismo "mx" (consulte a Seção 10).
ou seja, você pode ter 10 mecanismos mx, com até 10 nomes MX, para que cada um deles possa causar 20 operações DNS (10 pesquisas MX + 10 A DNS cada) para um total de 200. É semelhante para ptr ou % {p} . pode olhar para cima 10 ptr mecanismos, por conseguinte, 10x10 PTR, cada PTR também requer uma pesquisa a, novamente com um total de 200.
É exatamente isso que a suíte de testes 2009.10 verifica, consulte os testes " Limites de processamento ".
Não há um limite superior claramente definido para o número total de operações de pesquisa de DNS do cliente por verificação do SPF, calculo-o como implicitamente 210, mais ou menos. Há também uma sugestão para limitar o volume de dados DNS por verificação do SPF, mas nenhum limite real é sugerido. Você pode obter uma estimativa aproximada, pois os registros SPF estão limitados a 450 bytes (que infelizmente são compartilhados com todos os outros registros TXT), mas o total pode exceder 100 kB se você for generoso. Ambos os valores estão claramente abertos a possíveis abusos como um ataque de amplificação, que é exatamente o que § 10.1 diz que você precisa evitar.
As evidências empíricas sugerem que um total de 10 mecanismos de pesquisa é comumente implementado nos registros (confira o SPF do microsoft.com que parece ter se esforçado para mantê-lo exatamente em 10). É difícil coletar evidências de falha de muitas pesquisas, porque o código de erro obrigatório é simplesmente "PermError", que abrange todos os tipos de problemas (os relatórios do DMARC podem ajudar nisso).
O FAQ do OpenSPF perpetua o limite de um total de "10 pesquisas de DNS", em vez dos "10 mecanismos ou redirecionamentos que causam 10 DNS mais precisos". Este FAQ está indiscutivelmente errado, uma vez que realmente diz:
Como existe um limite de 10 pesquisas de DNS por registro SPF, especificando um endereço IP [...]
que está em desacordo com o RFC que impõe os limites em uma operação "verificação de SPF", não limita as operações de pesquisa de DNS dessa maneira e afirma claramente que um registro SPF é um único texto de DNS RR. As perguntas frequentes implicariam que você reinicie a contagem ao processar uma "inclusão", pois esse é um novo registro SPF. Que bagunça.
Pesquisas de DNS
O que é uma "pesquisa de DNS" de qualquer maneira? Como usuário . Eu consideraria " ping www.microsoft.com" envolver uma única "pesquisa" de DNS: há um nome que espero transformar em um IP. Simples? Infelizmente, não.
Como administrador, eu sei que www.microsoft.com pode não ser um registro A simples com um único IP, pode ser um CNAME que, por sua vez, precisa de outra pesquisa discreta para obter um registro A, embora o meu resolvedor upstream provavelmente execute em vez do resolvedor na minha área de trabalho. Hoje, para mim, www.microsoft.com é uma cadeia de 3 CNAMEs que finalmente acaba como um registro A no akamaiedge.net, que representa (pelo menos) quatro operações de consulta DNS para alguém. O SPF pode ver CNAMEs com o mecanismo "ptr", mas um registro MX não deve ser um CNAME.
Finalmente, como administrador de DNS , sei que responder (quase) a qualquer pergunta envolve muitas operações DNS discretas, perguntas individuais e transações de resposta (datagramas UDP) - assumindo um cache vazio, um resolvedor recursivo precisa iniciar na raiz do DNS e seguir seu caminho down: . → com→ microsoft.com→ www.microsoft.comsolicitando tipos específicos de registros (NS, A etc) conforme necessário e lidando com CNAMEs. Você pode ver isso em ação com dig +trace www.microsoft.com, embora provavelmente não obtenha exatamente a mesma resposta devido a truques de localização geográfica (exemplo aqui ). (Há um pouco mais nessa complexidade, uma vez que o SPF pega nos registros TXT, e limites obsoletos de 512 bytes nas respostas DNS podem significar tentar novamente as consultas pelo TCP.)
Então, o que o SPF considera como uma pesquisa? É realmente o ponto de vista do administrador , ele precisa estar ciente das especificidades de cada tipo de consulta DNS (mas não ao ponto em que realmente precisa contar datagramas ou conexões DNS individuais).