Via oficeja resolvilo respondas ĉion krom unu kompania nomspaco, kaj la kompania DNS-servilo kiu konas ĝin staras malantaŭ VPN. BIND povas transdoni tiun ununuran zonon al la upstream laŭ tri malsamaj manieroj, kaj ili malsukcesas malsame. Kondiĉa plusendo estas la plej malgranda engaĝiĝo, stub-zono konservas la delegaciajn datumojn, kaj secondary konservas plenan kopion. Elektu laŭ tio, kion la upstream permesos kaj kion vi volas ke via resolvilo konservu, ne laŭ tio, kiun fragmenton vi trovis unue.

Tri aranĝoj por unu nomspaco

TypeWhat your resolver keepsUpstream mustFails when
forwarda forwarder listanswer queries from your source addressupstream is down and forward only is set
stubthe zone's NS records and addressesanswer NS queries for the zonedelegation data goes stale after an NS change
secondarya full copy of the zonepermit AXFR or IXFR from your sourcetransfer is blocked by ACL or firewall

Kondiĉa plusendo: la plej malgranda engaĝiĝo

Supozu oficejan resolvilon ĉe 192.168.10.53 kaj kompanian servilon ĉe 10.40.0.53 atingeblan tra aprobita tunelo. La deklaro estas tri linioj, kaj la interesa estas forward only, ĉar ĝi ŝanĝas la malsukcesan konduton, ne la vojon.

zone "corp.example" {
    type forward;
    forward only;
    forwarders { 10.40.0.53; };
};

Kun forward only, neatingebla upstream produktas SERVFAIL por ĉi tiu zono anstataŭ fallback al ripeta solvado. Tio estas kutime tio, kion vi volas por privata nomspaco, ĉar la fallback sendus privatajn nomojn al publika resolvilo kaj redonus senutilan respondon el la interreto. La BIND-referenco dokumentas ambaŭ politikojn, kaj la diferenco pli gravas ol la fragmento sugestas. Kunfandu la zonon en la ekzistantan agordon anstataŭ anstataŭigi zonon kiu jam ekzistas por la sama nomo.

Stub aŭ secondary: kiam la delegacio gravas

Stub-zono demandas al la kompania servilo la NS-rikordojn de la zono kaj poste demandas la aŭtoritatajn servilojn rekte. Elektu ĝin kiam la upstream-regiono estas granda aŭ subdividita kaj vi volas ke via resolvilo sekvu la delegacion anstataŭ fiksi ĉion al unu adreso. La kosto estas dependeco de tio, ke la NS-datumoj estu aktualaj, kaj de tio, ke ĉiu listigita nomservilo estu atingebla el la fontadreso de via resolvilo.

zone "corp.example" {
    type stub;
    masters { 10.40.0.53; };
};

zone "corp.example" {
    type secondary;
    primaries { 10.40.0.53; };
    file "corp.example.db";
};

Secondary respondas el lokaj datumoj kaj postvivas halton de upstream, kaj tio estas la kialo akcepti la transigan dependon. Ĝi ankaŭ signifas ke via resolvilo nun tenas kopion de zono kiun ĝi ne posedas, do la dosierpatho, la transiga ACL sur la primara kaj la refreŝigaj tempigiloj ĉiuj fariĝas parto de via operacia surfaco.

La kontrolo kiu decidas inter ili

BIND generas sian propran elirantan peton, do la demando ne estas ĉu tekkomputilo povas atingi 10.40.0.53 sed ĉu la gastiganto de la resolvilo povas, el la fontadreso kiun la kompania servilo vidos. Demantu al la kerno, poste demantu al la servilo, en tiu ordo.

ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example

Permesu UDP kaj TCP sur la vojo: tranĉita respondo devigas TCP, kaj politiko kiu permesas nur UDP produktas intermitajn fiaskojn kiuj aspektas kiel pakperdo. La kompania flanko bezonas kaj akceptan regulon por la fonto de via resolvilo kaj revenan vojon al ĝi; tiu fonto povas esti la enkursigita adreso de la resolvilo aŭ eksplicite tradukita, kaj ĝi malofte estas adreso de klienta aro. Se la NS-peto fiaskas, stub-zono ne povas funkcii sendepende de tio, kiel la forward-zono kondutas.

Kontrolu la respondon, ne la tunelon

Petu tra la oficeja resolvilo nomon kiun vi neniam demandis, kaj kontrolu la authority-sekcion de la respondo por vidi ĉu ĝi venis el la kompania zono. Kaŝmemorita respondo pruvas nenion pri la nuna vojo, kaj sukcesa rekta peto al la upstream ne pruvas ke via resolvilo elektis tiun zonon. Ripetu la saman peton tra TCP por konfirmi ke la vojo postvivas tranĉon.

Tenu klientojn direktitaj al la oficeja resolvilo, kaj tenu DNSSEC-validadon ŝaltita. Retumilo agordita kun sendependa ĉifrita resolvilo tute preterpasas ĉi tiun aranĝon, kaj malŝalti validumon por ke neatendita respondo aspektu ĝusta interŝanĝas videblan fiaskon kontraŭ nevidebla.

Notu kiun el la tri tipoj vi elektis kaj kial. La sekva persono kiu vidos la zonon fiaski bezonos tiun frazon pli ol la agordan dosieron.

Rilataj artikoloj