BIND oer in VPN: betingst trochstjoere of stub-sône?

Trije manieren om ien partikuliere sône fia in VPN op te lossen, en wannear't elk past: forward, stub of secondary, plus de kontrôle fan it boarneadres dy't de kar beslút.

Jo kantoar-resolver beantwurdet alles behalve ien bedriuwsnammeromte, en de bedriuws-DNS-tsjinner dy't it ken sit efter in VPN. BIND kin dy iene sône op trije ferskillende manieren oan de upstream oerdrage, en se mislearje ferskillend. Betingst trochstjoere is de lytste ferplichting, in stub-sône hâldt de delegasjegegevens, en in secondary hâldt in folsleine kopy. Kies op grûn fan wat de upstream tastean sil en wat jo jo resolver hâlde litte wolle, net op grûn fan hokker fragmint jo it earst fûnen.

Trije opstellings foar ien nammeromte

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

Betingst trochstjoere: de lytste ferplichting

Stel jo in kantoar-resolver foar op 192.168.10.53 en in bedriuws-tsjinner op 10.40.0.53 dy't fia in goedkarde tunnel berikber is. De ferklearring is trije rigels, en de nijsgjirrige is forward only, want dy feroaret it gedrach by falen, net it paad.

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

Mei forward only jout in net berikbere upstream in SERVFAIL foar dizze sône ynstee fan in weromfal nei iteratyf oplossen. Dat is meastentiids wat jo wolle foar in partikuliere nammeromte, want de weromfal soe partikuliere nammen nei in iepenbiere resolver stjoere en in nutteleas antwurd fan it ynternet werombringe. De BIND-referinsje dokumintearret beide beliedsregels, en it ferskil is wichtiger as it fragmint suggerearret. Foegje de sône ta oan de besteande konfiguraasje ynstee fan in sône te ferfangen dy't al bestiet foar deselde namme.

Stub of secondary: wannear't de delegasje fan belang is

In stub-sône freget de bedriuws-tsjinner om de NS-records fan de sône en freget dêrnei de autoritative tsjinners direkt. Kies it as it upstream-gebiet grut of ûnderferdield is en jo wolle dat jo resolver de delegasje folget ynstee fan alles oan ien adres fêst te setten. De priis is in ôfhinklikens fan aktuele NS-gegevens en fan de berikberens fan elke neamde namtsjinner fanôf it boarneadres fan jo resolver.

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

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

In secondary antwurdet út lokale gegevens en oerlibbet in ûnderbrekking fan de upstream, en dat is de reden om de ôfhinklikens fan de oerdracht te akseptearjen. It betsjut ek dat jo resolver no in kopy hâldt fan in sône dy't net fan him is, sadat it bestânspaad, de oerdrachts-ACL op de primêre en de ferfarskjetimers allegear diel wurde fan jo operasjonele oerflak.

De kontrôle dy't tusken har beslút

BIND makket syn eigen útgeande fraach, dus de fraach is net oft in laptop 10.40.0.53 berikke kin, mar oft de resolver-host dat kin, fanôf it boarneadres dat de bedriuws-tsjinner sjocht. Freegje it kearn, freegje dan de tsjinner, yn dy folchoarder.

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

Stean UDP en TCP ta op it paad: in ôfkapt antwurd twingt TCP, en in belied dat allinnich UDP tastiet produsearret tuskenskoften falen dy't op pakketferlies lykje. De bedriuwskant hat sawol in akseptregel foar de boarne fan jo resolver as in weromrûte dêrhinne nedich; dy boarne kin it rûte-adres fan de resolver wêze of in eksplisyt oersetten ien, en it is selden in kliïntpool-adres. As de NS-fraach mislearret, kin in stub-sône net wurkje, hoe't de forward-sône him ek hâldt.

Ferifiearje it antwurd, net de tunnel

Freegje fia de kantoar-resolver nei in namme dêr't jo noait om frege hawwe, en besjoch de authority-seksje fan it antwurd om te sjen oft it út de bedriuws-sône kaam. In cache-antwurd bewiist neat oer it hjoeddeiske paad, en in suksesfolle fraach direkt oan de upstream bewiist net dat jo resolver dy sône keas. Werhelje deselde fraach oer TCP om te befêstigjen dat it paad ôfkapping oerlibbet.

Hâld klanten rjochte op de kantoar-resolver, en hâld DNSSEC-ferifikaasje oan. In browser ynsteld mei in ûnôfhinklike fersifere resolver giet folslein om dizze opstelling hinne, en ferifikaasje útsette sadat in ûnferwacht antwurd korrekt liket, ruilet in sichtber falen foar in ûnsichtber.

Skriuw op hokker fan de trije typen jo keazen hawwe en wêrom. De folgjende persoan dy't de sône falen sjocht, hat mear oan dy sin as oan it konfiguraasjebestân.

Relatearre artikelen