¿Cuál es el papel de los registros NS en la cúspide de un dominio DNS?


21
$ORIGIN example.com. ; not necessary, using this to self-document

$TTL 3600
@        IN     SOA   ns1.example.com. admin.example.com. (
                      1970010100 7200 1800 1209600 300)

@        IN     NS   ns1.example.com.
@        IN     NS   ns2.example.com.

@        IN     A    198.51.100.1
ns1      IN     A    198.51.100.2
ns2      IN     A    198.51.100.3

sub1     IN     NS   ns1.example.edu.

sub2     IN     NS   ns1.sub2
ns1.sub2 IN     A    203.0.113.1 ; inline glue record

El papel de un registro NS debajo del vértice de un dominio es bien entendido; existen para delegar autoridad para un subdominio a otro servidor de nombres. Ejemplos de esto arriba incluirían los registros NS para sub1y sub2. Esto permite que el servidor de nombres entregue referencias para partes del dominio para las cuales no se considera autoritario.

El propósito de los registros NS en la cúspide de un dominio, ns1y ns2en este caso, parece ser menos comprendido por Internet en general. Mi entendimiento (que puede no ser holístico) es el siguiente:

  1. Los servidores DNS en caché no los utilizan para determinar los servidores autorizados para el dominio. Esto lo maneja el pegamento de servidor de nombres , que se define a nivel de registrador. El registrador nunca usa esta información para generar los registros de pegamento.
  2. No se utilizan para delegar autoridad para todo el dominio a otros servidores de nombres. Intentar hacerlo con software como ISC BIND no dará como resultado el comportamiento de referencia "esperado", ya que el servidor de nombres seguirá considerándose autorizado para la zona.
  3. El servidor de nombres no los utiliza para determinar si debe devolver respuestas autorizadas ( AAconjunto de indicadores) o no; ese comportamiento se define por si se le dice al software que sea maestro o esclavo para la zona. La mayoría del software de servidor de nombres servirá con mucho gusto los registros NS de apex que no están de acuerdo con la información contenida en los registros de pegamento aguas arriba, lo que a su vez hará que los sitios web de validación de DNS conocidos generen advertencias para el dominio.

Siendo este el caso, ¿qué nos queda? ¿Por qué estamos definiendo esta información si no parece ser consumida por el almacenamiento en caché de servidores DNS en Internet en general?

Respuestas:


21

Identificación subordinada

Los registros NS de nivel Apex son utilizados por un servidor maestro para identificar a sus subordinados. Cuando los datos de un servidor de nombres autorizado cambien, lo anunciará a través de DNS NOTIFYmensajes ( RFC 1996 ) a todos sus pares en esa lista. Esos servidores a su vez volverán a llamar con una solicitud del SOAregistro (que contiene el número de serie) y tomarán una decisión sobre si retirar una copia más reciente de esa zona.

  • Es posible enviar estos mensajes a servidores que no figuran en la NSsección, pero esto requiere directivas de configuración específicas del servidor (como la also-notifydirectiva ISC BIND ). Los registros NS de apex comprenden la lista básica de servidores para notificar bajo una configuración predeterminada.
  • Vale la pena señalar que los servidores secundarios también se enviarán mensajes de NOTIFICACIÓN entre sí en función de estos NSregistros, lo que generalmente resulta en rechazos registrados. Esto puede deshabilitarse indicando a los servidores que solo envíen notificaciones para las zonas para las que son maestros (BIND:) notify master;, o que omitan las NSnotificaciones basadas completamente a favor de las notificaciones definidas explícitamente en la configuración. (BIND: notify explicit;)

Definición autoritativa

La pregunta anterior contenía una falacia:

No se utilizan al almacenar en caché los servidores DNS para determinar los servidores autorizados para el dominio. Esto lo maneja el pegamento de servidor de nombres, que se define a nivel de registrador. El registrador nunca usa esta información para generar los registros de pegamento.

Es una conclusión fácil de llegar, pero no precisa. Los NSregistros y los datos de registro de pegamento (como el definido dentro de su cuenta de registrador) no tienen autoridad. Es lógico pensar que no pueden considerarse "más autorizados" que los datos que residen en los servidores a los que se delega la autoridad. Esto se enfatiza por el hecho de que las referencias no tienen aaestablecido el indicador (Respuesta autorizada).

Para ilustrar:

$ dig @a.gtld-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14021
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      NS

;; AUTHORITY SECTION:
example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net.     172800  IN      A       199.43.135.53
a.iana-servers.net.     172800  IN      AAAA    2001:500:8f::53
b.iana-servers.net.     172800  IN      A       199.43.133.53
b.iana-servers.net.     172800  IN      AAAA    2001:500:8d::53

