Uso delle views con named

Spesso succede che per necessità ci si trovi costretti a utilizzare il proprio nameserver sia per gestire le richieste della rete interna che le richieste provenienti da Internet.
Ci sono diversi modi di configurare il BIND per questo tipo di lavoro e uno dei più innovativi implementato dalla versione 9.1.x in su è l'uso dell'istruzione view.

Le views permettono di presentare una configurazione del nameserver per una comunità di host e una differente configurazione per un'altro gruppo di host.  La sua sintassi è la seguente:

view "internal" {
};

Il nome che si da alla view è arbitrario e è buona norma che sia descrittivo per il tipo di lavoro che andiamo ad eseguire. Non è obbligatorio che sia quotato tra virgolette ma è consigliabile visto che si potrebbero usare nomi che collidono con direttive interne al named. Per specificare quali hosts vedono cosa e quali vedono altro si utilizza l'istruzione match-clients

view "internal" {
    match-clients { 192.168.0.0/24; };
}

Volendo si può utilizzare una acl precedentemente assegnata:
acl "intranet" { 192.168.0.0/24; };
view "internal" {
    match-clients { "intranet"; };
};

All'interno dell'istruzione view si possono definire molte direttive, si possono specificare le direttive per le zone, descrivere i nameserver remoti con l'istruzione server o configurare direttive key per l'uso di TSIG.
Si possono inoltre definire all'interno dell'istruzione view praticamente quasi tutte le options ricordando che sovrascriveranno ogni opzione globale precedentemente specificata per quegli host che rientrano nella direttiva match-clients

acl "intranet" { 192.168.0.0/24; };
view "internal" {
    match-clients { "intranet"; };
    recursion yes;
};

Vediamo ora un esempio di configurazione utilizzando le views:
acl "intranet" { 192.168.0.0/24; };
Definisco un Access Control List per gli host della rete interna
options {
    directory /var/named;
    pid-file /var/run/named.pid;
};
L'opzione directory può essere inclusa nella direttiva view nel caso ad esempio si abbiano molti file di zona e si voglia mantenere in directory separate i file interni e i file esterni.
view "internal" {
    match-clients { "intranet"; };
Non specifico una opzione recursion perchè il suo valore di default è yes.
    zone "esempio.com" {
    type master;
    file "esempio.com.db";
    };
    zone "0.168.192.in-addr.arpa" {
    type master;
    file "192.168.0.db";
    };
};

view "external" {
    match-clients { any; };
    recursion no;
    zone "esempio.com" {
    type master;
    file "esempio.com.db.external";
    };
    zone "0.168.192.in-addr.arpa" {
    type master;
    file "192.168.0.db.external";
    };
};
In questo caso si può notare che si utilizzano diversi file di zona per la view internal e per la external; questo non è necessariamente obbligatorio ad esempio si possono comunque utilizzare gli stessi file e definire solo chi ha la possibilità di effettuare recursive quering.

Quando ci si appresta a scrivere file di configurazione che utilizzano le direttive view bisogna prestare attenzione ad alcune regole:
Innanzi tutto l'ordine in cui si specificano le direttive, nel nostro caso per esempio se avessimo specificato prima la direttiva "external" questa avrebbe inevitabilmente occluso la direttiva interna perchè la direttiva esterna ha come match-clients chiunque.
E' importante inoltre ricordare che anche se si specifica una sola direttiva view tutte le direttive zone vanno poi specificate al suo interno.

Privacy Policy