Nameservers, glue records y propagación DNS: ¿quién responde por tu dominio?

Imagina un edificio con un vestíbulo concurrido. Los visitantes preguntan dónde está una empresa y recepción responde desde el directorio oficial. Tu dominio es el nombre del edificio, los registros DNS son números de oficina e instrucciones de correo, y los nameservers autoritativos son los mostradores autorizados para responder.

Cambiar un registro DNS edita una nota dentro del directorio. Cambiar nameservers sustituye a quien opera todo el mostrador. Esa diferencia explica por qué una migración incompleta puede dejar funcionando el sitio mientras desaparece el correo, la validación de certificados u otro servicio.

Nameservers frente a registros DNS

El registrador y el host DNS pueden ser la misma empresa, pero cumplen funciones distintas. El registro identifica al titular y comunica la delegación al registro; DNS autoritativo publica las respuestas activas. La configuración de nameservers une la propiedad del nombre con los sistemas que responden por él.

Los autoritativos saben; los resolvers recursivos preguntan

Un nameserver autoritativo es fuente oficial de una zona. Puede devolver el A de www.example.com o declarar autoritativamente que no existe. Un resolver recursivo trabaja para el usuario, recorre la jerarquía desde raíz a TLD y delegación del dominio, y guarda la respuesta para no repetir el recorrido en cada carga.

• Un dispositivo pregunta por www.example.com a su resolver configurado. Un dispositivo pregunta por www.example.com a su resolver configurado.
• El resolver recorre la jerarquía hasta identificar los nameservers autoritativos. El resolver recorre la jerarquía hasta identificar los nameservers autoritativos.
• Un servidor autoritativo devuelve la respuesta o una respuesta negativa. Un servidor autoritativo devuelve la respuesta o una respuesta negativa.
• El resolver guarda el resultado según su TTL y lo entrega al dispositivo. El resolver guarda el resultado según su TTL y lo entrega al dispositivo.

Tú controlas la zona autoritativa y la delegación publicada para tu dominio. No controlas cada resolver ni cuándo guardó la respuesta anterior. Esa asimetría crea el periodo de vistas mezcladas durante un cambio.

Qué hace realmente cambiar nameservers en el registrador

Reemplazar la lista de nameservers en el registrador no reescribe las cachés mundiales. Solicita al registrador y al registro actualizar la delegación del padre: el puntero que indica qué servidores deben responder por el dominio hijo.

• Crea o importa la zona completa en el nuevo host DNS antes de cambiar la delegación. Crea o importa la zona completa en el nuevo host DNS antes de cambiar la delegación.
• Copia en el registrador los hostnames de nameserver entregados por el nuevo host. Copia en el registrador los hostnames de nameserver entregados por el nuevo host.
• El registrador envía el cambio de delegación al registro según el proceso del TLD. El registrador envía el cambio de delegación al registro según el proceso del TLD.
• Cuando el padre lo publica, los resolvers sin una delegación anterior reutilizable preguntan a los nuevos servidores. Cuando el padre lo publica, los resolvers sin una delegación anterior reutilizable preguntan a los nuevos servidores.
• Los resolvers que aún conservan NS o respuestas antiguas continúan usándolos hasta su expiración. Los resolvers que aún conservan NS o respuestas antiguas continúan usándolos hasta su expiración.

Importan dos relojes: aceptación y publicación por registrador o registro, y vida restante de delegaciones y respuestas almacenadas. Nunca elimines la zona anterior inmediatamente después de guardar; algunos resolvers aún pueden consultarla aunque el panel ya muestre los nombres nuevos.

Glue records: cuando el mostrador vive dentro del edificio

Supón que example.com delega en ns1.example.com y ns2.example.com. El resolver necesita una IP para contactar ns1, pero obtenerla normalmente exigiría consultar los nameservers de example.com, precisamente los que todavía no puede alcanzar. Esa dependencia circular necesita datos de arranque.

Glue es una dirección A o AAAA que el padre publica junto a la delegación NS. Generalmente se necesita para nameservers in-bailiwick cuyos hostnames están dentro del espacio delegado. Nombres como ns1.provider.net se resuelven mediante la zona separada del proveedor y normalmente no requieren glue personalizado.

• Los paneles pueden llamar al glue host record, child nameserver, personal nameserver o registered nameserver. Los paneles pueden llamar al glue host record, child nameserver, personal nameserver o registered nameserver.
• Cuando cambia la dirección, actualiza tanto el glue en el padre como el A o AAAA dentro de la zona. Cuando cambia la dirección, actualiza tanto el glue en el padre como el A o AAAA dentro de la zona.
• Glue es solo una pista de arranque; la zona autoritativa también debe publicar la dirección real del hostname. Glue es solo una pista de arranque; la zona autoritativa también debe publicar la dirección real del hostname.

