BIND sa ibabaw ng VPN: conditional forward o stub zone?

Ang resolver ng opisina mo ay sumasagot sa lahat maliban sa isang corporate namespace, at ang corporate DNS server na nakakaalam nito ay nasa likod ng VPN. Kayang ibigay ng BIND ang nag-iisang zone na iyon sa upstream sa tatlong magkakaibang paraan, at magkaiba ang kanilang pagpalya. Ang conditional forward ang pinakamaliit na pangako, ang stub zone ay nagtatabi ng delegation data, at ang secondary ay nagtatabi ng buong kopya. Pumili batay sa papayagan ng upstream at sa gusto mong itabi ng resolver mo, hindi batay sa kung aling snippet ang una mong nakita.

Tatlong kaayusan para sa isang namespace

Conditional forward: ang pinakamaliit na pangako

Ipagpalagay na ang resolver ng opisina ay nasa 192.168.10.53 at ang corporate server ay nasa 10.40.0.53 na maaabot sa pamamagitan ng aprubadong tunnel. Tatlong linya ang deklarasyon, at ang kawili-wili ay forward only, dahil binabago nito ang pag-uugali sa pagpalya, hindi ang ruta.

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

Sa forward only, ang hindi maabot na upstream ay gumagawa ng SERVFAIL para sa zone na ito sa halip na bumalik sa iterative resolution. Karaniwang iyon ang gusto mo para sa pribadong namespace, dahil ipapadala ng pagbalik ang mga pribadong pangalan sa pampublikong resolver at magbabalik ng walang silbing sagot mula sa internet. Ang sangguniang BIND ay nagdodokumento ng dalawang patakaran, at mas mahalaga ang pagkakaiba kaysa sa ipinahihiwatig ng snippet. Isama ang zone sa umiiral na configuration sa halip na palitan ang zone na mayroon na para sa parehong pangalan.

Stub o secondary: kapag mahalaga ang delegation

Ang stub zone ay nagtatanong sa corporate server ng NS records ng zone at pagkatapos ay direktang nagtatanong sa mga authoritative server. Piliin ito kapag malaki o nahahati ang rehiyon ng upstream at gusto mong sundan ng resolver mo ang delegation sa halip na ipako ang lahat sa isang address. Ang halaga ay pagdepende sa pagiging napapanahon ng NS data, at sa pag-abot ng bawat nakalistang name server mula sa source address ng resolver mo.

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

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

Ang secondary ay sumasagot mula sa lokal na data at nakakaligtas sa pagtigil ng upstream, at iyon ang dahilan upang tanggapin ang pagdepende sa transfer. Nangangahulugan din ito na ang resolver mo ay may hawak na kopya ng zone na hindi kanya, kaya ang path ng file, ang transfer ACL sa primary at ang mga refresh timer ay nagiging bahagi ng iyong operational surface.

Ang pagsusuri na nagpapasya sa pagitan nila

Ang BIND ay gumagawa ng sarili nitong outbound query, kaya ang tanong ay hindi kung maaabot ng laptop ang 10.40.0.53 kundi kung kaya ng host ng resolver, mula sa source address na makikita ng corporate server. Tanungin ang kernel, pagkatapos ang server, sa ganoong pagkakasunod-sunod.

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

Payagan ang UDP at TCP sa ruta: ang putol na sagot ay nagpipilit ng TCP, at ang patakarang nagpapahintulot lamang ng UDP ay gumagawa ng paminsan-minsang pagpalya na mukhang pagkawala ng packet. Kailangan ng corporate side ang parehong acceptance rule para sa source ng resolver mo at return route patungo rito; ang source na iyon ay maaaring routed address ng resolver o isang tahasang isinalin, at bihira itong address ng client pool. Kung pumalya ang NS query, hindi gagana ang stub zone, gaano man kumilos ang forward zone.

I-verify ang sagot, hindi ang tunnel

Magtanong sa resolver ng opisina para sa pangalang hindi mo pa hinihingi, at tingnan ang authority section ng sagot upang malaman kung galing ito sa corporate zone. Walang pinapatunayan ang naka-cache na sagot tungkol sa kasalukuyang ruta, at ang matagumpay na direktang query sa upstream ay hindi nagpapatunay na pinili ng resolver mo ang zone na iyon. Ulitin ang parehong query sa TCP upang kumpirmahin na nakakaligtas ang ruta sa pagputol.

Panatilihing nakatutok ang mga client sa resolver ng opisina, at panatilihing bukas ang validation ng DNSSEC. Ang browser na naka-configure sa isang malayang encrypted resolver ay lumalampas nang tuluyan sa kaayusang ito, at ang pagpatay sa validation upang magmukhang tama ang hindi inaasahang sagot ay nagpapalit ng nakikitang pagpalya sa hindi nakikita.

Isulat kung alin sa tatlong uri ang pinili mo at bakit. Ang susunod na taong makakita ng pagpalya ng zone ay mas kailangan ang pangungusap na iyon kaysa sa configuration file.