Premesso che per mettere in piedi un nameserver locale si possono utilizzare diverse soluzioni open source, anche di tipo enterprise (una su tutte è rappresentata da bind/named), ho deciso di installare dnsmasq su un server Ubuntu per 2 motivi:
1) la rete aveva dimensioni estremamente ridotte (un server, qualche workstation e 3 stampanti), quindi rientrava nell’ambito delle infrastrutture SOHO (Small Office Home Office);
2) vi era la necessità di tirar su anche un servizio di DHCP, configurabile direttamente sull’applicativo in questione (che quindi può svolgere, contemporaneamente, sia il ruolo di nameserver che quello di DHCP server).
Configurazione del DHCP server
Fare in modo che dnsmasq svolga le funzioni tipiche di un server DHCP è un’operazione abbastanza banale. Infatti, è sufficiente editare la configurazione del demone in questione (operando sul file /etc/dnsmasq.conf), aggiungendo le seguenti direttive:
no-dhcp-interface=eth1 dhcp-range=eth1,192.168.0.100,192.168.0.199,8h
In particolare, ho messo in ascolto il server DHCP sulla sola interfaccia eth0 (dato che si tratta di una macchina dual homed, in cui la scheda eth1 è collegata ad Internet mediante uno screened router). Inoltre, ho definito il pool di indirizzi che possono assere assegnati ai client che ne fanno richiesta, con relativo lease time (8h).
Configurazione del nameserver
Tale configurazione è un po’ più complessa rispetto alla precedente ma risulta comunque abbordabile.
Diciamo che dnsmasq è un nameserver “giocattolo”, in cui molti record DNS devono essere definiti all’interno di un file “piatto”, quale, ad esempio, /etc/hosts (anche se è possibile definire un file ad hoc per tale scopo), senza che vi sia quindi la necessità di creare una specifica zona DNS (cosa che invece risulta essere mandatoria con altri nameserver “un po’ più seri”).
I record di tipo A presenti nel file /etc/hosts avevano un formato simile al seguente:
192.168.0.2 proxy 192.168.0.4 server1 192.168.0.5 PC1 192.168.0.6 stampante1 192.168.0.7 stampante2 192.168.0.9 stampante3 192.168.0.10 PC2
Per quanto riguarda, invece, la configurazione del servizio DNS, ho abilitato le seguenti direttive (all’interno del file /etc/dnsmasq.conf):
interface=eth0 except-interface=eth1 listen-address=192.168.0.2 expand-hosts domain=soho.loc
Le prime 3 servono a mettere in ascolto il server solo ed esclusivamente sull’interfaccia rivolta verso la LAN. Con expand-hosts e domain=soho.loc, invece, ho fatto in modo che le query DNS vadano a buon fine anche nel caso in cui venga fornito il solo hostname della macchina di cui si vuole conoscere l’indirizzo IP.
Poichè il suddetto nameserver deve risolvere solo ed esclusivamente gli indirizzi locali, ho dovuto definire i forwarder (o nameserver di upstream) a cui inviare le query per tutte le zone DNS pubbliche. La direttive che ho utilizzato sono le seguenti:
resolv-file=/etc/resolv.dnsmasq strict-order
dove il contenuto del file /etc/resolv.dnsmasq era il seguente:
nameserver 8.8.8.8 nameserver 208.67.222.222 nameserver 8.8.4.4 nameserver 208.67.220.220
La direttiva strict-order faceva in modo che i forwarder venissero contattati seguendo l’ordine con cui sono stati definiti all’interno del suddetto file (il secondo nameserver viene contattato solo nel caso in cui il primo non sia raggiungibile, ergo, per ottenere una maggiore ridondanza, ho deciso di alternare ai nameserver di Google quelli di OpenDNS).
Per avere un maggiore controllo sulle query inoltrate al nameserver locale, ho deciso di loggarle su un apposito file di testo grazie ai seguenti parametri di configurazione:
log-queries log-facility=/var/log/dnsmasq/query.log
Ho anche configurato la rotazione dei log mediante il file dnsmasq posto all’interno della directory /etc/logrotate.d:
/var/log/dnsmasq/query.log {
rotate 7
weekly
compress
missingok
notifempty
}
Infine, affinchè i client della LAN riuscissero a “riconoscere” i record DNSSEC (garantendo loro una maggiore sicurezza durante la navigazione su Internet), ho fatto in modo che dnsmasq girasse le query DNSSEC ai forwarder (demandando loro il ruolo di validator).
La direttiva che mi ha consentito di fare ciò è la seguente:
proxy-dnssec
Il fatto che il nameserver primario di Google (8.8.8.8) sia il primo della lista dei forwarder non è certamente un caso. Infatti, esso garantisce dei tempi di risposta più brevi rispetto a quelli di OpenDNS, oltre ad essere anche DNSSEC compliant (cosa che OpenDNS non è).
In definitiva, la configurazione di dnsmasq (in base alle mie esigenze) si è rivelata essere la seguente:
no-dhcp-interface=eth1 dhcp-range=eth1,192.168.0.100,192.168.0.199,8h interface=eth0 except-interface=eth1 listen-address=192.168.0.2 expand-hosts domain=soho.loc resolv-file=/etc/resolv.dnsmasq strict-order log-queries log-facility=/var/log/dnsmasq/query.log proxy-dnssec
Dopo aver effettuato un controllo sintattico della suddetta configurazione mediante il comando:
root@ubuntubox:~# dnsmasq --test
ed aver riavviato il demone:
root@ubuntubox:~# service dnsmasq restart
sono passato ai test funzionali mediante dig. Per prima cosa ho effettuato una query di tipo A per il record proxy, utilizzando dapprima il solo hostname:
root@fw-scar:~# dig @localhost proxy ; <<>> DiG 9.8.1-P1 <<>> @localhost proxy ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3216 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;proxy. IN A ;; ANSWER SECTION: proxy. 0 IN A 192.168.0.2 ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri May 20 15:50:11 2016 ;; MSG SIZE rcvd: 39
e successivamente l’intero FQDN:
root@fw-scar:~# dig @localhost proxy.soho.loc ; <<>> DiG 9.8.1-P1 <<>> @localhost proxy.soho.loc ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30251 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;proxy.soho.loc. IN A ;; ANSWER SECTION: proxy.soho.loc. 0 IN A 192.168.0.2 ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri May 20 15:52:15 2016 ;; MSG SIZE rcvd: 48
Successivamente mi sono concentrato sui tempi di risposta per i domini pubblici (da parte dei forwarder), ottenendo i seguenti tempi pre-cashing:
root@fw-scar:~# dig @localhost repubblica.it | grep "Query time" ;; Query time: 50 msec
e post caching:
root@fw-scar:~# dig @localhost repubblica.it | grep "Query time" ;; Query time: 0 msec
Infine, ho testato la risoluzione dei record DNSSEC, utilizzando il comando:
root@fw-scar:~# dig @localhost pir.org +dnssec +multi ; <<>> DiG 9.8.1-P1 <<>> @localhost pir.org +dnssec +multi ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35285 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;pir.org. IN A ;; ANSWER SECTION: pir.org. 299 IN A 97.107.141.235 pir.org. 299 IN RRSIG A 5 2 300 20160602204000 ( 20160519204000 58424 pir.org. cJwr7HlIMA+DyQ8vqqmkNtHRAqsGVdKWTQkJeP/a5698 UTyK/cF08uYhH8xMk9I0RMWqtkJDM8od8hWmYUZgidzi 7Fh26m1FQYGAcN/PMw2/6wEnNh4ErWZtXe2fXRAS8btx I+nyRPOCoAHR3CjC0cjKqtniUoWHt5x/51iEBw4= ) ;; Query time: 86 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri May 20 15:57:36 2016 ;; MSG SIZE rcvd: 219
ricevendo come risposta sia il record A che il relativo RRSIG.
Alla fine della fiera ho messo in piedi un server DNS/DHCP funzionante e funzionale.
Alla prossima.
