Pregunta ¿Cuál es la función de los registros NS en el vértice de un dominio DNS?


$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 el vértice de un dominio es bien conocido; existen para delegar la autoridad de un subdominio a otro servidor de nombres. Ejemplos de esto arriba incluirían los registros de NS para sub1 y sub2. Esto permite que el servidor de nombres distribuya referencias para partes del dominio para las que no se considera autoritario.

El propósito de los registros NS en el vértice de un dominio, ns1 y ns2 En este caso, parece ser menos comprendido por internet en general. Mi comprensión (que puede no ser holística) es la siguiente:

  1. No se utilizan al almacenar en caché los servidores DNS para determinar los servidores autorizados para el dominio. Esto es manejado por pegamento del servidor de nombres, que se define a nivel de registrador. El registrador Nunca Utiliza esta información para generar los registros de pegamento.
  2. Ellos no son utilizado para delegar la autoridad para todo el dominio a otros servidores de nombres. Tratar de hacerlo con software como ISC BIND no dará como resultado el comportamiento de referencia "esperado", ya que el servidor de nombres continuará considerándose autoritario para la zona.
  3. No son utilizados por el servidor de nombres para determinar si debe devolver respuestas autorizadas (AA conjunto de banderas) o no; ese comportamiento se define según si se le dice al software que sea un maestro o un esclavo para la zona. La mayoría del software de servidor de nombres servirá con mucho gusto los registros de NS de vértice que no estén de acuerdo con la información contenida en los registros de cola ascendentes, 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 parece que no se consume al almacenar en caché los servidores DNS en Internet en general?


16
2018-04-10 23:34


origen




Respuestas:


Identificación subordinada

