BIND yfir VPN: skilyrt framsend eða stub-svæði?

Resolver skrifstofunnar þinnar svarar öllu nema einu fyrirtækjanafnrými, og fyrirtækja-DNS-þjónninn sem þekkir það er bak við VPN. BIND getur afhent þetta eina svæði uppstreyminu á þrjá mismunandi vegu, og þau mistakast á mismunandi hátt. Skilyrt framsend er minnsta skuldbindingin, stub-svæði heldur delegunargögnunum, og secondary heldur fullri afriti. Veldu eftir því sem uppstreymið leyfir og því sem þú vilt að resolverinn þinn haldi, ekki eftir því hvaða brot þú fannst fyrst.

Þrjár ráðstafanir fyrir eitt nafnrými

Skilyrt framsend: minnsta skuldbindingin

Gerðu ráð fyrir resolver skrifstofu á 192.168.10.53 og fyrirtækjaþjóni á 10.40.0.53 sem er aðgengilegur um samþykkta göng. Yfirlýsingin er þrjár línur, og sú áhugaverða er forward only, því hún breytir biluninni, ekki slóðinni.

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

Með forward only gefur óaðgengilegt uppstreymi SERVFAIL fyrir þetta svæði í stað þess að falla aftur í endurtekna leysingu. Það er venjulega það sem þú vilt fyrir einkaaðgengilegt nafnrými, því afturfallið myndi senda einkanöfn til opinbers resolver og skila gagnslausu svari frá internetinu. BIND-tilvísunin skjalfestir báðar stefnurnar, og munurinn skiptir meira máli en brotið gefur til kynna. Sameinaðu svæðið í núverandi stillingar í stað þess að skipta um svæði sem þegar er til fyrir sama nafn.

Stub eða secondary: þegar delegunin skiptir máli

Stub-svæði spyr fyrirtækjaþjóninn um NS-færslur svæðisins og spyr síðan beint um hin heimilaða þjóna. Veldu það þegar uppstreymissvæðið er stórt eða skipt og þú vilt að resolverinn fylgi deleguninni í stað þess að negla allt á eitt fang. Kostnaðurinn er háð því að NS-gögnin séu uppfærð og að hver skráð nafnaþjónn sé aðgengilegur frá upprunafangi resolversins.

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 svarar úr staðbundnum gögnum og stendur af sér niðurfall uppstreymis, og það er ástæðan til að samþykkja flutningsháðina. Það þýðir líka að resolverinn heldur nú afriti af svæði sem hann á ekki, svo slóð skráarinnar, flutnings-ACL á aðalþjóninum og endurnýjunartímararnir verða allir hluti af rekstraryfirborði þínu.

Athugunin sem ræður milli þeirra

BIND býr til sína eigin útbeiðni, svo spurningin er ekki hvort fartölva komist á 10.40.0.53 heldur hvort hýsill resolversins komist þangað frá upprunafanginu sem fyrirtækjaþjónninn sér. Spurðu kjarnann, spurðu síðan þjóninn, í þeirri röð.

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

Leyfðu UDP og TCP á slóðinni: stytt svar þvingar TCP, og stefna sem leyfir aðeins UDP veldur tímabundnum bilunum sem líta út eins og pakkatap. Fyrirtækjahliðin þarf bæði viðtökureglu fyrir uppruna resolversins og afturleið til hans; sá uppruni getur verið beina fangi resolversins eða sérstaklega þýtt fang, og það er sjaldan fang úr biðlarahópi. Ef NS-beiðnin mistekst getur stub-svæði ekki unnið, sama hvernig forward-svæðið hagar sér.

Sannreyndu svarið, ekki göngin

Spurðu í gegnum resolver skrifstofunnar um nafn sem þú hefur aldrei spurð um, og skoðaðu authority-hlutann í svarinu til að sjá hvort það kom frá fyrirtækjasvæðinu. Svar í skyndiminni sannar ekkert um núverandi slóð, og árangursrík bein beiðni til uppstreymis sannar ekki að resolverinn hafi valið það svæði. Endurtaktu sömu beiðni yfir TCP til að staðfesta að slóðin standist styttingu.

Haltu biðlurum beint að resolver skrifstofunnar, og hafðu DNSSEC-staðfestingu áfram kveikta. Vafri sem er stilltur með sjálfstæðum dulkóðuðum resolver fer algjörlega fram hjá þessari ráðstöfun, og að slökkva á staðfestingu svo óvænt svar líti rétt út skiptir sýnilegri bilun fyrir ósýnilega.

Skrifaðu niður hverja af þremur gerðum þú valdir og hvers vegna. Næsta manneskja sem sér svæðið mistakast þarf þá setningu meira en stillingarskrána.