Squid Split DNS: enrutar dominios privados por el resolver correcto

Poner un resolver interno primero y un resolver público segundo no le dice a Squid qué nombres pertenecen a cada espacio de nombres.

En Squid 6 y 7, dns_nameservers sustituye la lista habitual de resolvers por direcciones de servidores. Su sintaxis no tiene asignación por dominio. Una respuesta negativa válida también difiere de un resolver inalcanzable, así que los alternos no son una forma fiable de buscar en espacios de nombres incompatibles.

Enrutar las consultas por dominio

Un reenviador DNS local puede expresar la política que falta. En una configuración existente de dnsmasq, un sufijo privado se puede enrutar así:

server=/internal.example/192.0.2.53

Sustituya el dominio y la dirección. Configure un upstream predeterminado aprobado para otros nombres, un listener adecuado y restricciones de acceso. Después apunte Squid a ese resolver con la configuración que admita la versión instalada.

Como alternativa, use un servicio DNS organizativo que resuelva correctamente ambos espacios de nombres. Evite un respaldo público que exponga nombres privados sin poder responder a ellos.

Si un proxy principal realiza la búsqueda del destino, ese salto necesita el espacio de nombres privado. Un resolver en el host local de Squid no corregirá la búsqueda del proxy principal.

Compruebe también el caso negativo

Elija un nombre privado válido, un nombre público válido y un nombre privado inexistente. Para cada uno, identifique el upstream previsto y si la respuesta esperada es una dirección o una respuesta negativa. El último caso revela un respaldo público accidental tras una respuesta negativa interna.

Incluya las familias de direcciones que requiera el cliente. Una búsqueda A que funcione no demuestra que AAAA siga la política ni que devuelva un destino alcanzable. Anote también el estado de la caché: una respuesta almacenada puede ocultar qué upstream elegiría una consulta nueva.