BIND VPN fölött: feltételes továbbítás vagy stub zóna?

Az irodai resolver mindenre válaszol egy vállalati névtér kivételével, és az azt ismerő vállalati DNS-kiszolgáló VPN mögött van. A BIND háromféleképpen adhatja át ezt az egyetlen zónát az upstreamnek, és ezek eltérően hibáznak. A feltételes továbbítás a legkisebb kötelezettség, a stub zóna megtartja a delegálási adatokat, a secondary pedig teljes másolatot tart. Aszerint válasszon, mit enged meg az upstream, és mit szeretne, hogy a resolver megtartson, ne aszerint, melyik részletet találta meg először.

Három elrendezés egy névtérhez

Feltételes továbbítás: a legkisebb kötelezettség

Tegyük fel, hogy az irodai resolver a 192.168.10.53, a vállalati kiszolgáló pedig a 10.40.0.53 címen érhető el egy jóváhagyott alagúton át. A deklaráció három sor, és az érdekes forward only, mert a hibaviselkedést változtatja meg, nem az útvonalat.

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

A forward only beállítással az elérhetetlen upstream SERVFAIL-t ad erre a zónára az iteratív feloldásra való visszaesés helyett. Ez általában éppen az, amit privát névtérnél szeretne, mert a visszaesés privát neveket küldene egy nyilvános resolvernek, és használhatatlan választ hozna az internetről. A BIND referenciája dokumentálja mindkét házirendet, és a különbség fontosabb annál, mint amit a részlet sugall. Olvassza be a zónát a meglévő konfigurációba, ahelyett hogy lecserélne egy zónát, amely ugyanarra a névre már létezik.

Stub vagy secondary: amikor a delegálás számít

A stub zóna megkérdezi a vállalati kiszolgálót a zóna NS-rekordjairól, majd közvetlenül kérdezi a hiteles kiszolgálókat. Akkor válassza, ha az upstream régió nagy vagy felosztott, és szeretné, hogy a resolver kövesse a delegálást, ahelyett hogy mindent egy címhez szögezne. Az ár az NS-adatok naprakészségétől való függés, és az, hogy minden felsorolt névkiszolgáló elérhető legyen a resolver forráscíméről.

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

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

A secondary helyi adatokból válaszol, és túléli az upstream kiesését, és ezért érdemes elfogadni az átviteli függőséget. Ez azt is jelenti, hogy a resolver most egy olyan zóna másolatát tartja, amely nem az övé, így a fájlútvonal, az elsődleges átviteli ACL-je és a frissítési időzítők mind az üzemeltetési felülete részévé válnak.

Az ellenőrzés, amely köztük dönt

A BIND maga állítja elő a kimenő lekérdezést, tehát nem az a kérdés, hogy egy laptop eléri-e a 10.40.0.53-at, hanem hogy a resolver gép el tudja-e érni a vállalati kiszolgáló által látott forráscímről. Kérdezze a kernelt, majd a kiszolgálót, ebben a sorrendben.

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

Engedje át az UDP-t és a TCP-t az útvonalon: a csonkolt válasz TCP-re kényszerít, és a csak UDP-t engedélyező házirend szakaszos hibákat okoz, amelyek csomagvesztésnek látszanak. A vállalati oldalnak egyszerre van szüksége elfogadási szabályra a resolver forrására és visszaútra hozzá; ez a forrás lehet a resolver irányított címe vagy kifejezetten lefordított cím, és ritkán klienspool-cím. Ha az NS-lekérdezés meghibásodik, a stub zóna nem működhet, bármit is csinál a forward zóna.

A választ ellenőrizze, ne az alagutat

Kérdezzen át az irodai resolveren egy olyan nevet, amelyet még soha nem kért, és nézze meg a válasz authority szakaszát, hogy a vállalati zónából jött-e. A gyorsítótárazott válasz semmit nem bizonyít a jelenlegi útvonalról, és az upstream közvetlen sikeres lekérdezése nem bizonyítja, hogy a resolver ezt a zónát választotta. Ismételje meg ugyanazt a lekérdezést TCP-n, hogy megerősítse: az útvonal kibírja a csonkítást.

Tartsa az ügyfeleket az irodai resolverre irányítva, és tartsa bekapcsolva a DNSSEC-ellenőrzést. Egy független titkosított resolverrel beállított böngésző teljesen megkerüli ezt az elrendezést, és az ellenőrzés kikapcsolása, hogy egy váratlan válasz helyesnek tűnjön, látható hibát cserél láthatatlanra.

Írja le, melyik három típus közül választott, és miért. A következő embernek, aki látja a zónát meghibásodni, többre lesz szüksége ahhoz a mondathoz, mint a konfigurációs fájlhoz.