Squid Split DNS: rut private domener gjennom riktig resolver

Å sette en intern resolver først og en offentlig resolver som nummer to forteller ikke Squid hvilke navn som hører til hvilket navnerom.

I Squid 6 og 7 erstatter dns_nameservers den vanlige resolverlisten med serveradresser. Syntaksen har ingen tilordning per domene. Et gyldig negativt svar er også forskjellig fra en utilgjengelig resolver, så alternativer er ikke en pålitelig måte å søke i inkompatible navnerom.

Rut forespørsler etter domene

En lokal DNS-videresender kan uttrykke den manglende policyen. I en eksisterende dnsmasq-konfigurasjon kan et privat suffiks rutes slik:

server=/internal.example/192.0.2.53

Erstatt domenet og adressen. Konfigurer en godkjent standard-upstream for andre navn, en passende lytter og tilgangsbegrensninger. Pek deretter Squid mot den resolveren med konfigurasjonen den installerte versjonen støtter.

Alternativt kan du bruke en organisatorisk DNS-tjeneste som løser begge navnerommene riktig. Unngå en offentlig fallback som avdekker private navn uten å kunne svare på dem.

Hvis en overordnet proxy utfører destinasjonsoppslaget, trenger det hoppet det private navnerommet. En resolver på den lokale Squid-verten retter ikke opp den overordnede proxyens oppslag.

Kontroller også det negative tilfellet

Velg et gyldig privat navn, et gyldig offentlig navn og et ikke-eksisterende privat navn. For hvert av dem må du identifisere den tiltenkte upstreamen og om det forventede svaret er en adresse eller et negativt svar. Det siste tilfellet avdekker utilsiktet offentlig fallback etter et internt negativt svar.

Ta med adressefamiliene klienten krever. Et fungerende A-oppslag beviser ikke at AAAA følger policyen eller returnerer en tilgjengelig destinasjon. Legg også merke til cachetilstanden: et bufret svar kan skjule hvilken upstream en fersk forespørsel ville valgt.