Métodos de verificación

Hay cuatro comprobaciones que tienen mayor peso en las herramientas gratuitas: Forward-confirmed reverse DNS, verificación mediante rastreador, coincidencia de prefijos RDAP y consultas a listas de Blacklists. Cada una de ellas tiene un atajo que parece correcto en las pruebas, pero que produce respuestas erróneas en producción. Esta página explica lo que hacen las herramientas en su lugar, con suficiente detalle como para poder reproducirlo.

Forward-confirmed reverse DNS

Un PTR Record no prueba nada por sí solo. Quien controla un bloque de direcciones decide qué nombre lleva, y nada impide que ese nombre sea mail.yourbank.com. La comprobación que tiene realmente importancia es la confirmación directa: resolver el nombre PTR a la inversa y comprobar si la dirección original se encuentra entre los resultados.

Compara todo el conjunto de direcciones, no solo el primer registro

El error más común es comparar con el primer registro A devuelto. Las direcciones detrás de un nombre de tipo «round-robin» rompen esa regla de inmediato:

8.8.8.8  ->  PTR dns.google
             ->  A     8.8.8.8, 8.8.4.4
             ->  AAAA  2001:4860:4860::8888, 2001:4860:4860::8844

8.8.4.4  ->  PTR dns.google
             ->  same four addresses

Una herramienta que se detiene en la primera respuesta lo considera 8.8.4.4 como no confirmada, porque el DNS devolvió 8.8.8.8 primero. Aproximadamente una de cada dos consultas sobre un nombre de tipo «round-robin» da un resultado erróneo de esa forma. Es necesario resolver y buscar tanto el conjunto A como el AAAA.

Compara las direcciones en formato binario

El segundo error es comparar direcciones como cadenas de caracteres. 2001:db8::1 y 2001:0db8:0000:0000:0000:0000:0000:0001 son la misma dirección y no comparten ningún carácter; ::ffff:192.0.2.1 y 192.0.2.1 son la misma dirección en dos familias. Ambas comparaciones deben realizarse sobre la forma empaquetada que inet_pton() devuelve, nunca en la forma de texto.

Qué significa un fallo

Pruébalo en Reverse DNS.

Verificación de un rastreador

Un encabezado User-Agent es texto libre que cualquier cliente puede enviar, por lo que todos los grandes operadores publican un método de verificación. Durante dos décadas, ese método fue el Forward-confirmed reverse DNS. Eso ya no es así para la mitad de los rastreadores que merece la pena comprobar.

La división se traza entre los motores de búsqueda clásicos y la generación de rastreadores de IA. Los operadores más recientes documentan archivos JSON de rangos de direcciones y no incluyen los nombres PTR en su método, por lo que una dirección dentro del rango que OpenAI publica para GPTBot no tiene ningún registro inverso en absoluto. Un verificador que solo conozca el método DNS marca cada una de ellas como no confirmada, que es el mismo veredicto que da a una falsificación.

Por lo tanto, se distinguen tres veredictos:

• Confirmado. El nombre pertenece a un rastreador conocido y el método que se aplica a ese operador concuerda.
• No confirmado. No hay PTR Record, la comprobación directa ha fallado o el User-Agent indica un rastreador que las pruebas no respaldan. Este es el caso en el que hay que actuar.
• No atribuible. Todo se resuelve correctamente, pero la dirección no pertenece a ningún rastreador conocido por esta herramienta. El resultado normal para un visitante habitual.

Pruébalo en «Verificación de bots».

Localización del Registry responsable a través de RDAP

Una denuncia de abuso enviada al bloque equivocado equivale a no enviar ninguna denuncia. Una sola dirección suele encontrarse dentro de la asignación de un proveedor de alojamiento, que a su vez se encuentra dentro de la asignación de un proveedor de tránsito, la cual pertenece a un Registry regional. Solo el operador más interno puede desconectar el equipo de la red.

El archivo de arranque, no un redireccionador

No existe un directorio central del espacio de direcciones. La IANA publica un archivo de arranque que asigna cada prefijo asignado al Registry responsable del mismo, y es mucho más pequeño de lo que sugieren la mayoría de las estimaciones : medido el 20 de septiembre de 2026, ipv4.json tenía 5.629 bytes y ipv6.json 1 476 bytes. Se sirve una copia en caché diaria a cada visitante, de modo que la consulta se dirige directamente al Registry en lugar de enrutarse a través de un redireccionador público.

