Quando o TLD com registros de cola para os servidores de nomes salva as pesquisas de DNS?

Question

Meu entendimento é que, se eu tiver os servidores de nomes para example1.com e example2.us, defina como ns1.example2.us e ns2.example2.us, procurando por www.example1.com:

• procure example1.com para encontrar seus servidores de nomes, não obtendo nenhum registro de cola (o registro .com não fornecerá cola para domínios .us)
• procure ns1.example2.us e ns2.example2.us ( necessariamente ambos? ), cada um dos quais:
  • query example2.us, produzindo registros de cola para ns1.example2.us e ns2.example2.us
  • aparentemente consulta ns1.example2.us e / ou ns2.example2.us para obter o (s) endereço (s) para ns1.example2.us e / ou ns2.example2.us ( está correto? esta pareceu ser a minha experiência)
• consulta ns1.example2.us e / ou ns2.example2.us para obter o endereço de www.example1.com

Se, em vez disso, tivermos os servidores de nomes para o exemplo1.com e o exemplo2.com definidos para ns1.exemplo2.com e ns2.exemplo2.com, a pesquisa de www.example1.com será:

• procure example1.com para encontrar seus servidores de nomes, gerando registros de cola para ns1.example2.com e ns2.example2.com
• pesquise ns1.example2.com e / ou ns2.example2.com para obter o endereço de www.example1.com

Eu corrijo que, nesse caso, há apenas estas duas etapas na pesquisa? Especificamente, parece que estou experimentando um volume de pesquisas em example2.com Isso sugere que as pesquisas de example1.com nem sempre estão usando os registros de cola, resultando em uma etapa extra em que ns1.example2.com e / ou ns2.example2.com são consultados consultando ns1.example2.com e / ou ns2. example2.com.

( editado para destacar minhas pequenas questões enterradas no primeiro exemplo e tentar esclarecer minha pergunta principal no final.)

Talvez alguns diagramas ajudem, já que acho que estou explicando isso mal. Aqui está o meu entendimento sobre o que deve acontecer ao pesquisar www.example.com se os servidores de nomes do example.com forem ns1.host.us e ns2.host.us:

Aterceiraetapadepesquisapareceestaracontecendoquaseuniversalmente,masnãofazsentidoparamim.Esseterceiropassorealmentedeveestarlá?

Aquiestáomeuentendimentosobreoquedeveacontecerquandoprocurarporwww.example.comseosservidoresdenomesdaexample.comforemns1.host.comens2.host.com:

O meu entendimento deste caso está correto?

Eis o que acho que pode estar acontecendo com cerca de 1/3 das pesquisas de www.example.com com os servidores de nomes ns1.host.com e ns2.host.com (com base no número e no tempo de consultas aos servidores de nomes para vários domínios):

Isso é realmente possível e / ou representa um cliente mal comportado?

    

Answer 1

Para adicionar a resposta de Mit. A melhor prática é somente usar o Glue Records para resolver essas dependências circulares. Consulte a seção 2.3 do RFC 1912: link

Para citar:

Some people get in the bad habit of putting in a glue record whenever
they add an NS record "just to make sure". Having duplicate glue
records in your zone files just makes it harder when a nameserver moves to a new IP address, or is removed. You'll spend hours trying to figure out why random people still see the old IP address for some host, because someone forgot to change or remove a glue record in some other file. Newer BIND versions will ignore these extra glue records in local zone files.

Observe esse último bit se você estiver usando o BIND. Além disso, acho que a maioria dos clientes DNS ignorará os registros de cola extra-domínio, o que explicaria o que você está vendo.

Editar para acompanhar o comentário.

Com os registros de cola de TLD, você normalmente os forneceria ao seu registrador, mas, do contrário, as mesmas regras se aplicam. Eu executo domínios em .co.uk e .com . Eu também tenho servidores de nomes em ambos os TLDs que são autoritativos para todos os meus domínios.

Se eu executar dig ns co.uk e dig ns com , posso ver a grande quantidade de servidores com autoridade para esses TLDs. Se eu escolher um desses .com servidores e dig @<server> ns <mydomain>.com , ele retornará todos os quatro servidores de nomes para o meu domínio, mas apenas os registros de cola dos servidores de nomes no mesmo TLD (fornecido como ADICIONAIS), que é o que você está descrevendo.

