Qué son los registros glue de DNS y cuándo los necesita
¿Qué es un registro glue?
Un registro glue es la dirección IP de un servidor de nombres, publicada no en su propia zona sino un nivel más arriba — en la zona padre, en el registro del TLD, a través de su registrador. Existe para romper una dependencia circular.
Tomemos example.com con los servidores de nombres ns1.example.com y ns2.example.com. Un resolutor que quiere buscar www.example.com pregunta primero a los servidores de .com quién es autoritativo para example.com. La respuesta es "ns1.example.com y ns2.example.com". Para preguntar algo a esos servidores, el resolutor necesita sus direcciones IP — pero los registros A de ns1.example.com viven dentro de example.com, en los mismos servidores que intenta encontrar. Sin ayuda, la búsqueda nunca puede empezar.
El registro glue es esa ayuda: junto con los registros NS, los servidores de .com entregan las direcciones IP de ns1 y ns2 en la sección adicional de la respuesta. El resolutor las usa, llega a los servidores de nombres y la zona funciona.
Puede ver el glue en una delegación real preguntando a un servidor del TLD por su propio dominio (el example.com real está delegado a servidores de nombres externos, así que no muestra ninguno):
dig NS yourdomain.com @a.gtld-servers.netLa sección de autoridad lista los nombres NS; la sección adicional lista sus direcciones glue. Si el nombre de un servidor de nombres está dentro de la zona y no aparece nada para él en la sección adicional, falta el glue.
Cuándo son obligatorios los registros glue
El glue es obligatorio exactamente cuando el nombre de host de un servidor de nombres está dentro de la zona que sirve — en el mundo DNS se le llama servidor de nombres in-bailiwick.
Obligatorio: example.com delegado a ns1.example.com y ns2.example.com. Ambos nombres están bajo example.com, así que ambos necesitan glue.
No obligatorio: example.com delegado a ns1.hosting-provider.net y ns2.hosting-provider.net. Un resolutor encuentra esas direcciones a través de la delegación de hosting-provider.net en .net; el registrador de example.com no tiene nada que añadir. Es el caso cotidiano cuando usa los servidores de nombres por defecto de su proveedor de DNS.
Un caso mixto: example.com delegado a ns1.example.com y ns3.seconddns.com — un nombre in-bailiwick que necesita glue y un nombre externo que no. Es la forma típica cuando su propio servidor es el primario y un secundario alojado responde bajo su propio nombre de host.
La regla es por nombre de servidor de nombres, no por zona: revise cada registro NS y pregúntese si ese nombre vive dentro de la zona que se delega.
Dónde residen los registros glue
El glue no es un registro que añada a su propio archivo de zona. Pertenece a la zona padre — el registro del TLD — y la única forma de ponerlo ahí es a través de su registrador, porque el registrador es quien habla con el registro del TLD en su nombre.
Todo registrador expone esto en algún lugar de la configuración del dominio, bajo nombres que varían mucho:
- "Registrar un servidor de nombres" / "Registrar host" - "Child nameservers" / "Child hosts" - "Registros de host" / "Glue records" - "Servidores de nombres privados" / "Servidores de nombres personalizados"
Se llame como se llame, el formulario pide dos cosas: el nombre de host del servidor de nombres (ns1.example.com) y su dirección IP (IPv4, y IPv6 si la tiene). Una vez enviado, el registro publica el glue en la zona del TLD; a partir de entonces, los servidores de .com responden con él.
De ahí se derivan dos consecuencias. El glue es una copia de la dirección de su servidor de nombres, mantenida a mano en el registrador — si la IP del servidor cambia, el glue no cambia con ella. Y el registro en su propia zona (el registro A de ns1.example.com) sigue teniendo que existir y coincidir: los resolutores usan el glue para empezar y después confían en lo que dice su zona.
Qué se rompe sin glue
Glue ausente. La delegación apunta a ns1.example.com, pero el registro del TLD no tiene dirección para él. Los resolutores no pueden llegar a los servidores de nombres; el dominio no resuelve en absoluto. Algunos resolutores se esfuerzan más que otros, así que el fallo suele ser inconsistente — "funciona en mi máquina, no para los clientes" — lo que lo hace difícil de diagnosticar.
Glue obsoleto. Movió el servidor, actualizó el registro A en la zona y olvidó el registrador. El registro del TLD sigue entregando la IP antigua. Los resolutores que siguen el glue llegan a una dirección muerta o, peor, a quien ahora posea esa IP. Como la mayoría de los resolutores cachean durante mucho tiempo el servidor de nombres que funciona, esta rotura puede aparecer días después de la migración.
Glue sin un registro A que coincida. El registro del TLD dice que ns1.example.com es 192.0.2.10, su zona no dice nada o dice otra cosa. El glue no es autoritativo: una vez que un resolutor aprende la dirección de la propia zona, usa esa en lugar del glue. Así que un registro A incorrecto en la zona anula un glue correcto, mientras que un registro A ausente deja el glue en vigor. Mantenga ambos alineados.
Delegación lame. El glue es correcto, la dirección responde, pero el servidor en realidad no sirve la zona — típico cuando un servidor de nombres fue retirado o una zona nunca se cargó en un secundario. Algunos registros de ccTLD lo comprueban cuando cambia una delegación (los registros de gTLD no), y las herramientas de monitorización lo señalan; los resolutores tratan el servidor como roto y recurren a los demás, si los hay.
Los cuatro fallan en silencio desde el lado del operador: nada en sus registros de log dice "el glue es incorrecto". El síntoma siempre está más adelante en la cadena — fallos de resolución intermitentes, búsquedas lentas, retrasos en el correo — así que merece la pena comprobar la delegación explícitamente.
Comprobar la delegación y el glue con dig
Trace la delegación desde la raíz hacia abajo para ver exactamente qué entrega cada nivel:
dig +trace www.example.com @1.1.1.1El resolutor se nombra explícitamente porque +trace solo le pide el conjunto de NS de la raíz y a partir de ahí recorre la delegación por sí mismo; sirve cualquier resolutor que devuelva ese conjunto.
En la salida, busque el paso en el que los servidores del TLD responden por example.com: los registros NS de ahí son la delegación. Tenga en cuenta que +trace imprime solo la delegación en sí, no la sección adicional, así que no muestra el glue. Para ver el glue, elija cualquier servidor autoritativo del TLD y pídale directamente el conjunto de NS:
dig NS example.com @a.gtld-servers.net +norecurseLa sección adicional muestra el glue tal como lo ve el padre; un servidor de nombres in-bailiwick sin entrada ahí no tiene glue. Compárelo con lo que dice su propia zona:
dig A ns1.example.com @ns1.example.com +shortLas dos direcciones deben coincidir. Por último, confirme que cada servidor de nombres listado sirve realmente la zona y coincide en la versión:
dig SOA example.com @ns1.example.com +short
dig SOA example.com @ns2.example.com +shortAmbos deberían responder de forma autoritativa con el mismo serial. Un REFUSED o SERVFAIL aquí es una delegación lame; un serial que se queda atrás en un servidor significa que las transferencias de zona no siguen el ritmo — vea Qué es el registro SOA de DNS.
Registros glue y servidores de nombres secundarios
El glue surge con más frecuencia cuando se añade un segundo servidor de nombres bajo el propio dominio. Dos configuraciones, dos respuestas distintas:
Secundario bajo el nombre de host del proveedor. Su zona está delegada a ns1.example.com (su servidor) y al nombre propio del proveedor secundario, como ns3.seconddns.com. Solo ns1 es in-bailiwick, así que solo ns1 necesita glue. Nada cambia en el registrador cuando cambian las direcciones del proveedor.
Secundario bajo su propio nombre de host — un servidor de nombres personalizado o vanity como ns2.example.com que apunta al servidor del proveedor. Ahora ns2 también es in-bailiwick y necesita glue con la dirección IP del proveedor. Lo añade en el registrador exactamente igual que ns1, y debe mantenerlo al día: si el proveedor cambia alguna vez esa dirección, el glue tiene que seguirla. También necesita el registro A correspondiente para ns2.example.com en su propia zona, que después viaja al secundario con cada transferencia de zona.
Este es el paso que más a menudo se omite al configurar servidores de nombres con marca propia, y la razón por la que un secundario perfectamente sincronizado sigue sin recibir consultas. Para la configuración completa — nombre de host, glue, registros A y verificación — vea Nameservers personalizados: configuración, glue records y errores comunes.
Errores comunes
- Editar el registro A pero no el glue tras mover un servidor. Actualice ambos y compruebe después el padre con dig. - Añadir glue para nombres fuera del bailiwick. La mayoría de los registradores lo rechazan; los que lo aceptan publican datos que el padre nunca usará. Registre solo nombres bajo el propio dominio. - Glue con una IP privada o incorrecta. Los registradores validan poco; una errata se publica en el registro del TLD. Verifique con una consulta a los servidores del TLD, no solo a su propio servidor de nombres. - Olvidar IPv6. Si su servidor de nombres tiene un registro AAAA, registre también el glue IPv6, o los resolutores solo IPv6 no podrán llegar a él. - Esperar un efecto inmediato. Los grandes registros de gTLD publican los cambios en minutos, mientras que algunos ccTLD regeneran su zona cada hora o unas pocas veces al día — y los resolutores cachean la delegación anterior hasta el TTL del padre — habitualmente 48 horas para .com. Planifique los cambios de IP de servidores de nombres con solapamiento: mantenga la dirección antigua respondiendo hasta que expiren las cachés. - Solo un servidor de nombres in-bailiwick con glue. Si ns1 tiene glue y ns2 (también in-bailiwick) no, la zona funciona solo mientras ns1 esté en línea — lo que anula el sentido de tener dos.