At sætte en intern resolver først og en offentlig resolver som nummer to fortæller ikke Squid, hvilke navne der hører til hvilket navnerum.

I Squid 6 og 7 erstatter dns_nameservers den sædvanlige resolverliste med serveradresser. Syntaksen har ingen mapping pr. domæne. Et gyldigt negativt svar er også forskelligt fra en utilgængelig resolver, så alternativer er ikke en pålidelig måde at søge i uforenelige navnerum.

Send forespørgsler efter domæne

En lokal DNS-forwarder kan udtrykke den manglende politik. I en eksisterende dnsmasq-konfiguration kan et privat suffiks sendes sådan:

server=/internal.example/192.0.2.53

Erstat domænet og adressen. Konfigurer en godkendt standard-upstream til andre navne, en passende listener og adgangsbegrænsninger. Peg derefter Squid mod den resolver med den konfiguration, som den installerede version understøtter.

Alternativt kan du bruge en organisatorisk DNS-tjeneste, der opløser begge navnerum korrekt. Undgå en offentlig fallback, der afslører private navne uden at kunne svare på dem.

Hvis en overordnet proxy udfører destinationsopslaget, har det hop brug for det private navnerum. En resolver på den lokale Squid-vært retter ikke den overordnede proxys opslag.

Kontroller også det negative tilfælde

Vælg et gyldigt privat navn, et gyldigt offentligt navn og et ikke-eksisterende privat navn. For hvert navn skal du fastlægge den tilsigtede upstream og afgøre, om det forventede svar er en adresse eller et negativt svar. Det sidste tilfælde afslører utilsigtet offentlig fallback efter et internt negativt svar.

Medtag de adressefamilier, klienten kræver. Et fungerende A-opslag beviser ikke, at AAAA følger politikken eller returnerer en tilgængelig destination. Bemærk også cachetilstanden: et cachelagret svar kan skjule, hvilken upstream en frisk forespørgsel ville vælge.

Relaterede artikler