Se eu executar dig @<co.uk server> <myotherdomain>.co.uk , novamente terei os quatro servidores de nome, mas desta vez acompanhados pelos registros de colagem dos três deles no .co.uk TLD.

Isto é tudo como deveria ser. Se todos os seus servidores de nomes estiverem em .us TLD, os clientes que estiverem procurando seus .com domínios serão informados dos nomes de domínio de seus servidores de nomes pelos .com servers; então os clientes realizarão outra consulta nos .us servidores para encontrar seus IPs. Essa viagem extra de ida e volta pode parecer ineficiente, mas só precisa acontecer uma vez por período TTL por cliente. (normalmente 48 horas para registros de TLDs).

(Desculpas se você já conhece todas as opções acima). Para responder a pergunta original. Os registros de cola não se destinam a salvar pesquisas de DNS. Eles são necessários para evitar loops infinitos.

Editar 2

Desculpem o assunto. Eu vejo o que você quer dizer agora (bons diagramas, a propósito).

Meu entendimento de como os clientes devem se comportar é que, se alguém tem a oportunidade de obter RRs com autoridade, então deveria; mas neste caso, o cliente está pedindo ao servidor de nomes por seus registros próprios A, o que é inútil, já que o Glue é aqueles registros A.

Estou alcançando os limites do meu conhecimento aqui, mas não consigo imaginar nenhuma situação em que um cliente precise fazer isso. Eu estou supondo aqui, mas talvez a implementação do cliente precise verificar se o servidor é definitivamente autoritativo para o ns_.host.us, mesmo quando isso significa o que parece ser uma ida e volta sem sentido.

Tente um dig +trace www.example.com para ver se ele faz a mesma coisa. Eu ficaria curioso para ver se ele faz a mesma pesquisa se a consulta original fosse para um nome _.host.us também.

    

Answer 2

Os servidores de nomes nas delegações são identificados por nome, em vez de por endereço IP. Isso significa que um servidor de nomes de resolução deve emitir outra solicitação de DNS para descobrir o endereço IP do servidor para o qual foi encaminhado. Se o nome fornecido na delegação for um subdomínio do domínio para o qual a delegação está sendo fornecida, haverá uma dependência circular. Nesse caso, o servidor de nomes que fornece a delegação também deve fornecer um ou mais endereços IP para o servidor de nomes autoritativo mencionado na delegação. Esta informação é chamada de cola. O servidor de nomes de delegação fornece essa cola na forma de registros na seção adicional da resposta do DNS e fornece a delegação na seção de resposta da resposta.

Por exemplo, se o servidor de nomes autoritativo para example.org for ns1.example.org, um computador que tente resolver www.example.org primeiro resolve ns1.example.org. Como ns1 está contido em example.org, isso requer a resolução de example.org primeiro, que apresenta uma dependência circular. Para quebrar a dependência, o servidor de nomes para o domínio de nível superior da organização inclui cola junto com a delegação para example.org. Os registros de cola são registros de endereço que fornecem endereços IP para ns1.example.org. O resolvedor usa um ou mais desses endereços IP para consultar um dos servidores autoritativos do domínio, o que permite concluir a consulta DNS. Isso pode corrigir o problema.

    

Answer 3

O Glue destina-se a fazer bootstrap de consultas que, de outra forma, não seriam resolvidas. Imagine sem cola:

1. query root para www.example1.com, obtenha referência para os namesevers com.
2. consulta com nameserver para www.example1.com, obtenha referência para ns1.example.com, o servidor de nomes para example1.com.
3. Ops, não temos o IP para ns1.example1.com. consulta com nameserver para ns1.example.com.
4. goto 3.

O servidor de nomes com deve retornar um registro A para ns1.example.com ou você nunca chegará lá.

Você ainda pode se deparar com problemas com delegações de bailiwick, já que servidores de nomes confiáveis não costumam obter registros de cola para eles. Por exemplo:

1. consulta com o nameserver para ns1.example1.com, obtenha resposta de ns1.example1.us
2. consulte-nos servidor de nomes para ns1.exemplo1.us, obtenha resposta de ns1.exemplo.com
3. goto 1

Opa - nem o servidor de nomes com nem o servidor de nomes dos EUA devolverão cola para fora das referências de domicílio. O DJB tem alguns exemplos mais detalhados.

De qualquer forma, a cola não é um atalho, mas um mecanismo para evitar loops. O armazenamento em cache fornece seu mecanismo para salvar pesquisas.