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.
PPPCCCPPPCCC...), criança-centrada (PPPCCCCCC...) e mãe-pegajosa (PPPPPP...). O adesivo não centrado na criança é de longe o mais comum, e o adesivo centrado na criança é realmente mais prevalente do que o adesivo pai. De fato, os clientes retornam entre as duas versões da realidade se os dados NS sobre o filho e o pai não estiverem de acordo , a menos que o software do resolvedor seja pai ou mãe, o que é o resultado menos provável.Os registros NS da zona delegada fornecem a integridade da definição de domínio. Os próprios servidores NS dependerão do arquivo de zona. Não é esperado que eles tentem se encontrar fazendo uma consulta recursiva nos servidores raiz. Os registros NS no arquivo de zona fornecem várias outras funções.
Os servidores de armazenamento em cache podem atualizar a lista de servidores de nomes consultando um servidor de nomes a partir do cache. Desde que um servidor de armazenamento em cache saiba o endereço de um servidor de nomes, ele o utilizará, em vez de procurar recursivamente um registro NS apropriado.
Ao mover servidores de nomes, é importante atualizar os servidores de nomes antigos e os novos. Isso evitará interrupções ou inconsistências que resultarão quando as duas definições de zona ficarem fora de sincronia. Os registros atualizados serão atualizados por todos os servidores que armazenaram em cache os registros NS. Isso substituirá a lista em cache de servidores de nomes.
Os registros NS também ajudam a confirmar a correção da configuração do DNS. O software de validação geralmente verifica se as definições do servidor de nomes da zona de delegação correspondem às fornecidas pela zona. Essa verificação pode ser realizada em todos os servidores de nomes. Qualquer incompatibilidade pode indicar uma configuração incorreta.
Ter os registros NS permite zonas desconectadas (locais). Estes podem ser subdomínios de um domínio registrado ou um domínio totalmente novo (não recomendado devido a alterações no TLD). Os hosts que usam os servidores de nomes como seus servidores de nomes poderão encontrar as zonas que não são acessíveis recorrendo a partir dos servidores raiz. Outros servidores de nomes podem ser configurados para procurar nos servidores de nomes as zonas locais.
No caso de DNS dividido (interno / externo), pode ser desejável ter um conjunto diferente de servidores DNS. Nesse caso, a lista NS (e provavelmente outros dados) será diferente, e os registros NS nos arquivos de zona listarão a lista apropriada do servidor de nomes.
fonte