Búsqueda registro NS

Host

Tipo

Resolvedor

Trazado iterativo

En modo de traza iterativa, se ignora el resolvedor.

Prueba de propagación

Consulta varios resolvedores públicos para comparar las respuestas.

¿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. Raíz
Descubrimiento de los servidores del TLD para el nombre solicitado.
2. TLD
Referencia a los NS de la zona (delegación).
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. Resolvedor elegido
Utiliza el preset o la configuración personalizada para lanzar la consulta exactamente como lo haría tu servicio.
2. Protocolo conservado
Respeta el transporte seleccionado (UDP, TCP o DoH) para reproducir el comportamiento real.
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. Resolvedores multipunto
Activa los presets de propagación para consultar a varios actores repartidos por el mundo.
2. Comparación automática
Agrupa las respuestas idénticas y señala las divergencias o los errores propios de cada resolvedor.
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.

Información adicional sobre los registros DNS tipo NS

Un registro NS indica qué servidores son autoritarios para una zona DNS. Lista los nombres de los servidores que poseen la zona. Los resolutores consultan estos servidores para obtener los otros registros.
Un registro NS contiene un nombre, un tipo, un objetivo NS y un TTL. El TTL indica cuánto tiempo la respuesta permanece en caché en el resolutor local.

Ejemplo registro DNS de tipo NS

Nombre	Tipo	Servidor NS	TTL en segundos
@	NS	ns1.ejemplo.net.	3600

En este ejemplo el nombre @ se dirige al apex de la zona. El objetivo es un nombre de host. Este nombre debe publicar registros A o AAAA y ser accesible.

Ejemplo con varios servidores

Una zona debe publicar varios registros NS. Esto aporta redundancia y mejor disponibilidad.

Nombre	Tipo	Servidor NS	TTL en segundos
@	NS	ns1.ejemplo.net.	3600
@	NS	ns2.ejemplo.net.	3600

Prever dos servidores o más. Deben responder de manera coherente.

Delegación de un subdominio

Para delegar sub.ejemplo.com agregar NS en este nombre en la zona padre. Cada objetivo debe resolver en A o AAAA. Si el nombre del servidor está dentro del subdominio, la zona padre puede publicar direcciones de asistencia que se llaman glue. El objetivo sigue siendo simple. Permitir a los resolutores alcanzar rápidamente los servidores del subdominio.

TTL explicado claramente

Un TTL corto hace más visible un cambio de servidores. Útil en fase de transición.
Un TTL medio o largo reduce las consultas hacia los servidores autoritarios. Adaptado a una zona estable.
Reducir el TTL algunas horas antes de un cambio luego subirlo después de la validación.

Bueno saber
NS y SOA se publican en el apex de una zona. Un CNAME no debe aparecer en un nombre que lleva NS. Un objetivo NS es siempre un nombre, no una dirección.

Dónde usar un registro NS

En el apex de la zona para designar los servidores autoritarios de esta zona.
En un subdominio cuando se delega este subdominio hacia servidores dedicados.
Las zonas hijas poseen su propio SOA y sus propios NS.

A evitar
Apuntar un registro NS hacia una dirección directa.
Publicar un solo NS en una zona.
Dejar un objetivo NS sin A ni AAAA.
Tener conjuntos de NS diferentes entre la zona padre y la zona hija sin razón.

Verificar en línea

Una búsqueda DNS en línea permite introducir un nombre de dominio. El resultado muestra la lista de servidores NS y el TTL visible desde Internet. Es un primer control útil. Hacer luego una prueba local desde su máquina.

Verificar bajo Windows

Windows proporciona nslookup. Se puede usar en modo interactivo.

Resolutor local

nslookup
set q=ns
ejemplo.com

Resolutor específico

nslookup
set q=ns
server 1.1.1.1
ejemplo.com

La primera parte consulta según la configuración de red de la máquina. La segunda fuerza el uso de un resolutor tercero, aquí el de Cloudflare.

Verificar bajo Linux y bajo Mac

En estos sistemas el comando dig es práctico y fácil de usar.

Resolutor local

dig NS ejemplo.com

Resolutor específico

dig NS ejemplo.com @1.1.1.1

Lectura rápida de las respuestas

Varias líneas NS indican varios servidores. Buscar nombres variados y redes diferentes para mejor resistencia.
Un TTL restante elevado puede explicar un desfase después de un cambio.
Una diferencia entre los NS vistos desde la zona padre y los vistos en la zona misma revela falta de sincronización.

Procedimiento de migración simple

Preparar los nuevos servidores y sus registros A o AAAA.
Reducir el TTL de los NS a 300 o incluso 60 segundos algunas horas antes de la transición.
Actualizar la zona con la nueva lista NS.
Actualizar la delegación del lado del registro si es necesario.
Verificar desde varias redes luego subir el TTL cuando todo esté estable.

Consejo práctico
Conservar una ficha con la lista de los NS publicados del lado de la zona y del lado del registro. Anotar la fecha, el TTL y la razón del cambio. Esta traza evita las diferencias durante las actualizaciones.

Casos frecuentes

Cambio de proveedor DNS

Publicar los nuevos NS en la zona. Actualizar la delegación en la oficina de registro. Verificar la coherencia.

Delegación de un subdominio a un equipo

Agregar NS en el subdominio en la zona padre. El equipo gestiona luego su zona hija con su propio SOA.

Adición de un servidor adicional

Agregar un NS más. Verificar que resuelve en A o AAAA y que sirve la zona actualizada.

Resolución de problemas rápida

Si la zona responde a veces con registros antiguos verificar la coherencia de los NS publicados.
Si un servidor NS no responde retirar temporalmente su entrada mientras se repara.
Si la delegación no funciona verificar la presencia de direcciones glue cuando son necesarias.
Si la respuesta sigue siendo antigua a pesar de la actualización esperar la expiración del TTL y purgar la caché del resolutor local si es posible.

En resumen, un registro NS designa los servidores autoritarios de una zona. Debe apuntar hacia nombres accesibles y coherentes. Una zona publica varios NS para la disponibilidad. El TTL bien ajustado facilita las transiciones. La verificación pasa por una herramienta en línea luego por nslookup y por dig.
Con estas referencias la gestión permanece clara. Los cambios se desarrollan sin estrés. Los resolutores encuentran la zona sin incidentes.