Pór un resolutor interno primeiro e un resolutor público segundo non lle di a Squid que nomes pertencen a cada espazo de nomes.

En Squid 6 e 7, dns_nameservers substitúe a lista habitual de resolutores por enderezos de servidor. A súa sintaxe non ten asignación por dominio. Unha resposta negativa válida tamén difire dun resolutor inalcanzable, así que os alternos non son un xeito fiable de buscar en espazos de nomes incompatibles.

Encamiñar as consultas por dominio

Un reenviador DNS local pode expresar a política que falta. Nunha configuración existente de dnsmasq, un sufixo privado pódese encamiñar así:

server=/internal.example/192.0.2.53

Substitúa o dominio e o enderezo. Configure un upstream predeterminado aprobado para outros nomes, un listener axeitado e restricións de acceso. Despois apunte Squid a ese resolutor coa configuración que admita a versión instalada.

Como alternativa, use un servizo DNS organizativo que resolva correctamente ambos espazos de nomes. Evite un retroceso público que expoña nomes privados sen poder responder a eles.

Se un proxy principal realiza a busca do destino, ese salto necesita o espazo de nomes privado. Un resolutor no host local de Squid non corrixirá a busca do proxy principal.

Comprobe tamén o caso negativo

Escolla un nome privado válido, un nome público válido e un nome privado inexistente. Para cada un, identifique o upstream previsto e se a resposta agardada é un enderezo ou unha resposta negativa. O último caso revela un retroceso público accidental tras unha resposta negativa interna.

Inclúa as familias de enderezos que requira o cliente. Unha busca A que funcione non demostra que AAAA siga a política nin que devolva un destino alcanzable. Anote tamén o estado da caché: unha resposta almacenada pode ocultar que upstream escollería unha consulta nova.

Artigos relacionados