Qual é o papel dos registros NS no ápice de um domínio DNS?

Question

$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

O papel de um registro NS abaixo do ápice de um domínio é bem compreendido; eles existem para delegar autoridade para um subdomínio para outro servidor de nomes. Exemplos disso acima incluiriam os registros NS para sub1 e sub2 . Isso permite que o servidor de nomes distribua referências para partes do domínio para as quais ele não se considera autorizado.

O objetivo dos registros de NS no ápice de um domínio, ns1 e ns2 neste caso, parece ser menos compreendido pela Internet em geral. Meu entendimento (que pode não ser holístico) é o seguinte:

1. Eles não são usados pelo armazenamento em cache de servidores DNS para determinar os servidores autoritativos do domínio. Isso é tratado pelo adesivo do servidor de nomes , que é definido no nível do registrador. O registrador nunca usa essas informações para gerar os registros de cola.
2. Eles não são usados para delegar autoridade para todo o domínio a outros servidores de nomes. Tentar fazer isso com um software como o ISC BIND não resultará no comportamento de referência "esperado", pois o servidor de nomes continuará a considerar-se autoritário para a zona.
3. Eles não são usados pelo servidor de nomes para determinar se devem retornar respostas autoritativas ( AA flag set) ou não; Esse comportamento é definido por se o software é instruído a ser um mestre ou um escravo para a zona. A maioria dos softwares de servidor de nomes servirá satisfatoriamente os registros de NS do apex que discordam das informações contidas nos registros upstream de cola, que por sua vez farão com que sites de validação de DNS bem conhecidos gerem avisos para o domínio.

Com este ser o caso, o que nos resta? Por que estamos definindo essa informação se ela não parece ser consumida pelo armazenamento em cache de servidores DNS na Internet em geral?

    

Answer 1

Identificação subordinada

Registros NS no nível do Apex são usados por um servidor mestre para identificar seus subordinados. Quando os dados em um servidor de nomes autoritativo mudarem, ele anunciará isso via DNS NOTIFY messages ( RFC 1996 ) a todos os seus pares nessa lista. Esses servidores, por sua vez, retornarão a chamada com uma solicitação para o registro SOA (que contém o número de série) e tomarão uma decisão sobre a possibilidade de baixar uma cópia mais recente dessa zona.

• É possível enviar essas mensagens para servidores não listados na seção NS , mas isso exige diretivas de configuração específicas do servidor (como a diretiva also-notify do ISC BIND). Os registros NS do ápice incluem a lista básica de servidores a serem notificados em uma configuração padrão.
• Vale a pena notar que os servidores secundários também enviarão mensagens NOTIFY com base nesses registros NS , geralmente resultando em recusas registradas. Isso pode ser desabilitado instruindo os servidores a somente enviarem notificações para as zonas para as quais são mestres (BIND: notify master; ), ou pular NS com base em notificações inteiramente a favor de notificações explicitamente definidas na configuração. (BIND: notify explicit; )

Definição autoritativa

A pergunta acima continha uma falácia:

They are not used by caching DNS servers in order to determine the authoritative servers for the domain. This is handled by nameserver glue, which is defined at the registrar level. The registrar never uses this information to generate the glue records.

Essa é uma conclusão fácil de se chegar, mas não precisa. Os registros de NS e os dados de registro de cola (como os definidos em sua conta de registrador) não são autoritativos. É lógico que eles não podem ser considerados "mais autorizados" do que os dados que residem nos servidores aos quais a autoridade está sendo delegada. Isso é enfatizado pelo fato de que as referências não têm o sinalizador aa (resposta autoritativa) definido.

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

Observe a falta de aa nos sinalizadores da resposta acima. O encaminhamento em si não é autoritativo. Por outro lado, os dados no servidor que estão sendo referenciados a são autoritativos.

$ 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 autoritativas desses registros NS sem os registros NS não autoritativos definidos no lado pai da referência. O que acontece se eles discordarem?

