Å setje ein intern resolver først og ein offentleg resolver som nummer to fortel ikkje Squid kva namn som høyrer til kva namnerom.

I Squid 6 og 7 byter dns_nameservers ut den vanlege resolverlista med tenaradresser. Syntaksen har inga tilordning per domene. Eit gyldig negativt svar er òg ulikt ein utilgjengeleg resolver, så alternativ er ikkje ein påliteleg måte å søkje i inkompatible namnerom.

Rut førespurnader etter domene

Ein lokal DNS-vidaresendar kan uttrykkje den manglande policyen. I ein eksisterande dnsmasq-konfigurasjon kan eit privat suffiks ruttast slik:

server=/internal.example/192.0.2.53

Byt ut domenet og adressa. Konfigurer ein godkjend standard-upstream for andre namn, ein høveleg lyttar og tilgangsavgrensingar. Peik deretter Squid mot den resolveren med konfigurasjonen den installerte versjonen støttar.

Alternativt kan du bruke ein organisatorisk DNS-teneste som løyser begge namneromma rett. Unngå ein offentleg fallback som avdekkjer private namn utan å kunne svare på dei.

Viss ein overordna proxy gjer destinasjonsoppslaget, treng det hoppet det private namnerommet. Ein resolver på den lokale Squid-verten rettar ikkje opp oppslaget til den overordna proxyen.

Kontroller òg det negative tilfellet

Vel eit gyldig privat namn, eit gyldig offentleg namn og eit ikkje-eksisterande privat namn. For kvart av dei må du identifisere den tiltenkte upstreamen og om det venta svaret er ei adresse eller eit negativt svar. Det siste tilfellet avdekkjer utilsikta offentleg fallback etter eit internt negativt svar.

Ta med adressefamiliane klienten krev. Eit fungerande A-oppslag beviser ikkje at AAAA følgjer policyen eller returnerer ein tilgjengeleg destinasjon. Legg òg merke til cachestatusen: eit bufra svar kan skjule kva upstream ein fersk førespurnad ville valt.

Relaterte artiklar