Existe um limite oficial para a indireção do servidor de nomes?

Question

Os registros de cola geralmente não estarão disponíveis se um domínio e seu servidor de nomes não compartilharem um TLD e tecnicamente não forem necessários se não compartilharem o mesmo domínio de segundo nível, o que poderia levar para etapas extras para resolver um domínio. O resolvedor deve primeiro procurar o endereço do servidor de nomes antes de encontrar o endereço do seu domínio. Mas, teoricamente, você poderia adicionar mais etapas lá do que apenas as duas.

A questão aqui é: por quanto tempo essa cadeia pode ser ?

se xyz.com usar o nameserver ns1.xyz.info ,
 e xyz.info usa o nameserver ns1.xyz.co ,
 e xyz.co usa o nameserver ns1.xyz.cc ,
 e xyz.cc usa o nameserver ns1.xyz.co.uk , ... e assim por diante

... você pode acabar com uma cadeia muito longa para o resolvedor resolver antes que possa resolver o nome que você queria originalmente.

Presumivelmente, existe um limite prático - o BIND só deve estar disposto a percorrer tantos links, caso contrário, existe o potencial para uma negação de serviço. Mas existe um limite oficial? Algum número de etapas além das quais o resolvedor não é oficialmente requisitado para prosseguir?

    

Answer 1

if xyz.com uses nameserver ns1.xyz.info,

Nesse caso, seu resolvedor local perguntará primeiro aos servidores .com (por exemplo, a.gtld-servers.net) onde encontrar os servidores de nomes para o domínio xyz.com. O servidor de domínio .com normalmente fornecerá registros de cola para os endereços IP dos servidores de nomes para o domínio xyz.com.

por exemplo:

$ dig  gmail.com @a.gtld-servers.net 

; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1.1 <<>> gmail.com @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46893
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 5
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;gmail.com.         IN  A

;; AUTHORITY SECTION:
gmail.com.      172800  IN  NS  ns2.google.com.
gmail.com.      172800  IN  NS  ns1.google.com.
gmail.com.      172800  IN  NS  ns3.google.com.
gmail.com.      172800  IN  NS  ns4.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.     172800  IN  A   216.239.34.10
ns1.google.com.     172800  IN  A   216.239.32.10
ns3.google.com.     172800  IN  A   216.239.36.10
ns4.google.com.     172800  IN  A   216.239.38.10

;; Query time: 375 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Thu Jul 10 01:10:57 EST 2014
;; MSG SIZE  rcvd: 181

Na minha experiência, sua declaração de que "os registros de cola geralmente não estão disponíveis se um domínio e seu servidor de nomes não compartilham um TLD" simplesmente não é verdade. No entanto, ela depende dos dados fornecidos pelo registrador para o domínio e suas políticas variam. Alguns exigem que o IP seja especificado. Alguns deixam para o proprietário do domínio. Acho que lembro de um na Austrália que não os apoia. Se o número de registradores que lidam com o domínio do seu país for pequeno, talvez isso possa ser verdade dentro dessa parte do espaço de domínio, mas para a rede como um todo isso é atípico.

Certamente é uma boa prática para os proprietários de domínio fornecerem registros de colagem, mas às vezes a capacidade de especificar um servidor DNS pelo nome sem restringir o IP é considerada uma flexibilidade, e muitos proprietários de domínio não entendem o problema de desempenho .

Se você está fornecendo uma ferramenta de relatório de DNS, é realmente o limite absoluto de tal configuração incorreta que você está interessado? Certamente é mais para o ponto de você relatar os registros de cola em falta como um aviso se mesmo um tal problema de registro de cola ausente apresentar. Você provavelmente vai querer rastrear pelo menos algumas indirecções como você fornece (e reportar seus registros de cola perdidos), mas deve haver alguns limites sobre até onde você deve seguir isso. Eu ficaria muito feliz se uma ferramenta de relatórios de DNS alertasse sobre os 3 primeiros, mais ou menos, já que eu realmente estaria interessada em adicionar os registros de cola ao meu domínio ou mudar o provedor de DNS do domínio para um mais competente.

Tenho dúvidas sobre sua abordagem proposta pelo DOS no BIND, já que o BIND armazenará em cache as informações coletadas sobre o local dos servidores de nomes. Um invasor teria que configurar muitos domínios sem cola e fazer várias consultas sobre eles. O custo de configurar domínios que provavelmente seriam cancelados pelo registrador após o uso provavelmente tornará isso desagradável para um invasor.