BIND super VPN: kondiĉa plusendo aŭ stub-zono?
Tri manieroj solvi unu privatan zonon tra VPN, kaj kiam taŭgas ĉiu: forward, stub aŭ secondary, kun la kontrolo de fontadreso kiu decidas.
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
| Type | What your resolver keeps | Upstream must | Fails when |
|---|---|---|---|
forward | a forwarder list | answer queries from your source address | upstream is down and forward only is set |
stub | the zone's NS records and addresses | answer NS queries for the zone | delegation data goes stale after an NS change |
secondary | a full copy of the zone | permit AXFR or IXFR from your source | transfer 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.