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.