Att sätta en intern resolver först och en offentlig resolver som nummer två talar inte om för Squid vilka namn som hör till vilken namnrymd.

I Squid 6 och 7 ersätter dns_nameservers den vanliga resolverlistan med serveradresser. Syntaxen har ingen mappning per domän. Ett giltigt negativt svar skiljer sig också från en onåbar resolver, så alternativ är inte ett pålitligt sätt att söka i inkompatibla namnrymder.

Dirigera frågor efter domän

En lokal DNS-vidarebefordrare kan uttrycka den saknade policyn. I en befintlig dnsmasq-konfiguration kan ett privat suffix dirigeras så här:

server=/internal.example/192.0.2.53

Byt ut domänen och adressen. Konfigurera en godkänd standard-upstream för andra namn, en lämplig lyssnare och åtkomstbegränsningar. Peka sedan Squid mot den resolvern med den konfiguration som den installerade versionen stöder.

Alternativt kan du använda en organisatorisk DNS-tjänst som löser båda namnrymderna korrekt. Undvik en offentlig reservväg som avslöjar privata namn utan att kunna svara på dem.

Om en överordnad proxy gör destinationsuppslaget, behöver det hoppet den privata namnrymden. En resolver på den lokala Squid-värden åtgärdar inte den överordnade proxyns uppslag.

Kontrollera även det negativa fallet

Välj ett giltigt privat namn, ett giltigt offentligt namn och ett icke-existerande privat namn. För varje namn, identifiera den avsedda upstreamen och om det förväntade svaret är en adress eller ett negativt svar. Det sista fallet avslöjar en oavsiktlig offentlig reservväg efter ett internt negativt svar.

Ta med de adressfamiljer som klienten kräver. Ett fungerande A-uppslag bevisar inte att AAAA följer policyn eller returnerar en nåbar destination. Notera också cachetillståndet: ett sparat svar kan dölja vilken upstream en ny fråga skulle välja.

Relaterade artiklar