Internet è il postino dei nostri tempi che nessun cane azzannerà.
Dopo aver visto come configurare un semplice servizio di caching DNS con Bind9 (Berkley Internet Name Daemon Version 9) e Ubuntu (la versione LTS, Hardy Heron 8.04), vediamo qualcosa di più utile nella configurazione di una LAN aziendale. Configuriamo il DNS come master per il nostro dominio per fare in modo che oltre al caching dei nomi esterni, risolva anche i nomi host della rete locale.
Nel nostro dominio stenoit.com supponiamo di aver questi quattro host a cui vogliamo associare un IP fisso:
| Ruolo | IP | nome host | Alias |
| DNS Server | 192.168.1.1 | dns | |
| Mail Server | 192.168.1.2 | pop3 smtp | |
| Web Server | 192.168.1.3 | web | www |
| Workstation | 192.168.1.10 | wks01 |
Notiamo che il Mail server ha due “alias” (canonical name, CNAME) e il web server uno (www). In questo modo possiamo avere, semplicemente, più nomi riferiti allo stesso IP.
Ubuntu (a dire il vero in tradizione Debian) installa un file di configurazione (/etc/named.conf) che, se non in casi particolari, non ha bisogno di essere modificato. Tutte le nostre personalizzazioni le facciamo su di un apposito file secondario:
sudo nano /etc/bind/named.conf.local
zone “stenoit.com” IN {
type master;
file “/etc/bind/zones/stenoit.com.db”;
};
zone “1.168.192.in-addr.arpa” {
type master;
file “/etc/bind/zones/1.168.192.in-addr.arpa”;
};
sudo mkdir /etc/bind/zones
sudo nano /etc/bind/zones/stenoit.com.db
stenoit.com. IN SOA dns.stenoit.com. admin.stenoit.com. (
2009260401 ; numero di serie
8H ; refresh
4H ; retry
4W ; expire
1D ; minimum
)
Andiamo avanti:
stenoit.com. IN NS dns.stenoit.com.
stenoit.com. IN MX 10 mail.stenoit.com.
pop3 IN CNAME mail.stenoit.com.
smtp IN CNAME mail.stenoit.com.
www IN CNAME web.stenoit.com.
localhost IN A 127.0.0.1
dns IN A 192.168.1.1
mail IN A 192.168.1.2
web IN A 192.168.1.3
wks01 IN A 192.168.1.10
sudo nano /etc/bind/zones/1.168.192.in-addr.arpa
@ IN SOA dns.stenoit.com. admin.stenoit.com. (
2009042601 ; serial
8H ; refresh
4H ; retry
4W ; expire
1D ; minimum
)IN NS dns.stenoit.com.
1 IN PTR dns.stenoit.com.
2 IN PTR mail.stenoit.com.
3 IN PTR web.stenoit.com.
10 IN PTR wks01.stenoit.com.
Ora non ci resta che riavviare il servizio.
sudo /etc/init.d/bind9 restart
dig web.stenoit.com
Il nostro DNS è pronto e funzionante. In una moderna installazione mancano però ancora un paio di tasselli importanti: il DHCP per assegnare automaticamente l'indirizzo IP a chi ne fa richiesta e il conseguente aggiornamento automatico delle tabelle DNS. Lo vedremo nel proseguo.
Bye.
Ma se volessi fare in modo che il dns risolva diversamente sulla base dell'indirizzo ip richiedente?
Questo per fare in modo che una richiesta di risoluzione dall'esterno della mia rete dia come risultato un nome generico per le macchine ( per i reverse: host-192.168.x.x ) mentre dall'interno il nome "specifico" ( mail.domain.it ).
E' possibile?
Non sono certo di aver capito cosa intendi, ma non vedrei difficoltà. Anzi, è usato molto spesso.
Gli host "esterni" useranno il DNS "ufficiale" del tuo dominio (che sta quasi sicuramente dal provider dove lo hai registrato), gli host interni quello aziendale.
Gli indirizzi privati (192.168.x.x e altri) non possono essere usati/instradi su internet.
Be' si' con 2 DNS :)
Cercando un po' direi che volevo trasmettere il concetto delle "viste" DNS di Bind...
Comunque quello che vorrei e' poter divulgare "mondialmente" delle informazioni generiche ( anonime diciamo ) su macchine interne ( con ip pubblici ).
Mentre internamente le stesse macchine devono essere risolte correttamente ( smtp.domain.com ).
E' chiaro che e' tutto complicato da risoluzione diretta e reverse ma diciamo che l'idea sarebbe dividere le risoluzioni condivise al resto del mondo da quelle locali su base ip.
@grick: la cosa che vuoi fare è *pericolosissima*: non bisogna mai dare accesso dall'esterno ad un resolver (bind configurato come lo vediamo qui fornisce risposte authoritative per il dominio locale e fa da resolver per quelli esterni).
Il motivo è un pelo delicato e lungo da spiegare.
Sei "obbligato" ad usare più macchine per fare quello che chiedi, oppure due servizi con file di configurazione indipendenti. Poi via firewall giri le richieste in modo opportuno.
Ma il DNS non sarebbe accessibile dall'esterno , pero' le zone ( dirette e reverse ) per cui e' authoritative sono giustamente propagate a tutti gli altri DNS.
Ecco diciamo che dovrebbe propagare quelle anonime e invece risolvere diversamente internamente.