O que é a raiz, afinal

Existem treze identidades de servidor raiz (os root servers), de A a M, operadas por doze organizações independentes: universidades, órgãos de governo, entidades sem fins lucrativos e empresas, espalhadas por várias jurisdições. O número treze vem do protocolo, não da quantidade de máquinas: no projeto original, era o número de servidores cujos endereços cabiam numa única resposta sem fragmentação. Por trás desses treze endereços há bem mais de mil instâncias físicas pelo mundo, alcançáveis por anycast, e quem responde a você é a cópia mais próxima.

O que esses servidores entregam é pequeno e sem graça: a zona raiz, um arquivo com cerca de mil e quinhentas delegações que diz quais servidores de nomes são autoritativos para .com, .br, .org, .uk e todos os outros domínios de topo (os TLDs). A raiz não sabe onde fica o example.com. Ela sabe a quem perguntar sobre o .com.

Dois fatos sobre esse arquivo determinam tudo o que vem a seguir. Ele é publicado, e qualquer um pode baixá-lo. E é assinado com , então dá para confirmar que uma cópia é autêntica sem perguntar nada a nenhum servidor raiz.

Cenário um: todos saem do ar

Imagine que todas as instâncias da raiz parem de responder ao mesmo tempo, seja por um desligamento coordenado, por um ataque coordenado ou por uma ordem dada a doze organizações de uma vez.

Da hora 0 à hora 24: quase nada acontece. Os resolvers recursivos não vão até a raiz nas consultas do dia a dia. Eles guardam em cache a delegação de cada domínio de topo, e esses registros vêm com um (time-to-live) de dois dias. O seu resolver já sabe quais servidores respondem pelo .com e vai continuar usando esses servidores. O tráfego segue normal, os e-mails são entregues e ninguém percebe nada.

Do segundo dia em diante: as coisas começam a se desfazer, um domínio de topo de cada vez. À medida que cada delegação em cache expira, o resolver tenta renová-la, precisa da raiz para isso e não consegue. Se o .com ou o .br cai antes do .io, isso depende de quando cada resolver fez a última renovação. Por isso a falha não é global nem simultânea: é irregular e confusa, diferente em cada rede, o que, do ponto de vista operacional, é muito pior do que uma queda limpa.

Primeira semana: os nomes param de funcionar, o roteamento continua normal. Essa é a distinção que importa. Os pacotes continuam trafegando. Um endereço IP digitado direto ainda conecta. As conexões longas que já estavam abertas continuam de pé. O que morre é a capacidade de transformar um nome em endereço para qualquer coisa que ainda não esteja em cache. E como praticamente todo software usa nomes, o efeito prático é uma internet que roteia perfeitamente e não encontra nada.

O que quebra, mais ou menos nesta ordem: a entrega de e-mail novo para domínios desconhecidos, a emissão e a renovação de certificados (as validações se baseiam em nomes), os canais de atualização de software, as APIs dos provedores de nuvem, os serviços federados e tudo o que faz descoberta de serviços por nome. O que continua funcionando: redes internas com resolvers e zonas próprios, tudo o que já estiver em cache, tudo o que for acessado por IP e o conteúdo que já foi entregue.

Mitigações que atrasariam esse processo: os resolvers que implementam stale-answer serving (servir respostas vencidas) continuam entregando registros expirados quando não conseguem renová-los. Com isso, uma falha total vira uma degradação, que dura enquanto alguém aceitar conviver com ela. Esse comportamento foi padronizado justamente para esse tipo de evento.

Cenário dois: a raiz responde, e diz que não

Agora, a versão que deveria preocupar mais. Os servidores raiz continuam no ar, alcançáveis, respondendo rápido, e se recusam a delegar. As respostas para domínios de topo inteiros voltam dizendo este nome não existe.

Isso é pior por três motivos.

É rápido. Não existe um timer de dois dias para esperar. O resolver pergunta, recebe uma resposta negativa, guarda essa resposta em cache e para de tentar. Na raiz, o cache negativo vale por um dia, e é renovado a cada nova negativa.

É autenticado. A zona raiz é assinada com DNSSEC, e o DNSSEC também assina as negativas: uma prova de inexistência é um registro assinado como qualquer outro. Um resolver que faz validação conferiria a assinatura de este domínio de topo não existe, veria que ela é criptograficamente perfeita e aplicaria o resultado. O DNSSEC protege você contra alguém que se passe pela raiz. Contra a própria raiz, ele não oferece nada. A validação autentica a origem, não a verdade.

É fácil de negar. Uma queda tem cara de ataque. Uma delegação retirada em silêncio tem cara de ato administrativo, e a discussão sobre se ela foi legítima só acontece depois que o tráfego já parou.

O mesmo mecanismo existe numa versão menor, e real: um domínio de topo pode ser retirado ou passado para outro operador por uma decisão de governança, sem ataque nenhum, e o efeito operacional para quem usa esse domínio é idêntico ao de uma queda direcionada.