Los registros NS de nivel de Apex son utilizados por un servidor maestro para identificar a sus subordinados. Cuando los datos de un servidor de nombres autorizado cambien, se anunciará a través de DNS NOTIFY mensajesRFC 1996) a todos sus compañeros en esa lista. Esos servidores a su vez devolverán la llamada con una solicitud para el SOA registro (que contiene el número de serie), y tome una decisión sobre si quitar una copia más reciente de esa zona.

  • Es posible enviar estos mensajes a servidores que no figuran en el NS sección, pero esto requiere directivas de configuración específicas del servidor (como ISC BIND's also-notify directiva). Los registros de apex NS comprenden la lista básica de servidores a notificar bajo una configuración predeterminada.
  • Vale la pena señalar que los servidores secundarios también se enviarán mensajes de NOTIFY entre ellos en función de estos NS registros, generalmente resultando en denegaciones registradas. Esto se puede desactivar indicando a los servidores que solo envíen notificaciones para las zonas para las que son maestros (BIND: notify master;), o para saltar NS basado notifica totalmente a favor de notificaciones explícitamente definidas en la configuración. (ENLAZAR: notify explicit;)

Definición autoritaria

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 se maneja con la cola del servidor de nombres, que se define a nivel de registrador. El registrador nunca usa esta información para generar los registros de pegamento.

Esta es una conclusión fácil de llegar, pero no precisa. los NS los registros y los datos de registro de cola (como los definidos en su cuenta de registrador) no tienen autoridad. Es lógico que no puedan considerarse "más autorizados" que los datos que residen en los servidores a los que se les está delegando la autoridad. Esto se enfatiza por el hecho de que las referencias no tienen la aa (Respuesta autoritaria) conjunto de banderas.

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 aa En las banderas para la respuesta anterior. La referencia en sí no es autoritaria. Por otro lado, los datos en el servidor al que se hace referencia es autoritario.

$ 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 ser muy confusa ya que no es posible conocer las versiones autorizadas de estos NS registros sin la autoridad no autorizada NS Registros definidos en el lado padre 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 al principio apilarán todo lo que se encuentre fuera de la referencia (y el pegamento) en un caché vacío, pero esos NS, Ay AAAA los registros pueden eventualmente ser reemplazados 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.
    • A y AAAA registros de datos fuera de la zona (es decir, com Los servidores de nombres que definen el pegamento para los datos fuera de la com zona, como example.net) definitivamente terminará siendo renovado, ya que es un concepto bien entendido de que un servidor de nombres no debe considerarse una fuente autorizada de dicha información. (RFC 2181)
    • Cuando los valores de la NS los registros difieren entre el lado principal y el secundario de la referencia (como los servidores de nombres ingresados ​​en el panel de control del registrador que difieren de los NS registros que viven en esos mismos servidores), los comportamientos experimentados serán inconsistentes, hasta e incluyendo niños NS Los registros 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 según las diferentes implementaciones de servidores recursivos. En otras palabras, solo se puede esperar un comportamiento consistente a través de Internet si las definiciones del servidor de nombres para un dominio son consistentes entre los lados padre e hijo de una referencia.

En resumen, los servidores DNS recursivos en todo el Internet se recuperarán entre los destinos si los registros definidos en el lado primario de la referencia no concuerdan con las versiones autorizadas de esos registros. Inicialmente, se preferirá la información presente en la referencia, solo para ser reemplazada por las definiciones autorizadas. Dado que los cachés se están reconstruyendo constantemente desde cero en Internet, es imposible que Internet se asiente en una única versión de la realidad con esta configuración. Si los registros de autoridad están haciendo algo ilegal según las normas, como señalar NSregistros en alias definidos por una CNAME, esto se vuelve aún más difícil de solucionar; el dominio alternará entre el trabajo y el 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 las referencias y el 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.

19
2018-04-10 23:34



Respuesta bien escrita! No estoy de acuerdo con el "largo y corto" de su respuesta. El uso principal de DNS en Internet consiste en obtener la IP del host, por lo tanto, las solicitudes "A". Los resolutores de DNS siempre aceptarán y reemplazarán la referencia para obtener una Respuesta "A" autoritaria. Y él "siempre" solo almacenará en caché el registro de referencia. La única vez que se reemplazarán los registros es cuando entra una solicitud explícita de "example.com IN NS". Luego el resolvedor 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 se actualiza, es una entrada en caché de NS para example.com a partir de una respuesta de NS autoritaria (ahora vencida). Se romperá la cadena de DNS. Debido a que ahora está atascado en un bucle donde el servidor NS (antiguo) sigue respondiendo, no tendrá en cuenta los cambios en el servidor DNS de vértice anterior (el registrador). Como en el caso de que mueva los servidores DNS pero no actualice o desconecte el antiguo servidor DNS. ¿O es este "problema" totalmente el caso hoy? - Wasted_Coder
@Wast también estoy en desacuerdo con su primer comentario debido a las muchas suposiciones que se hicieron. Dado que el comportamiento no está explícitamente establecido por las normas, en realidad es específico de la implementación. Esta presentación tiene 6 años. (comience en la diapositiva # 11), pero aún así se entiende; la preferencia del servidor de nombres padre e hijo variará. Más allá de eso, solo puede contar con los requisitos de RFC 2181. - Andrew B
Creo que mi punto de preocupación es si las entradas en caché del NS del resolvedor alcanzan TTL = 0, por ejemplo, para example.com. Y debe buscar una nueva entrada de host que aún no esté en caché, por ejemplo 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 tratar de llegar a ese servidor NS "caducado" solo para ver si todavía responde. TENDRÁ que verificar con el siguiente antepasado, por lo tanto, el NS de .com para la dirección. Esto significa que los registros NS del antepasado prevalecerían la mayoría de las veces (hasta que se procese una solicitud NS). - Wasted_Coder
@Wasted Comience desde la diapositiva # 11 y observe los tres patrones: centrados en los niños, no pegajosos (PPPCCCPPPCCC...), centrada en el niño pegajosa (PPPCCCCCC...), y el padre pegajoso (PPPPPP...). Centrado en el niño no pegajoso es por mucho el más común, y pegajoso centrado en el niño es en realidad Más prevalente que el padre pegajoso. Los clientes se moverán de un lado a otro entre las dos versiones de la realidad si los datos del NS sobre el niño y el padre no están de acuerdo a no ser que El software de resolución es padre pegajoso, que es el resultado menos probable. - Andrew B


Los registros NS de la zona delegada proporcionan la integridad de la definición de dominio. Los propios servidores NS dependerán del 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 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é sepa la dirección de un servidor de nombres, utilizará eso en lugar de buscar recursivamente un registro NS apropiado.

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

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

Tener los registros NS permite zonas desconectadas (locales). Estos pueden ser subdominios de un dominio registrado o un dominio completamente nuevo (no se recomienda debido a cambios de TLD). Los hosts que utilizan 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 que busquen las zonas locales en los servidores de nombres.

En el caso de DNS dividido (interno / externo), se puede desear 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 mostrarán la lista apropiada de servidores de nombres.


3
2018-04-11 03:36