BIND VPN:n yli: ehdollinen edelleenlähetys vai stub-vyöhyke?

Toimiston resolveri vastaa kaikkeen paitsi yhteen yrityksen nimiavaruuteen, ja sen tunteva yrityksen DNS-palvelin on VPN:n takana. BIND voi luovuttaa tuon yhden vyöhykkeen upstreamille kolmella eri tavalla, ja ne epäonnistuvat eri tavoin. Ehdollinen edelleenlähetys on pienin sitoumus, stub-vyöhyke säilyttää delegointitiedot ja secondary säilyttää täyden kopion. Valitse sen mukaan, mitä upstream sallii ja mitä haluat resolverisi pitävän, älä sen mukaan, minkä katkelman löysit ensin.

Kolme järjestelyä yhdelle nimiavaruudelle

Ehdollinen edelleenlähetys: pienin sitoumus

Oletetaan toimiston resolveri osoitteessa 192.168.10.53 ja yrityksen palvelin osoitteessa 10.40.0.53, joka on tavoitettavissa hyväksytyn tunnelin kautta. Määrittely on kolme riviä, ja kiinnostava on forward only, koska se muuttaa virhetilanteen käyttäytymistä, ei polkua.

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

Kun forward only on asetettu, tavoittamaton upstream tuottaa tälle vyöhykkeelle SERVFAILin iteratiiviseen ratkaisuun palaamisen sijaan. Yksityiselle nimiavaruudelle haluat yleensä juuri tämän, koska paluu lähettäisi yksityiset nimet julkiselle resolverille ja toisi internetistä hyödyttömän vastauksen. BIND-viite dokumentoi molemmat käytännöt, ja ero on tärkeämpi kuin katkelma antaa ymmärtää. Yhdistä vyöhyke olemassa olevaan kokoonpanoon sen sijaan että korvaisit vyöhykkeen, joka on jo olemassa samalle nimelle.

Stub vai secondary: milloin delegointi merkitsee

Stub-vyöhyke kysyy yrityksen palvelimelta vyöhykkeen NS-tietueet ja kysyy sitten autoritatiivisilta palvelimilta suoraan. Valitse se, kun upstream-alue on suuri tai jaettu ja haluat resolverisi seuraavan delegointia sen sijaan että naulitsisi kaiken yhteen osoitteeseen. Hinta on riippuvuus siitä, että NS-tiedot ovat ajan tasalla, ja siitä, että jokainen lueteltu nimipalvelin on tavoitettavissa resolverisi lähdeosoitteesta.

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 vastaa paikallisista tiedoista ja kestää upstreamin katkoksen, ja siksi siirtoriippuvuus kannattaa hyväksyä. Se tarkoittaa myös, että resolverisi pitää nyt kopiota vyöhykkeestä, joka ei ole sen oma, joten tiedostopolku, primäärin siirto-ACL ja päivitysajastimet tulevat kaikki osaksi käyttöpintaasi.

Tarkistus, joka ratkaisee niiden välillä

BIND luo oman lähtevän kyselynsä, joten kysymys ei ole siitä, pääseekö kannettava 10.40.0.53:een, vaan siitä, pääseekö resolverin isäntä, siitä lähdeosoitteesta, jonka yrityksen palvelin näkee. Kysy ytimeltä ja sitten palvelimelta, tässä järjestyksessä.

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

Salli UDP ja TCP polulla: katkaistu vastaus pakottaa TCP:n, ja käytäntö, joka sallii vain UDP:n, tuottaa ajoittaisia vikoja, jotka näyttävät pakettihäviöltä. Yrityksen puoli tarvitsee sekä hyväksyntäsäännön resolverisi lähteelle että paluureitin siihen; tämä lähde voi olla resolverin reititetty osoite tai nimenomaisesti käännety osoite, ja se on harvoin asiakaspoolin osoite. Jos NS-kysely epäonnistuu, stub-vyöhyke ei voi toimia riippumatta siitä, miten forward-vyöhyke käyttäytyy.

Varmista vastaus, älä tunnelia

Kysy toimiston resolverin kautta nimeä, jota et ole koskaan kysynyt, ja katso vastauksen authority-osasta, tuliko se yrityksen vyöhykkeeltä. Välimuistissa oleva vastaus ei todista mitään nykyisestä polusta, eikä onnistunut suora kysely upstreamille todista, että resolverisi valitsi juuri tuon vyöhykkeen. Toista sama kysely TCP:n yli varmistaaksesi, että polku kestää katkaisun.

Pidä asiakkaat osoittamassa toimiston resolveriin, ja pidä DNSSEC-validointi päällä. Itsenäisellä salatulla resolverilla määritetty selain ohittaa tämän järjestelyn kokonaan, ja validoinnin poistaminen käytöstä, jotta odottamaton vastaus näyttäisi oikealta, vaihtaa näkyvän vian näkymättömään.

Kirjoita muistiin, minkä kolmesta tyypistä valitsit ja miksi. Seuraava henkilö, joka näkee vyöhykkeen pettävän, tarvitsee tuon lauseen enemmän kuin kokoonpanotiedoston.