Ir al contenido principal

Búsqueda registro A (IPv4)

Verifique la dirección IPv4 de su dominio en segundos

¿Su sitio no responde? Verifique si el registro A apunta a la dirección IPv4 correcta. Compare las respuestas de múltiples resolutores DNS para detectar problemas de propagación.

En modo de traza iterativa, se ignora el resolvedor.
Consulta varios resolvedores públicos para comparar las respuestas.

Resolución instantánea

Obtenga la dirección IPv4 de un dominio en tiempo real. Compare respuestas de Google, Cloudflare, Quad9 y el servidor autoritativo.

Detección de discrepancias

Identifique diferencias entre resolutores. Detecte cachés obsoletos que aún devuelven la dirección antigua.

Traza iterativa completa

Visualice el recorrido DNS: raíz → TLD → autoritativo. Identifique qué paso es lento o falla.

TTL y latencia

Consulte el TTL restante para saber cuándo expira la caché. Mida la latencia de cada resolutor.

Gratuito e ilimitado

Sin registro requerido. Pruebe tantos dominios como necesite, tan frecuentemente como desee.

¿Cómo usar correctamente las diferentes opciones del motor de búsqueda DNS?

¿Qué es la traza iterativa?

La traza ejecuta la resolución paso a paso. El resolvedor consulta primero a los servidores raíz, luego a los del TLD (.com, .fr, .eu) y finalmente a los servidores autoritativos de la zona objetivo. En cada etapa la página muestra el servidor consultado, la respuesta, el RCODE y la latencia.

  1. 1. Raíz

    Descubrimiento de los servidores del TLD para el nombre solicitado.

  2. 2. TLD

    Referencia a los NS de la zona (delegación).

  3. 3. Autoritativos

    Respuesta final (o error) con TTL y latencia.

¿Para qué sirve?

  • Comparar respuestas según los resolvedores y las regiones
  • Detectar un caché caliente, un TTL demasiado largo o una delegación incompleta
  • Explicar una diferencia de latencia o un RCODE inesperado

Truco: deja la traza desactivada para las comprobaciones rápidas; actívala cuando investigues o prepares un ticket/post-mortem.

¿Qué es la traza clásica?

La traza clásica consulta únicamente el resolvedor seleccionado (UDP o DoH) y muestra la respuesta tal como se percibe desde ese punto de la red. Obtienes el RCODE, las secciones de la respuesta y la latencia del tramo cliente → resolvedor.

  1. 1. Resolvedor elegido

    Utiliza el preset o la configuración personalizada para lanzar la consulta exactamente como lo haría tu servicio.

  2. 2. Protocolo conservado

    Respeta el transporte seleccionado (UDP, TCP o DoH) para reproducir el comportamiento real.

  3. 3. Respuesta detallada

    Muestra las secciones question, answer y authority/additional cuando existen, con TTL y metadatos útiles.

¿Por qué usarla?

  • Comprobar la visión de un resolvedor específico antes de sospechar de la delegación
  • Confirmar los valores en caché y el impacto de un TTL o de un vaciado
  • Documentar una resolución tal como la ve un cliente o un microservicio

Truco: deja desactivada la opción de traza iterativa cuando audites un resolvedor concreto; actívala después para compararla con el recorrido raíz → TLD → autoritativo.

¿Cómo funciona la prueba de propagación?

La prueba consulta en paralelo un conjunto de resolvedores públicos (Google, Cloudflare, Quad9, OpenDNS, ISP…) y agrupa las respuestas por contenido y RCODE. Ves al instante quién ya aplicó la actualización.

  1. 1. Resolvedores multipunto

    Activa los presets de propagación para consultar a varios actores repartidos por el mundo.

  2. 2. Comparación automática

    Agrupa las respuestas idénticas y señala las divergencias o los errores propios de cada resolvedor.

  3. 3. Resumen accionable

    Ofrece un resumen claro, la lista de resolvedores, sus latencias y el estado de cada grupo.

¿Cuándo usarla?

  • Seguir la difusión de un cambio DNS a escala mundial
  • Identificar cachés aún antiguos y decidir un vaciado específico
  • Compartir un estado de propagación en un ticket o post-mortem

