A.gtld-servers.net tem uma lista de todos os domínios .com?

Quando o faço dig @a.gtld-servers.net example.com, ele retorna rapidamente os servidores de nomes example.come os endereços IP desses servidores (registros de cola).

Isso significa a.gtld-servers.net(e *.gtld-servers.net) tem um registro de todos os .comdomínios localmente? Eles respondem muito rapidamente, então não acho que eles mesmos façam uma nova consulta. Da mesma forma, uma solicitação para example.comservidores de nomes não me redireciona para domains.starting.with.e.gtld-servers.netnada.

Sei que a.gtld-servers.netprovavelmente há várias máquinas e que estou sendo roteado para a mais próxima de mim (por meio da nova tecnologia de um IP com várias máquinas), mas isso apenas significaria que várias outras máquinas têm todos os .comdomínios.

EDIT: Obrigado a todos que responderam! Pergunta de acompanhamento: se alguém "invadir" uma dessas máquinas, não conseguirá obter uma lista de todos os .comdomínios? Parece informações úteis, a menos que já estejam disponíveis em algum lugar de graça? Sei que as informações do domínio são públicas, mas ainda é difícil obter em massa. Eu acho *.gtld-servers.netque não suporta transferências de zona (embora .eduos servidores de nomes suportassem, pelo menos alguns anos atrás).

NOTA: Eu sei que example.com não é um domínio real - basta substituí-lo por qualquer outro domínio .com acima (eu originalmente tinha xyz.com, mas alguém o editou corretamente para evitar o uso de um nome de domínio real).

Sim, os "x.gtld-servers.net" são os servidores com autoridade para o domínio de nível superior "com", portanto, eles têm todos os "indicadores" para os domínios .com. Você pode ver os servidores de nomes para o TLD executando

dig -t ns com
dig -t ns us
dig -t ns dk
dig -t ns aero

Faça uma consulta para o próprio domínio - dig @a.gtld-servers.net com.- e procure o sinalizador "resposta autorizada":

snowflake ~ $ dig @a.gtld-servers.net com | grep flags
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
             ^^

Você já recebeu uma resposta há muito tempo, mas acho que podemos ser mais precisos e você tem uma pergunta de acompanhamento, que deveria ter sido outra pergunta de fato.

Então, vamos voltar do começo.

Se você consultar os servidores raiz para aprender sobre a .COMdelegação (observe que tudo a seguir se aplica da mesma maneira, .NETpois os dois são tratados pelo mesmo registro), você obtém esta resposta:

$ dig @a.root-servers.net com. NS +noall +auth

; <<>> DiG 9.12.0 <<>> @a.root-servers.net com. NS +noall +auth
; (1 server found)
;; global options: +cmd
com.            172800 IN NS e.gtld-servers.net.
com.            172800 IN NS b.gtld-servers.net.
com.            172800 IN NS j.gtld-servers.net.
com.            172800 IN NS m.gtld-servers.net.
com.            172800 IN NS i.gtld-servers.net.
com.            172800 IN NS f.gtld-servers.net.
com.            172800 IN NS a.gtld-servers.net.
com.            172800 IN NS g.gtld-servers.net.
com.            172800 IN NS h.gtld-servers.net.
com.            172800 IN NS l.gtld-servers.net.
com.            172800 IN NS k.gtld-servers.net.
com.            172800 IN NS c.gtld-servers.net.
com.            172800 IN NS d.gtld-servers.net.

Portanto, em resumo, qualquer um desses servidores de nomes é autoritário .COMe todos eles têm os mesmos dados (para que você possa ampliar sua pergunta, não a.gtld-servers.neté de forma alguma especial, tudo a seguir será aplicado a qualquer um desses servidores de nomes).

Quando você consulta esses servidores de nomes em busca de qualquer .COM/.NETnome de domínio, eles precisam responder com autoridade com os servidores de nomes com autoridade para o nome de domínio que você está solicitando.

Portanto, por definição, "Isso significa que a.gtld-servers.net (e * .gtld-servers.net) tem um registro de todos os domínios .com localmente?", Mas significa exatamente isso! Com algumas ressalvas em torno de "tudo", abordadas mais abaixo.

Observe que você fala sobre registros de cola, este é um caso específico e não o mais frequente. Normalmente, uma solicitação de domínio em qualquer um dos servidores de nome acima apenas devolve um ou mais registros NS.

