Resumo

  • A ISC apresentou na APNIC 62 a listagem de zonas e a detecção de seriais divergentes entre os recursos DNS atuais do Stork. As fontes não registram implantação do Stork na produção da APNIC nem um incidente real de zona desatualizada.
  • Uma divergência prova algo sobre as linhas que o Stork descobriu e buscou. A ausência de divergências não descreve todo o ambiente sem falhas de busca, views não suportadas, exclusões e idade do cache.
  • O resultado precisa de um recibo de cobertura: versões, escopo esperado e observado, estado e horário da busca, valores SOA brutos, limite de validade e tratamento de cada item indisponível.

É mais fácil provar uma divergência do que provar que nenhuma existe

Dois números diferentes já carregam uma evidência estreita. A mesma zona aparece em dois servidores; os seriais SOA não coincidem; existe algo para investigar. Uma tela sem diferenças exige mais trabalho. Ela pode significar que todo o conjunto esperado concorda. Pode também significar que uma parte do conjunto nunca chegou à tela.

Na apresentação do Stork na APNIC 62, Marcin Siodelski, da ISC, colocou a listagem e filtragem de zonas, o visualizador e a detecção de serial divergente entre as funções DNS disponíveis naquele momento. O relato publicado pela APNIC destacou o mesmo ganho operacional. Em um parque grande, reunir a comparação evita abrir servidor por servidor.

O Stork, porém, não observa uma abstração chamada “todos os nossos DNS”. Ele observa daemons que os agentes detectam, configurações e interfaces às quais conseguem ter acesso e informações de zona que o servidor Stork solicitou e armazenou. Uma linha que não atravessou essa cadeia não pode acusar divergência. Também não pode confirmar igualdade.

A documentação DNS da versão 2.4.1 mostra o limite no caso do BIND 9. O agente parte do processo named, procura o arquivo de configuração efetivamente utilizado e depende do statistics channel para obter as views e zonas configuradas. Se não encontra a configuração, o daemon não entra na lista de detectados. Para PowerDNS, a integração usa a configuração e a API web do servidor.

Ficar fora não é sinônimo de defeito. Um servidor pode ter sido excluído por decisão operacional; uma permissão pode estar restrita corretamente; uma interface pode estar desativada por política. A consequência é apenas epistemológica: o resultado vale para o conjunto observado, não para todos os ativos que a organização possui.

O tempo cria outro limite. No Stork 2.4.1, a lista de zonas começa vazia. O operador usa Fetch Zones, e o Stork grava na própria base o inventário obtido pelos agentes. A lista não é atualizada automaticamente; outra busca é necessária para ver mudanças. Os erros ficam em Fetch Status. Assim, uma tela pode representar com precisão a busca da manhã sem saber que uma nova view apareceu à tarde.

Dois contadores descrevem universos diferentes. Zone Configs Count soma configurações, inclusive várias ocorrências do mesmo nome em views distintas. Distinct Zones conta o nome uma vez. Se o recibo guardar apenas zonas distintas, perde a dimensão das views. Se guardar apenas configurações, não revela se a variação veio de novos nomes ou de novas instâncias do mesmo nome. Os dois números precisam acompanhar a comparação.

As views também determinam qual objeto está sendo lido. Para obter por AXFR o conteúdo de uma zona BIND 9 em uma view não padrão, o Stork precisa de uma chave TSIG que permita ao BIND selecionar a view. As regras match-clients e allow-transfer fazem parte dessa decisão. Já as views introduzidas no PowerDNS 5.0 não são suportadas pelo Stork 2.4.1. Uma view ausente por esse limite não deve ser tratada como igual nem como divergente: ela é indisponível para aquela observação.

Há ainda dois caminhos de dados. A lista de zonas e seus seriais vem das integrações com os servidores e fica em cache depois de Fetch Zones. O conteúdo detalhado é pedido quando alguém escolhe Show Zone; nesse momento o agente usa AXFR e pode reapresentar uma cópia armazenada até Refresh from DNS. Um AXFR malsucedido pode impedir a leitura dos registros sem apagar um serial já presente no inventário. Ver o serial, por sua vez, não prova que todo o conteúdo foi transferido.

O monitoramento de transferências é uma terceira função. Os slides o identificam como novidade da versão de desenvolvimento 2.5.1. O manual do agente 2.5.1 diz que o rastreamento de logs XFR cobre apenas BIND, vem desativado por padrão e não acompanha eventos registrados somente em syslog. A página do Stork na ISC lista a 2.4.1 como estável e a 2.5.1 como desenvolvimento. O número da versão impede que visibilidades diferentes sejam somadas como se fossem uma só.

Nem o serial SOA é um contador comum. A RFC 1912 explica como o secundário consulta o serial do primário antes de pedir dados mais novos. A RFC 1982 define a aritmética circular de 32 bits: há retorno após o maior valor, e um par separado exatamente por metade do espaço não tem ordem definida.

As fontes sustentam que o Stork destaca valores diferentes. Elas não documentam qual rótulo de ordem é usado para todos os pares possíveis. O registro deve preservar os valores brutos e, se houver uma decisão de anterioridade, a regra e o resultado. “Diferente” é observação. “Este secundário está atrasado” acrescenta papel do servidor, tempo e semântica da RFC 1982.

Seriais iguais também não garantem conteúdo idêntico, DNSSEC válido ou a resposta vista pelo usuário. Essas perguntas têm seus próprios mecanismos de prova. A questão específica aqui vem antes: todos os servidores, views e configurações que deveriam participar apareceram na comparação?

Um recibo de cobertura não precisa expor chaves nem topologia sensível. Ele pode registrar versões do Stork server, dos agentes e dos daemons DNS; identidades estáveis de máquina, daemon, zona, classe e view; o inventário esperado e seu responsável; início, fim e estado por daemon de cada busca; Zone Configs Count e Distinct Zones; exclusões e limites de suporte; seriais brutos; horário observado ou armazenado e idade máxima; resultado, decisão de alerta e correções.

Com isso, a tela pode assumir quatro estados: completa para o escopo declarado, parcial por itens indisponíveis, vencida por falta de atualização ou não comparável porque a composição mudou. Uma divergência em um conjunto parcial continua verdadeira para aquele par. Zero divergências em um conjunto parcial não ganha alcance sobre aquilo que não foi visto.

Essa disciplina não reduz o valor do Stork. A vista central é justamente o que transforma sinais dispersos em um objeto operacional. O software fornece o conjunto observado. A organização fornece o conjunto esperado. A reconciliação entre ambos é o que permite usar uma diferença — ou a ausência dela — como decisão reproduzível.

Fontes