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

Normalmente, os registros de cola não estão disponíveis se um domínio e seu servidor de nomes não compartilham um TLD e tecnicamente não são necessários se eles não compartilham o mesmo domínio de segundo nível, o que pode levar a 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 do que apenas essas duas.

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

Se xyz.comusos servidor de nomes ns1.xyz.info,
e xyz.infousos de servidor de nomes ns1.xyz.co,
e xyz.cousos de servidor de nomes ns1.xyz.cc,
e xyz.ccusos nameserver ns1.xyz.co.uk, ... e assim por diante

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

Presumivelmente, existe um limite prático - o BIND só deve estar disposto a atravessar tantos links, caso contrário, há o potencial de 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 obrigado a prosseguir?

domain-name-system rfc

— tylerl
fonte

A seção "quantidade limitada de trabalho" em tools.ietf.org/html/rfc1035#section-7.1 é o que me vem à mente. Não é realmente específico quanto ao limite, mas não estou ciente de que existe alguma regra definitiva sobre isso.

— Håkan Lindqvist

Além disso, você pode elaborar um cenário real em que prevê que isso é um problema (parece bastante improvável na prática) ou é uma questão de natureza puramente acadêmica?

— Håkan Lindqvist

@ HåkanLindqvist Na verdade, estou criando uma ferramenta que procura problemas nas configurações de DNS. Este é um dos problemas a procurar. A questão é: até que ponto o sistema deve recuar para procurar mais problemas antes de desistir.

— tylerl

@tylerl Você pode dar uma olhada em github.com/dotse/dnscheck .

— 21714 Jenny D

@ JennyD sim, existem vários projetos por aí assim. Mas estou construindo um que, com sorte, dê mais detalhes e seja mais fácil de entender. Mas obrigado por apontar isso.

— tylerl

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

Nesse caso, o seu resolvedor local primeiro solicitará 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 geralmente fornece 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 afirmaçã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 é verdadeiro. No entanto, depende dos dados fornecidos pelo registrador para o domínio, e suas políticas variam. Alguns exigem que o IP seja especificado. Alguns deixam isso para o proprietário do domínio. Acho que me 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 seja verdade nessa parte do espaço do 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 Glue, mas às vezes a capacidade de especificar um servidor DNS por nome sem prender o IP é vista como uma flexibilidade, e muitos proprietários de domínio não entendem o problema de desempenho que isso cria.

Se você está fornecendo uma ferramenta de relatório de DNS, é realmente o limite absoluto para essa configuração incorreta em que você está interessado? Certamente, é mais importante que você relate os registros de cola ausentes como um aviso, se houver um problema desse registro. Você provavelmente deseja rastrear pelo menos alguns indícios indiretos, como você fornece (e relata seus registros de cola ausentes), mas deve haver alguns limites sobre até que ponto você deve seguir isso. Eu ficaria muito feliz se uma ferramenta de relatório de DNS avisasse os três primeiros, mais ou menos, porque eu realmente estaria interessado em adicionar os registros de cola ao meu domínio ou mudar o provedor de DNS para o domínio para um que seja mais competente.

Eu duvido da sua abordagem DOS proposta no BIND, pois o BIND armazenará em cache as informações coletadas sobre a localização dos servidores de nomes. Um invasor teria que configurar muitos domínios sem cola e, em seguida, fazer muitas perguntas 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.

— mc0e
fonte

.com e .net são ambos verisign. Eles são a exceção. en.m.wikipedia.org/wiki/Verisign

— tylerl

As 'exceções' parecem abranger a maioria dos DPNs com os quais trabalhei, mas sim, certamente existem domínios em que os registros de cola não estão presentes.

— Mc0e