Resumo

  • O ZONE do RFC 1296 mantinha domínios e servidores em uma lista, perguntava SOA para verificar a autoridade do servidor contatado e então pedia AXFR. O estudo chamou de host um agrupamento de nome(s) e endereço(s) IP descoberto no DNS, e não uma máquina testada quanto ao acesso direto.
  • Transferências recusadas ou abandonadas e hosts que não apareciam em servidores de domínio reduziam a coleta; registros aleatórios, malformados, não autoritativos ou preservados durante renomeações podiam inflá-la. Depois de revisão manual, o autor descreveu os dados de ZONE como o número mínimo de hosts, não o número real.

RFC 1296, Internet Growth (1981-1991) é lembrado pelas tabelas de crescimento, mas seu ensinamento histórico é mais rigoroso do que a tabela. Mark Lottor não fingiu que a superfície observável do DNS era a própria Internet. Ele colocou entre a pergunta e o número uma cadeia completa: uma lista inicial, um servidor a contatar, um teste de autoridade, uma transferência, uma tabela em memória, uma regra de agrupamento, fontes de ausência e fontes de duplicação. O resultado só tem sentido junto com essa cadeia.

ZONE, abreviação de Zealot Of Name Edification, foi escrito em 1986 para a transição da host table para o DNS. A ideia inicial era caminhar pela árvore DNS, formar uma host table a partir do que fosse coletado e servir aos locais que ainda não haviam concluído a transição. O programa não foi usado para esse fim. Tornou-se útil para estatísticas sobre o tamanho do sistema de domínios e da Internet. Uma mudança de finalidade não amplia, por si, o alcance da evidência: uma tabela produzida por um coletor continua sendo uma tabela das observações que esse coletor pôde fazer.

A autoridade de uma resposta não era disponibilidade do host

O procedimento de ZONE tinha uma disciplina própria. Mantinha uma lista de domínios e seus servidores e uma marca que dizia se as informações de um domínio já haviam sido carregadas com sucesso de um desses servidores. Por causa de outro defeito no BIND, precisava começar com uma lista dos domínios de topo e de seus name servers. Para um domínio ainda não transferido, percorria a lista tentando contatar um de seus servidores por TCP. Quando conseguia contato, enviava primeiro uma pergunta Start of Authority, SOA, para verificar se aquele servidor era autoritativo para o domínio solicitado.

Apenas se a resposta permitisse essa conclusão enviava AXFR para solicitar todos os resource records da zona.

Um registro NS recebido acrescentava o domínio e o servidor referenciados ao trabalho pendente. Registros A, CNAME, HINFO e MX recebidos eram colocados em uma tabela de informações de hosts em memória. O programa parava quando percorria toda a lista sem obter informação nova e gravava a tabela em formato HOSTS.TXT. Esta sequência não deve ser encurtada num verbo único como “contar a Internet”. A resposta SOA é evidência sobre a base para consultar um servidor a respeito de uma zona. A transferência é evidência sobre registros recebidos pelo coletor. A tabela é evidência de que uma regra foi aplicada a esses registros.

Nada nessa sequência comprova que um host seja alcançável diretamente da Internet. Um servidor que responde de modo autoritativo não certifica que cada registro da zona descreve uma máquina atual. Um AXFR completo não certifica que todos os hosts que importam estejam no DNS. Um endereço agregado à tabela não certifica que a aplicação aceite conexões. A ferramenta encontrou material publicado por uma infraestrutura de nomes; alcance, identidade, pertinência e população exigem observações ou definições adicionais.

O RFC explicita a unidade do estudo: um host é um agrupamento [name(s), IP-address(es)] descoberto no DNS. A regra impede que um host com vários nomes ou endereços seja contado mais de uma vez. Ela não leva em conta se esse host é diretamente acessível. Essa frase impede uma extrapolação comum. Normalizar registros resolve um problema de contagem definido pelo pesquisador; não decide se os nomes descrevem a mesma máquina física, se a máquina está ligada, se há rota ou se ela pertence à população que o leitor quer discutir.

O que faltava tinha direção, não tamanho conhecido

O limite de baixo veio das observações que ZONE não conseguia obter. Alguns Internet sites não permitiam transferências de zona de seus domain servers. Depois de muitas falhas, ZONE abandonava a tentativa. Na execução de 1º de janeiro de 1992, cerca de 800 dos 17.000 domínios não puderam ser transferidos. O documento também parte do pressuposto de que nem todos os hosts da Internet estavam registrados num servidor de domínio. As duas condições retiravam da tabela registros que a regra de coleta poderia ter usado. Por isso o RFC diz que as estatísticas reunidas ficam abaixo das quantidades efetivas.

Uma direção de erro não é uma estimativa da parte ausente. O memo não informa quantos hosts havia por trás de cada transferência recusada, nem diz que todo host sem registro DNS era alcançável. Ele preserva uma afirmação mais modesta: um método que soma registros de zonas recebidas não pode transformar em presença observada aquilo cuja transferência falhou, foi recusada ou nunca foi inscrito naquela fonte. “Mínimo” é uma conclusão sobre a orientação do viés sob essas condições, não uma autorização para inventar o complemento.

A história operacional de ZONE também desaconselha tratar o número como fotografia de um instante. O DNS foi introduzido por volta de 1984 e levou quase quatro anos até estar plenamente implementado na Internet; naquele período muitos hosts já não eram registrados na Host Table. Versões iniciais de BIND tinham grandes problemas com a função de transferência de zona, e ZONE só pôde coletar dados DNS completos por volta de 1988. O tempo de coleta cresceu de horas para uma semana, e a tabela chegou perto de 50 megabytes.