Tenga en cuenta la falta de aaen las banderas para la respuesta anterior. La referencia en sí no es autorizada. Por otro lado, los datos en el servidor al que se hace referencia son autorizados.

$ dig @a.iana-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2349
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      NS

;; ANSWER SECTION:
example.com.            86400   IN      NS      a.iana-servers.net.
example.com.            86400   IN      NS      b.iana-servers.net.

Dicho esto, esta relación puede volverse muy confusa ya que no es posible aprender sobre las versiones autorizadas de estos NSregistros sin los registros no autorizados NSdefinidos en el lado principal de la referencia. ¿Qué pasa si no están de acuerdo?

  • La respuesta corta es "comportamiento inconsistente".
  • La respuesta larga es que los servidores de nombres serán inicialmente talón de todo lo que fuera de la remisión (y pegamento) en una caché vacía, pero aquellos NS, Ay AAAAlos registros pueden eventualmente ser reemplazadas cuando se actualizan. Las actualizaciones se producen a medida que caducan los TTL en esos registros temporales, o cuando alguien solicita explícitamente la respuesta para esos registros.
    • Ay los AAAAregistros de datos fuera de zona (es decir, los comservidores de nombres que definen el pegamento para datos fuera de la comzona, por ejemplo example.net) definitivamente se actualizarán, ya que es un concepto bien entendido que un servidor de nombres no debe considerarse una fuente autorizada de dicha información . (RFC 2181)
    • Cuando los valores de los NSregistros difieren entre los lados padre e hijo de la referencia (como los servidores de nombres ingresados ​​en el panel de control del NSregistrador que difieren de los registros que viven en esos mismos servidores), los comportamientos experimentados serán inconsistentes, hasta el niño incluido NSregistros que se ignoran por completo. Esto se debe a que el comportamiento no está bien definido por los estándares, y la implementación varía entre diferentes implementaciones de servidor recursivo. En otras palabras, solo se puede esperar un comportamiento consistente en Internet si las definiciones del servidor de nombres para un dominio son consistentes entre los lados padre e hijo de una referencia .

En resumidas cuentas, los servidores DNS recursivos en Internet se recuperarán entre los destinos si los registros definidos en el lado principal de la referencia no están de acuerdo con las versiones autorizadas de esos registros. Inicialmente, se preferirán los datos presentes en la referencia, solo para ser reemplazados por las definiciones autorizadas. Dado que los cachés se reconstruyen constantemente desde cero a través de Internet, es imposible que Internet se establezca en una única versión de la realidad con esta configuración. Si los registros autorizados están haciendo algo ilegal según los estándares, como señalar NSregistros en alias definidos por unCNAME, esto se vuelve aún más difícil de solucionar; el dominio alternará entre funcional y roto para el software que rechaza la violación. (es decir, ISC BIND / named)

RFC 2181 §5.4.1 proporciona una tabla de clasificación para la confiabilidad de estos datos, y hace explícito que los datos de caché asociados con referencias y pegamento no pueden devolverse como respuesta a una solicitud explícita de los registros a los que se refieren.

5.4.1. Ranking data

   When considering whether to accept an RRSet in a reply, or retain an
   RRSet already in its cache instead, a server should consider the
   relative likely trustworthiness of the various data.  An
   authoritative answer from a reply should replace cached data that had
   been obtained from additional information in an earlier reply.
   However additional information from a reply will be ignored if the
   cache contains data from an authoritative answer or a zone file.

   The accuracy of data available is assumed from its source.
   Trustworthiness shall be, in order from most to least:

     + Data from a primary zone file, other than glue data,
     + Data from a zone transfer, other than glue,
     + The authoritative data included in the answer section of an
       authoritative reply.
     + Data from the authority section of an authoritative answer,
     + Glue from a primary zone, or glue from a zone transfer,
     + Data from the answer section of a non-authoritative answer, and
       non-authoritative data from the answer section of authoritative
       answers,
     + Additional information from an authoritative answer,
       Data from the authority section of a non-authoritative answer,
       Additional information from non-authoritative answers.

   <snip>

   Unauthenticated RRs received and cached from the least trustworthy of
   those groupings, that is data from the additional data section, and
   data from the authority section of a non-authoritative answer, should
   not be cached in such a way that they would ever be returned as
   answers to a received query.  They may be returned as additional
   information where appropriate.  Ignoring this would allow the
   trustworthiness of relatively untrustworthy data to be increased
   without cause or excuse.

Respuesta bien escrita! No estoy de acuerdo con el "largo y corto" de su respuesta. El uso principal de DNS en Internet se trata de obtener la IP del host, por lo tanto, las solicitudes "A". Los solucionadores de DNS siempre aceptarán y reemplazarán la referencia para obtener una respuesta autorizada "A". Y "siempre" solo almacenará en caché el registro de referencia. El único momento en que los registros serían reemplazados es cuando entra una solicitud explícita para un "example.com IN NS". Luego, el resolver le preguntará al servidor en la ubicación de referencia. Y esa respuesta AR reemplazará la respuesta de referencia en caché (solo para el TTL de ese registro).
Wasted_Coder

