Identificação subordinada
Os registros NS do nível Apex são usados por um servidor mestre para identificar seus subordinados. Quando os dados em um servidor de nomes com autoridade são alterados, ele os anuncia por meio de DNS NOTIFYmensagens ( RFC 1996 ) para todos os seus pares nessa lista. Esses servidores, por sua vez, retornam a chamada com uma solicitação para o SOAregistro (que contém o número de série) e tomam uma decisão sobre a retirada de uma cópia mais recente dessa zona.
- É possível enviar essas mensagens para servidores não listados na
NSseção, mas isso requer diretivas de configuração específicas do servidor (como a also-notifydiretiva ISC BIND ). Os registros do apex NS compreendem a lista básica de servidores a serem notificados em uma configuração padrão.
- Vale ressaltar que os servidores secundários também enviarão mensagens NOTIFY entre si com base nesses
NSregistros, geralmente resultando em recusas registradas. Isso pode ser desabilitado instruindo os servidores a enviar apenas notificações para zonas para as quais são mestres (BIND:) notify master;ou ignorar NSnotificações baseadas inteiramente a favor de notificações definidas explicitamente na configuração. (BIND: notify explicit;)
Definição autoritativa
A pergunta acima continha uma falácia:
Eles não são usados no cache de servidores DNS para determinar os servidores autoritativos do domínio. Isso é tratado pela cola do servidor de nomes, definida no nível do registrador. O registrador nunca usa essas informações para gerar os registros de cola.
É uma conclusão fácil de se chegar, mas não precisa. Os NSregistros e os dados do registro colado (como os definidos na sua conta de registrador) não têm autoridade. É lógico que eles não podem ser considerados "mais autoritativos" do que os dados que residem nos servidores aos quais a autoridade está sendo delegada. Isso é enfatizado pelo fato de as referências não terem o aasinalizador (Resposta autoritativa) definido.
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
Observe a falta de aasinalizadores na resposta acima. A referência em si não é autorizada. Por outro lado, os dados no servidor que está sendo referido são oficiais.
$ 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.
Dito isso, esse relacionamento pode ficar muito confuso, pois não é possível aprender sobre as versões autorizadas desses NSregistros sem os registros não autoritativos NSdefinidos no lado pai da referência. O que acontece se eles discordarem?
- A resposta curta é "comportamento inconsistente".
- A resposta longa é que servidores de nomes vai tudo inicialmente esboço fora da arbitragem (e cola) em um cache vazio, mas aqueles
NS, Ae AAAAregistros podem, eventualmente, ser substituído quando eles são atualizados. As atualizações ocorrem quando os TTLs desses registros temporários expiram ou quando alguém solicita explicitamente a resposta para esses registros.
Ae os AAAAregistros de dados fora da zona (ou seja, os comservidores de nomes que definem cola para dados fora da comzona, como example.net) definitivamente serão atualizados, pois é um conceito bem entendido que um servidor de nomes não deve ser considerado uma fonte autorizada dessas informações . (RFC 2181)- Quando os valores dos
NSregistros diferem entre os lados pai e filho da referência (como os servidores de nomes inseridos no painel de controle do registrador diferentes dos NSregistros que vivem nesses mesmos servidores), os comportamentos experimentados serão inconsistentes, incluindo NSregistros sendo completamente ignorados. Isso ocorre porque o comportamento não é bem definido pelos padrões e a implementação varia entre diferentes implementações de servidor recursivo. Em outras palavras, um comportamento consistente na Internet só pode ser esperado se as definições de servidor de nomes para um domínio forem consistentes entre os lados pai e filho de uma referência .
A questão é que servidores DNS recursivos na Internet retornam entre destinos se os registros definidos no lado pai da referência não concordarem com as versões autorizadas desses registros. Inicialmente, os dados presentes no encaminhamento serão preferidos, apenas para serem substituídos pelas definições autorizadas. Como os caches são constantemente reconstruídos do zero na Internet, é impossível que a Internet se acomode em uma única versão da realidade com essa configuração. Se os registros oficiais estiverem fazendo algo ilegal de acordo com os padrões, como apontar NSregistros para aliases definidos por umCNAME, isso fica ainda mais difícil de solucionar; o domínio alternará entre trabalho e interrupção para o software que rejeita a violação. (ou seja, ISC BIND / nomeado)
A RFC 2181 §5.4.1 fornece uma tabela de classificação para a confiabilidade desses dados e torna explícito que os dados em cache associados a referências e cola não podem ser retornados como resposta a uma solicitação explícita dos registros a que se referem.
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.