Quem conseguiria, na prática, fazer uma coisa ou outra

A resposta honesta é que os dois cenários são difíceis, e a dificuldade é mais institucional do que técnica.

Para mudar o que a raiz diz, o operador das funções da (a Public Technical Identifiers, ligada à desde a transição de 2016, que tirou a supervisão das mãos do governo americano) precisa aprovar a mudança, o mantenedor da zona raiz (o root zone maintainer) precisa publicá-la e a zona precisa ser assinada numa cerimônia de chaves (a key ceremony): um ritual filmado, auditado, com várias partes e testemunhas externas, feito para que nenhuma pessoa, sozinha, consiga alterar a âncora de confiança (o trust anchor) da raiz. Já para desligar os servidores, doze organizações em vários países teriam de obedecer ao mesmo tempo.

Isso não é garantia. É um arranjo em que o custo da coerção é alto e público, e em que os participantes são diversos o bastante para tornar improvável uma obediência silenciosa. Vale notar que as raízes já foram atacadas diretamente: as grandes tentativas de negação de serviço de 2002 e 2007 degradaram algumas letras sem quebrar a resolução, porque o anycast, somado à redundância, garantiu que sobrasse capacidade suficiente. (distributed denial of service, a negação de serviço distribuída) contra a raiz já foi tentado e não funcionou. Coagir as pessoas que assinam a zona é a ameaça mais plausível, e contra ela o anycast não ajuda.

O que dá para fazer hoje

Esta é a parte que pouca gente conhece: dá para deixar de depender dos servidores raiz para ter disponibilidade, agora mesmo, sem pedir permissão a ninguém.

A zona raiz é pública. Um resolver pode manter uma cópia local da zona raiz inteira, atualizá-la de tempos em tempos e responder ele mesmo às consultas à raiz. Essa prática foi padronizada na 7706 e na sua sucessora, a RFC 8806, e as implementações de resolver mais comuns têm suporte a ela. Como a zona é assinada com DNSSEC, dá para verificar a cópia local: você não está confiando na cópia, está conferindo a cópia contra a âncora de confiança.

O efeito é que uma queda da raiz deixa de afetar os seus usuários. E ainda some um vazamento de privacidade, porque o seu resolver para de contar a terceiros o domínio de topo de cada consulta que não estava em cache. O custo é uma transferência periódica e a disciplina de manter a cópia atualizada.

A lição vale para muito além do DNS: quando a dependência é um conjunto de dados público e assinado, replique os dados e verifique a cópia localmente. Disponibilidade e autenticidade são problemas separáveis, e a raiz é o exemplo mais claro que existe de um sistema em que o segundo está tão bem resolvido que dá para contornar o primeiro.

Por que as raízes alternativas sempre fracassam

A resposta óbvia, montar outra raiz, já foi tentada várias vezes e nunca funcionou, por um motivo que vale a pena entender.

A AlterNIC, nos anos noventa, chegou a sequestrar o tráfego destinado ao registro oficial para marcar posição, e o resultado foi uma condenação criminal, não uma mudança de política. A Open Root Server Network manteve por anos uma alternativa europeia, com o argumento de que a raiz não deveria ficar sob a jurisdição de um único governo. A OpenNIC ainda hoje oferece domínios de topo extras. Mais recentemente, sistemas de nomes baseados em propuseram trocar a raiz inteira por um ledger, um registro distribuído.

Todos esbarram no mesmo obstáculo: um nome precisa significar a mesma coisa para todo mundo, senão não é um nome. Se o seu resolver e o meu discordam sobre a quem pertence o .example, um link, um endereço de e-mail e um certificado deixam de valer da mesma forma para nós dois, e some a propriedade que faz da internet uma rede única. O Internet Architecture Board registrou isso na RFC 2826, o argumento técnico a favor de uma raiz única, e três décadas de tentativas não conseguiram desmenti-lo.

É aí que aparece a tensão de verdade, e ela não se resolve com engenharia. Uma raiz única é tecnicamente necessária e politicamente desconfortável: significa que um único processo de governança, por mais multissetorial que seja, fica no topo dos nomes do mundo inteiro. Toda alternativa séria ou recria esse ponto de estrangulamento sob outra administração, ou fragmenta o espaço de nomes e destrói justamente aquilo que queria defender.

Em resumo

  • Dá para sobreviver a uma raiz desligada, e o estrago é lento: cerca de dois dias de folga e, depois, um desmanche irregular, de resolver em resolver.
  • Fazer a raiz mentir é rápido, vem autenticado pela mesma criptografia que protege você e é muito mais difícil de contestar.
  • O roteamento sobrevive aos dois cenários; a camada frágil é a dos nomes, e quase todo software depende dela.
  • O fato de a zona raiz ser pública e assinada é a saída de emergência: replique a zona localmente e a questão da disponibilidade praticamente desaparece.
  • Nenhuma raiz alternativa resolveu o problema político sem quebrar o técnico, porque um espaço de nomes só funciona se for único.