¿Cómo soluciono el problema "sin pegamento" con las búsquedas de DNS?

Cuando busco mi dominio en http://www.intodns.com , aparece un problema:

GLUE no fue enviado cuando le pedí a sus servidores de nombres sus registros NS. Esto está bien, pero debe saber que en este caso se requiere una búsqueda de registros A adicional para obtener las IP de sus registros NS. Puede solucionar esto, por ejemplo, agregando registros A a sus servidores de nombres para las zonas enumeradas anteriormente.

Pero tengo entradas A para todos mis servidores de nombres en cada entrada de zona:

ns1.example.com. IN A <IP>
ns2.example.com. IN A <IP>

¿Cómo soluciono este problema de GLUE?

Los registros de pegamento son registros A especiales que se necesitan cuando el servidor de nombres para un dominio DNS está en el mismo dominio.

Por ejemplo, si su dominio es example.com y su servidor de nombres es ns.example.com, debe crear un registro A "adhesivo" para ns.example.com en la siguiente zona DNS más alta, en este caso en el zona "com". Esto debe hacerse a través de su registrador.

Esto es necesario porque las solicitudes de DNS para servidores de nombres (registros NS) siempre se responden con un nombre, no con una IP.

Sin un registro de pegamento, si se hiciera una solicitud para los registros A www.example.com, un servidor de nombres que sirve "com" devolvería el registro NS de example.com como ns.example.com (no una IP), y el la solicitud original no tendría forma de resolverse, porque cualquier intento adicional de resolver ns.example.com simplemente se referiría a ns.example.com.

El problema con GLUE desde los servidores DNS raíz es que cuando tienes la siguiente situación:

example.com tiene registros DNS ns1.example.net y ns2.example.net como sus servidores NS. La autoridad .com, que es donde el resolutor DNS buscará el nombre de dominio, NO PUEDE proporcionar las direcciones IP para ns1.example.net y ns2.example.net porque no están bajo su autoridad.

La forma de solucionar esto es que un dominio .com use servidores NS originados en .com. Entonces example.com usaría ns1.example-2.com y ns2.example-2.com y todo estará bien ya que la autoridad .com puede proporcionar la dirección IP para el servidor de nombres. Esto ahorra múltiples viajes de ida y vuelta a los servidores DNS raíz, ya que en su caso para obtener example.com ahora también debe preguntarle a .net sobre example.net.

En mi caso, todos mis dominios tienen sus propias entradas NS, así que por ejemplo.com tengo a.ns.example.com y b.ns.example.com y para mi dominio example.net tengo a.ns.example .net y b.ns.example.net.

Requiere más configuración, y no todos los hosts pueden estar dispuestos a permitírselo. ¡Puede estar atrapado con lo que tiene actualmente!

Al probar la herramienta yo mismo y ver lo que informa con algunos dominios con los que estoy familiarizado, diría que podrían ser varias las cosas que conducen a ese mensaje informativo (tenga en cuenta que es una 'i' para información, no un '!')

Por ejemplo, una de mis zonas tiene servidores de nombres fuera de la zona, y de los servidores de nombres autorizados para la zona no todos tienen registros A dentro de sus datos autorizados para ser devueltos en una respuesta.

Pero está bien: cualquier servidor de nombres que consulta no debería confiar en esos datos de todos modos. Hace mucho tiempo, te habrías salido con la tuya, pero en estos días cada servidor de nombres podría estar tratando de mentir y escabullirse de los datos de la zona en tu caché.

Así que no te preocupes por eso. Cuando la consulta llega a su servidor de nombres, ya ha encontrado al menos algunas de las direcciones IP de sus servidores de nombres. Preocúpese más por las delegaciones que son las mismas que sus propios datos de zona (la siguiente entrada, "Registros NS no coincidentes") y que ninguno es 'cojo' ("Los servidores de nombres son cojos: todos los servidores de nombres listados en los servidores principales responden con autoridad para su dominio "- redactado mal, pero desea asegurarse de que haya una marca allí.)