Resolver ya ofisi yako hujibu kila kitu isipokuwa nafasi moja ya majina ya shirika, na seva ya DNS ya shirika inayoijua iko nyuma ya VPN. BIND inaweza kukabidhi eneo hilo moja kwa upstream kwa njia tatu tofauti, na zinashindwa kwa namna tofauti. Uelekezaji wa masharti ni ahadi ndogo zaidi, eneo la stub huhifadhi data ya uwakilishi, na secondary huhifadhi nakala kamili. Chagua kwa kuzingatia kile upstream itaruhusu na kile unataka resolver yako ihifadhi, si kwa kuzingatia snippet gani uliipata kwanza.

Mipangilio mitatu kwa nafasi moja ya majina

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

Uelekezaji wa masharti: ahadi ndogo zaidi

Fikiria resolver ya ofisi iko 192.168.10.53 na seva ya shirika iko 10.40.0.53 inayofikika kupitia handaki iliyoidhinishwa. Tamko ni mistari mitatu, na inayovutia ni forward only, kwa sababu inabadilisha tabia ya kushindwa, si njia.

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

Pamoja na forward only, upstream isiyofikika hutoa SERVFAIL kwa eneo hili badala ya kurudi kwenye utatuzi wa kurudia. Kwa kawaida hii ndiyo unayotaka kwa nafasi ya faragha ya majina, kwa sababu kurudi kungetuma majina ya faragha kwa resolver ya umma na kurudisha jibu lisilo na maana kutoka mtandao. Marejeo ya BIND inaeleza sera zote mbili, na tofauti ni muhimu zaidi kuliko snippet inavyodokeza. Unganisha eneo katika usanidi uliopo badala ya kubadilisha eneo ambalo tayari lipo kwa jina hilohilo.

Stub au secondary: wakati uwakilishi ni muhimu

Eneo la stub huuliza seva ya shirika kuhusu rekodi za NS za eneo kisha huuliza seva zenye mamlaka moja kwa moja. Ichague wakati eneo la upstream ni kubwa au limegawanywa na unataka resolver yako ifuate uwakilishi badala ya kubandika kila kitu kwenye anwani moja. Gharama ni utegemezi wa data ya NS kuwa ya sasa, na wa kila seva ya majina iliyoorodheshwa kufikika kutoka anwani ya chanzo ya resolver yako.

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 hujibu kutoka data ya ndani na hustahimili kukatika kwa upstream, na hiyo ndiyo sababu ya kukubali utegemezi wa uhamishaji. Inamaanisha pia resolver yako sasa inashikilia nakala ya eneo ambalo si lake, kwa hivyo njia ya faili, ACL ya uhamishaji kwenye seva ya msingi na vipima muda vya kuonyesha upya vyote vinakuwa sehemu ya uso wako wa uendeshaji.

Ukaguzi unaoamua baina yao

BIND huzalisha swali lake la kutoka lenyewe, kwa hivyo swali si kama kompyuta mpakato inaweza kufikia 10.40.0.53 bali kama mwenyeji wa resolver anaweza, kutoka anwani ya chanzo ambayo seva ya shirika itaona. Uliza kernel, kisha uliza seva, kwa mpangilio huo.

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

Ruhusu UDP na TCP kwenye njia: jibu lililokatwa hulazimisha TCP, na sera inayoruhusu UDP pekee huzalisha kushindwa kwa vipindi kunakoonekana kama upotevu wa pakiti. Upande wa shirika unahitaji kanuni ya kukubali kwa chanzo cha resolver yako na njia ya kurudi kwayo; chanzo hicho kinaweza kuwa anwani iliyoelekezwa ya resolver au iliyotafsiriwa waziwazi, na mara chache ni anwani ya kundi la wateja. Ikiwa swali la NS litashindwa, eneo la stub haliwezi kufanya kazi, bila kujali eneo la forward linafanyaje.

Thibitisha jibu, si handaki

Uliza kupitia resolver ya ofisi kwa jina ambalo hukuwahi kuliomba, na angalia sehemu ya authority ya jibu ili kuona kama lilitoka kwenye eneo la shirika. Jibu lililohifadhiwa kwenye kashe halithibitishi chochote kuhusu njia ya sasa, na swali la moja kwa moja lililofanikiwa kwa upstream halithibitishi kwamba resolver yako ilichagua eneo hilo. Rudia swali hilo hilo kupitia TCP ili kuthibitisha kwamba njia inastahimili kukatwa.

Weka wateja wakielekezwa kwa resolver ya ofisi, na weka uthibitishaji wa DNSSEC ukiwa umewashwa. Kivinjari kilichosanidiwa na resolver ya usimbaji fiche huru hukwepa mpangilio huu kabisa, na kuzima uthibitishaji ili jibu lisilotarajiwa lionekane sahihi hubadilisha kushindwa kunakoonekana kwa kusikoonekana.

Andika ni aina ipi kati ya tatu uliyochagua na kwa nini. Mtu anayefuata atakayeona eneo likishindwa atahitaji sentensi hiyo kuliko faili ya usanidi.

Makala zinazohusiana