Por que existem apenas 13 grupos de servidores raiz no mundo?

1. A restrição rígida do protocolo: 512 bytes

1.1 MTU do IPv4 e UDP sem fragmentação

As primeiras redes ARPANET / IPv4 exigiam um MTU mínimo de 576 bytes. Todo host precisava ser capaz de receber pacotes desse tamanho, ou nem a alcançabilidade básica estaria garantida (RFC 791).

Total Length is the length of the datagram, measured in octets,
including internet header and data.  This field allows the length of
a datagram to be up to 65,535 octets.  Such long datagrams are
impractical for most hosts and networks.  All hosts must be prepared
to accept datagrams of up to 576 octets (whether they arrive whole
or in fragments).  It is recommended that hosts only send datagrams
larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams.

• 576 bytes de comprimento total − cabeçalho IP típico de 20 bytes − cabeçalho UDP de 8 bytes ≈ 548 bytes utilizáveis (com opções IP o cabeçalho pode chegar a 60 bytes, sobrando menos)
• A RFC 1035 § 4.2.1 adotou a potência de dois mais conservadora, 512 bytes, como teto rígido do DNS sobre UDP — seguro mesmo quando o cabeçalho IP carrega todas as opções
• Se uma resposta UDP passar de 512 bytes, ela deve ser truncada com o flag TC ativado, forçando o cliente a recorrer ao TCP — e o handshake de três vias do TCP multiplica a latência da primeira resolução

Em outras palavras, "a lista completa de servidores raiz precisa caber em um único pacote UDP de 512 bytes" — caso contrário, toda consulta à raiz no mundo teria de passar por TCP, o que seria quase catastrófico no hardware dos anos 1980.

1.2 Layout em bytes da mensagem DNS

A estrutura completa da resposta a uma consulta dos registros NS de . (o servidor devolve todos os registros NS raiz mais os registros A de glue):

Header   (12 bytes)

Fórmula do comprimento total:

Aplicando o limite de 512 bytes:

Em teoria isso permite até 15 grupos, mas é preciso deixar folga para assinaturas DNSSEC, o pseudo-registro OPT do EDNS0 e preenchimento de campos, então o número ficou em 13 grupos — a RFC 2010 (1996) definiu os critérios operacionais dos servidores raiz, e a contagem não mudou desde que o M-root entrou em operação no ano seguinte.

1.3 Teste você mesmo — <code>dig +noedns -t ns .</code> devolve cerca de 490–510 bytes

Essa é a teoria. Agora vamos consultar de fato um servidor raiz com dig e ver o tamanho real da resposta:

$ dig +noedns -t ns .

; <<>> DiG 9.10.6 <<>> +noedns -t ns .
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35973
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15

;; QUESTION SECTION:
;.                                IN      NS

;; ANSWER SECTION:
.                       430502  IN      NS      a.root-servers.net.
.                       430502  IN      NS      b.root-servers.net.
…  (13 registros NS no total, c–l omitidos)
.                       430502  IN      NS      m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.     516909  IN      A       198.41.0.4
b.root-servers.net.     562547  IN      A       170.247.170.2
…  (os 13 registros glue A couberam)
m.root-servers.net.     516941  IN      A       202.12.27.33
a.root-servers.net.     516930  IN      AAAA    2001:503:ba3e::2:30
b.root-servers.net.     562547  IN      AAAA    2801:1b8:10::b
↑ só couberam 2 registros AAAA — o pacote está cheio

;; Query time: 8 msec
;; SERVER: 192.168.1.1#53
;; MSG SIZE  rcvd: 492

A linha-chave no final — uma resposta total de cerca de 490–510 bytes, folgadamente abaixo de 512 (o valor exato depende de qual raiz você consulta e de quantos registros de glue IPv6 voltam) — confere com o orçamento de bytes acima. Repare no flag +noedns: por padrão o dig envia EDNS0, e aí a resposta passa bem de 800 bytes. É exatamente por isso que 512 bytes deixou de ser um limite rígido quando o EDNS0 se tornou universal — mas o 13 já estava fixado.

2. De onde vem o 13? Um breve histórico

Esse número não foi fixado desde o início. A quantidade de servidores raiz passou por várias expansões; depois que o M-root (WIDE, Japão) entrou em operação em 1997, nunca mais mudou:

Uma vez fixados em 13, os nomes de letra de A a M nunca mudam — só o hardware é atualizado e novos espelhos anycast são adicionados. O arquivo de hints raiz da Internet (named.root) está há muito tempo embutido no código de bilhões de resolvedores recursivos e clientes stub; mudar um único número significaria atualizar a Internet inteira.

3. Mas existem mesmo só 13 máquinas no mundo?

Não. Esse é o equívoco mais comum. "13 grupos de servidores raiz" se refere a 13 nomes NS (a–m.root-servers.net), cada um associado a um endereço IPv4 e um IPv6 — não a 13 máquinas físicas.

Por trás de cada IP há um cluster anycast — o mesmo endereço IP é anunciado via BGP simultaneamente por centenas de datacenters no mundo, e a consulta DNS do usuário é roteada ao espelho mais próximo em RTT. Quando um servidor raiz "cai", normalmente significa apenas que o espelho de uma cidade está em manutenção — a resolução global não é afetada.

Situação dos 13 grupos de servidores raiz em 2024

A China continental (Pequim, Xangai, Shenzhen, Guangzhou, Hefei e outras) hospeda nós espelho anycast de vários servidores raiz, incluindo F / I / J / K / L; o RTT medido até os servidores raiz a partir da China costuma ficar abaixo de 20ms.

4. Depois do EDNS0, 512 bytes deixou de ser um limite real

Você pode perguntar: pacotes DNS de 4KB ou mais são comuns hoje, então por que não simplesmente "passar de 13"?

• EDNS0 (RFC 2671 em 1999, atualmente RFC 6891) — negocia uma carga útil UDP maior (normalmente 4096 bytes), suportado por todo resolvedor moderno
• O DNSSEC exige EDNS0, já que só os dados de assinatura passam muito de 512 bytes
• Fallback para TCP — o handshake de três vias do TCP moderno, mais TLS / cookies, já é barato

Mas a lista de servidores raiz hoje é um consenso de toda a rede: cada resolvedor recursivo do planeta traz esses 13 grupos fixos no arquivo de hints (named.root), e por trás desses resolvedores estão bilhões de dispositivos. O incentivo para mudar é zero, e o risco é fragmentar a Internet global, então esse número quase certamente continuará sendo 13 para sempre.

Em resumo: os "13 grupos" ficaram obsoletos fisicamente há muito tempo, mas são impossíveis de derrubar do ponto de vista de engenharia.

5. Pontos-chave

1. Razão histórica: o limite de 512 bytes do DNS sobre UDP → teto matemático de 15 grupos → 13 escolhidos com folga, fixados quando o M-root entrou em operação em 1997
2. Inércia do protocolo: atualizar os arquivos de hints em bilhões de dispositivos é inviável, então isso nunca muda
3. Capacidade real: mais de 1395 nós espelho anycast, tornando o risco de falha em ponto único quase zero
4. Acessível a partir da China: vários servidores raiz, incluindo F / I / J / K / L, têm espelhos na China continental, com RTT medido < 20ms