BIND mbi një VPN: përcjellje e kushtëzuar apo zonë stub?

Resolver-i i zyrës suaj përgjigjet për gjithçka përveç një hapësire emrash korporative, dhe serveri DNS korporativ që e njeh ndodhet pas një VPN. BIND mund ta dorëzojë atë zonë të vetme te upstream në tre mënyra të ndryshme, dhe ato dështojnë ndryshe. Përcjellja e kushtëzuar është angazhimi më i vogël, një zonë stub mban të dhënat e delegimit, dhe një secondary mban një kopje të plotë. Zgjidhni sipas asaj që upstream do të lejojë dhe asaj që dëshironi të mbajë resolver-i juaj, jo sipas fragmentit që gjetët i pari.

Tre rregullime për një hapësirë emrash

Përcjellje e kushtëzuar: angazhimi më i vogël

Supozoni një resolver zyre në 192.168.10.53 dhe një server korporativ në 10.40.0.53 të arritshëm përmes një tuneli të miratuar. Deklarata është tre rreshta, dhe më interesanti është forward only, sepse ndryshon sjelljen në dështim, jo rrugën.

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

Me forward only, një upstream i paarritshëm prodhon SERVFAIL për këtë zonë në vend të kthimit në zgjidhje iterative. Kjo është zakonisht ajo që dëshironi për një hapësirë emrash private, sepse kthimi do të dërgonte emra privatë te një resolver publik dhe do të sillte një përgjigje të padobishme nga interneti. Referenca e BIND dokumenton të dyja politikat, dhe ndryshimi ka më shumë rëndësi sesa sugjeron fragmenti. Bashkoni zonën në konfigurimin ekzistues në vend që të zëvendësoni një zonë që ekziston tashmë për të njëjtin emër.

Stub ose secondary: kur delegimi ka rëndësi

Një zonë stub i kërkon serverit korporativ regjistrimet NS të zonës dhe pastaj pyet serverët autoritativë drejtpërdrejt. Zgjidhni atë kur rajoni i upstream është i madh ose i ndarë dhe dëshironi që resolver-i juaj të ndjekë delegimin në vend që të gozhdojë gjithçka në një adresë. Kostoja është varësia nga të dhënat NS të përditësuara, dhe nga aksesueshmëria e çdo serveri emrash të listuar nga adresa burimore e resolver-it tuaj.

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 përgjigjet nga të dhëna lokale dhe i mbijeton një ndërprerjeje të upstream, dhe kjo është arsyeja për të pranuar varësinë nga transferimi. Kjo do të thotë gjithashtu se resolver-i juaj tani mban një kopje të një zone që nuk e zotëron, kështu që rruga e skedarit, ACL-ja e transferimit në primar dhe kohëmatësit e rifreskimit bëhen të gjithë pjesë e sipërfaqes tuaj operacionale.

Kontrolli që vendos midis tyre

BIND gjeneron vetë kërkesën e tij dalëse, kështu që pyetja nuk është nëse një laptop arrin në 10.40.0.53, por nëse hosti i resolver-it arrin, nga adresa burimore që serveri korporativ do të shohë. Pyetni kernelin, pastaj pyetni serverin, në atë rend.

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

Lejoni UDP dhe TCP në rrugë: një përgjigje e shkurtuar detyron TCP, dhe një politikë që lejon vetëm UDP prodhon dështime të ndërprera që duken si humbje paketash. Ana korporative ka nevojë si për një rregull pranimi për burimin e resolver-it tuaj, ashtu edhe për një rrugë kthimi drejt tij; ai burim mund të jetë adresa e rrugëzuar e resolver-it ose një adresë e përkthyer në mënyrë eksplicite, dhe rrallë është adresë e një grupi klientësh. Nëse kërkesa NS dështon, një zonë stub nuk mund të punojë, pavarësisht se si sillet zona forward.

Verifikoni përgjigjen, jo tunelin

Pyetni përmes resolver-it të zyrës për një emër që nuk e keni kërkuar kurrë, dhe shikoni seksionin authority të përgjigjes për të parë nëse erdhi nga zona korporative. Një përgjigje në cache nuk provon asgjë për rrugën aktuale, dhe një kërkesë e drejtpërdrejtë e suksesshme te upstream nuk provon që resolver-i juaj zgjodhi atë zonë. Përsëritni të njëjtën kërkesë përmes TCP për të konfirmuar se rruga i mbijeton shkurtimit.

Mbajini klientët të drejtuar te resolver-i i zyrës, dhe mbajeni aktivizuar verifikimin DNSSEC. Një shfletues i konfiguruar me një resolver të pavarur të kriptuar e anashkalon plotësisht këtë rregullim, dhe çaktivizimi i verifikimit që një përgjigje e papritur të duket e saktë shkëmben një dështim të dukshëm me një të padukshëm.

Shkruani cilën nga tre llojet zgjodhët dhe pse. Personi tjetër që do të shohë zonën duke dështuar do t'i duhet ajo fjali më shumë sesa skedari i konfigurimit.