Tanto libspf2(C) como Mail::SPF::Query(perl, utilizado en sendmail-spf-milter ) implementan un límite de 10 mecanismos causantes de DNS , pero este último (AFAICT) no aplica los límites MX o PTR. libspf2limita cada uno de mx y ptr a 10 también.
Mail::SPF(perl) tiene un límite de 10 mecanismos causantes de DNS y un límite de 10 búsquedas por mecanismo, por MX y por PTR. (Los dos paquetes perl se usan comúnmente, aunque no de manera predeterminada, en MIMEDefang ).
pyspftiene límites de 10 en todas las "búsquedas", MX, PTR, CNAME; pero explícitamente multiplica MAX_LOOKUPS por 4 durante la operación. A menos que esté en modo "estricto", también multiplica MAX_MX y MAX_PTR por 4.
No puedo comentar sobre implementaciones comerciales / propietarias, pero lo anterior (excepto pyspf) implementa claramente un límite superior de 10 mecanismos de activación de DNS (más sobre eso a continuación), más o menos, aunque en la mayoría de los casos se puede anular en la ejecución hora.
En su caso específico está en lo correcto, es 12 incluye y eso excede el límite de 10. Esperaría que la mayoría del software SPF devuelva "PermError", sin embargo , las fallas solo afectarán a los proveedores finales "incluidos" porque el recuento se calculará como un total acumulado: los mecanismos SPF se evalúan de izquierda a derecha y las comprobaciones "saldrán anticipadamente" en un pase, por lo que depende de en qué parte de la secuencia aparezca el servidor emisor.
La forma de evitar esto es usar mecanismos que no activen las búsquedas de DNS, por ejemplo, ip4y ip6, y luego usar mxsi es posible, ya que eso le da hasta 10 nombres adicionales, cada uno de los cuales puede tener más de una IP.
Dado que SPF genera solicitudes DNS arbitrarias con escalamiento potencialmente exponencial, podría explotarse fácilmente para ataques DOS / amplificación. Tiene límites deliberadamente bajos para evitar esto: no se escala de la manera que desea.
Sin embargo, 10 mecanismos (estrictamente mecanismos + el modificador de "redireccionamiento") que provocan búsquedas de DNS no es exactamente lo mismo que 10 búsquedas de DNS. Incluso las "búsquedas DNS" están abiertas a interpretación, no sabe de antemano cuántas búsquedas discretas se requieren, y no sabe cuántas búsquedas discretas puede necesitar realizar su resolución recursiva (ver más abajo).
RFC 4408 §10.1 :
Las implementaciones de SPF DEBEN limitar el número de mecanismos y modificadores que realizan búsquedas de DNS a un máximo de 10 por verificación de SPF, incluidas las búsquedas causadas por el uso del mecanismo "incluir" o el modificador "redireccionar". Si se excede este número durante una verificación, se DEBE devolver un PermError. Los mecanismos "incluir", "a", "mx", "ptr" y "existe", así como el modificador "redirigir" cuentan para este límite. Los mecanismos "todos", "ip4" e "ip6" no requieren búsquedas de DNS y, por lo tanto, no cuentan para este límite.
[...]
Al evaluar los mecanismos "mx" y "ptr", o la macro% {p}, DEBE haber un límite de no más de 10 MX o PTR RR buscados y verificados.
Por lo tanto, puede utilizar hasta 10 mecanismos / modificadores que desencadenan búsquedas de DNS. (La redacción aquí es pobre: parece indicar solo el límite superior del límite, una implementación confirmada podría tener un límite de 2).
§5.4 para el mecanismo mx , y §5.5 para el mecanismo ptr tienen un límite de 10 búsquedas de ese tipo de nombre, y eso se aplica solo al procesamiento de ese mecanismo, por ejemplo:
Para evitar ataques de denegación de servicio (DoS), NO DEBEN buscarse más de 10 nombres MX durante la evaluación de un mecanismo "mx" (consulte la Sección 10).
es decir, puede tener mecanismos de 10 mx, con hasta 10 nombres MX, por lo que cada uno de ellos puede causar 20 operaciones de DNS (10 búsquedas de MX + 10 A DNS cada una) para un total de 200. Es similar para ptr o % {p} , usted puede buscar mecanismos de 10 ptr , por lo tanto, 10x10 PTR, cada PTR también requiere una búsqueda A, nuevamente un total de 200.
Esto es exactamente lo que comprueba el conjunto de pruebas 2009.10 , consulte las pruebas " Límites de procesamiento ".
No hay un límite superior claramente establecido en el número total de operaciones de búsqueda de DNS del cliente por verificación SPF, lo calculo implícitamente como 210, más o menos. También hay una sugerencia para limitar el volumen de datos DNS por verificación SPF, aunque no se sugiere ningún límite real. Puede obtener una estimación aproximada ya que los registros SPF están limitados a 450 bytes (que tristemente se comparte con todos los demás registros TXT), pero el total podría exceder los 100 KB si es generoso. Ambos valores están claramente expuestos a posibles abusos como un ataque de amplificación, que es exactamente lo que §10.1 dice que debe evitar.
La evidencia empírica sugiere que un total de 10 mecanismos de búsqueda se implementan comúnmente en los registros (consulte el SPF para microsoft.com que parece haber hecho todo lo posible para mantenerlo exactamente en 10). Es difícil recopilar evidencia de fallas en demasiadas búsquedas porque el código de error obligatorio es simplemente "PermError", que cubre todo tipo de problemas (los informes DMARC podrían ayudar con eso).
Las preguntas frecuentes de OpenSPF perpetúan el límite de un total de "10 búsquedas de DNS", en lugar de los "mecanismos o redireccionamientos de 10 DNS" más precisos. Esta pregunta frecuente es posiblemente incorrecta ya que en realidad dice:
Dado que hay un límite de 10 búsquedas de DNS por registro SPF, especificando una dirección IP [...]
que está en desacuerdo con el RFC que impone los límites en una operación de "verificación de SPF", no limita las operaciones de búsqueda de DNS de esta manera, y establece claramente que un registro de SPF es un solo texto de DNS RR. Las preguntas frecuentes implicarían que reinicie el recuento cuando procese una "inclusión", ya que se trata de un nuevo registro SPF. Que desastre.
Búsquedas de DNS
¿Qué es una "búsqueda de DNS" de todos modos? Como usuario . Consideraría " ping www.microsoft.com" involucrar una sola "búsqueda" de DNS: hay un nombre que espero convertir en una IP. ¿Simple? Tristemente no.
Como administrador , sé que www.microsoft.com podría no ser un simple registro A con una sola IP, podría ser un CNAME que, a su vez, necesita otra búsqueda discreta para obtener un registro A, aunque es probable que lo haga mi resolutor ascendente en lugar de la resolución en mi escritorio. Hoy, para mí, www.microsoft.com es una cadena de 3 CNAME que finalmente terminan como un registro A en akamaiedge.net, es decir (al menos) 4 operaciones de consulta DNS para alguien. SPF puede ver CNAME con el mecanismo "ptr", aunque un registro MX no debería ser un CNAME.
Finalmente, como administrador de DNS , sé que responder (casi) cualquier pregunta implica muchas operaciones discretas de DNS, preguntas individuales y transacciones de respuesta (datagramas UDP), suponiendo que haya un caché vacío, un resolutor recursivo debe comenzar en la raíz del DNS y funcionar a su manera abajo: . → com→ microsoft.com→ www.microsoft.compreguntando por tipos específicos de registros (NS, A, etc.) según sea necesario, y tratando con CNAME. Puede ver esto en acción con dig +trace www.microsoft.com, aunque probablemente no obtendrá exactamente la misma respuesta debido al truco de geolocalización (ejemplo aquí ). (Hay incluso un poco más de esta complejidad ya que SPF se complementa con los registros TXT, y los límites obsoletos de 512 bytes en las respuestas de DNS pueden significar volver a intentar consultas a través de TCP).
Entonces, ¿qué considera SPF como una búsqueda? Está realmente más cerca del punto de vista del administrador , debe ser consciente de los detalles de cada tipo de consulta DNS (pero no del punto en el que realmente necesita contar los datagramas o conexiones DNS individuales).