Herramientas de diagnóstico de red
Un informe completo de delegación y DNS
DNS y registros
Consulta DNS Todos los registros DNS de cualquier dominio Consulta de registro A Direcciones IPv4 de un dominio Consulta de registro AAAA Direcciones IPv6 de un dominio Consulta MX Servidores de correo de un dominio Consulta NS Servidores de nombres autoritativos Consulta TXT Registros TXT, SPF, verificación Consulta CNAME Registros de nombre canónico (alias) Consulta SOA Registro Start of Authority Consulta SRV Registros de localización de servicios Consulta CAA Qué CAs pueden emitir certificados DNS inverso (PTR) Dirección IP a nombre de host Comprobación DNSSEC ¿Está el dominio firmado y validado? Diagnóstico DNS Un informe completo de delegación y DNSEntregabilidad de correo
Comprobación SPF Valida tu registro Sender Policy Framework Comprobación DMARC Inspecciona y califica tu política DMARC Comprobación DKIM Encuentra y valida tu clave pública DKIM Comprobación de lista negra Comprueba una IP contra listas negras de correo (DNSBLs) Test SMTP Conecta a un servidor de correo y comprueba STARTTLS Comprobación MTA-STS Política TLS forzada para el correo entrante Comprobación BIMI Registro del logo de marca para el correo Comprobación TLS-RPT Política de informes de TLS de SMTPRed y web
Comprobación de certificado SSL Inspecciona el certificado TLS de un sitio y su caducidad Comprobación de cabeceras HTTP Inspecciona cabeceras de respuesta, redirecciones y seguridad Ping (TCP) Accesibilidad y latencia sobre TCP Comprobación de puertos Qué puertos comunes están abiertosDominio
Consulta WHOIS Datos de registro de dominios, IPs y ASNsUn diagnóstico DNS inspecciona cómo está delegado y configurado un dominio de principio a fin, no solo un tipo de registro. Pregunta a los servidores del padre (el TLD) qué publican sobre tu dominio, después pregunta directamente a tus propios servidores de nombres, y compara ambos. Las discrepancias entre el padre y tus servidores —glue ausente, listas de NS que no coinciden, seriales SOA desincronizados, servidores lame o con recursión abierta— son exactamente los problemas que causan un DNS lento, intermitente o silenciosamente roto. IPeek ejecuta cada comprobación y te dice, en lenguaje claro, por qué importa cada una y cómo solucionarla.
Cada consulta a tu dominio empieza en la zona padre —el registro del TLD (por ejemplo .es o .com)— que guarda los registros NS que apuntan a tus servidores de nombres. Si esos servidores viven dentro de tu propio dominio, el padre también debe publicar sus direcciones IP como «glue», de lo contrario los resolutores caen en un bucle del huevo y la gallina. Una delegación sana tiene al padre y a tus propios servidores coincidiendo en el mismo conjunto de NS, con glue presente donde haga falta. Cuando no coinciden, algunos resolutores siguen información obsoleta y tus cambios funcionan para unos usuarios y para otros no.
El RFC 2182 recomienda varios servidores de nombres en redes distintas para que una sola caída nunca deje el dominio fuera de línea. Cada uno debe responder de forma autoritativa por tu zona — un servidor «lame» que no lo hace es un agujero de fiabilidad silencioso. Tus servidores autoritativos también deberían rechazar la recursión a desconocidos: un servidor recursivo abierto puede usarse para envenenamiento de caché y amplificación de DDoS. IPeek consulta cada uno de tus servidores directamente para confirmar que responden, que lo hacen de forma autoritativa, que coinciden entre sí, que soportan TCP y que mantienen la recursión cerrada.
El registro SOA contiene el número de serie de tu zona y sus valores de temporización; cada servidor de nombres debe reportar el mismo serial, o tu zona está desincronizada y los cambios se propagan de forma desigual. El serial debería seguir la convención AAAAMMDDnn, y los temporizadores refresh/retry/expire/minimum deberían estar dentro de los rangos recomendados por los RFC. Del lado del correo, los registros MX deben ser nombres de host (nunca IPs sueltas ni CNAME) que resuelvan a direcciones públicas. Por último, el dominio raíz debería publicar una dirección pero no un CNAME, que el RFC 1912 prohíbe junto a otros registros.
Una búsqueda DNS te muestra los registros vistos a través de un resolutor recursivo. Un diagnóstico va más allá: consulta a los servidores del TLD padre y a cada uno de tus propios servidores de nombres directamente, y después los compara. Eso permite detectar problemas de delegación que una búsqueda normal oculta: glue ausente, discrepancias de NS entre padre e hijo, servidores lame o en desacuerdo, y seriales SOA desincronizados.
El glue es la dirección IP de un servidor de nombres, publicada por la zona padre junto al registro NS. Es obligatorio cuando tus servidores están dentro del mismo dominio que sirven (por ejemplo ns1.ejemplo.com sirviendo ejemplo.com), porque si no los resolutores tendrían que resolver el servidor antes de poder resolver nada. Si falta el glue en ese caso, la resolución se rompe; si tus servidores están en otro dominio, el glue es opcional y solo ahorra una búsqueda extra.
Los servidores de nombres autoritativos deberían responder solo por las zonas que alojan. Un servidor que hace recursión para cualquiera (un «resolutor abierto») puede usarse para ataques de amplificación DDoS y está más expuesto al envenenamiento de caché. Si el diagnóstico marca recursión abierta, desactiva la recursión en el servidor autoritativo o separa los roles autoritativo y recursivo en hosts distintos.
El serial SOA es un número de versión de tu zona. Cuando tus servidores reportan seriales distintos, al menos uno sirve datos obsoletos — normalmente un secundario que no logró transferir la última zona desde el primario. El resultado son respuestas inconsistentes según qué servidor toque cada resolutor. Revisa las transferencias de zona (AXFR/IXFR), la configuración NOTIFY del primario y el temporizador refresh del SOA.
Ninguno es un error, pero ambos son puntos únicos de fallo. Con un solo MX, el correo puede perderse si ese servidor está caído el tiempo suficiente; un MX de respaldo añade resiliencia. Dos servidores de nombres es aceptable según el RFC 2182, pero tres o más en redes distintas es más seguro. El diagnóstico los marca como avisos, no como fallos — vale la pena mejorarlos, no son emergencias.