BIND sobre unha VPN: reenvío condicional ou zona stub?

O teu resolver de oficina responde a todo agás a un espazo de nomes corporativo, e o servidor DNS corporativo que o coñece está detrás dunha VPN. BIND pode entregar esa única zona ao upstream de tres maneiras distintas, e fallan de forma distinta. O reenvío condicional é o compromiso máis pequeno, unha zona stub conserva os datos de delegación e unha secondary conserva unha copia completa. Escolle segundo o que permita o upstream e o que queiras que garde o teu resolver, non segundo o fragmento que atopaches primeiro.

Tres disposicións para un espazo de nomes

Reenvío condicional: o compromiso máis pequeno

Supón un resolver de oficina en 192.168.10.53 e un servidor corporativo en 10.40.0.53 accesible por un túnel aprobado. A declaración son tres liñas, e a interesante é forward only, porque cambia o comportamento ante un fallo, non a ruta.

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

Con forward only, un upstream inalcanzable produce un SERVFAIL para esta zona en lugar dunha caída á resolución iterativa. Iso adoita ser o que queres para un espazo de nomes privado, porque a caída enviaría nomes privados a un resolver público e devolvería unha resposta inútil de internet. A referencia de BIND documenta ambas as políticas, e a diferenza importa máis do que suxire o fragmento. Incorpora a zona á configuración existente en lugar de substituír unha zona que xa existe para o mesmo nome.

Stub ou secondary: cando importa a delegación

Unha zona stub pide ao servidor corporativo os rexistros NS da zona e despois consulta directamente os servidores autoritativos. Escóllea cando a rexión do upstream é grande ou está subdividida e queres que o teu resolver siga a delegación en lugar de fixalo todo a un enderezo. O custo é unha dependencia de que os datos NS estean actualizados e de que cada servidor de nomes listado sexa accesible desde o enderezo de orixe do teu 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";
};

Unha secondary responde con datos locais e sobrevive a unha caída do upstream, e esa é a razón para aceptar a dependencia da transferencia. Tamén significa que o teu resolver agora garda unha copia dunha zona que non posúe, así que a ruta do ficheiro, a ACL de transferencia no primario e os temporizadores de refresco pasan a formar parte da túa superficie operativa.

A comprobación que decide entre elas

BIND xera a súa propia consulta de saída, así que a pregunta non é se un portátil pode chegar a 10.40.0.53, senón se pode o host do resolver, desde o enderezo de orixe que verá o servidor corporativo. Pregunta ao núcleo e despois ao servidor, nesa orde.

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

Permite UDP e TCP na ruta: unha resposta truncada forza TCP, e unha política que só permite UDP produce fallos intermitentes que parecen perda de paquetes. O lado corporativo necesita tanto unha regra de aceptación para a orixe do teu resolver como unha ruta de volta cara a ela; esa orixe pode ser o enderezo encamiñado do resolver ou un traducido explicitamente, e raramente é un enderezo dun pool de clientes. Se a consulta NS falla, unha zona stub non pode funcionar faga o que faga a zona forward.

Verifica a resposta, non o túnel

Consulta a través do resolver de oficina un nome que nunca pediches e mira a sección de autoridade da resposta para ver se veu da zona corporativa. Unha resposta en caché non demostra nada sobre a ruta actual, e unha consulta directa exitosa ao upstream non demostra que o teu resolver elixise esa zona. Repite a mesma consulta por TCP para confirmar que a ruta sobrevive ao truncamento.

Mantén os clientes apuntando ao resolver de oficina, e mantén activada a validación DNSSEC. Un navegador configurado cun resolver cifrado independente elude por completo esta disposición, e desactivar a validación para que unha resposta inesperada pareza correcta troca un fallo visible por un invisible.

Anota cal dos tres tipos escolliches e por que. A próxima persoa que vexa fallar a zona necesitará esa frase máis que o ficheiro de configuración.