BIND su una VPN: inoltro condizionale o zona stub?

Il resolver dell'ufficio risponde a tutto tranne che a uno spazio dei nomi aziendale, e il server DNS aziendale che lo conosce sta dietro una VPN. BIND può consegnare quella singola zona all'upstream in tre modi diversi, e falliscono in modo diverso. L'inoltro condizionale è l'impegno più piccolo, una zona stub conserva i dati di delega e una secondary conserva una copia completa. Scegli in base a ciò che l'upstream consentirà e a ciò che vuoi che il tuo resolver conservi, non in base a quale frammento hai trovato per primo.

Tre disposizioni per uno spazio dei nomi

Inoltro condizionale: l'impegno più piccolo

Supponi un resolver d'ufficio su 192.168.10.53 e un server aziendale su 10.40.0.53 raggiungibile attraverso un tunnel approvato. La dichiarazione è di tre righe, e quella interessante è forward only, perché cambia il comportamento in caso di guasto, non il percorso.

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

Con forward only, un upstream irraggiungibile produce un SERVFAIL per questa zona invece di un ritorno alla risoluzione iterativa. Di solito è ciò che vuoi per uno spazio dei nomi privato, perché il ritorno manderebbe nomi privati a un resolver pubblico e restituirebbe una risposta inutile da internet. La documentazione di BIND descrive entrambe le politiche, e la differenza conta più di quanto suggerisca il frammento. Unisci la zona alla configurazione esistente invece di sostituire una zona che esiste già per lo stesso nome.

Stub o secondary: quando la delega conta

Una zona stub chiede al server aziendale i record NS della zona e poi interroga direttamente i server autorevoli. Sceglila quando la regione upstream è grande o suddivisa e vuoi che il tuo resolver segua la delega invece di fissare tutto a un solo indirizzo. Il costo è una dipendenza dall'aggiornamento dei dati NS e dalla raggiungibilità di ogni nameserver elencato dall'indirizzo di origine del tuo 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";
};

Una secondary risponde da dati locali e sopravvive a un'interruzione dell'upstream, ed è questa la ragione per accettare la dipendenza dal trasferimento. Significa anche che il tuo resolver ora detiene una copia di una zona che non possiede, quindi il percorso del file, l'ACL di trasferimento sul primario e i timer di aggiornamento diventano tutti parte della tua superficie operativa.

Il controllo che decide tra loro

BIND genera la propria query in uscita, quindi la domanda non è se un portatile può raggiungere 10.40.0.53, ma se può farlo l'host del resolver, dall'indirizzo di origine che il server aziendale vedrà. Chiedi al kernel, poi chiedi al server, in quest'ordine.

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

Consenti UDP e TCP sul percorso: una risposta troncata forza TCP, e una politica che consente solo UDP produce guasti intermittenti che sembrano perdita di pacchetti. Il lato aziendale ha bisogno sia di una regola di accettazione per l'origine del tuo resolver sia di una rotta di ritorno verso di essa; quell'origine può essere l'indirizzo instradato del resolver o uno tradotto esplicitamente, e raramente è un indirizzo di un pool di clienti. Se la query NS fallisce, una zona stub non può funzionare, qualunque sia il comportamento della zona forward.

Verifica la risposta, non il tunnel

Interroga il resolver dell'ufficio per un nome che non hai mai chiesto, e guarda la sezione authority della risposta per capire se proviene dalla zona aziendale. Una risposta in cache non dimostra nulla sul percorso attuale, e una query diretta riuscita all'upstream non dimostra che il tuo resolver abbia scelto quella zona. Ripeti la stessa query su TCP per confermare che il percorso sopravvive al troncamento.

Mantieni i client puntati al resolver dell'ufficio, e mantieni attiva la validazione DNSSEC. Un browser configurato con un resolver cifrato indipendente aggira del tutto questa disposizione, e disattivare la validazione per far sembrare corretta una risposta inattesa scambia un guasto visibile con uno invisibile.

Annota quale dei tre tipi hai scelto e perché. La prossima persona che vedrà la zona fallire avrà bisogno di quella frase più del file di configurazione.