BIND oor 'n VPN: voorwaardelike aanstuur of stub-sone?

Jou kantoor-resolver beantwoord alles behalwe een korporatiewe naamruimte, en die korporatiewe DNS-bediener wat dit ken, sit agter 'n VPN. BIND kan daardie enkele sone op drie verskillende maniere aan die upstream oorhandig, en hulle faal op verskillende maniere. 'n Voorwaardelike aanstuur is die kleinste verbintenis, 'n stub-sone hou die delegasiedata, en 'n secondary hou 'n volledige kopie. Kies volgens wat die upstream sal toelaat en wat jy in jou resolver wil hou, nie volgens watter snippet jy eerste gekry het nie.

Drie reëlings vir een naamruimte

Voorwaardelike aanstuur: die kleinste verbintenis

Aanvaar 'n kantoor-resolver by 192.168.10.53 en 'n korporatiewe bediener by 10.40.0.53 wat oor 'n goedgekeurde tonnel bereikbaar is. Die verklaring is drie reëls, en die interessante een is forward only, want dit verander die foutgedrag eerder as die pad.

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

Met forward only gee 'n onbereikbare upstream 'n SERVFAIL vir hierdie sone in plaas van 'n terugval na iteratiewe oplossing. Dit is gewoonlik wat jy vir 'n private naamruimte wil hê, want die terugval sou private name na 'n publieke resolver stuur en 'n nuttelose antwoord van die internet terugbring. BIND-verwysing dokumenteer beide beleide, en die verskil maak meer saak as wat die snippet laat blyk. Voeg die sone by die bestaande konfigurasie in eerder as om 'n sone te vervang wat reeds vir dieselfde naam bestaan.

Stub of secondary: wanneer die delegasie saak maak

'n Stub-sone vra die korporatiewe bediener vir die sone se NS-rekords en vra dan die gesaghebbende bedieners direk. Kies dit wanneer die upstream-gebied groot of onderverdeel is en jy wil hê jou resolver moet die delegasie volg in plaas daarvan om alles aan een adres vas te pen. Die koste is 'n afhanklikheid daarvan dat die NS-data aktueel is, en dat elke gelyste naamruimte-bediener vanaf jou resolver se bronadres bereikbaar is.

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

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

'n Secondary antwoord uit plaaslike data en oorleef 'n upstream-onderbreking, en dit is die rede om die oordrag-afhanklikheid te aanvaar. Dit beteken ook jou resolver hou nou 'n kopie van 'n sone wat nie aan hom behoort nie, so die lêerpad, die oordrag-ACL op die primêre en die verversingstye word almal deel van jou operasionele oppervlak.

Die toets wat tussen hulle besluit

BIND genereer sy eie uitgaande navraag, so die vraag is nie of 'n skootrekenaar 10.40.0.53 kan bereik nie, maar of die resolver-gasheer dit kan, vanaf die bronadres wat die korporatiewe bediener sal sien. Vra die kernel, vra dan die bediener, in daardie volgorde.

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

Laat UDP en TCP op die pad toe: 'n afgekapte antwoord dwing TCP, en 'n beleid wat net UDP toelaat, lewer onderbroke foute wat soos pakketverlies lyk. Die korporatiewe kant het beide 'n aanvaardingsreël vir jou resolver se bron en 'n terugroete na dit nodig; daardie bron kan die resolver se gerouteerde adres of 'n eksplisiet vertaalde een wees, en dit is selde 'n kliëntpoeladres. As die NS-navraag misluk, kan 'n stub-sone nie werk nie, maak nie saak hoe die forward-sone optree nie.

Verifieer die antwoord, nie die tonnel nie

Vra deur die kantoor-resolver vir 'n naam wat jy nog nooit gevra het nie, en kyk na die antwoord se authority-afdeling om te sien of dit uit die korporatiewe sone kom. 'n Gekaste antwoord bewys niks oor die huidige pad nie, en 'n suksesvolle navraag direk na die upstream bewys nie dat jou resolver daardie sone gekies het nie. Herhaal dieselfde navraag oor TCP om te bevestig dat die pad afkapping oorleef.

Hou kliënte na die kantoor-resolver wys, en hou DNSSEC-bevestiging aan. 'n Blaaier wat met 'n onafhanklike geïnkripteerde resolver opgestel is, omseil hierdie reëling heeltemal, en om bevestiging af te skakel sodat 'n onverwagte antwoord korrek lyk, ruil 'n sigbare fout vir 'n onsigbare een.

Skryf neer watter van die drie tipes jy gekies het en waarom. Die volgende persoon wat die sone sien faal, sal daardie sin meer nodig hê as die konfigurasielêer.