Resumo

  • George Michaelson escreveu que seu backup de DNS existia apenas em teoria; ao reiniciar o suposto principal, descobriu que aquela era a única instância.
  • DHCP e anúncios de roteador podem fornecer vários endereços de resolvedores, mas a lista não prova que os clientes guardaram ou usaram a alternativa.
  • Um registro proporcional deve separar endpoint ativo, domínio de falha, configuração anunciada, estado no cliente, resposta útil, política local e reversão.

George Michaelson publicou em 9 de setembro, no blog da APNIC, uma experiência com Pi-hole e AdGuard como DNS interno de sua casa. Não foi um comunicado sobre serviços de produção da APNIC; a própria página atribui as opiniões ao autor. O episódio é valioso justamente por sua escala. Michaelson acreditava ter um plano de backup, mas não o havia implementado. Quando reiniciou o serviço que chamava de principal, equipamentos dependentes pararam. O “principal” era a única instância.

Não há no texto duração da interrupção, diagrama, inventário de aparelhos, captura de pacotes ou efeito de segurança. Não é necessário inventar nada disso. O fato publicado já permite distinguir desejo de estado operacional. Um segundo resolvedor pode aparecer num desenho sem estar rodando. Pode rodar sem ter seu endereço distribuído. O endereço pode ser distribuído e não permanecer em todos os clientes. E o cliente pode alcançar o backup sem receber as mesmas regras de bloqueio ou redirecionamento.

A lacuna existia antes da reinicialização

A interrupção apareceu com o reboot; a ausência de resiliência já estava lá. Essa ordem muda a leitura da manutenção. Desligar um endpoint parece uma operação limitada quando se supõe haver alternativa testada. Se a alternativa é só uma intenção, a mudança vira um ensaio de dependências em usuários reais.

Michaelson relata que reiniciar o DNS interrompia outras funções da casa, que alterações no roteador podiam derrubar a rede sem fio e que mudar o DNS do roteador afetava o DHCP. As perguntas certas passam a ser: quais equipamentos dependem do componente, se adotarão o serviço alternativo e se o estado anterior pode ser restaurado.

Duas instâncias não respondem sozinhas. Dois processos no mesmo host compartilham a falha do host. Duas máquinas na mesma alimentação compartilham o corte. Dois endereços enviados pelo mesmo roteador compartilham sua indisponibilidade e seus erros. Duas configurações clonadas do mesmo arquivo errado compartilham a causa administrativa. Independência só é demonstrada quando se nomeia a falha que não elimina os dois caminhos.

Endereço anunciado não é caminho comprovado

A RFC 2132 permite que a opção 6 do DHCPv4 entregue uma lista de servidores DNS em ordem de preferência. A RFC 3646 faz o correspondente no DHCPv6, com um ou mais endereços IPv6 de servidores recursivos. A RFC 8106 autoriza anúncios de roteador IPv6 a transportar endereços RDNSS com um tempo de vida; valor zero retira o endereço de uso.

Esses mecanismos provam a intenção do lado que provisiona. Uma captura mostra o que o roteador ou DHCP emitiu naquele instante. Não mostra o que uma televisão, telefone, notebook ou sensor guardou e escolheu. A RFC 6419 registrou pouca uniformidade entre sistemas de múltiplas interfaces: alguns conservam listas por interface, outros uma lista global, com escolhas diferentes quando chegam várias configurações. É um retrato histórico, não um levantamento dos aparelhos da casa de Michaelson. Mesmo assim, impede que a tela do roteador seja tratada como estado de todos os clientes.

A RFC 9520 observa que um resolvedor stub pode ter vários endereços recursivos e tentar outro servidor ou transporte. Ela não garante quando um cliente específico fará isso. Só há falha de resolução quando nenhum servidor disponível entrega dados úteis para a consulta. Portanto, entre “dois endereços foram anunciados” e “o usuário recebeu resposta útil durante a falha” há um comportamento que precisa ser observado.

Disponibilidade sem a mesma política

O DNS do relato não era apenas um encaminhador. Michaelson diz que redirecionava alguns nomes conhecidos para endereços sem raiz. Um backup pode responder consultas comuns e, ainda assim, não reproduzir bloqueios ou respostas locais. A conectividade volta, mas o comportamento que motivou a operação própria se perde.

A fonte não demonstra desvio real nem incidente de segurança. A conclusão correta é limitada: o teste deve verificar tanto continuidade de resolução quanto coerência da política local. Se só a primeira passar, o resultado é parcial.

Um comprovante curto basta

A objeção mais forte é a proporção. O próprio autor admite que a maioria das casas tolera falhas ocasionais e não precisa de redundância empresarial. Manter dois serviços, sincronizar regras e testar aparelhos diferentes pode custar mais que a breve indisponibilidade evitada.

O registro pode ser simples. Anotar os resolvedores A e B, onde executam e quais dependências compartilham; capturar endereços e validades emitidos por DHCPv4, DHCPv6 ou RDNSS; verificar alguns clientes distintos; retirar por pouco tempo o preferido; consultar um nome comum e outro sujeito à regra local; registrar o endpoint usado quando isso for observável; restaurar a configuração anterior.

O ensaio não cobre todo aparelho, consulta ou modo de falha. Ele fecha um caso delimitado e preserva as incertezas. A alternativa em execução transforma plano em backup; o uso pelo cliente transforma backup em resiliência; a reversão comprovada torna essa resiliência administrável.

Fontes