O sistema de nomes da internet começou como um arquivo de texto, e o que acabou com esse arquivo foi a limitação mais humana de todo este catálogo.

Antes: um telefonema e um arquivo de texto

e a equipe dela no Network Information Center (NIC) do SRI mantinham o , um arquivo central que associava nomes a endereços (RFC 608; RFC 952). Quem queria entrar na rede falava com o NIC, a equipe fazia a inclusão e atualizava o arquivo umas duas vezes por semana; cada host então buscava a cópia nova por File Transfer Protocol () (RFC 1034, seção 2.1).

O sistema funcionava, mas tinha um limite que nenhuma engenharia conseguia contornar: Feinler e os colegas trabalhavam em horário comercial e tiravam folga nos feriados. Uma rede que precisa estar sempre disponível não pode depender de um sistema de nomes que fecha às cinco da tarde. Como equilíbrio entre vida pessoal e trabalho, ótimo; como modelo de operação, impossível. É o exemplo mais claro deste catálogo de uma arquitetura técnica imposta por uma limitação humana, e não computacional.

O outro limite era de aritmética. Cada host novo exigia uma edição manual e uma redistribuição completa do arquivo, e a banda de rede consumida para distribuir cada nova versão "is proportional to the square of the number of hosts in the network", ou seja, proporcional ao quadrado do número de hosts na rede (RFC 1034, seção 2.1).

1983: o aluno de pós-graduação e a tarefa

Paul Mockapetris entrou no ISI em 1978 como aluno de pós-graduação, numa equipe de umas vinte pessoas sob a supervisão de . Segundo o relato do próprio Mockapetris, um dia Postel entrou na sala dele e perguntou se ele queria trabalhar no problema dos nomes de domínio. Outro relato descreve a tarefa de forma mais estreita: conciliar as cinco propostas que já existiam para melhorar o sistema de nomes.

Ele leu todas e, em vez de conciliá-las, escreveu a sua. Assim nasceram as RFCs 882 e 883, publicadas em novembro de 1983 e assinadas só por ele (RFC 882; RFC 883), que descrevem o Domain Name System e o seu protocolo de consulta. Em 2019, ao lhe dar o Software System Award, a ACM chamou esse projeto de ousado e de uma simplicidade desconcertante.

Ele também escreveu a primeira implementação, um servidor chamado Jeeves, que rodava em máquinas DEC Tops-20 no ISI e no NIC do SRI e que ofereceu o primeiro serviço estável em produção. O veio logo depois, escrito por alunos de pós-graduação de Berkeley com financiamento da DARPA.

A especificação foi revista em novembro de 1987, nas RFCs 1034 e 1035 (RFC 1034; RFC 1035), que continuam sendo os documentos de referência. Desde então, mais de duzentas outras RFCs se somaram às cem páginas originais.

O que o projeto realmente fez

A grande mudança foi sair de uma autoridade única para a autoridade delegada. Em vez de um arquivo central, cada organização opera o seu pedaço do namespace (o espaço de nomes) nos seus próprios servidores, e qualquer pessoa no mundo pode consultá-lo.

Daí vêm três propriedades, e são as três que, até hoje, fazem o sistema funcionar:

Delegação. A raiz não precisa conhecer os seus hostnames; precisa saber quem conhece. A autoridade termina em cada fronteira, e a carga se distribui junto com a estrutura.

Cache. Cada resposta tem um prazo de validade, então um nome popular é resolvido uma vez e reaproveitado muitas vezes. Sem cache, o sistema teria quebrado com uma fração do tamanho que tem hoje, e o (time to live, a validade da resposta) é o número de maior impacto que a maioria dos engenheiros configura sem pensar.

Nomes para qualquer coisa. Segundo a descrição do próprio Mockapetris, o sistema foi criado para que as pessoas pudessem usar nomes para qualquer coisa. Os tipos de registro que surgiram depois, com roteamento de e-mail, texto, localização de serviços, chaves e restrições de certificado, são todos consequência dessa generalidade.

A parte que ficou de fora

O DNS foi projetado para uma rede em que os participantes eram conhecidos e, em geral, confiáveis, e o projeto original não tem autenticação nenhuma. O resolver acredita na resposta que recebe.

Todas as dificuldades que vieram depois nascem daí. O cache poisoning (envenenamento de cache) funciona porque uma resposta que parece certa é aceita. O existe para assinar os registros e levou décadas para chegar a uma implantação parcial: ele exige uma cadeia de cooperação da raiz até cada zona, e quem implanta fica com a dor de cabeça operacional enquanto o benefício vai para todos os outros. Essa é a lógica econômica clássica das melhorias de segurança na internet, e o motivo clássico de elas empacarem.

O DNS over TLS e o resolveram outro problema: não se a resposta é verdadeira, mas quem mais consegue ver a pergunta. E foram adotados mais depressa justamente porque um navegador ou um sistema operacional pode ativá-los por conta própria. A correção que uma parte consegue implantar sozinha vence; a que depende da cooperação de todos fica esperando. Vale guardar isso como regra geral, porque ela prevê, melhor do que qualquer avaliação de mérito técnico, quais melhorias de segurança vão dar certo.

