BIND sobre uma VPN: encaminhamento condicional ou zona stub?

O seu resolver de escritório responde a tudo excepto a um espaço de nomes corporativo, e o servidor DNS corporativo que o conhece está atrás de uma VPN. O BIND pode entregar essa única zona ao upstream de três formas diferentes, e falham de forma diferente. O encaminhamento condicional é o compromisso mais pequeno, uma zona stub mantém os dados de delegação e uma secondary mantém uma cópia completa. Escolha pelo que o upstream permitirá e pelo que quer que o seu resolver mantenha, não pelo fragmento que encontrou primeiro.

Três disposições para um espaço de nomes

Encaminhamento condicional: o compromisso mais pequeno

Suponha um resolver de escritório em 192.168.10.53 e um servidor corporativo em 10.40.0.53 acessível por um túnel aprovado. A declaração tem três linhas, e a interessante é forward only, porque altera o comportamento em caso de falha, não o caminho.

zone "corp.example" {
    type forward;
    forward only;
    forwarders { 10.40.0.53; };
};

Com forward only, um upstream inalcançável produz um SERVFAIL para esta zona em vez de recuar para a resolução iterativa. É normalmente o que quer para um espaço de nomes privado, porque o recuo enviaria nomes privados para um resolver público e devolveria uma resposta inútil da internet. A referência do BIND documenta ambas as políticas, e a diferença importa mais do que o fragmento sugere. Incorpore a zona na configuração existente em vez de substituir uma zona que já existe para o mesmo nome.

Stub ou secondary: quando a delegação importa

Uma zona stub pede ao servidor corporativo os registos NS da zona e depois consulta diretamente os servidores autoritativos. Escolha-a quando a região do upstream é grande ou subdividida e quer que o seu resolver siga a delegação em vez de fixar tudo num único endereço. O custo é uma dependência de que os dados NS estejam atualizados e de que cada servidor de nomes listado seja acessível a partir do endereço de origem do seu resolver.

zone "corp.example" {
    type stub;
    masters { 10.40.0.53; };
};

zone "corp.example" {
    type secondary;
    primaries { 10.40.0.53; };
    file "corp.example.db";
};

Uma secondary responde a partir de dados locais e sobrevive a uma falha do upstream, e é essa a razão para aceitar a dependência da transferência. Também significa que o seu resolver guarda agora uma cópia de uma zona que não possui, pelo que o caminho do ficheiro, a ACL de transferência no primário e os temporizadores de atualização passam todos a fazer parte da sua superfície operacional.

A verificação que decide entre elas

O BIND gera a sua própria consulta de saída, por isso a questão não é se um portátil consegue chegar a 10.40.0.53, mas se o anfitrião do resolver consegue, a partir do endereço de origem que o servidor corporativo verá. Pergunte ao kernel e depois ao servidor, nessa ordem.

ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example

Permita UDP e TCP no caminho: uma resposta truncada força TCP, e uma política que só permite UDP produz falhas intermitentes que parecem perda de pacotes. O lado corporativo precisa tanto de uma regra de aceitação para a origem do seu resolver como de uma rota de retorno para ela; essa origem pode ser o endereço encaminhado do resolver ou um traduzido explicitamente, e raramente é um endereço de um pool de clientes. Se a consulta NS falhar, uma zona stub não pode funcionar, independentemente do comportamento da zona forward.

Verifique a resposta, não o túnel

Consulte através do resolver de escritório um nome que nunca pediu e veja a secção authority da resposta para saber se veio da zona corporativa. Uma resposta em cache não prova nada sobre o caminho atual, e uma consulta direta bem-sucedida ao upstream não prova que o seu resolver escolheu essa zona. Repita a mesma consulta por TCP para confirmar que o caminho sobrevive ao truncamento.

Mantenha os clientes apontados ao resolver de escritório, e mantenha a validação DNSSEC ativa. Um navegador configurado com um resolver cifrado independente contorna totalmente esta disposição, e desativar a validação para que uma resposta inesperada pareça correta troca uma falha visível por uma invisível.

Anote qual dos três tipos escolheu e porquê. A próxima pessoa que vir a zona falhar precisará mais dessa frase do que do ficheiro de configuração.