Truco: durante la prueba de propagación la selección de resolvedor queda bloqueada. Desactiva el modo para volver al diagnóstico unitario.

¿Qué es un registro A?

Un registro A (Address Record) es el registro DNS fundamental que asocia un nombre de dominio con una dirección IPv4. Cuando escribe una URL en su navegador, la respuesta del registro A indica qué servidor contactar.

Estructura de un registro A:

CampoDescripciónEjemplo
NombreDominio o subdominiowww
TipoSiempre AA
ValorDirección IPv4203.0.113.10
TTLDuración de caché en segundos3600

Ejemplo concreto:

www.captaindns.com.  3600  IN  A  203.0.113.10

Este registro indica que www.captaindns.com apunta a la dirección IPv4 203.0.113.10 con un TTL de una hora.


Casos de uso comunes

1. Apuntar el apex del dominio

El apex (o raíz) de un dominio (captaindns.com sin www) debe usar registros A porque los CNAME no están permitidos en esta ubicación según las RFC.

captaindns.com.  3600  IN  A  203.0.113.10

2. Distribución de carga (Round-Robin)

Publique múltiples registros A para distribuir las solicitudes entre servidores:

www.captaindns.com.  300  IN  A  203.0.113.10
www.captaindns.com.  300  IN  A  203.0.113.11
www.captaindns.com.  300  IN  A  203.0.113.12

El resolutor devuelve la lista completa. El cliente generalmente elige el primero. Este mecanismo distribuye la carga pero no detecta fallos.

3. Servidor de correo

El servidor apuntado por un registro MX debe tener un registro A:

mail.captaindns.com.  3600  IN  A  203.0.113.25

El DNS inverso (PTR) de esta IP debe coincidir para mejorar la entregabilidad del correo.


Buenas prácticas

TTL: encontrar el equilibrio

SituaciónTTL recomendadoRazón
Configuración estable3600-86400 (1h-24h)Reduce la carga en servidores autoritativos
Migración planificada300-600 (5-10 min)Permite rollback rápido
Prueba o depuración60-300 (1-5 min)Cambios visibles rápidamente

Consejo de migración: Reduzca el TTL 24-48h antes del cambio, realice la modificación, luego aumente el TTL una vez estable.

Evitar

  • CNAME en el apex: No conforme con RFC, puede romper el correo
  • A + CNAME en el mismo nombre: Prohibido por las RFC
  • Dirección IP privada: No funciona desde Internet
  • Olvidar registros antiguos: Limpie después de una migración

Diagnóstico de problemas comunes

El sitio no responde

  1. Verifique que el registro A existe
  2. Confirme que la IP devuelta es correcta
  3. Pruebe la accesibilidad de la IP (ping, telnet puerto 80/443)
  4. Compare múltiples resolutores para detectar problemas de propagación

Propagación lenta después de un cambio

  1. Verifique el TTL del valor antiguo (es el que cuenta)
  2. El servidor autoritativo debe devolver el nuevo valor
  3. Espere la expiración del TTL en los resolutores públicos
  4. Limpie la caché DNS local si es necesario

Respuestas inconsistentes entre resolutores

  1. Es normal durante la propagación
  2. Verifique que el servidor autoritativo devuelve el valor correcto
  3. Use la traza iterativa para identificar diferencias
  4. Espere a que expire el TTL más largo

Verificar en línea de comandos

Windows (nslookup)

nslookup
set q=a
captaindns.com

Con un resolutor específico:

nslookup captaindns.com 1.1.1.1

Linux/Mac (dig)

dig A captaindns.com

Con un resolutor específico:

dig A captaindns.com @1.1.1.1

Traza iterativa completa:

dig A captaindns.com +trace

Herramientas complementarias

HerramientaUtilidad
Búsqueda AAAAVerificar la dirección IPv6 del dominio
Búsqueda CNAMEVerificar alias DNS
Test de propagaciónComparar decenas de resolutores simultáneamente
Auditoría DNS completaVerificar la configuración DNS global

Recursos útiles