De sistema de nomes a ponto de controle

O resolver vê cada nome que um dispositivo pede, antes de qualquer conexão acontecer. Por isso, ele virou três coisas para as quais nunca foi projetado.

Um controle de segurança. Basta não resolver o nome, e a conexão nunca acontece. Essa é toda a premissa do mercado de resolvers, e é por isso que OpenDNS, NextDNS, Infoblox e EfficientIP vendem a partir dessa posição.

Um ponto de vigilância. O log de consultas é um registro de intenções, e é por isso que a criptografia no transporte virou um argumento de privacidade, e não uma questão técnica.

Um instrumento de censura. Bloquear na camada de nomes é a forma mais barata de filtragem em escala nacional, não exige nenhuma cooperação do site bloqueado e é usada por governos de todo o espectro político.

Um sistema de nomes construído sobre a confiança entre pesquisadores virou o ponto de controle mais conveniente da internet, e nenhum desses três usos exigiu qualquer mudança no protocolo. Bastou estar no caminho da pergunta.

Cargos e práticas

O DNS gera poucos cargos dedicados, mas aparece no de toda queda séria. O reflexo profissional que ele criou é de diagnóstico: verifique primeiro a resolução de nomes, porque um nome que resolve para o lugar errado produz sintomas impossíveis de distinguir dos de uma dúzia de outras falhas.

As práticas que ele criou são fáceis de reconhecer. Disciplina com o TTL antes de uma migração: baixar os valores com antecedência para que a mudança se propague a tempo, na hora em que importa. Mudanças de zona com revisão, porque um registro errado é uma queda sem mensagem de erro. O split-horizon e a confusão que ele traz: as respostas internas e externas são diferentes, e cedo ou tarde alguém investiga a resposta errada. E o cuidado com o registrar e o registry: domínio expirado e conta comprometida no registrar são quedas que nenhuma qualidade de infraestrutura evita.

As empresas

O trabalho saiu do SRI, do ISI e de Berkeley, e nenhum dos três o transformou em produto. O Internet Systems Consortium mantém o BIND; quem opera a raiz e os domínios de topo é uma mistura de instituições, empresas e governos; e o mercado comercial é formado pelos registrars, pelos provedores de DNS autoritativo gerenciado, pelos fabricantes de DDI e pelos resolvers públicos.

Para onde o DNS está indo

A resolução está se centralizando. Hoje, um punhado de resolvers públicos responde a uma fatia enorme das consultas do mundo. Isso melhora o desempenho e a privacidade em relação ao provedor local, mas cria exatamente a concentração que o projeto distribuído foi feito para evitar.

A criptografia mudou a pergunta de lugar, mas não a respondeu. O transporte criptografado esconde a consulta da rede e a entrega a quem opera o resolver; a confiança não desaparece, só muda de lugar. Por isso, escolher um resolver virou uma decisão importante, e não mais uma configuração padrão.

O registro DNS está virando um veículo de uso geral. Service binding, restrições de certificado, os parâmetros do Encrypted Client Hello (ECH) e registros de verificação: cada vez mais, o jeito de um sistema dizer a outro como chegar até ele com segurança é um registro DNS.

E o princípio fundador continua valendo. Mais de quarenta anos depois, o sistema faz o que um aluno de pós-graduação especificou em cem páginas: delegar a autoridade, guardar a resposta em cache e deixar as pessoas usarem nomes para qualquer coisa. Quase nada mais da internet de 1983 continua rodando sem modificações, e, se o DNS continua, o motivo tem menos a ver com o protocolo do que com a decisão de ceder a autoridade em vez de guardá-la para si.

Esta série, em ordem

Este artigo abre a série O DNS como infraestrutura e conta como o DNS surgiu. As partes seguintes tratam do sistema como ele é hoje: a falha que permitia tomar um domínio inteiro em segundos, o que aconteceria se a raiz saísse do ar ou começasse a mentir, o que você está escolhendo quando escolhe um resolver público e o resolver usado como controle de segurança.

  1. A falha de Kaminsky: o verão em que oitenta fabricantes corrigiram o mesmo bug no mesmo dia. 2008: a fraqueza conhecida que acabou se revelando capaz de tomar domínios inteiros, e o dia em que oitenta fabricantes lançaram a correção ao mesmo tempo.
  2. O que acontece se a raiz do DNS sair do ar, ou começar a mentir. Cerca de dois dias de delegações em cache se a raiz ficar muda, e o caso muito pior de uma raiz que mente.
  3. Resolvers DNS públicos: o que você está escolhendo de verdade. Cloudflare, Google, Quad9 e OpenDNS diferem menos em velocidade do que em política: o que cada um faz com as suas consultas.
  4. Listas de bloqueio no DNS: RPZ, classificações e o custo de uma resposta recusada. Feeds de , as classificações dos fabricantes e o custo de uma resposta recusada: o controle de segurança mais barato que existe.

Fontes