Esclarecimento sobre por que os arquivos da zona DNS exigem registros NS

Esta pergunta foi feita originalmente aqui: Por que os arquivos de zona DNS exigem registros NS?

Para resumir: "Quando eu for ao meu registrador e comprar o example.com, informarei ao meu registrador que meus servidores de nomes são ns1.example.org e ns2.example.org".

Mas alguém pode esclarecer o seguinte:

Após o registro, o registro .com agora terá um registro informando que um resolvedor precisa visitar ns1.example.org ou ns2.example.org para descobrir o endereço IP de exemplo.com. O endereço IP reside em um registro A em um arquivo de zona no ns1.example.org e possui uma cópia idêntica no ns2.example.org.

No entanto, dentro desse arquivo, também deve haver 2 registros NS que listam ns1.example.org e ns2.example.org como servidores de nomes. Mas como já estamos em um desses servidores, essas informações parecem duplicadas.

A resposta originalmente dada à pergunta dizia que os servidores de nomes listados no arquivo de zona são "oficiais". Se os servidores de nomes não corresponderem, os servidores de nomes com autoridade terão precedência. Tudo muito bem, mas o resolvedor chegou ao servidor de nomes usando os servidores de nomes listados no registro .com e, se o servidor de nomes não corresponder, o resolvedor procuraria o arquivo de zona no servidor de nomes errado e não iria ' não conseguir encontrá-lo.

Ou é um caso de o registro .com extrair informações do servidor de nomes do registro ns do arquivo de zona? (Mas suponho que, se você alterar o registro ns do arquivo de zona sem informar o registro, não haverá como saber para onde procurar.)

obrigado

Vamos dividir um pouco.

Os registros NS na zona do TLD (por exemplo, example.com NS ...em com) são registros de delegação .

Os registros A e AAAA na zona do TLD (por exemplo, ns1.example.com A ...em com) são registros de cola .

Os registros NS na própria zona (ou seja, example.com NS ...em example.com) são registros de autoridade .

Os registros A e AAAA na própria zona ( ns1.example.com A ...pol example.com) são registros de endereço , simples e simples.

Quando um resolvedor (recursivo) inicia sem cache dos dados da sua zona e somente o cache da zona raiz (usado para inicializar o processo de resolução de nomes), ele primeiro acessará ., então com.. Os comservidores irão responder com uma resposta seção autoridade que basicamente diz: "Eu não sei, mas olha aqui para alguém que sabe", mesmo que os servidores para .fazer cerca com. Esta resposta de consulta não é autoritativa e não inclui uma seção de resposta preenchida. Também pode incluir o chamado adicionalseção que fornece os mapeamentos de endereço para qualquer nome de host conhecido pelo servidor em particular (a partir de registros de cola ou, no caso de resolvedores recursivos, de dados armazenados em cache anteriormente). O resolvedor receberá esta resposta de delegação, resolverá o nome do host de um registro NS, se necessário, e continuará consultando o servidor DNS ao qual a autoridade foi delegada. Esse processo pode se repetir várias vezes se você tiver uma hierarquia profunda de delegação, mas eventualmente resultar em uma resposta de consulta com o sinalizador "resposta autoritativa" definido .

É importante observar que o resolvedor (geralmente, espero) não tentará detalhar o nome do host que está sendo resolvido para perguntar sobre ele, peça por peça, mas simplesmente o enviará na íntegra para o "melhor" servidor que ele conhece. Como o servidor de nomes autoritativo médio na Internet não é autoritativo para a grande maioria dos nomes DNS válidos, a resposta será uma resposta de delegação não autoritativa apontando para outro servidor DNS.

Agora, um servidor não precisa ser nomeado nos registros de delegação ou autoridade em qualquer lugar para ser autoritário para uma zona. Considere, por exemplo, o caso de um servidor mestre privado; nesse caso, existe um servidor DNS autoritativo do qual apenas os administradores dos servidores DNS escravos da zona estão cientes. Um servidor DNS é autoritário para uma zona se, através de algum mecanismo, em sua opinião, tiver um conhecimento completo e preciso da zona em questão. Um servidor DNS normalmente autoritativo pode, por exemplo, se tornar não autoritativo se os servidores principais configurados não puderem ser alcançados dentro do prazo definido como o tempo de expiração no registro SOA.