• A resposta curta é "comportamento inconsistente".
• A resposta longa é que os servidores de nomes eliminarão inicialmente tudo da referência (e cola) em um cache vazio, mas os registros NS , A e AAAA poderão eventualmente ser substituídos quando forem atualizados. As atualizações ocorrem à medida que os TTLs desses registros temporários expiram ou quando alguém solicita explicitamente a resposta para esses registros.
  • Os registros A e AAAA dos dados fora da zona (ou seja, os% de servidores de nomescom que definem os dados fora da zona com , como example.net ) definitivamente serão atualizados, pois é um bem conceito compreendido de que um servidor de nomes não deve ser considerado uma fonte autorizada de tal informação. (RFC 2181)
  • Quando os valores dos registros NS diferem entre os lados pai e filho da referência (como os servidores de nomes inseridos no painel de controle do registrador que diferem dos registros NS que residem nesses mesmos servidores), os comportamentos enfrentados será inconsistente, até e incluindo os registros child NS sendo ignorados completamente. Isso ocorre porque o comportamento não é bem definido pelos padrões, e a implementação varia entre diferentes implementações de servidores recursivos. Em outras palavras, o comportamento consistente em toda a Internet só pode ser esperado se as definições do servidor de nomes de um domínio forem consistentes entre os lados pai e filho de uma referência .

O problema é que os servidores DNS recursivos em toda a Internet retornarão entre os destinos se os registros definidos no lado pai da referência não concordarem com as versões oficiais desses registros. Inicialmente, os dados presentes no encaminhamento serão preferenciais, apenas para serem substituídos pelas definições autorizadas. Como os caches estão sendo constantemente reconstruídos do zero pela Internet, é impossível que a Internet estabeleça uma única versão da realidade com essa configuração. Se os registros autoritativos estiverem fazendo algo ilegal de acordo com os padrões, como apontar NS registros em aliases definidos por CNAME , isso fica ainda mais difícil de solucionar; o domínio alternará entre trabalho e quebrado para software que rejeita a violação. (isto é, ISC BIND / named)

RFC 2181 §5.4.1 fornece uma tabela de classificação para a confiabilidade desses dados, e torna explícito que os dados de cache associados a referências e cola não podem ser retornados como a resposta a uma solicitação explícita para os registros aos quais eles 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.

    

Answer 2

O NS registra que a zona delegada fornece integridade na definição do domínio. Os próprios servidores NS dependerão do arquivo de zona. Eles não devem tentar se encontrar fazendo uma consulta recursiva a partir dos 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 em seu cache. Desde que um servidor de cache saiba o endereço de um servidor de nomes, ele usará isso em vez de procurar recursivamente um registro NS apropriado.

Ao mover servidores de nomes, é importante atualizar os servidores de nomes antigos, bem como os novos servidores de nomes. Isso evitará interrupções ou inconsistências que resultarão quando as duas definições de zona ficarem fora de sincronia. Os registros atualizados eventualmente serão atualizados por quaisquer servidores que armazenaram em cache os registros do NS. Isso substituirá a lista de servidores de nomes em cache.

Os registros NS também ajudam a confirmar a exatidão da configuração do DNS. Muitas vezes, o software de validação verificará se as definições do servidor de nomes da zona de delegação correspondem às fornecidas pela zona. Essa verificação pode ser executada 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 de TLDs). Os hosts que usam os servidores de nome como seu servidor de nomes poderão localizar as zonas que não podem ser acessadas pelos servidores raiz. Outros servidores de nomes podem ser configurados para procurar os servidores de nomes para as zonas locais.

No caso de DNS dividido (interno / externo), pode ser desejado ter um conjunto diferente de servidores DNS. Nesse caso, a lista de NS (e provavelmente outros dados) será diferente, e os registros NS nos arquivos de zona listarão a lista apropriada de servidores de nomes.