BIND üle VPN-i: tingimuslik edastus või stub-tsoon?

Kolm viisi ühe privaatse tsooni lahendamiseks üle VPN-i ja millal kumb sobib: forward, stub või secondary, pluss lähteaadressi kontroll, mis otsustab.

Teie kontori resolver vastab kõigele peale ühe ettevõtte nimeruumi, ja ettevõtte DNS-server, mis seda teab, asub VPN-i taga. BIND saab selle üksiku tsooni upstreamile üle anda kolmel erineval viisil ja need ebaõnnestuvad erinevalt. Tingimuslik edastus on väikseim kohustus, stub-tsoon hoiab delegeerimisandmeid ja secondary hoiab täielikku koopiat. Valige selle järgi, mida upstream lubab ja mida te oma resolveril hoida tahate, mitte selle järgi, millise lõigu te esimesena leidsite.

Kolm korraldust ühe nimeruumi jaoks

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

Tingimuslik edastus: väikseim kohustus

Oletame, et kontori resolver on aadressil 192.168.10.53 ja ettevõtte server aadressil 10.40.0.53, mis on kättesaadav kinnitatud tunneli kaudu. Deklaratsioon on kolm rida ja huvitav on forward only, sest see muudab rikke käitumist, mitte teed.

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

Kui forward only on seatud, annab kättesaamatu upstream sellele tsoonile SERVFAILi, mitte tagasilangust iteratiivsele lahendamisele. Privaatse nimeruumi puhul on see tavaliselt soovitud, sest tagasilangus saadaks privaatsed nimed avalikku resolverisse ja tagastaks internetist kasutu vastuse. BIND-i viide dokumenteerib mõlemad poliitikad ja erinevus loeb rohkem, kui lõik vihjab. Liitke tsoon olemasolevasse konfiguratsiooni, selle asemel et asendada tsooni, mis sama nime jaoks juba olemas on.

Stub või secondary: kui delegeerimine loeb

Stub-tsoon küsib ettevõtte serverilt tsooni NS-kirjeid ja küsib seejärel autoriteetseid servereid otse. Valige see, kui upstreami piirkond on suur või jaotatud ja te tahate, et teie resolver järgiks delegeerimist, mitte ei kinnitaks kõike ühe aadressi külge. Hind on sõltuvus NS-andmete ajakohasusest ja sellest, et iga loetletud nimeserver oleks teie resolveri lähteaadressilt kättesaadav.

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 vastab kohalikest andmetest ja elab üle upstreami katkestuse, ja see on põhjus, miks ülekande sõltuvus vastu võtta. See tähendab ka, et teie resolver hoiab nüüd tsooni koopiat, mis ei kuulu talle, nii et failitee, primaari ülekande-ACL ja värskendustaimerid muutuvad kõik teie tööpinna osaks.

Kontroll, mis nende vahel otsustab

BIND genereerib oma väljuva päringu, seega küsimus ei ole, kas sülearvuti jõuab aadressini 10.40.0.53, vaid kas resolveri host jõuab, lähteaadressilt, mida ettevõtte server näeb. Küsige kernellilt, siis küsige serverilt, selles järjekorras.

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

Lubage teel UDP ja TCP: kärbitud vastus sunnib TCP-d, ja poliitika, mis lubab ainult UDP-d, tekitab katkendlikke rikkeid, mis näevad välja nagu paketikaotus. Ettevõtte pool vajab nii teie resolveri lähte jaoks lubamisreeglit kui ka tagasiteed sinna; see lähe võib olla resolveri suunatud aadress või selgesõnaliselt tõlgitud aadress, ja see on harva kliendipooli aadress. Kui NS-päring ebaõnnestub, ei saa stub-tsoon töötada ükskõik kuidas forward-tsoon käitub.

Kontrollige vastust, mitte tunnelit

Pärige kontori resolveri kaudu nime, mida te pole kunagi küsinud, ja vaadake vastuse authority-osa, et näha, kas see tuli ettevõtte tsoonist. Vahemällu salvestatud vastus ei tõesta praeguse tee kohta midagi, ja edukas otsepäring upstreamile ei tõesta, et teie resolver valis just selle tsooni. Korrake sama päringut TCP kaudu, et kinnitada, et tee peab kärpimisele vastu.

Hoidke kliendid suunatud kontori resolverile, ja hoidke DNSSEC-valideerimine sisse lülitatud. Iseseisva krüpteeritud resolveriga seadistatud brauser möödub sellest korraldusest täielikult, ja valideerimise väljalülitamine, et ootamatu vastus näeks õige välja, vahetab nähtava rikke nähtamatu vastu.

Pange kirja, millise kolmest tüübist valisite ja miks. Järgmine inimene, kes tsooni rikkimist näeb, vajab seda lauset rohkem kui konfiguratsioonifaili.

Seotud artiklid