Somente respostas autorizadas devem ser consideradas respostas de consulta adequadas; tudo o resto é uma delegação ou algum tipo de erro. Uma delegação para um servidor não autoritativo é denominada delegação "coxa" e significa que o resolvedor precisa voltar uma etapa e tentar outro servidor DNS nomeado. Se não houver servidores de nomes acessíveis autoritativos na delegação, a resolução de nomes falhará (caso contrário, será apenas mais lento que o normal).

Isso tudo é importante porque dados não autoritativos não devem ser armazenados em cache . Como poderia ser, já que o servidor não autoritativo não tem a imagem completa? Portanto, o servidor autoritário deve, por sua própria vontade, responder à pergunta "quem deve ser autoritário e para quê?". Essa é a informação fornecida pelos registros NS na zona.

Existem vários casos extremos nos quais isso pode realmente fazer uma diferença séria, principalmente centrada em vários rótulos de nomes de host dentro de uma única zona (provavelmente bastante comum, por exemplo, com zonas DNS reversas, principalmente para grandes intervalos de IP dinâmicos) ou quando a lista de servidores de nomes difere entre a zona pai e a zona em questão (o que provavelmente é um erro, mas também pode ser feito intencionalmente).

Você pode ver como isso funciona um pouco mais detalhadamente usando dige seus +norec(não solicite recursão) e @recursos do especificador de servidor. A seguir, é apresentada uma ilustração de como funciona um servidor DNS de resolução real. Consulta para o (s) registro (s) A para unix.stackexchange.cominiciar, por exemplo a.root-servers.net:

$ dig unix.stackexchange.com. A @a.root-servers.net. +norec

Observe atentamente as flagscontagens, bem como por seção. qré resposta de consulta e aaé resposta autoritativa. Observe que você só é delegado nos comservidores. Siga manualmente essa delegação (na vida real, um resolvedor recursivo usaria o endereço IP da seção adicional, se fornecido, ou iniciaria uma resolução de nome separada de um dos servidores de nome nomeado, se nenhum IP for fornecido na resposta da delegação, mas pule essa parte e volte ao resolvedor normal do sistema operacional para uma breve descrição do exemplo):

$ dig unix.stackexchange.com. A @a.gtld-servers.net. +norec

Agora você vê que stackexchange.comestá delegado a (entre outros) ns1.serverfault.come ainda não está obtendo uma resposta autorizada. Novamente siga a delegação:

$ dig unix.stackexchange.com. A @ns1.serverfault.com. +norec
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35713
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;unix.stackexchange.com. IN A

;; ANSWER SECTION:
unix.stackexchange.com. 300 IN A 198.252.206.16

Bingo! Temos uma resposta, porque o aasinalizador está definido e, por acaso, contém um endereço IP exatamente como esperávamos encontrar. Como um aparte, vale a pena notar que, pelo menos no momento em que escrevi esta postagem, as listas de servidores de nomes de autoridade delegada e listada diferem, mostrando que os dois não precisam ser idênticos. O que eu exemplifiquei acima é basicamente o trabalho realizado por qualquer resolvedor, exceto que qualquer resolvedor prático também armazenará respostas em cache ao longo do caminho, para que não precise acessar os servidores raiz todas as vezes.

Como você pode ver no exemplo acima, os registros de delegação e cola servem a um propósito distinto dos registros de autoridade e endereço na própria zona.

Um servidor de nomes com armazenamento em cache e resolução também geralmente faz algumas verificações de integridade nos dados retornados para proteger contra envenenamento de cache. Por exemplo, ele pode se recusar a armazenar em cache uma resposta nomeando os servidores autoritativos a compartir de uma fonte diferente da que já foi nomeada por uma zona pai como delegada para com. Os detalhes dependem do servidor, mas a intenção é armazenar em cache o máximo possível, sem abrir a porta do celeiro, permitindo que qualquer servidor de nomes aleatórios na Internet substitua os registros de delegação por qualquer coisa que não esteja oficialmente sob sua "jurisdição".

O registro .com é o "registro de cola" que tem a localização dos seus servidores de nomes como um endereço IP. O resolvedor não tem como saber a "identidade" do seu servidor DNS, portanto, usa o registro NS para garantir que os números correspondam.

Solicitação de DNS -> registro .com (ip é xxxx) -> DNS (NS xxxx) corresponde, resolva.

Se eles não corresponderem ou existirem, será uma resposta não autorizada para o domínio.