Resumo

  • O APNIC PING apresentou em 3 de setembro um estudo controlado de janeiro de 2026 que compara consultas convencionais à raiz com a manutenção de cópias locais.
  • Em quatro dias, o BIND com IXFR registrou média de 4,35 MB por resolvedor por dia; o Unbound por DNS, 3,93 MB; e o Knot Resolver com uma obtenção HTTPS diária, 2,65 MB.
  • Os 105,12 MB do Unbound por HTTPS vieram de 48 downloads completos de 2,19 MB por dia. O relatório identifica um bug confirmado, e não um custo intrínseco do HTTPS.

Quatro sistemas podem receber a mesma etiqueta operacional e esconder quatro rotinas diferentes. No teste, BIND e Unbound por DNS aguardavam mudança no serial. Knot buscava aproximadamente uma cópia completa por dia. A outra instância do Unbound repetia o arquivo a cada meia hora.

Essa diferença é o centro da publicação do APNIC PING. George Michaelson apresenta o projeto de Ilyas Rahimi, com participação de Willem Toorop, do NLnet Labs. Não se discute transferência de autoridade sobre a raiz. Mede-se a obrigação de distribuição que substitui muitas consultas pequenas.

O custo está na rotina

O relatório de Rahimi normaliza tudo em MB por resolvedor por dia. O caso convencional usa RSSAC002 de 1 a 7 de janeiro: quase todas as letras da raiz ficam entre 0,67 e 1,34 MB, com F-root em 11,18 MB. O lado local vem de capturas entre 20 e 23 de janeiro em ambiente virtual controlado.

Configuração observada Rotina de atualização MB/resolvedor/dia
BIND, DNS IXFR Após mudança de serial, 2-4 vezes/dia 4,35
Unbound, DNS IXFR Após mudança de serial, 2-4 vezes/dia 3,93
Knot Resolver, HTTPS Cerca de uma cópia completa/dia 2,65
Unbound, HTTPS Cópia completa a cada 30 minutos 105,12

BIND transferiu cerca de 1,45 MB por atualização; Unbound por DNS, 1,31 MB. Houve duas, três, quatro e três atualizações nos quatro dias. O total diário acompanhou mudanças reais.

Knot apresentou o menor volume local, porém com agenda mais conservadora. Isso não o torna vencedor universal: menor frequência também pode adiar uma mudança. O extremo de 105,12 MB não condena HTTPS. A configuração do Unbound baixava a zona inteira sem verificar antes o serial. O relatório diz que um desenvolvedor confirmou o defeito e previa correção. O diagnóstico está na lógica, não no nome do transporte.

Limites antes da conclusão

Todas as configurações locais superaram a referência convencional nos períodos escolhidos. O teste local durou quatro dias; a base, sete. Não mediu latência, custo computacional de DNSSEC, recuperação, complexidade ou o valor de depender menos dos caminhos públicos da raiz.

A escala usa fontes únicas do RSSAC002 como aproximação de resolvedores. NAT e agregação IPv6 impedem que isso seja um censo. A multiplicação por cerca de 59,1 milhões ilustra crescimento linear, não prevê tráfego mundial.

O RFC 8806 preserva o requisito estável de cópia completa, atual, validada por DNSSEC e com retorno à raiz não local antes de servir dados vencidos. O Internet-Draft individual versão 07 propõe verificar o estado antes da zona inteira e discute distribuição HTTPS eficiente. Apesar de bcp no nome histórico, a nota editorial diz que ele não segue como BCP. Não é política atual do IETF.

O resultado que um operador pode usar é mais simples: serial, tipo de transferência, bytes por evento, eventos por dia, validação e idade da cópia. A etiqueta local não substitui esses fatos.