Aclaración de por qué los archivos de zona DNS requieren registros NS


18

Esta pregunta se hizo originalmente aquí: ¿Por qué los archivos de zona DNS requieren registros NS?

Para resumir: "Cuando vaya a mi registrador y compre example.com, le diré a mi registrador que mis servidores de nombres son ns1.example.org y ns2.example.org".

Pero, por favor, ¿alguien puede aclarar lo siguiente?

Después del registro, el registro .com ahora tendrá un registro que le indica a un solucionador que debe visitar ns1.example.org o ns2.example.org para averiguar la dirección IP de example.com. La dirección IP reside en un registro A en un archivo de zona en ns1.example.org y tiene una copia idéntica en ns2.example.org.

Sin embargo, dentro de este archivo, también debe haber 2 registros NS que enumeren ns1.example.org y ns2.example.org como servidores de nombres. Pero como ya estamos en uno de estos servidores, esto parece ser información duplicada.

La respuesta originalmente dada a la pregunta decía que los servidores de nombres listados en el archivo de zona son "autorizados". Si los servidores de nombres no coincidían, los servidores de nombres autorizados tendrían prioridad. Eso está muy bien, pero el solucionador llegó al servidor de nombres usando los servidores de nombres enumerados en el registro .com , y si los servidores de nombres no coincidían, entonces el resolutor buscaría el archivo de zona en el servidor de nombres incorrecto y no No poder encontrarlo.

¿O es un caso del registro .com que extrae información del servidor de nombres del archivo ns del archivo de zona? (Pero supongo que si cambia el ns registre el archivo de zona sin decirle al registro, entonces no tendría forma de saber dónde buscar).

Gracias

Respuestas:


23

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".


Muchas gracias por esta respuesta detallada. Entonces, imagine que el registro de delegación envía el resolutor a ns4.serverfault.com. Esto no figura en los registros NS del archivo de zona. ¿El solucionador nota la falta de coincidencia y retroceso? (una delegación pobre) Supongo que eso plantea la pregunta, ¿por qué ns4.serverfault.com? aparecer como un registro de delegación si no está incluido en el archivo de zona?
Lars

@Lars No, ns4.serverfault.com seguiría teniendo autoridad; la autoridad (¿es eso incluso una palabra?) es independiente de si el servidor en cuestión se nombra en los registros NS o no, ya sea en la zona misma o en la delegación. Es solo una delegación poco convincente si un servidor delegado responde de manera no autoritativa (es decir, el aaindicador no está configurado en la respuesta).
un CVn

1

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.


Gracias pero todavía estoy un poco confundido. El solucionador usa la dirección IP en el registro de pegamento en el registro .com para ir al archivo de zona almacenado en esa dirección IP. Ahora puede recuperar el registro A. ¿Por qué es necesario verificar que esta IP del servidor de nombres coincida con el registro NS en el archivo de zona?
Lars

Para que sepa que está buscando en el lugar correcto. Por ejemplo, si tuviera un subdominio cuyos registros A residieran en un servidor diferente , los registros NS le dirían al resolutor dónde buscar. Algo así como migas de pan.
Nathan C
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.