BIND over een VPN: voorwaardelijke forwarding of stub-zone?

Je kantoorresolver beantwoordt alles behalve één bedrijfsnaamruimte, en de bedrijfs-DNS-server die die kent staat achter een VPN. BIND kan die ene zone op drie verschillende manieren aan de upstream overhandigen, en ze falen verschillend. Voorwaardelijke forwarding is de kleinste toezegging, een stub-zone houdt de delegatiegegevens, en een secondary houdt een volledige kopie. Kies op basis van wat de upstream toestaat en wat je je resolver wilt laten vasthouden, niet op basis van welk fragment je het eerst vond.

Drie opstellingen voor één naamruimte

Voorwaardelijke forwarding: de kleinste toezegging

Stel een kantoorresolver op 192.168.10.53 en een bedrijfsserver op 10.40.0.53 die bereikbaar is via een goedgekeurde tunnel. De declaratie is drie regels, en de interessante is forward only, omdat die het faalgedrag verandert, niet het pad.

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

Met forward only levert een onbereikbare upstream een SERVFAIL voor deze zone op in plaats van terug te vallen op iteratieve resolutie. Dat is meestal wat je wilt voor een privénaamruimte, omdat de terugval privénamen naar een publieke resolver zou sturen en een nutteloos antwoord van het internet zou terugbrengen. De BIND-referentie documenteert beide beleidsregels, en het verschil is belangrijker dan het fragment suggereert. Voeg de zone toe aan de bestaande configuratie in plaats van een zone te vervangen die al voor dezelfde naam bestaat.

Stub of secondary: wanneer de delegatie ertoe doet

Een stub-zone vraagt de bedrijfsserver om de NS-records van de zone en bevraagt daarna de autoritatieve servers rechtstreeks. Kies hem wanneer de upstream-regio groot of opgedeeld is en je wilt dat je resolver de delegatie volgt in plaats van alles aan één adres vast te pinnen. De prijs is een afhankelijkheid van actuele NS-gegevens en van de bereikbaarheid van elke genoemde naamserver vanaf het bronadres van je 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";
};

Een secondary antwoordt uit lokale gegevens en overleeft een storing van de upstream, en dat is de reden om de overdrachtsafhankelijkheid te accepteren. Het betekent ook dat je resolver nu een kopie houdt van een zone die niet van hem is, dus het bestandspad, de overdrachts-ACL op de primaire en de vernieuwingstimers worden allemaal deel van je operationele oppervlak.

De controle die tussen hen beslist

BIND genereert zijn eigen uitgaande query, dus de vraag is niet of een laptop 10.40.0.53 kan bereiken, maar of de resolverhost dat kan, vanaf het bronadres dat de bedrijfsserver ziet. Vraag het de kernel, vraag het dan de server, in die 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

Sta UDP en TCP toe op het pad: een afgekapt antwoord dwingt TCP af, en een beleid dat alleen UDP toestaat levert periodieke storingen op die op pakketverlies lijken. De bedrijfskant heeft zowel een acceptatieregel voor de bron van je resolver als een terugroute daarheen nodig; die bron kan het gerouteerde adres van de resolver zijn of een expliciet vertaald adres, en het is zelden een adres uit een clientpool. Als de NS-query mislukt, kan een stub-zone niet werken, hoe de forward-zone zich ook gedraagt.

Controleer het antwoord, niet de tunnel

Vraag via de kantoorresolver naar een naam die je nooit hebt opgevraagd, en bekijk de authority-sectie van het antwoord om te zien of het uit de bedrijfszone kwam. Een gecachet antwoord bewijst niets over het huidige pad, en een geslaagde directe query naar de upstream bewijst niet dat je resolver die zone koos. Herhaal dezelfde query via TCP om te bevestigen dat het pad afkapping overleeft.

Houd clients op de kantoorresolver gericht, en houd DNSSEC-validatie aan. Een browser die is geconfigureerd met een onafhankelijke versleutelde resolver omzeilt deze opstelling volledig, en validatie uitschakelen zodat een onverwacht antwoord correct lijkt, ruilt een zichtbare fout tegen een onzichtbare.

Schrijf op welke van de drie typen je hebt gekozen en waarom. De volgende persoon die de zone ziet falen, heeft meer aan die zin dan aan het configuratiebestand.