¿Se aplica normalmente el límite de búsqueda de 10 DNS en la especificación SPF?

24

Según tengo entendido, la especificación SPF especifica que un receptor de correo electrónico no debería tener que hacer más de 10 búsquedas de DNS para reunir todas las IP permitidas para un remitente. Entonces, si un registro SPF tiene include:foo.com include:bar.com include:baz.comy esos tres dominios tienen registros SPF que también tienen 3 includeentradas, ahora tenemos hasta 3 + 3 + 3 + 3 = 12 búsquedas DNS.

  1. ¿Es correcto mi entendimiento anterior?

  2. Solo uso 2 o 3 servicios para mi dominio y ya he superado este límite. ¿Es este límite típicamente (o alguna vez) impuesto por los proveedores de correo electrónico principales / menores?

John Bachir
fuente
3
RFC4408 s10.1 dice que "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 ", pero esto es una limitación en el número de mecanismos y modificadores que hacen ... búsquedas , no la cantidad de cheques que hacen ¿Podría darnos una idea más clara de cómo cree que su registro SPF está incumpliendo ese límite?
MadHatter apoya a Monica el
@MadHatter gracias por esa información! He aclarado mi pregunta.
John Bachir
Potencialmente podría ser incluso más de 12 si las inclusiones se refieren a registros CNAME o MX en lugar de solo direcciones IP. A menos que no entienda a qué se refiere @ MadHatter.
Simon East

Respuestas:

29

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: .commicrosoft.comwww.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).

Sr. púrpura
fuente
Esta herramienta le permite saber si tiene más de 10 búsquedas: tools.bevhost.com/spf
Gaia
¿podría darme la versión ELI5 de su publicación? ¿Dónde debería tener menos de 10 entradas en emailstuff.org/spf ? En la pestaña DNS? En la pestaña 'resultado' solo veo 5 entradas (cada una con muchas IP.)
Gaia
2
Aquí hay otras dos herramientas SPF que parecían útiles: dmarcian.com/spf-survey : muestra un mensaje de error de color rojo brillante si su SPF supera las 10 búsquedas. emailstuff.org/spf : haga clic en la pestaña DNS una vez que reciba el informe (pero debe contarlos usted mismo).
medmunds
Todavía estoy confundido. ¿Podría dar un ejemplo de cómo una "búsqueda" es diferente de un "mecanismo"? ¿O es la conclusión de que realmente no importa, que aún debe mantenerse dentro de 10 búsquedas?
Simon East
1
@SimonEast agregó una explicación, SPF necesita comprender las implicaciones de cada tipo de registro DNS para que pueda obtener una estimación aproximada del "costo" DNS, sin contar realmente todos los beans.
mr.spuratic
11

RFC4408 s10.1 , como ha señalado, pone algunos límites a la actividad de DNS. Específicamente:

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 de "inclusión" o el modificador de "redireccionamiento". 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. El modificador "exp" no cuenta contra este límite porque la búsqueda de DNS para obtener la cadena de explicación se produce después de que se haya evaluado el registro SPF.

y además

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.

Tenga en cuenta que el primero es un límite en la cantidad de mecanismos , no en la cantidad de búsquedas realizadas; Pero sigue siendo un límite.

Por lo que puedo decir, sí, estos límites se aplican con bastante fuerza. Están diseñados para evitar que las personas construyan registros SPF arbitrariamente complejos y los usen para servidores DoS que verifican sus registros deteniéndolos en una gran cadena de búsquedas de DNS, por lo que es lo mejor para cualquiera que implemente un verificador SPF honrarlos.

Tiene razón al notar que las inclusiones anidadas pueden causar el mayor problema con estos límites, y si decide incluir varios dominios, cada uno de los cuales hace un uso intensivo de las inclusiones, puede revisarlas con bastante rapidez. No es demasiado difícil encontrar ejemplos de personas para quienes esto ha creado problemas concretos .

El resultado parece ser que por lo general los problemas surgen cuando las personas deciden utilizar tanto SPF y varias compañías distintas y dispares para manejar su correo electrónico saliente. De su pregunta infiero que encaja en esa categoría. SPF no parece estar diseñado para servir a las personas que eligen hacer esto . Si insiste en hacer esto, es probable que tenga que tener algún tipo de trabajo cron en su servidor DNS que evalúe constantemente todos los registros SPF que hubiera deseado incluir, los exprese como una serie de ip4:y ip6:mecanismos (en cuyo número no hay límite) y vuelve a publicar el resultado como su registro SPF.

No olvides terminar con un -all, o todo el ejercicio fue inútil.

MadHatter apoya a Monica
fuente
Su herramienta ahora parece estar inactiva, @ JánSáreník
Simon East
@SimonEast No hay nada que pueda hacer cuando un moderador elimina una publicación. spf-tools está en github (intenta buscar spf-tools github), soy uno de los autores, es un software gratuito destinado a retribuir a la comunidad de la que saqué tanto y sería feliz si ayudara a alguien más. Auto promoción lo llaman. Y no hay espacio para la discusión.
@ JánSáreník Oh, qué raro, ahora MadHatter y mis comentarios no tienen sentido fuera de contexto. Hmm Ah bueno.
Simon East
@SimonEast, discúlpeme por eliminar esos comentarios. Lo hice y no me di cuenta de que hará que los otros comentarios se vean fuera de contexto.