Resumo
- Em 11 de julho de 1997, um operador relatou que um resolvedor associava
www.internic.neta um endereço da AlterNIC e marcava o registro como dado adicional. - O episódio ligou a disputa sobre quem podia registrar domínios comerciais a uma falha técnica separada: um resolvedor confiou e guardou uma associação que não deveria devolver como resposta.
Um endereço da Web, duas autoridades diferentes
A AlterNIC contestava o papel da Network Solutions no registro de domínios comerciais de nível superior. A disputa era sobre quem poderia acrescentar nomes como .com e .net e sob quais regras. Mas a evidência preservada mais reveladora é menor que esse debate. Em 11 de julho de 1997, Kevin Brintnall, operador de rede, publicou no NANOG uma consulta e um despejo do cache do servidor de nomes da Visi Internet. www.internic.net retornava 207.51.48.15; uma consulta ao endereço o identificou como aragorn.alternic.net.
O despejo de Brintnall marcava o registro de endereço inesperado como addtnl, abreviação de dados adicionais na resposta DNS. Ele também disse que o cache de raiz do seu resolvedor não tinha indicações da AlterNIC. Nesse caso, o usuário não havia escolhido uma raiz alternativa. Um dado obtido durante a resolução recursiva alterou o que aquele resolvedor respondia para o host da InterNIC.
A distinção importa porque os nomes envolvidos exerciam poderes diferentes. A zona raiz delega nomes de nível superior. Um registrador aceita inscrições sob um domínio de nível superior. Um resolvedor recursivo segue as delegações DNS e mantém registros em cache para responder localmente a consultas seguintes. O desafio político da AlterNIC era às regras do sistema de nomes; a evidência de Brintnall mostra um mapeamento guardado por um resolvedor. Ela não mostra que a AlterNIC tenha reescrito a zona raiz pública.
O que o cache prova — e o que não prova
A postagem original no NANOG é excepcionalmente concreta para uma história do DNS. Ela mostra o endereço do servidor, o registro A devolvido, o endereço de origem guardado no cache e a anotação de procedência do resolvedor. O endereço de origem correspondia a um host da AlterNIC. A marca addtnl é compatível com a explicação publicada depois pela WIRED: respostas DNS podiam carregar registros adicionais, e um resolvedor confiante demais podia guardar um deles para um nome diferente daquele que havia consultado.
A evidência estabelece uma resposta incorreta em um cache. Ela não conta todos os resolvedores afetados, não prova que cada visitante tenha sido redirecionado nem mostra que os servidores raiz públicos estivessem sob controle da AlterNIC. Relatos da época às vezes descreviam o incidente como se “a Internet” tivesse sido redirecionada. O registro técnico restringe a afirmação: um resolvedor devolveu outro destino para um nome específico de site. O valor 146598 no despejo é um campo do registro, não a duração de uma interrupção global nem o número de usuários.
O contexto político era real. O Washington Post informou que a Network Solutions tinha, por acordo com a National Science Foundation, direitos exclusivos de registro para .com, .org e .net. A AlterNIC se apresentava como registradora concorrente e contestava o que seu operador descrevia como a alegação de propriedade da NSI sobre esses nomes. Esse papel contratual era poderoso, mas não equivalia a possuir todos os nomes nem a raiz inteira da Internet. Redirecionar visitantes para a AlterNIC tornou o argumento visível; não resolveu quem tinha autoridade legítima para definir o espaço público de nomes.
Um incidente de cache não era uma decisão de política
A resposta passou por software e operação. O aviso da CERT sobre BIND, publicado em agosto de 1997, descreveu o envenenamento de cache como dados de um servidor de nomes remoto que outro servidor salvava e disponibilizava aos programas clientes. O documento diz que a vulnerabilidade havia sido corrigida no BIND 4.9.6 e recomenda um caminho de atualização que inclui o BIND 8.1.1. O aviso trata de uma classe de comportamento de resolvedor, não apenas da AlterNIC.
Publicado em julho de 1997, o RFC 2181 classifica as informações da seção adicional entre os dados DNS menos confiáveis e diz que registros adicionais não autenticados não devem ser devolvidos depois como respostas. O RFC esclarece como os dados devem ser tratados; as fontes disponíveis não demonstram que ele tenha sido escrito por causa desse episódio. A publicação de um padrão também não prova que todos os operadores tenham atualizado ou configurado cada resolvedor.
O debate norte-americano sobre nomes de domínio seguiu seu próprio caminho. O Departamento de Comércio abriu uma consulta pública em julho de 1997; o Green Paper, o White Paper e a formação da ICANN vieram em 1998. A cronologia da Internet Society registra essa sequência, mas não atribui sua causa ao redirecionamento da AlterNIC. Em 2000, o IAB argumentou no RFC 2826 que o DNS público precisava de uma raiz única para preservar nomes consistentes. Essa é uma posição institucional posterior, não uma perícia sobre o cache de Brintnall.
O episódio pertence a duas histórias ao mesmo tempo. Foi um protesto contra um papel concentrado de registro e uma demonstração operacional de que um resolvedor local podia transformar dados adicionais duvidosos em outro destino. A primeira pergunta era quem deveria definir as regras dos nomes. A segunda, em quais dados um resolvedor deveria confiar. Confundir as duas transforma uma linha de cache em transferência da zona raiz e um redirecionamento visível em prova de controle universal.
Fontes
- Relato de cache de Kevin Brintnall no NANOG, 11 de julho de 1997
- WIRED: “InterNIC Who?” (16 de julho de 1997)
- The Washington Post: Network Solutions e o redirecionamento da AlterNIC (23 de julho de 1997)
- Aviso CERT CA-1997-22: BIND
- RFC 2181, seção 5.4.1
- Internet Society: A história da IANA
- RFC 2826: comentário técnico do IAB sobre uma raiz DNS única
- WIRED: “Network Solutions Takes AlterNIC to Court”
- WIRED: “Domain Guerrilla Says He’s Sorry”
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
