Dois sites, uma zona DNS privada: de quem são os registos?

Adiciona um anfitrião no site verde, ele resolve para os utilizadores verdes, e o escritório amarelo continua a receber NXDOMAIN. Não é uma falha de VPN nem um resolvedor avariado; é uma lacuna de propriedade dentro da zona privada. Duas listas de registos editadas em separado não se tornam uma só zona só porque os sites se conseguem alcançar. A solução é um plano de publicação, não outra regra de firewall.

O sintoma nomeia o proprietário ausente

Cada site tem provavelmente uma substituição local, uma entrada Pi-hole ou uma linha dnsmasq que alguém acrescentou quando era preciso um nome. O registo verde só existe no resolvedor verde, por isso um cliente no amarelo pergunta ao seu próprio resolvedor e recebe um "não existe esse nome" verdadeiro. Uma resposta desatualizada parece diferente: o anfitrião mudou-se, um site atualizou a sua cópia e o outro continua a devolver o endereço antigo.

Nenhum dos padrões se corrige durante muito tempo com uma limpeza de cache. A cache de um resolvedor de encaminhamento é uma cópia de uma resposta que recebeu uma vez, não uma autoridade que publica novos nomes, por isso uma cache que funciona hoje não diz nada sobre o anfitrião de amanhã. A documentação do BIND descreve os papéis primário, secundário, recursivo e de encaminhamento em separado exatamente por esta razão.

Assim, a pergunta de conceção é estreita e tem resposta: quem pode criar um registo, e como chega esse registo a cada resolvedor que tem de responder por ele?

Opção A: uma zona autoritativa com secundários

Execute um primário para internal.example.com e deixe que os secundários suportados obtenham a zona em cada site. O resolvedor recursivo de cada site consulta o seu secundário local, por isso as respostas vêm de uma fonte autoritativa e não de uma cache, e uma alteração feita uma vez é transferida em vez de ser reescrita.

Essa disposição exige decisões explícitas, fáceis de adiar e caras de omitir. Quem pode editar a zona? Que servidores podem transferi-la, e através de que endereços? O que devem os clientes ver enquanto o túnel entre sites está em baixo? Um secundário continua a responder a partir da sua última cópia, o que normalmente é o comportamento desejado, mas tem de ser uma escolha declarada e não uma surpresa durante uma falha.

Limite as transferências de zona aos secundários conhecidos por endereço e use assinaturas de transação onde a implementação as suporta. Uma transferência aberta é uma cópia do seu espaço de nomes interno para quem conseguir alcançar a porta.

O custo é a coordenação: um único caminho de edição, uma única revisão de alterações e um entendimento partilhado de quem está de prevenção quando um registo está errado.

Opção B: um subdomínio por site

Delegue green.internal.example.com ao site verde e yellow.internal.example.com ao amarelo. Cada site torna-se autoritativo para os seus próprios nomes, e a zona principal transporta apenas os registos de delegação. A disputa por um único ficheiro desaparece, e uma equipa local pode acrescentar um anfitrião sem esperar por uma alteração central.

A delegação tem de existir na zona principal, com registos NS que apontem para os servidores autoritativos do site. Um encaminhamento condicional para o subdomínio é uma alternativa válida quando uma delegação completa não é prática, mas é uma configuração do resolvedor e não um facto publicado, por isso cada resolvedor precisa da mesma regra.

O custo desloca-se em vez de desaparecer: a zona principal continua a precisar de um proprietário, e criar um novo site é agora uma alteração em dois locais em vez de um.

Faça com que cada resolvedor siga a escolha

Forneça aos clientes o resolvedor aprovado e o domínio de pesquisa através da configuração suportada, e garanta que o resolvedor tem uma rota VPN permitida para qualquer servidor DNS remoto que tenha de consultar. As aplicações também precisam de rotas para os endereços privados que essas respostas devolvem, porque um nome correto sem caminho continua a ser uma ligação quebrada.

Se o Pi-hole fornece resolução local, anote que registos possui e que consultas encaminha. Duas listas Pi-hole editadas em separado continuam a não se replicar. No Pi-hole v6, as linhas dnsmasq personalizadas definem-se através de opções do lado do anfitrião como TOML, CLI ou variáveis de ambiente e não são expostas pela API; carregar ficheiros de /etc/dnsmasq.d/ é uma opção separada que está desactivada por predefinição.

Depois teste dos dois lados com um nome que devia ser visível em todo o lado:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

A resposta SOA diz-lhe se o resolvedor amarelo se considera autoritativo, se está a consultar um secundário ou se apenas encaminha. São conceções diferentes com modos de falha diferentes, e a resposta normalmente identifica qual implementou de facto.

Termine com três casos de aceitação: um nome de cada site, um registo alterado dentro da hora e a ligação entre sites indisponível. Uma conceção que só passa o primeiro tem um plano de publicação no papel e uma substituição local em produção.