Vamos a desglosarlo un poco.
Los registros NS en la zona de TLD (por ejemplo, example.com NS ...en com) son registros de delegación .
Los registros A y AAAA en la zona de TLD (por ejemplo, ns1.example.com A ...en com) son registros de pegamento .
Los registros NS en la zona misma (es decir, example.com NS ...en example.com) son registros de autoridad .
Los registros A y AAAA en la zona misma ( ns1.example.com A ...en example.com) son registros de direcciones , simples y simples.
Cuando una resolución (recursiva) comienza sin memoria caché de los datos de su zona y solo la memoria caché de la zona raíz (que se utiliza para iniciar el proceso de resolución de nombres), primero irá a ., luego com.. Los comservidores responderán con una respuesta de la sección de autoridad que básicamente dice "No sé, pero busque aquí a alguien que sí sepa", al igual que los servidores para .hacer sobre com. Esta respuesta de consulta no es autorizada y no incluye una sección de respuesta poblada. También puede incluir un llamado adicionalsección que proporciona las asignaciones de direcciones para cualquier nombre de host que el servidor particular conozca (ya sea de registros de pegamento o, en el caso de resolvers recursivos, de datos previamente almacenados en caché). El resolutor tomará esta respuesta de delegación, resolverá el nombre de host de un registro NS si es necesario y procederá a consultar al servidor DNS al que se le ha delegado la autoridad. Este proceso puede repetirse varias veces si tiene una jerarquía de delegación profunda, pero finalmente da como resultado una respuesta de consulta con el conjunto de indicadores "respuesta autorizada" .
Es importante tener en cuenta que el solucionador (generalmente, con suerte) no intentará desglosar el nombre del host que se está resolviendo para preguntarlo pieza por pieza, sino que simplemente lo enviará en su totalidad al "mejor" servidor que conoce. Dado que el servidor de nombres autorizado promedio en Internet no tiene autorización para la gran mayoría de los nombres DNS válidos, la respuesta será una respuesta de delegación no autorizada que apunte hacia algún otro servidor DNS.
Ahora, un servidor no tiene que ser nombrado en los registros de delegación o autoridad en ningún lugar para tener autoridad para una zona. Considere, por ejemplo, el caso de un servidor maestro privado; en ese caso, existe un servidor DNS autorizado que solo los administradores de los servidores DNS esclavos de la zona conocen. Un servidor DNS tiene autoridad para una zona si, a través de algún mecanismo, en su opinión, tiene un conocimiento completo y preciso de la zona en cuestión. Un servidor DNS normalmente autorizado puede, por ejemplo, dejar de serlo si no se puede alcanzar el servidor o servidores maestros configurados dentro del límite de tiempo definido como el tiempo de vencimiento en el registro SOA.
Solo las respuestas autorizadas deben considerarse respuestas de consulta adecuadas; todo lo demás es una delegación o un error de algún tipo. Una delegación a un servidor no autorizado se denomina delegación "poco convincente" y significa que el solucionador tiene que retroceder un paso e intentar con otro servidor DNS con nombre. Si no hay servidores de nombres accesibles con autoridad en la delegación, la resolución de nombres falla (de lo contrario, será más lenta de lo normal).
Todo esto es importante porque los datos no autorizados no deben almacenarse en caché . ¿Cómo podría ser, ya que el servidor no autorizado no tiene la imagen completa? Por lo tanto, el servidor autorizado debe, por sí solo, ser capaz de responder la pregunta "¿quién se supone que tiene autoridad y para qué?". Esa es la información proporcionada por los registros NS en la zona.
Hay una serie de casos extremos en los que esto realmente puede hacer una gran diferencia, centrada principalmente en múltiples etiquetas de nombre de host dentro de una sola zona (probablemente bastante común, por ejemplo, con zonas DNS inversas, particularmente para grandes rangos de IP dinámicos) o cuando la lista de servidores de nombres difiere entre la zona principal y la zona en cuestión (lo que probablemente sea un error, pero también se puede hacer intencionalmente).
Puede ver cómo funciona esto con un poco más de detalle utilizando digy sus características de especificador de servidor +norec(no solicitar recursividad) @. Lo que sigue es una ilustración de cómo funciona un servidor DNS de resolución real. Consulte los registros A para unix.stackexchange.comcomenzar, por ejemplo, en a.root-servers.net:
$ dig unix.stackexchange.com. A @a.root-servers.net. +norec
Observe atentamente los flagsrecuentos, así como los por sección. qres la respuesta a la consulta y aaes la respuesta autorizada. Tenga en cuenta que solo se le delega a los comservidores. Siga manualmente esa delegación (en la vida real, un solucionador recursivo usaría la dirección IP de la sección adicional si se proporciona, o iniciará una resolución de nombre separada de uno de los servidores de nombres con nombre si no se proporcionan IP en la respuesta de delegación, pero omita esa parte y simplemente recurra a la resolución normal del sistema operativo por brevedad del ejemplo):
$ dig unix.stackexchange.com. A @a.gtld-servers.net. +norec
Ahora ve que stackexchange.comse delega a (entre otros) ns1.serverfault.comy aún no obtiene una respuesta autorizada. Nuevamente sigue a la delegación:
$ dig unix.stackexchange.com. A @ns1.serverfault.com. +norec
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35713
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;unix.stackexchange.com. IN A
;; ANSWER SECTION:
unix.stackexchange.com. 300 IN A 198.252.206.16
¡Bingo! Obtuvimos una respuesta, porque el aaindicador está configurado y contiene una dirección IP tal como esperábamos encontrar. Por otro lado, vale la pena señalar que, al menos en el momento en que escribo esta publicación, las listas de servidores de nombres con autoridad delegada y listada difieren, lo que demuestra que los dos no necesitan ser idénticos. Lo que he ejemplificado anteriormente es básicamente el trabajo realizado por cualquier solucionador, excepto que cualquier solucionador práctico también almacenará en caché las respuestas en el camino para que no tenga que llegar a los servidores raíz cada vez.
Como puede ver en el ejemplo anterior, los registros de delegación y pegamento tienen un propósito distinto de los registros de autoridad y dirección en la zona misma.
Un servidor de nombres de almacenamiento en caché y resolución también generalmente realizará algunas comprobaciones de los datos devueltos para proteger contra el envenenamiento de la memoria caché. Por ejemplo, puede negarse a almacenar en caché una respuesta que nombra los servidores autorizados comde una fuente que no haya sido nombrada por una zona principal como delegada para com. Los detalles dependen del servidor, pero la intención es almacenar en caché tanto como sea posible sin abrir la puerta del granero de permitir que cualquier servidor de nombres aleatorios en Internet anule los registros de delegación para cualquier cosa que no esté oficialmente bajo su "jurisdicción".
aaindicador no está configurado en la respuesta).El registro .com es el "registro de pegamento" que tiene la ubicación de sus servidores de nombres como una dirección IP. El solucionador no tiene forma de conocer la "identidad" de su servidor DNS, por lo que utiliza el registro NS para garantizar que los números coincidan.
Solicitud DNS -> .com registro (ip es xxxx) -> DNS (NS xxxx) coincide, resolver.
Si no coinciden o existen, entonces es una respuesta no autorizada para el dominio.
fuente