Resumo

  • O e-mail de Jon Postel de 28 de janeiro de 1998 pediu aos servidores secundários da raiz que obtivessem uma cópia em DNSROOT.IANA.ORG; dizia que ela seria igual à do A-root e que as regras para alterar a zona raiz não mudariam.
  • Em 3 de fevereiro, Postel declarou encerrado o teste de verificação e pediu aos operadores que voltassem ao A-root. Os e-mails documentam pedidos, não a configuração de cada operador.

Um serviço DNS, dois tipos de tráfego

Um resolvedor que procura um nome e um servidor secundário que atualiza sua cópia de uma zona fazem trabalhos diferentes. O resolvedor envia uma consulta DNS a um servidor autoritativo. O secundário obtém os dados que vai servir por meio de uma relação de transferência separada. As duas funções podem estar na mesma máquina, mas não são a mesma transação de rede.

Essa distinção já fazia parte do desenho operacional do DNS. A RFC 1034 descreve um servidor primário que coordena as mudanças e servidores secundários que verificam o número de série SOA e obtêm uma cópia atualizada quando ele avança. A RFC 1035 define AXFR como uma solicitação de transferência de uma zona inteira. Um resolvedor que pede um registro não está solicitando um AXFR da zona raiz.

Em janeiro de 1998, uma máquina podia responder a consultas como servidor raiz e também servir de origem para que outros servidores raiz atualizassem seus dados. O pedido de Postel tratava dessa segunda função. Ele não pediu que os resolvedores da Internet enviassem suas consultas comuns ao host da IANA.

O e-mail delimitou um pedido de transferência

O e-mail preservado é de 28 de janeiro de 1998 e tem o assunto “root zone secondary service”. Postel pediu aos servidores secundários do domínio raiz que obtivessem a zona “por transferência de zona” diretamente de DNSROOT.IANA.ORG, no endereço 198.32.1.98. A mensagem dizia que os dados seriam uma cópia exata da zona então disponível em A.ROOT-SERVERS.NET. Também afirmava que nenhuma política ou procedimento para mudar a zona raiz seria alterado.

A frase que limita o escopo importa tanto quanto o nome do servidor. O pedido se aplicava somente à zona raiz. Os operadores que prestavam serviço secundário para outras zonas, incluindo domínios de primeiro nível, deveriam continuar usando suas fontes de costume. O e-mail, portanto, propunha alterar um caminho de replicação, não redirecionar todo o serviço DNS nem substituir todas as relações com servidores de origem.

O mesmo arquivo conserva uma declaração de Postel à imprensa. Ele descreveu o trabalho como um teste para reorganizar o fluxo de informações da zona raiz e afirmou que seu conteúdo continuaria sendo decidido e preparado da mesma maneira. São duas afirmações distintas: os dados deveriam permanecer iguais, enquanto outro servidor da IANA seria testado como fonte das cópias secundárias. Esses textos não trazem a configuração de cada servidor nem o resultado de cada transferência.

O teste convivia com outra questão administrativa: quem podia autorizar mudanças nos próprios registros. O e-mail de janeiro deixava esses procedimentos inalterados. Uma fonte de transferência pode fornecer uma cópia sem se tornar autora de todos os registros nela contidos. As mensagens disponíveis não mostram que a IANA tenha começado a editar ou publicar um novo conjunto de dados da zona raiz durante o teste.

Mudar a fonte não redireciona as consultas

O episódio pode ser lido de forma equivocada porque o A-root ocupava duas posições: respondia a consultas como um dos servidores raiz e era descrito como a fonte estabelecida do arquivo da zona. As funções estavam associadas à mesma máquina, mas o protocolo de transferência permitia separar a origem da distribuição dos servidores que respondiam aos resolvedores.

A consequência pode ser formulada como uma inferência condicional. Se um servidor secundário recebe uma cópia idêntica e a carrega corretamente, mudar o servidor de onde ela veio não altera, por si só, os registros retornados a um resolvedor. O e-mail preservado diz que a cópia da IANA deveria ser idêntica; não publica uma comparação por servidor nem medições de consultas que comprovem que isso ocorreu em todos os lugares.

Em um depoimento posterior ao Congresso, a NSI afirmou que atuava como servidor raiz “primário” sob seu acordo com o governo, que não havia contratos entre os treze operadores e que os demais não eram obrigados a baixar o arquivo todos os dias. O depoimento ajuda a entender que “primário” descrevia um arranjo operacional, não uma ordem contratual a cada secundário. Ele não revela quem aceitou o pedido de Postel em 1998.

O pedido de retorno delimita o episódio

Em 3 de fevereiro, na mensagem “root zone transfer verification completed”, Postel declarou encerrado o teste e pediu aos operadores que voltassem a obter a zona do A-root. O pedido continuava limitado à zona raiz. A história posterior do sistema de servidores raiz, RSSAC-023v2, diz que Postel pediu a Jim Koda e Paul Vixie que criassem e operassem um servidor raiz primário na ISI para o teste; depois, avisou vários operadores para obterem a zona de lá e pediu que todos voltassem ao servidor primário anterior alguns dias mais tarde.

O relato posterior confirma a sequência, mas fala apenas em “vários” operadores. Nem ele nem os e-mails preservados apresentam uma lista de quem alterou a configuração, um registro AXFR completo ou recibos que mostrem quando cada operador voltou ao A-root. Um pedido comprova intenção; não prova que todos os destinatários o executaram.

Os registros tampouco permitem medir o impacto no serviço. A declaração à imprensa de Postel expressava muita confiança de que a transição ocorreria sem interrupção, mas confiança não é telemetria. Os e-mails não vêm acompanhados de uma série de consultas, registros de indisponibilidade ou comparação independente de todas as cópias em serviço.

Fontes

Os registros mais próximos do episódio são as cópias preservadas do pedido de Postel em 28 de janeiro e da mensagem de retorno em 3 de fevereiro. O arquivo reproduz um bloco de assinatura PGP, cuja validade não foi verificada de forma independente neste artigo. A retrospectiva do RSSAC oferece um relato institucional posterior. As RFCs 1034 e 1035 definem o mecanismo de transferência, não a configuração de cada operador em 1998. O relato da NSI aparece na transcrição de uma audiência do Comitê Judiciário da Câmara dos Representantes e é atribuído à empresa.