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.
¿Es correcto mi entendimiento anterior?
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?
Respuestas:
Tanto
libspf2(C) comoMail::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,
ip4yip6, y luego usarmxsi 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 :
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:
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:
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 condig +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).
fuente
RFC4408 s10.1 , como ha señalado, pone algunos límites a la actividad de DNS. Específicamente:
y además
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:yip6: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.fuente
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.