Posar un resolutor intern primer i un resolutor públic segon no diu a Squid quins noms pertanyen a cada espai de noms.

A Squid 6 i 7, dns_nameservers substitueix la llista habitual de resolutors per adreces de servidor. La seva sintaxi no té assignació per domini. Una resposta negativa vàlida també difereix d'un resolutor inabastable, així que els alterns no són una manera fiable de cercar en espais de noms incompatibles.

Encamineu les consultes per domini

Un reenviador DNS local pot expressar la política que falta. En una configuració dnsmasq existent, un sufix privat es pot encaminar així:

server=/internal.example/192.0.2.53

Substituïu el domini i l'adreça. Configureu un upstream predeterminat aprovat per als altres noms, un listener adequat i restriccions d'accés. Després apunteu Squid a aquest resolutor amb la configuració que admet la versió instal·lada.

Com a alternativa, feu servir un servei DNS organitzatiu que resolgui correctament tots dos espais de noms. Eviteu un retrocés públic que exposi noms privats sense poder-hi respondre.

Si un proxy pare fa la cerca de destinació, aquest salt necessita l'espai de noms privat. Un resolutor a l'amfitrió local de Squid no arreglarà la cerca del proxy pare.

Comproveu també el cas negatiu

Trieu un nom privat vàlid, un nom públic vàlid i un nom privat inexistent. Per a cada un, identifiqueu l'upstream previst i si la resposta esperada és una adreça o una resposta negativa. L'últim cas revela un retrocés públic accidental després d'una resposta negativa interna.

Incloeu les famílies d'adreces que requereixi el client. Una cerca A que funcioni no demostra que AAAA segueixi la política ni que retorni una destinació abastable. Anoteu també l'estat de la memòria cau: una resposta desada pot amagar quin upstream triaria una consulta nova.

Articles relacionats