Meti internan solvilon unue kaj publikan solvilon due ne diras al Squid, kiuj nomoj apartenas al kiu nomspaco.

En Squid 6 kaj 7, dns_nameservers anstataŭigas la kutiman solvilan liston per servilaj adresoj. Ĝia sintakso ne havas mapadon laŭ domajno. Valida negativa respondo ankaŭ malsamas de neatingebla solvilo, do alternativoj ne estas fidinda maniero serĉi en malkongruaj nomspacoj.

Enkursigi demandojn laŭ domajno

Loka DNS-plusendilo povas esprimi la mankantan politikon. En ekzistanta dnsmasq-agordo, privata sufikso povas esti enkursigita tiel:

server=/internal.example/192.0.2.53

Anstataŭigu la domajnon kaj la adreson. Agordu aprobitan defaŭltan upstream por aliaj nomoj, taŭgan aŭskultanton kaj alirlimigojn. Poste direktu Squid al tiu solvilo per la agordo subtenata de la instalita versio.

Alternative uzu organizan DNS-servon, kiu ĝuste solvas ambaŭ nomspacojn. Evitu publikan rezervon, kiu malkaŝas privatajn nomojn sen povi respondi al ili.

Se gepatra prokura servilo faras la celan serĉon, tiu salto bezonas la privatan nomspacon. Solvilo sur la loka Squid-gastiganto ne riparos la serĉon de la gepatra prokura servilo.

Kontrolu ankaŭ la negativan kazon

Elektu validan privatan nomon, validan publikan nomon kaj neekzistantan privatan nomon. Por ĉiu, identigu la celatan upstream kaj ĉu la atendata respondo estas adreso aŭ negativa respondo. La lasta kazo malkaŝas hazardan publikan rezervon post interna negativa respondo.

Inkluzivu la adresajn familiojn postulatajn de la kliento. Funkcianta A-serĉo ne pruvas, ke AAAA sekvas la politikon aŭ redonas atingeblan celon. Notu ankaŭ la kaŝmemoran staton: kaŝita respondo povas kaŝi, kiun upstream freŝa demando elektus.

Rilataj artikoloj