El prefijo más largo, no la primera coincidencia

Los prefijos se solapan. Un pequeño rango dentro de una asignación antigua y grande suele pertenecer a un Registry distinto al de su prefijo principal, por lo que el primer prefijo que coincide suele ser el incorrecto. La coincidencia tiene que ser la más larga.

El contacto con la función de abuso

Una respuesta RDAP incluye varias entidades de contacto, y la primera suele ser administrativa en lugar de operativa. La dirección que devuelve la herramienta procede de la entidad que desempeña la abuse función. Si una red no publica ninguna, el resultado lo indica en lugar de recurrir a un contacto no relacionado: el Registry y el titular del bloque son entonces los siguientes lugares a los que acudir.

Pruébalo en «Contacto de abuso» y consulta «IP Delisting» para la otra dirección.

Consultas de Blacklist

El formato de la consulta

Para consultar una DNSBL, se invierte la dirección y se añade la zona. Para IPv4, se trata de los octetos en orden inverso; para IPv6, el RFC 5782 especifica el formato de nibbles, con cada dígito hexadecimal por separado y en orden inverso:

192.0.2.1        ->  1.2.0.192.<zone>
2001:db8::1      ->  1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
                     0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.<zone>

No todas las listas responden para IPv6

Nueve de las doce listas gestionadas publican una zona IPv6; tres no lo hacen. Al consultar una zona exclusiva de IPv4 para una dirección IPv6 se obtiene NXDOMAIN, lo cual es indistinguible de un resultado limpio. Por lo tanto, esas tres listas no se consultan en absoluto para IPv6 y se indican como no aplicables, de modo que una respuesta vacía nunca se presenta como un resultado satisfactorio.

Se verifica qué listas responden, en lugar de darlo por sentado: cada zona del conjunto responde a la entrada de prueba del RFC 5782 del resolver de este servidor. Se excluyen las listas que, por su estructura, no pueden consultarse desde un resolver compartido; entre ellas, Spamhaus ZEN, que responde a un resolver público con un código de bloqueo en lugar de un resultado.

Interpretación del código de respuesta

Un acierto se indica mediante un registro A en 127.0.0.0/8, y el valor exacto indica el motivo. Hay un rango que no corresponde a ninguna lista: los códigos de 127.255.255.0/24 están reservados para errores de consulta, un resolutor público bloqueado, un Rate Limit superado o una consulta mal formada. Interpretar esos códigos como un acierto convierte un problema de infraestructura en una acusación falsa.

Pruébalo en la DNSBL Blacklist Check. Nuestra propia zona está documentada en la zona DNSBL / RBL Zone.

Carga segura de una página

La comprobación de encabezados es la única herramienta que recupera la URL indicada por el visitante, lo que la convierte en una vía de ataque de falsificación de solicitudes del lado del servidor. La recuperación está restringida en consecuencia:

• Solo http y https, únicamente los puertos 80 y 443.
• Se resuelve el nombre de host y cada dirección devuelta se compara con los rangos privados, de bucle de retorno, locales de enlace, CGNAT y de multidifusión, en ambas familias de direcciones.
• Hay cuatro notaciones que contienen una dirección IPv4 dentro de una IPv6, y las cuatro se desenvuelven antes de la comprobación de rangos, en lugar de después: v4-mapped, v4-compatible, NAT64 y 6to4. Un filtro que solo compruebe la forma textual las deja pasar, porque 2002:7f00:1:: y 127.0.0.1 no se parecen en nada, aunque designen al mismo host.
• Las redirecciones se siguen manualmente, como máximo tres veces, repitiéndose la comprobación completa en cada salto.
• Se aplica un tiempo de espera fijo y solo se leen los primeros kilobytes del cuerpo.
• La solicitud utiliza GET en lugar de HEAD, ya que varios servidores responden a HEAD con un conjunto de encabezados diferente.

Pruébalo con «Security Headers». Cómo se traducen los resultados en una puntuación se describe en la sección «Puntuación de la herramienta».

Última actualización: 20. septiembre 2026 · Mantenido por el equipo de ReportedIP