Puedo estar equivocado según la respuesta de @BillThor. Basé mi razonamiento en el hecho de que si un servidor DNS actualiza su entrada en caché NS para example.com de una respuesta NS autorizada (ahora caducada). Romperá la cadena DNS. Debido a que ahora está atascado en un bucle donde mientras el servidor NS (antiguo) sigue respondiendo, no tendrá en cuenta los cambios en el servidor DNS apex anterior (el registrador). Como en el caso de mover servidores DNS pero no actualizar o desconectar el antiguo servidor DNS. ¿O este "problema" es totalmente el caso hoy?
Wasted_Coder

@Wasted También estoy en desacuerdo con tu primer comentario debido a las muchas suposiciones que se hacen. Dado que el comportamiento no está explícitamente establecido por los estándares, en realidad es específico de la implementación. Esta presentación tiene 6 años (comienza en la diapositiva n. ° 11), pero aún se entiende; la preferencia del servidor de nombres padre vs. hijo variará. Más allá de eso, solo puede contar con los requisitos de RFC 2181.
Andrew B

Creo que mi preocupación es si las entradas en caché NS de un resolutor alcanzan TTL = 0, por ejemplo, por ejemplo.com. Y debe buscar una nueva entrada de host que aún no se haya almacenado en caché, digamos para new.example.com. Ahora necesita el (los) servidor (es) NS para example.com y dado que sus copias en caché han caducado, sería malo intentar alcanzar ese servidor NS "caducado" solo para ver si aún responde. Tendrá que consultar con el próximo antepasado, por lo tanto, NS de .com para la dirección. Esto significa que los registros NS ancestrales prevalecerían la mayoría de las veces (hasta que se procese una solicitud NS).
Wasted_Coder

@Wasted Comience desde la diapositiva n. ° 11 y observe los tres patrones: centrado en el niño no adhesivo ( PPPCCCPPPCCC...), centrado en el niño adhesivo ( PPPCCCCCC...) y padre adhesivo ( PPPPPP...). La no-pegajosa centrada en el niño es, con mucho, la más común, y la pegajosa centrada en el niño es en realidad más frecuente que la pegajosa de los padres. Los clientes rebotarán de un lado a otro entre las dos versiones de la realidad si los datos de NS sobre el niño y el padre no están de acuerdo, a menos que el software de resolución sea adhesivo para los padres, que es el resultado menos probable.
Andrew B

3

El NS registra que la zona delegada proporciona la integridad de la definición del dominio. Los propios servidores NS se basarán en el archivo de zona. No se espera que intenten encontrarse haciendo una consulta recursiva desde los servidores raíz. Los registros NS en el archivo de zona proporcionan una serie de otras funciones.

Los servidores de almacenamiento en caché pueden actualizar la lista de servidores de nombres consultando un servidor de nombres desde su caché. Siempre que un servidor de almacenamiento en caché conozca la dirección de un servidor de nombres, lo usará en lugar de buscar recursivamente un registro NS apropiado.

Al mover servidores de nombres, es importante actualizar los servidores de nombres antiguos, así como los nuevos servidores de nombres. Esto evitará interrupciones o inconsistencias que resultarán cuando las dos definiciones de zona no estén sincronizadas. Los registros actualizados eventualmente serán actualizados por cualquier servidor que haya almacenado en caché los registros NS. Esto reemplazará la lista en caché de los servidores de nombres.

Los registros NS también ayudan a confirmar la corrección de la configuración de DNS. El software de validación a menudo verificará que las definiciones del servidor de nombres de la zona de delegación coincidan con las proporcionadas por la zona. Esta verificación se puede realizar en todos los servidores de nombres. Cualquier falta de coincidencia puede indicar una configuración incorrecta.

Tener los registros NS permiten zonas desconectadas (locales). Estos pueden ser subdominios de un dominio registrado o un dominio completamente nuevo (no recomendado debido a cambios de TLD). Los hosts que usan los servidores de nombres como su servidor de nombres podrán encontrar las zonas a las que no se puede acceder recurriendo desde los servidores raíz. Se pueden configurar otros servidores de nombres para buscar los servidores de nombres para las zonas locales.

En el caso de DNS dividido (interno / externo), puede desearse tener un conjunto diferente de servidores DNS. En este caso, la lista NS (y probablemente otros datos) será diferente, y los registros NS en los archivos de zona enumerarán la lista de servidores de nombres apropiada.

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.