Squid Split DNS: direcționarea domeniilor private prin resolverul corect

Punerea unui resolver intern primul și a unui resolver public al doilea nu îi spune lui Squid ce nume aparțin fiecărui spațiu de nume.

În Squid 6 și 7, dns_nameservers înlocuiește lista obișnuită de resolvere cu adrese de server. Sintaxa sa nu are mapare pe domeniu. Un răspuns negativ valid diferă și el de un resolver inaccesibil, așa că alternativele nu sunt o modalitate fiabilă de a căuta în spații de nume incompatibile.

Direcționarea interogărilor după domeniu

Un forwarder DNS local poate exprima politica lipsă. Într-o configurație dnsmasq existentă, un sufix privat poate fi direcționat astfel:

server=/internal.example/192.0.2.53

Înlocuiți domeniul și adresa. Configurați un upstream implicit aprobat pentru celelalte nume, un listener potrivit și restricții de acces. Apoi îndreptați Squid către acel resolver folosind configurația acceptată de versiunea instalată.

Alternativ, folosiți un serviciu DNS organizațional care rezolvă corect ambele spații de nume. Evitați un fallback public care expune nume private fără a le putea răspunde.

Dacă un proxy părinte face căutarea destinației, acel salt are nevoie de spațiul de nume privat. Un resolver pe gazda locală Squid nu va repara căutarea proxy-ului părinte.

Verificați și cazul negativ

Alegeți un nume privat valid, un nume public valid și un nume privat inexistent. Pentru fiecare, identificați upstream-ul dorit și dacă răspunsul așteptat este o adresă sau un răspuns negativ. Ultimul caz dezvăluie un fallback public accidental după un răspuns negativ intern.

Includeți familiile de adrese cerute de client. O căutare A funcțională nu dovedește că AAAA respectă politica sau returnează o destinație accesibilă. Notați și starea cache-ului: un răspuns stocat poate ascunde ce upstream ar alege o interogare nouă.