Vamos reservar um tempo para abordar os outros pontos menores do seu texto:

Eles respondem muito rapidamente, então não acho que eles mesmos façam uma nova consulta.

Um servidor de nomes autoritativo, por definição, possui os dados necessários para responder às consultas, sem precisar confiar em nenhum recurso externo; caso contrário, ele não é autoritativo.

Quanto à velocidade, isso é parcialmente subjetivo e altamente dependente do que e como você testa, mas existem vários fatores: por padrão, o DNS usa UDP que é mais leve que o TCP, portanto, mais rápido, e esses servidores de nomes são anycasted, o que significa que, com alguma sorte, você sempre tem um "perto" de você.

Eu percebo que a.gtld-servers.net é provavelmente várias máquinas

Você pode remover o "provavelmente" :-) Esses servidores de nomes recebem tantas consultas que uma única caixa nunca será capaz de suportar.

Se você acessar https://stat.ripe.net/192.5.6.30#tabId=routing , verá muitas informações difíceis de digerir, mas basicamente vendo que esse único IP de a.gtld-servers.net(na verdade, o bloco em que é) é anunciado por vários AS todos controlados por uma empresa, que é um forte indicador de anycasting, que funciona lindamente para a maior parte do DNS.

Se você for para http://www.root-servers.org/, poderá aprender mais. Isso está relacionado aos servidores de nomes raiz, não .COMaos mais, mas tecnicamente é exatamente a mesma coisa. Você pode descobrir, por exemplo, que os 13 servidores raiz são gerenciados por 12 organizações diferentes em 930 instâncias (uma instância não é apenas um servidor, é um local, um "ponto de presença" em que o operador tem um "nó" que normalmente é equipamento de roteamento, vários servidores na configuração de balanceamento de carga / failover, alguns recursos de monitoramento / mãos remotas, etc.). Fpor exemplo, está em 222 lugares.

e que estou sendo roteado para o mais próximo de mim (por meio da nova tecnologia de um IP com várias máquinas), mas isso apenas significaria que várias outras máquinas têm todos os domínios .com.

Sim, muitas máquinas têm a lista de todos .COMos nomes de domínio. Mas primeiro uma precisão: nesses servidores de nomes, você obterá a lista de todos os servidores de nomes para todos os nomes de domínio .COM ... o que significa que, para nomes de domínio não delegados, você não os encontrará aqui. Isso pode acontecer em vários casos:

1. ao registrar um nome de domínio, você pode optar por não definir servidores de nomes ou removê-los mais tarde.
2. seu registrador, por exemplo, devido a uma disputa de pagamento, pode adicionar o status clientHoldao seu nome de domínio, o que faz com que ele desapareça do DNS
3. o registro pode colocar o domínio serverHoldpor qualquer motivo.

(consulte https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en, se você quiser saber mais sobre esses status e outros).

Dependendo de como você define "todos" e o que você faria com esses dados, talvez você não obtenha absolutamente todos eles.

Em todos os casos acima, o domínio não aparecerá nos servidores DNS do registro, mas aparecerá quando você fizer uma consulta whois. Portanto, os servidores whois (novamente, nem uma única caixa) também terão ... a lista de todos os nomes de domínio .COM e ainda mais dados do que nos servidores de nomes porque:

1. você realmente possui todos os nomes de domínio, incluindo aqueles que não estão resolvendo e, portanto, não estão em servidores de registro
2. whois fornece muito mais informações, como dados de contato

E ainda são apenas os serviços de registro voltados ao público, que têm, de alguma forma ou parte, a lista (ou parte dela) de nomes de domínio.

Quanto ao seu acompanhamento:

Pergunta de acompanhamento: se alguém "invadir" uma dessas máquinas, não conseguirá obter uma lista de todos os domínios .com?

Tecnicamente sim. Mas:

1. Esse certamente não é o alvo mais fácil que você encontrará on-line
2. E, neste caso específico, os dados já estão disponíveis gratuitamente.

.COMé um gTLD e, como tal, está sob contrato com a ICANN. A ICANN determina que todos os registros de gTLDs publiquem seus arquivos de zona (que é basicamente o que os servidores de nomes usam, para que os registros NS e as colas A / AAAA), pelo menos uma vez por dia, e o acesso seja gratuito para qualquer pessoa, desde que você assine um contrato para garantir que você não reutilize esses dados para fins "ruins" (como republicá-los você mesmo).

