BIND sobre una VPN: ¿reenvío condicional o zona stub?

Su resolver de oficina responde a todo menos a un espacio de nombres corporativo, y el servidor DNS corporativo que lo conoce está detrás de una VPN. BIND puede entregar esa única zona al upstream de tres maneras distintas, y fallan de forma distinta. El reenvío condicional es el compromiso más pequeño, una zona stub conserva los datos de delegación y una secondary conserva una copia completa. Elija según lo que permita el upstream y lo que quiera que guarde su resolver, no según qué fragmento encontró primero.

Tres disposiciones para un espacio de nombres

Reenvío condicional: el compromiso más pequeño

Suponga un resolver de oficina en 192.168.10.53 y un servidor corporativo en 10.40.0.53 accesible por un túnel aprobado. La declaración son tres líneas, y la interesante es forward only, porque cambia el comportamiento ante un fallo, no la 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 de una caída a la resolución iterativa. Eso suele ser lo que quiere para un espacio de nombres privado, porque la caída enviaría nombres privados a un resolver público y devolvería una respuesta inútil de internet. La referencia de BIND documenta ambas políticas, y la diferencia importa más de lo que sugiere el fragmento. Incorpore la zona a la configuración existente en lugar de sustituir una zona que ya existe para el mismo nombre.

Stub o secondary: cuándo importa la delegación

Una zona stub pide al servidor corporativo los registros NS de la zona y luego consulta directamente a los servidores autoritativos. Elíjala cuando la región del upstream sea grande o esté subdividida y quiera que su resolver siga la delegación en lugar de fijarlo todo a una dirección. El coste es una dependencia de que los datos NS estén al día y de que cada servidor de nombres listado sea accesible desde la dirección de origen de su 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";
};

Una secondary responde con datos locales y sobrevive a una caída del upstream, y esa es la razón para aceptar la dependencia de la transferencia. También significa que su resolver ahora guarda una copia de una zona que no posee, así que la ruta del archivo, la ACL de transferencia en el primario y los temporizadores de refresco pasan a formar parte de su superficie operativa.

La comprobación que decide entre ellas

BIND genera su propia consulta saliente, así que la pregunta no es si un portátil puede llegar a 10.40.0.53, sino si puede el host del resolver, desde la dirección de origen que verá el servidor corporativo. Pregunte al núcleo y luego al servidor, en ese orden.

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 y TCP en la ruta: una respuesta truncada fuerza TCP, y una política que solo permite UDP produce fallos intermitentes que parecen pérdida de paquetes. El lado corporativo necesita tanto una regla de aceptación para el origen de su resolver como una ruta de vuelta hacia él; ese origen puede ser la dirección enrutada del resolver o una traducida explícitamente, y rara vez es una dirección de un pool de clientes. Si la consulta NS falla, una zona stub no puede funcionar haga lo que haga la zona forward.

Verifique la respuesta, no el túnel

Consulte a través del resolver de oficina un nombre que nunca haya pedido y mire la sección de autoridad de la respuesta para ver si vino de la zona corporativa. Una respuesta en caché no demuestra nada sobre la ruta actual, y una consulta directa exitosa al upstream no demuestra que su resolver eligiera esa zona. Repita la misma consulta por TCP para confirmar que la ruta sobrevive al truncamiento.

Mantenga a los clientes apuntando al resolver de oficina, y mantenga activada la validación DNSSEC. Un navegador configurado con un resolver cifrado independiente elude por completo esta disposición, y desactivar la validación para que una respuesta inesperada parezca correcta cambia un fallo visible por uno invisible.

Anote cuál de los tres tipos eligió y por qué. La próxima persona que vea fallar la zona necesitará esa frase más que el archivo de configuración.