Om 'n interne resolver eerste en 'n publieke resolver tweede te plaas, sê nie vir Squid watter name aan watter naamruimte behoort nie.

In Squid 6 en 7 vervang dns_nameservers die gewone resolver-lys met bedieneradresse. Die sintaks het geen per-domein-kaart nie. 'n Geldige negatiewe antwoord verskil ook van 'n onbereikbare resolver, dus is alternatiewe nie 'n betroubare manier om onversoenbare naamruimtes te deursoek nie.

Lei navrae per domein

'n Plaaslike DNS-aanstuurder kan die ontbrekende beleid uitdruk. In 'n bestaande dnsmasq-opstelling kan 'n private agtervoegsel so gerouteer word:

server=/internal.example/192.0.2.53

Vervang die domein en adres. Stel 'n goedgekeurde verstek-upstream vir ander name, 'n geskikte luisteraar en toegangsbeperkings op. Wys dan Squid na daardie resolver met die opstelling wat die geïnstalleerde weergawe ondersteun.

Alternatiewelik, gebruik 'n organisatoriese DNS-diens wat beide naamruimtes korrek oplos. Vermy 'n publieke terugval wat private name blootstel sonder om hulle te kan beantwoord.

As 'n ouer-proxy die bestemming opsoek, het daardie hop die private naamruimte nodig. 'n Resolver op die plaaslike Squid-gasheer sal nie die ouer se opsoek regstel nie.

Toets ook die negatiewe geval

Kies 'n geldige private naam, 'n geldige publieke naam en 'n nie-bestaande private naam. Vir elkeen, identifiseer die beoogde upstream en of die verwagte antwoord 'n adres of 'n negatiewe antwoord is. Die laaste geval openbaar toevallige publieke terugval ná 'n interne negatiewe antwoord.

Sluit die adresfamilies in wat die kliënt vereis. 'n Werkende A-opsoek bewys nie dat AAAA die beleid volg of 'n bereikbare bestemming teruggee nie. Let ook op die kas-toestand: 'n gekaste antwoord kan wegsteek watter upstream 'n vars navraag sou kies.

Verwante artikels