Introdução
Os ‘Root-Servers‘ são servidores distribuídos globalmente e que são vitais para o funcionamento do serviço de DNS. Eles operam a ‘Root Zone‘ ou Zona Raiz, que é responsável por responder pelas requisições dos TLDs – Top Level Domains ou domínios de topo.
Você já parou para pensar no que ocorre desde o momento em que você digita uma URL em seu navegador, por exemplo: http://www.ipok.com.br, até o momento em que o conteúdo do site é carregado em sua tela?
Entre outras coisas, seu navegador consulta um servidor de DNS recursivo para obter o endereço IP do servidor web deste domínio, conecta-se na porta 80 deste servidor, envia um requisição HTTP, recebe a resposta e renderiza o conteúdo em sua tela.
Relembrando o que já vimos nos dois artigos anteriores sobre o DIG (parte 1 e parte 2), o que o navegador faz é executar uma query de dns, solicitando o registro do tipo ‘A’ para o nome ‘ipok.com.br’. Como resposta, ele recebe o endereço “177.66.168.145”.
Um pouco de história….
Nos primórdios da Internet, antes da criação do DNS, o mapeamento entre domínios e IPs era centralizado e mantido pela InterNIC, através de um único arquivo chamado HOSTS.TXT. Este arquivo, quando alterado, era transferido por ftp para todos os outros nós da rede.
A RFC 1034 descreve alguns problemas decorrentes desta forma de gerenciamento:
- Os computadores de grande porte (baseados em ‘time-sharing’), usados até então, começaram a dar lugar a redes locais compostas por ‘workstations’.
- Algumas organizações já viam a necessidade de administrar suas próprias configurações de domínios e endereços IP. Porém, precisavam aguardar as publicações do arquivo HOSTS.TXT da InterNIC.
- A largura de banda necessária para manter estas atualizações tornava-se maior, conforme mais nós entravam em operação.
- As aplicações estavam se tornando mais sofisticadas e demandavam um serviço de gerenciamento de nomes mais generalista e robusto.
Diversas ideias e modelos foram debatidos (e assim, surgindo várias RFCs), porém todas acabavam versando sobre algum tipo de estrutura distribuída e hierárquica de nomes, valendo-se do ‘.’ para demarcar os diferentes níveis nesta hierarquia.
O DNS ou “Domain Name System” pode ser entendido como um grade catálogo de informações ou banco de dados hierárquico e distribuído. É ele quem torna possível, por exemplo, converter um domínio para o seu respectivo endereço IP.
Sua estrutura é organizada no formado de uma árvore invertida, com o nó do topo chamado de ‘Root’ ou ‘Raiz’.
Um domínio representa a posição de um nó dentro desta estrutura hierárquica. Ele é composto por um conjunto de nomes únicos, e subindo dos nós mais específicos (na parte de baixo da árvore) em direção ao nó raiz (no topo da estrutura), sempre separados pelo caracter “.” – que indica uma mudança de nível na hierarquia. Abaixo, um exemplo da formação do domínio “ipok.com.br”.
Como ocorre uma resolução de nome
No exemplo citado no começo deste artigo, quando seu navegador precisa resolver um domínio, ele envia esta solicitação ao DNS recursivo configurado em seu computador. Pode ser um endereço fornecido pelo seu provedor de conexão, um servidor localizado em sua rede corporativa, um software de DNS recursivo instalado em seu próprio computador ou algum serviço de terceiros, como é o exemplo do Google DNS (8.8.8.8).
Pois bem, o servidor recursivo vai receber esta solicitação e só tem duas alternativas. A primeira é responder diretamente com os dados que ele possa ter armazenado em seu cache local. A segunda alternativa é ele não ter esse dado armazenado em seu cache, e aí ele precisa iniciar a busca pelo recurso em outros servidores. Porém, uma questão vital precisa ser resolvida: por onde começar essa busca?
É aí que entram os “Root-Servers“…
Enfim, os Root-Servers
Também chamados de ‘Servidores Raiz’, eles são o conjunto de servidores espalhados globalmente e os responsáveis pela autoridade da ‘Root Zone‘ ou ‘Zona Raiz’ – que é a tabela com toda a lista dos TLDs – Top Level Domains ou ‘Domínios de Topo’.
Esta tabela contém o próximo nível de delegação na hierarquia de nomes, pois é ela quem guarda a relação de todos os servidores autoritativos para cada um dos TLDs existentes. É esta resposta que permite um servidor de DNS recursivo continuar realizando sucessivas queries até chegar no servidor autoritativo para o domínio procurado.
Genericamente, um TLD pode ser entendido como o último termo a direita de um domínio. Ele pode representar (entre outras possibilidades), um código de país (ccTLD ou country-code Top Level Domain), com o ‘.br’, ‘.ca’, etc. Também podem ser domínios genéricos (gTLD ou generic Top Level Domain), como o ‘.com’, ‘.org’, ‘.edu’, ou, curiosamente, como “.bradesco”. Tente acessar em seu navegador o endereço: “http://banco.bradesco”.
Veja abaixo a resposta quando pesquisamos o TLD “.br”:
$ dig @a.root-servers.net ns br ;; Got answer: ;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 5006 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 9 ;; QUESTION SECTION: ;br. IN NS ;; AUTHORITY SECTION: br. 172800 IN NS f.dns.br. br. 172800 IN NS e.dns.br. br. 172800 IN NS b.dns.br. br. 172800 IN NS c.dns.br. br. 172800 IN NS d.dns.br. br. 172800 IN NS a.dns.br. ;; ADDITIONAL SECTION: f.dns.br. 172800 IN A 200.219.159.10 e.dns.br. 172800 IN A 200.229.248.10 b.dns.br. 172800 IN A 200.189.41.10 c.dns.br. 172800 IN A 200.192.233.10 d.dns.br. 172800 IN A 200.219.154.10 a.dns.br. 172800 IN A 200.160.0.10 ;; Query time: 198 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Sun Jul 24 20:50:44 BRT 2016 ;; MSG SIZE rcvd: 300
Você pode baixar a ‘Root Zone‘, com a lista completa dos TLDs no seguinte endereço: https://www.internic.net/domain/root.zone
Onde estão localizados
Existem 13 conjuntos de servidores globalmente distribuídos. Diversos desses ‘clusters’ operam em modo ‘anycast’, ou seja, o mesmo grupo compartilha um único endereço IP e os pacotes são entregues ao membro mais próximo da origem.
Eles são gerenciados por 12 instituições, entre públicas (como a NASA, Departamento de Defesa Americano), universidades (Maryland e Southern California) e instituições privadas (como a Verisign – que possui gestão de duas destas estruturas). Atualmente, são mais de 300 servidores distribuídos em mais de 30 países dos 6 continentes.
Localização dos e.root-servers.net, sob a gestão da NASA
Localização dos e.root-servers.net, sob a gestão do ISC (Internet Systems Consortium)
Cada um destes grupos de servidores são nomeados utilizando-se uma letra de ‘A’ a ‘M’, seguidos do domínio “root-servers.net”. Assim, temos o a.root-servers.net, b.root-servers.net, etc.
Segue abaixo a lista completa dos servidores e as instituições que os gerenciam.
O quadro acima pode ser encontrado em: http://www.iana.org/domains/root/servers
Alguns deles mantém sites informativos, trazem dados dados históricos (como é o caso do http://a.root-servers.org/), gráficos de uso, métricas, mapas de localização, etc. Faça o teste e acesse: http://e.root-servers.org – esse é o grupo operado pela Nasa. Já o http://a.root-servers.org/ é mantido pela Verisign.
Cada uma das instituições operam de forma independente seus servidores. São elas quem decidem quantos eles serão, em que localidades serão instalados, qual hardware e versão de software utilizado.
Já a gestão dos dados da ‘Root Zone‘, que é sincronizada entre todo os servidores, é de responsabilidade da IANA (Internet Assigned Numbers Authority), que é mantida pelo ICANN (Internet Corporation for Assigned Names and Numbers).
Como um servidor recursivo encontra um ‘Root Server’ ?
Uma vez que os “Root-Servers” estão no topo da hierarquia de domínios, eles não podem ser encontrados quando percorremos a própria hierarquia. Portanto, o software de DNS instalado no servidor recursivo é quem traz a lista dos servidores raiz e de seus respectivos endereços.
O BIND, por exemplo, tem a seguinte configuração para essa finalidade:
zone "." IN { type hint; file "named.ca"; };
O conteúdo deste arquivo é:
$ cat /var/named/named.ca ; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . " ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC ; under anonymous FTP as ; file /domain/named.cache ; on server FTP.INTERNIC.NET ; -OR- RS.INTERNIC.NET ; ; last update: December 01, 2015 ; related version of root zone: 2015120100 ; ; formerly NS.INTERNIC.NET ; . 3600000 NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:ba3e::2:30 ; ; FORMERLY NS1.ISI.EDU ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201 B.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:84::b ; ; FORMERLY C.PSI.NET ; . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 C.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2::c ; ; FORMERLY TERP.UMD.EDU ; . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 199.7.91.13 D.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2d::d ; ; FORMERLY NS.NASA.GOV ; . 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ; ; FORMERLY NS.ISC.ORG ; . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 F.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2f::f ; ; FORMERLY NS.NIC.DDN.MIL ; . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ; ; FORMERLY AOS.ARL.ARMY.MIL ; . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 198.97.190.53 H.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:1::53 ; ; FORMERLY NIC.NORDU.NET ; . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 I.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fe::53 ; ; OPERATED BY VERISIGN, INC. ; . 3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30 J.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:c27::2:30 ; ; OPERATED BY RIPE NCC ; . 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129 K.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fd::1 ; ; OPERATED BY ICANN ; . 3600000 NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42 L.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:3::42 ; ; OPERATED BY WIDE ; . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 M.ROOT-SERVERS.NET. 3600000 AAAA 2001:dc3::35 ; End of file
Uma versão sempre atualizada deste conteúdo pode ser encontrada no seguinte endereço: https://www.internic.net/domain/named.root
Assim, quando um servidor recursivo precisa encontrar um domínio desconhecido por ele (e, portanto, sem informações em seu cache), é daí que ele extrai a lista de “Root-Servers” para iniciar suas pesquisas.
Por hora é isso aí! Em breve falarei mais sobre flags, recursividade, autoridade, etc, etc, etc.
Parabens pelo artigo, muito bom!
Olá Fernando, parabéns pelo artigo.
Muito bom! Excelente iniciativa.
Conteúdo como esse deveriam ser indexados e serem os primeiros a serem achados nas buscas.
Ótima iniciativa e parabéns.
Me tire uma dúvida por favor “Atualmente, são mais de 300 servidores distribuídos em mais de 30 países dos 6 continentes.” Esses 300 servidores são os replicados? Ex: Quantos servidores espalhados pelo mundo replicam diretamente os Root-Servers?
A resposta é 300 servidores?
Olá,
Basicamente, sim. Apesar de 13 agrupamentos de root-servers, fisicamente estamos falando de mais de 300 servidores. Todos eles replicando a zona raiz, que é gerenciada pela IANA.
Abs,
Fernando
Gostei bastante do artigo. Explicou um assunto relativamente complexo com uma didática muito bacana e ainda com um pequeno fundo histórico.
Fiquei com uma dúvida: é possível alguma entidade/empresa se oferecer para gerir um novo conjunto de servidores raiz, por exemplo o n.root-servers.net?
Me vem à mente empresas com alcance global, tais como Akamai, Amazon, Cloudflare. Inclusive o Cloudflare está de certa forma na lista de entidades dos root-servers pois fecharam uma parceria com o ISC e operam em conjunto o f-root > https://blog.cloudflare.com/f-root/
Olá Diego, obrigado pela mensagem.
Dos agrupamentos atuais existem servidores no Brasil. Já quanto a um novo agrupamento, essa é realmente uma boa pergunta. Vou ver o que consigo de informação.
Uma questão que me vem à mente é: Atualizar o named.root. As atualizações dos clients de dns deveriam incluir a nova versão desse arquivo, ou o administrador atualizá-lo manualmente. Talvez a questão política pegue mais que a questão técnica 🙂
Parabéns! Muito bacana o artigo, esclarecedor.
Adicionando mais conhecimento e curiosidade, é possível ter seu próprio root-server.
Não são todos os root-servers que podem ser replicados (b, c, f, g, k), porém há uma RFC (7706, senão me engano) que explica como fazê-lo.
Basicamente consiste em rodar um DNS server autoritativo na loopback (127.x.y.z) do seu server recursivo e usar esse root-server como hint/forwarder do seu recursivo. Sincroniza via AXFR com um dos root-servers replicaváveis.
Todo o procedimento está na RFC.
Uma outra boa prática (BCP) que não vejo o pessoal comentar, é sobre o ASN112.
Que basicamente é ter um DNS autoritativo com respostas para os reversos das zonas privadas (RFC1918) e mais algumas, é uma pesquisa aos interessados e curiosos.
Parabéns!
Abs
Legal Henrique, vou dar uma olhada nesta rfc que você comentou.
Obrigado pela contribuição!
Obrigado por compartilhar seu conhecimento.
Excelente artigo! Parabéns!!!
Olá Túlio,
Obrigado! Que bom que gostou!
Abs,
Fernando