TTL: el tiempo de expiración de una respuesta almacenada

TTL se expresa en segundos e indica cuánto puede reutilizarse un dato DNS. 3600 representa cerca de una hora y 86400 un día. Valores bajos como 300 pueden agilizar un cambio planificado, pero mantenerlos permanentemente aumenta consultas y no elimina otras cachés de la delegación.

Reducir un TTL no reescribe copias ya almacenadas con el valor alto anterior. Haz la reducción con tiempo para que esa vigencia se agote y restaura TTL razonables tras estabilizar. Recuerda que los TTL dentro de la zona hija y los de delegación en el padre son independientes.

Propagación DNS: mitos y realidad

La propagación no es una ola que copia tu zona completa en cada computadora. Publicas datos autoritativos; los resolvers los aprenden cuando necesitan responder y ya no tienen una copia reutilizable. Las redes cambian en momentos distintos porque consultaron en momentos distintos y tienen vidas restantes diferentes.

Un mensaje más preciso es: “Esperamos que expiren las cachés existentes; algunas redes cambiarán antes que otras”. Describe el mecanismo sin prometer un plazo arbitrario.

Cómo verificar con dig y nslookup

La verificación debe preguntar a más de un lugar e incluir los servidores que deberían ser autoritativos. dig es común en Linux y macOS, y nslookup está ampliamente disponible, incluso en Windows. El objetivo no es memorizar opciones, sino separar delegación del padre, verdad autoritativa y caché del resolver.

Si prefieres una interfaz web, la consulta DNS de SoxDomains revisa registros públicos sin usar la línea de comandos. Úsala como un punto de vista junto con consultas directas a los autoritativos, no como reemplazo de revisar cada nameserver listado. Usar la consulta DNS gratuita de SoxDomains

1. Pregunta qué publica el padre

Consulta los NS del dominio y, cuando sea posible, traza la delegación. Confirma que el padre publique exactamente el conjunto nuevo tras aceptar el cambio. Consultar el dominio con WHOIS y RDAP de SoxDomains

2. Pregunta directamente a cada servidor nuevo

Consulta apex, www, MX y TXT críticos contra cada servidor listado. Si uno tiene una zona incompleta o antigua, los usuarios pueden fallar intermitentemente según cuál contacte su resolver.

3. Compara el servicio autoritativo anterior

Durante la coexistencia, servicios antiguo y nuevo deberían devolver respuestas productivas compatibles. Las diferencias revelan registros no copiados o cambios intencionales; documenta cada una antes de culpar a la caché.

4. Muestrea resolvers y redes reales

Un resolver público ofrece otro punto de vista, no un veredicto mundial. Prueba conexión móvil, red de oficina y otro ISP cuando importe. Los verificadores en línea son muestras útiles, pero no representan cada caché.

Errores comunes y sus síntomas reales

Glue huérfano o antiguo

La zona dice que ns1 tiene una dirección nueva mientras el glue del padre apunta a una máquina retirada. Algunas rutas llegan al servidor nuevo y otras a una dirección vacía. Trata el glue como dato productivo y actualízalo o elimínalo cuando cambien direcciones.

Migración a medias

La zona nueva incluye el A del sitio pero omite MX, DKIM o un TXT de un servicio. El sitio funciona mientras falla el correo u otro servicio. Inventaría y copia la zona viva, no solo la puerta principal.

TTL bajo olvidado para siempre

Un TTL temporal de 300 segundos permanece durante meses. No ocurre algo dramático, pero aumenta el volumen y cada error se hace visible rápido. Reduce antes, eleva después e incluye la restauración en la lista.

Eliminar la zona anterior demasiado pronto

El registrador muestra los nameservers nuevos y el servicio anterior se elimina de inmediato. Los resolvers con la delegación antigua reciben fallos. Mantén la zona anterior durante la cola de caché y el periodo de estabilidad verificado.

Editar el panel DNS equivocado

El dominio delega en Host A mientras alguien edita un panel cómodo en Host B o la zona predeterminada inactiva. El guardado funciona, pero internet nunca consulta ese servicio. Revisa los NS autoritativos antes de editar.

Cambiar todas las capas al mismo tiempo