No modo então usado, o programa guardava apenas nomes de hosts e endereços IP, ignorava dados de protocolo, informação de host e MX, e depois usava sort, uniq e grep para produzir estatísticas. A execução em SRI ocorria a cada três meses.

Uma caminhada que dura uma semana não observa todos os pontos no mesmo momento. Uma rodada trimestral não é um inventário continuamente atual. Um campo ignorado para reduzir volume não pode reaparecer como dado observado. A cifra depende da lista de partida, da janela de coleta, dos servidores que responderam, das transferências que terminaram, das classes mantidas e da regra de agrupamento. A metodologia não é um rodapé que reforça a tabela; ela determina o que a tabela afirma.

Registros extras não corrigiram os registros ausentes

O RFC também descreve risco de viés para cima. A revisão manual do material recolhido encontrou muitas entradas aleatórias no DNS. Entradas mal formatadas podiam causar o aparecimento de registros falsos de servidor ou host. Às vezes um servidor não era autoritativo para o domínio ao qual estava associado. Domínios inteiros podiam ser renomeados, com as entradas antigas mantidas durante uma transição, o que fazia cada host daquele domínio ser contado duas vezes. São problemas de adição e repetição dentro da parte que o coletor viu.

A conclusão de limite inferior não resulta de negar esse risco. O autor diz que a varredura manual indicava serem essas entradas adicionais insignificantes quando comparadas às ausências já discutidas. É essa comparação que permite ver os dados de ZONE como um número mínimo de hosts, e não o fato abstrato de que um programa percorreu o DNS. Não se deve converter a frase em uma lei para toda enumeração DNS, em qualquer época. Trata-se do juízo declarado para o programa, o material e a revisão que o memo registra.

Há dois trabalhos distintos por trás de uma série. O primeiro é registrar procedência: que domínio foi tentado, qual servidor foi chamado, se o SOA foi aceito, se o AXFR terminou, quando os registros chegaram e como entraram na tabela. O segundo é interpretar o conjunto: o que o agrupamento representa e se o padrão de faltas e sobras permite uma conclusão direcional. Deduplicar nomes e endereços não informa quantos hosts ficaram dentro de uma zona inacessível. Encontrar uma entrada velha não revela se ela ainda corresponde a um host. Ter um registro não substitui um teste de alcance.

Um nome no DNS não resolvia quem estava na Internet

O RFC trata o escopo como problema central. Encontrar entradas de host no DNS não significa que o host seja acessível a partir da Internet. Empresas podiam manter mail gateways entre a Internet e suas redes locais, bloqueando acesso direto; algumas anunciavam todos os hosts e outras apenas o gateway. Quais deveriam entrar na conta? Muitos domínios DNS eram apenas entradas MX de encaminhamento para sites fora da Internet, como sites Usenet. Devem entrar num estudo de tamanho da Internet?

Não são perguntas que uma transferência adicional responde. São escolhas sobre o objeto medido. Uma resposta DNS apoia uma afirmação sobre um registro publicado. Um AXFR finalizado apoia uma afirmação sobre dados recebidos por um processo. Uma normalização apoia uma afirmação sobre como se unificaram campos. Para afirmar acessibilidade direta, filiação institucional, identidade ou população total, é preciso acrescentar outro critério, outra observação ou outra fonte de autoridade. Uma linha ascendente não carrega esses predicados apenas por ser uma linha ascendente.

O custo da coleta torna visível outra fronteira. Baixar informação de cada domínio gerava tráfego de rede e sobrecarga de CPU em cada servidor contatado. O RFC sugere que um esforço organizado poderia ter apenas um programa em intervalos regulares para evitar vários coletores. Isso é uma proposta de coordenação e de limitação de custo, não a prova de que alguém possuía o direito ilimitado de interrogar zonas ou de decidir sozinho quem compõe o conjunto público.

O desenho futuro não era um resultado presente

Na seção de questões futuras, ZONE aparece rodando num DECsystem-20 e escrito em assembler. O volume se aproximava dos limites do espaço de endereçamento e da capacidade de sobrevivência do hardware. O programa mantinha os dados em memória antes de gravá-los, para relacionar apelidos de host a nomes oficiais; um apelido podia estar em domínio diferente do nome oficial, o que complicava métodos mais simples. O autor propôs uma nova arquitetura: guardar dados em disco, executar várias transferências em paralelo e rodar continuamente num ciclo de semanas a um mês, atualizando uma base local com estatísticas por domínio.

Essa passagem descreve uma proposta, não a implantação de um substituto nem a existência de uma base contínua e completa. Coletar com mais frequência pode reduzir a idade de certas observações. Paralelizar pode encurtar a duração de uma caminhada. Usar disco pode evitar perda após uma falha. Nada disso apaga a diferença entre registro e host alcançável, entre agrupamento de nomes e identidade ou entre um limite observado e o total. RFC 1296 imagina melhorias sem prometer que elas resolvem a questão que o número não podia resolver.

Fontes e limites da evidência

A única fonte é RFC 1296. Ela apoia o status Informational de janeiro de 1992, os dados de Host Table e ZONE, a sequência SOA/AXFR, os tipos de registro, a definição de host, as falhas de transferência, as entradas residuais, a conclusão de limite inferior, as perguntas de escopo, os números de janeiro de 1992, o custo e a proposta de arquitetura futura. Não prova uma população DNS atual, um AXFR ao vivo, uma característica atual de BIND, uma política contemporânea de enumeração, a alcançabilidade de um host, a filiação de uma organização, segurança, a implantação de um novo coletor ou um resultado posterior.