Veja https://czds.icann.org/en para obter todos os detalhes sobre isso. Isso pode lhe dar acesso a centenas de arquivos de zona de gTLDs.

Observe que se sua pergunta for estendida para "se alguém invadir uma dessas máquinas e alterar o conteúdo que adiciona ou remove nomes de domínio .COM ...", podemos responder rapidamente com:

1. as alterações não serão vistas em todo o mundo, já que você abre apenas uma caixa e existem inúmeros servidores de nomes, primeiro pelo nome e depois por anycasting
2. O DNSSEC pode fazer com que suas alterações sejam exibidas como erros e, portanto, serão detectadas rapidamente (além de quaisquer contramedidas locais pelo próprio operador, é claro).

Em suma, não é a melhor ideia fazer isso para mexer com .COMnomes de domínio, e existem outras maneiras.

Sei que as informações do domínio são públicas, mas ainda é difícil obter em massa.

Veja acima o programa da ICANN. Quanto aos ccTLDs, a situação varia, mas com mais freqüência eles não dão acesso ao seu arquivo de zona e não em tempo real.

Às vezes, você pode acessá-lo após algum tempo, por exemplo, através de movimentos de "dados abertos". Um exemplo: https://opendata.afnic.fr/en/products-and-services/services/opendata-en.html para .FRnomes de domínio.

Acho que o * .gtld-servers.net não suporta transferências de zona (apesar dos servidores de nomes do .edu, há pelo menos alguns anos).

Fácil de testar:

$ for ns in $(dig NS . +noall +ans | grep 'IN NS' | awk '{print $5}') ; do echo $ns ; dig @$ns com. AXFR; done
c.root-servers.net.

; <<>> DiG 9.12.0 <<>> @c.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
m.root-servers.net.

; <<>> DiG 9.12.0 <<>> @m.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
i.root-servers.net.

; <<>> DiG 9.12.0 <<>> @i.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
e.root-servers.net.

; <<>> DiG 9.12.0 <<>> @e.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
j.root-servers.net.

; <<>> DiG 9.12.0 <<>> @j.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
l.root-servers.net.

; <<>> DiG 9.12.0 <<>> @l.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
g.root-servers.net.

; <<>> DiG 9.12.0 <<>> @g.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
k.root-servers.net.

; <<>> DiG 9.12.0 <<>> @k.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
b.root-servers.net.

; <<>> DiG 9.12.0 <<>> @b.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
h.root-servers.net.

; <<>> DiG 9.12.0 <<>> @h.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
d.root-servers.net.

; <<>> DiG 9.12.0 <<>> @d.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
;; QUERY SIZE: 44

;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
;; QUERY SIZE: 44

;; connection timed out; no servers could be reached
;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
a.root-servers.net.

; <<>> DiG 9.12.0 <<>> @a.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
f.root-servers.net.

; <<>> DiG 9.12.0 <<>> @f.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.

Não, no momento, nenhum .COMservidor de nomes autoritativo aceita consultas AXFR. Mas isso não é necessariamente o mesmo em todos os lugares. Se você consultar o f.root-servers.netservidor de nomes, poderá fazer uma consulta AXFR para publicar todos os TLDs. Alguns outros TLDs também podem permitir isso.

Observe que existem "muitas" recomendações contra a permissão de consultas públicas do AXFR. O fato é que elas são enormes respostas por definição e podem sobrecarregar um servidor se repetidas, isso é verdade. On pode argumentar incessantemente sobre por que / se o público precisa dessas informações. Foi mais usado no início do DNS para copiar zonas entre servidores de nomes (existem alternativas muito melhores agora). Portanto, o AXFR geralmente está desativado ... exceto que, se você faz o DNSSEC ao mesmo tempo, de alguma maneira específica (que é a variante NSEC e não a NSEC3), é fácil percorrer as consultas DNS padrão e sem o AXFR, todas as suas zona e reconstrua o arquivo de zona. Existem ferramentas para fazer isso.

Observe também que vários fornecedores on-line venderão arquivos de zona e / ou lista de todos os nomes de domínio para muitos TLDs adquiridos por vários meios (uma idéia entre outras: você usa arquivos de zona abertos, como .COM, e para o TLD .examplevocê consulta um por um todo o nome que você encontrou .COM, que pode lhe dar algumas idéias, além de, é claro, caminhar no dicionário com base nos idiomas mais usados ​​no TLD pesquisado).