DNS Server · 8 min read · Oct 02, 2025
Server DNS due in uno con BIND9
Questo tutorial ti mostra come configurare il server DNS BIND9 per servire una rete interna e una rete esterna contemporaneamente con un insieme di informazioni diverso. Per raggiungere questo obiettivo, viene utilizzata una nuova funzionalità di BIND9 chiamata view. Come tutorial, ti guiderà attraverso l’intera configurazione, ma è necessaria una conoscenza iniziale di BIND e DNS, ci sono molti documenti che coprono queste informazioni su Internet.
Continua a leggere sul sito originale o scarica il PDF.
Contenuti
- 1 Il problema
- 2 Configurazione iniziale
- 3 Interni ed esterni
- 4 Sicurezza
- 5 File di configurazione - 5.1 /etc/bind/named.conf.local
- 5.2 /etc/bind/externals/db.example.com
- 5.3 /etc/bind/internals/db.example.com
- Bibliografia
1 Il problema
È un problema tipico nelle organizzazioni in crescita che devono risolvere due problemi contemporaneamente:
- Avere un server DNS per la rete interna dell’azienda perché molto tempo fa c’erano già troppi computer da ricordare i loro IP 1 e anche troppi computer per mantenere un insieme di file host 2.
- Avere un server DNS per i server esterni, per i clienti esterni, ecc.
Risolvere questi problemi diventa un problema più grande quando l’organizzazione in crescita non può fornire più risorse di un server DNS 3. È un problema più grande perché se configuri semplicemente il tuo server con tutti i tuoi nomi, pubblici e privati, finirai per inquinare Internet con indirizzi privati, qualcosa di molto negativo, e anche mostrare al mondo parte della topologia della tua rete interna. Qualcosa che non vuoi che un possibile attaccante/cracker abbia.
L’altra parte del problema è che per efficienza potresti voler risolvere a IP interni quando sei dentro e a IP esterni quando sei fuori. Qui parlo di computer che hanno connessioni pubbliche e private.
Ci sono molte soluzioni diverse a questo problema e ricordo di averlo risolto anche con BIND4, ma ora userò BIND9 per fare una soluzione molto pulita. Questo è stato implementato su un server Debian GNU/Linux 3.1 ma dovrebbe funzionare anche per altri sistemi operativi che eseguono BIND9, assicurati solo di cambiare i tuoi percorsi di conseguenza.
2 Configurazione iniziale
Immaginiamo che l’organizzazione per cui lavoro faccia esempi… di cosa? Non lo so, ma puoi ordinarli su example.com. La Examples Corporation ha ricevuto la rete 192.0.2.0/24 e internamente stiamo usando 10.0.0.0/24.
Iniziamo a servire i nomi e gli IP esterni, modifichiamo /etc/bind/named.conf.local 4 e aggiungiamo:
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
};e poi creiamo /etc/bind/db.example.com con i seguenti contenuti:
; example.com
$TTL 604800
@ IN SOA ns1.example.com. root.example.com. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
@ IN NS ns1
IN MX 10 mail
IN A 192.0.2.1
ns1 IN A 192.0.2.1
mail IN A 192.0.2.128 ; Abbiamo il nostro server di posta da un'altra parte.
www IN A 192.0.2.1
client1 IN A 192.0.2.201 ; Ci connettiamo a client1 molto spesso.Come puoi vedere, il nostro avvio ha un computer per servire tutti, tranne la posta, gestisce anche l’inoltro degli IP e un paio di database.
Ora, una buona configurazione DNS ha almeno un server secondario e infatti, alcuni registrar (dove registri i nomi di dominio) lo impongono. Poiché non abbiamo un secondo computer, andiamo su XName, apriamo un account e registriamo example.com come secondario con 192.0.2.1 come IP da trasferire. Ora dobbiamo consentire all’IP di XName di effettuare il trasferimento; siamo una piccola organizzazione ma poiché vogliamo essere una start up di successo cerchiamo di fare tutto nel modo più intelligente possibile. Quindi usiamo la direttiva di configurazione di BIND9 acl per definire un identificatore che si riferisce agli indirizzi IP di XName; all’inizio di /etc/bind/named.conf.local aggiungiamo:
acl slaves {
195.234.42.0/24; // XName
193.218.105.144/28; // XName
193.24.212.232/29; // XName
};e cambiamo la dichiarazione della zona in:
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
allow-transfer { slaves; };
};Avremmo potuto semplicemente digitare gli IP dove digitiamo “slaves”.
3 Interni ed esterni
Ora che abbiamo una base solida, possiamo iniziare a pensare a servire contenuti diversi alla rete interna ed esterna, ma prima, dobbiamo definire cosa è interno e cosa è esterno.
In /etc/bind/named.conf.local aggiungiamo la seguente definizione (in cima o sotto la definizione di slaves):
acl internals {
127.0.0.0/8;
10.0.0.0/24;
};Se avessimo più reti interne, potremmo semplicemente aggiungerle lì. Non definiamo esterni perché tutto ciò che non è interno è esterno. Puoi, se vuoi, definire insiemi di esterni diversi se desideri servire contenuti diversi a diverse porzioni di Internet.
Useremo una nuova funzionalità di BIND9 chiamata views. Una view ci consente di mettere un pezzo di configurazione all’interno di una condizione che può dipendere da un certo numero di cose, in questo caso dipenderemo solo da internals. Sostituiamo la dichiarazione della zona in /etc/bind/named.conf.local con:
view "internal" {
match-clients { internals; };
zone "example.com" {
type master;
file "/etc/bind/internals/db.example.com";
};
};
view "external" {
match-clients { any; };
zone "example.com" {
type master;
file "/etc/bind/externals/db.example.com";
allow-transfer { slaves; };
};
};La direttiva di configurazione match clients ci consente di mostrare condizionatamente quella view basata su un insieme di IP, “any” sta per qualsiasi IP. Gli IP interni saranno memorizzati nella cache dalla view interna e il resto sarà scartato nella view esterna. Il mondo esterno non può vedere la view interna, e questo include XName, il nostro fornitore DNS secondario, ma abbiamo rimosso l’allow-transfer dalla view interna poiché non vogliamo che nessuno possa trasferire in nessuna circostanza i contenuti della view interna.
Abbiamo anche cambiato il percorso, dovremo creare la directory /etc/bind/externals e /etc/bind/internals e spostare /etc/bind/db.example.com in /etc/bind/externals/.
In /etc/bind/internals/db.example.com mettiamo un file di zona simile al corrispondente esterno ma contenente gli IP interni:
; example.com
$TTL 604800
@ IN SOA ns1.example.com. root.example.com. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
@ IN A 10.0.0.1
boss IN A 10.0.0.100
printer IN A 10.0.0.101
scrtry IN A 10.0.0.102
sip01 IN A 10.0.0.201
lab IN A 10.0.0.103Ottimo, ora possiamo pingare il computer del nostro capo con
ping boss.example.comma cercare di raggiungere mail.example.com ci deluderà, cosa è successo? Non c’è riferimento a mail.example.com nel file di zona interno e poiché siamo nella rete interna possiamo risolvere mail.example.com. Bene, copiamo semplicemente i contenuti del file di zona esterno nel file di zona interno. Questo funzionerà.
Ma siamo una piccola, intelligente start up, possiamo fare meglio che copiare e incollare ogni modifica nel file di zona, inoltre, è molto soggetto a errori (ricorderai sempre di modificare il file di zona interno quando modifichi quello esterno, o dimenticherai e passerai giorni a fare debug dei problemi di rete?).
Quello che faremo è includere il file di zona esterno nel file interno in questo modo:
$include "/etc/bind/external/db.example.com"
@ IN A 10.0.0.1
boss IN A 10.0.0.100
printer IN A 10.0.0.101
scrtry IN A 10.0.0.102
sip01 IN A 10.0.0.201
lab IN A 10.0.0.103e voilà! Trovare la direttiva $include nella documentazione attuale è stato difficile… Ricorda solo di cambiare il serial del file di zona esterno ogni volta che cambi quello interno, ma non è un grosso problema, se dimentichi, non succederà nulla di male poiché non è probabile che tu abbia server di caching all’interno della tua piccola rete.
4 Sicurezza
Non è consigliabile utilizzare lo stesso server DNS come primario per un dominio (nel nostro caso example.com) e come server DNS di caching, ma nel nostro caso siamo costretti a farlo. Dal mondo esterno 192.0.2.1 è il server DNS primario per example.com, dalla nostra rete interna, 192.0.2.1 (o il suo indirizzo privato, 10.0.0.1) è il nostro server di nomi di caching che dovrebbe essere configurato come nameserver da utilizzare su ogni workstation che abbiamo.
Uno dei problemi è che qualcuno potrebbe iniziare a utilizzare il nostro server di nomi di caching dall’esterno, c’è un attacco chiamato cache-poisoning e molte altre cose brutte che possono essere fatte e sono documentate su [ SINS ] (incluso come evitarle).
Per migliorare un po’ la nostra sicurezza, aggiungeremo un paio di direttive al file di configurazione:
view "internal" {
match-clients { internals; };
recursion yes;
zone "example.com" {
type master;
file "/etc/bind/internals/db.example.com";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "example.com" {
type master;
file "/etc/bind/externals/db.example.com";
allow-transfer { slaves; };
};
};Questo impedirà a chiunque su Internet pericoloso di utilizzare il nostro server in modo ricorsivo mentre noi, sulla nostra rete, possiamo ancora farlo.
5 File di configurazione
5.1 /etc/bind/named.conf.local
acl slaves {
195.234.42.0/24; // XName
193.218.105.144/28; // XName
193.24.212.232/29; // XName
};
acl internals {
127.0.0.0/8;
10.0.0.0/24;
};
view "internal" {
match-clients { internals; };
recursion yes;
zone "example.com" {
type master;
file "/etc/bind/internals/db.example.com";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "example.com" {
type master;
file "/etc/bind/externals/db.example.com";
allow-transfer { slaves; };
};
};5.2 /etc/bind/externals/db.example.com
; example.com
$TTL 604800
@ IN SOA ns1.example.com. root.example.com. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
@ IN NS ns1
IN MX 10 mail
IN A 192.0.2.1
ns1 IN A 192.0.2.1
mail IN A 192.0.2.128 ; Abbiamo il nostro server di posta da un'altra parte.
www IN A 192.0.2.1
client1 IN A 192.0.2.201 ; Ci connettiamo a client1 molto spesso.5.3 /etc/bind/internals/db.example.com
$include "/etc/bind/external/db.example.com"
@ IN A 10.0.0.1
boss IN A 10.0.0.100
printer IN A 10.0.0.101
scrtry IN A 10.0.0.102
sip01 IN A 10.0.0.201
lab IN A 10.0.0.103Bibliografia
SINS
Securing an Internet Name Server
Note
… IPs
1
Per me, due computer già qualificano come troppi computer da ricordare i loro IP.
… file
2
Il file host risiede in /etc/hosts ed è una semplice mappatura per il computer locale da nomi a IP. Era il primo modo per risolvere i nomi in IP e molto tempo fa veniva mantenuto un grande file host centrale, successivamente distribuito tramite FTP o simili. È rapidamente cresciuto in un problema che è stato risolto con l’invenzione del DNS. Cerca di non lasciare che il tuo file host cresca in un problema prima di trasformarlo in DNS, impara dai pionieri!
… server
3
O quando sei un perfezionista e credi che questo dovrebbe essere realizzabile con solo un server.
…/etc/bind/named.conf.local
4
Potrebbe essere semplicemente /etc/bind/named.conf nel tuo sistema operativo se non è Debian.
Ricevi i nuovi post nella tua casella di posta.
Nessuno spam. Disiscriviti in qualsiasi momento.