Nameservers, direcciones web y correo cambian juntos mientras quedan TTL altos. Cuando falla algo no hay forma clara de identificar la capa. Construye y verifica la zona, cambia la delegación una vez, observa y retira después.

Lista práctica para cambiar nameservers

Unos días antes

• Lista sitio, correo, nombres administrativos, verificaciones SaaS, CDN y cada servicio que use el dominio. Lista sitio, correo, nombres administrativos, verificaciones SaaS, CDN y cada servicio que use el dominio.
• Exporta o captura la zona actual y registra los nameservers anteriores. Exporta o captura la zona actual y registra los nameservers anteriores.
• Registra los TTL y reduce con tiempo los registros que cambiarán. Registra los TTL y reduce con tiempo los registros que cambiarán.
• Crea la zona completa en el nuevo host, incluidos correo y verificaciones. Crea la zona completa en el nuevo host, incluidos correo y verificaciones.

Antes del cambio

• Consulta directamente cada servidor nuevo por apex, www, MX y TXT clave. Consulta directamente cada servidor nuevo por apex, www, MX y TXT clave.
• Prepara glue en el padre y direcciones coincidentes para nameservers dentro del dominio. Prepara glue en el padre y direcciones coincidentes para nameservers dentro del dominio.
• Confirma acceso al registrador y a las cuentas DNS antigua y nueva. Confirma acceso al registrador y a las cuentas DNS antigua y nueva.
• Informa que algunas redes pueden cambiar antes que otras. Informa que algunas redes pueden cambiar antes que otras.

El cambio

• Actualiza una vez la lista de nameservers y el glue requerido. Actualiza una vez la lista de nameservers y el glue requerido.
• Mantén activa la zona anterior. Mantén activa la zona anterior.
• Espera la aceptación y revisa la delegación del padre. Espera la aceptación y revisa la delegación del padre.
• Vuelve a comprobar registros críticos contra cada servidor nuevo. Vuelve a comprobar registros críticos contra cada servidor nuevo.

Después del cambio

• Compara servidores nuevos, anteriores y al menos un resolver recursivo. Compara servidores nuevos, anteriores y al menos un resolver recursivo.
• Prueba clientes reales en red móvil, oficina y otra red disponible. Prueba clientes reales en red móvil, oficina y otra red disponible.
• Mantén el servicio anterior hasta que pase la cola de caché. Mantén el servicio anterior hasta que pase la cola de caché.
• Restaura TTL razonables, elimina glue antiguo y documenta fecha, NS anteriores, nuevos y direcciones. Restaura TTL razonables, elimina glue antiguo y documenta fecha, NS anteriores, nuevos y direcciones.

Si algo parece incorrecto

• Identifica la capa: delegación, zona incompleta, glue antiguo o caché aún válida. Identifica la capa: delegación, zona incompleta, glue antiguo o caché aún válida.
• Corrige primero la verdad autoritativa; esperar no restaura un MX faltante. Corrige primero la verdad autoritativa; esperar no restaura un MX faltante.
• No alternes nameservers cada pocos minutos. No alternes nameservers cada pocos minutos.

Historia breve de una migración limpia

María administra el sitio de un estudio. El lunes copia todos los registros al nuevo host, reduce los TTL que cambiarán y consulta directamente los nuevos nameservers hasta que web, correo y verificaciones coinciden. El miércoles actualiza el registrador con nameservers externos del proveedor, por lo que no necesita glue personalizado, y deja intacto el servicio anterior.

El jueves su teléfono y oficina muestran la ruta nueva mientras un cliente continúa viendo la dirección anterior hasta mediodía. Es una vista almacenada esperada, no evidencia de que deba volver a guardar el formulario. El viernes restaura TTL normales, documenta la migración y programa retirar la zona anterior después de la coexistencia.

Uniendo el modelo

Los nameservers identifican quién puede responder; los registros son lo que dicen; los resolvers preguntan y recuerdan; glue aporta una dirección inicial cuando el servidor vive dentro del nombre delegado; TTL limita reutilización; y propagación es principalmente la expiración de notas almacenadas en momentos distintos.

Construye y verifica primero la zona nueva, cambia después la delegación, mantén abierto el mostrador anterior mientras cambian las cachés y verifica con consultas deliberadas. Si el dominio también cambia de registrador, separa esa transferencia de la migración DNS cuando sea posible. Planificar una transferencia de dominio

Los registros de país pueden validar accesibilidad, exigir cierta cantidad de servidores o aplicar políticas propias. Revisa los requisitos de la extensión específica en vez de asumir que cada ccTLD funciona como .com. Comparar requisitos de ccTLD