FreeBSD utilizza, di default, una versione di BIND (Berkeley Internet Name Domain), che è la più completa implementazione del protocollo DNS. DNS è il protocollo attraverso il quale nomi sono mappati ad indirizzi IP, e viceversa. Per esempio, una query per www.FreeBSD.org riceverà una replica con l'indirizzo IP del web server del The FreeBSD Project, mentre una query per ftp.FreeBSD.org ritornerà l'indirizzo IP della corrispondente macchina FTP. Allo stesso modo, può avvenire l'opposto. Una query per un indirizzo IP può risolvere il suo nome host. Non è necessario avere in esecuzione un name server per fare DNS lookups su un sistema.
FreeBSD al momento viene distribuito con software DNS BIND9 di default. La nostra installazione fornisce caratteristiche di sicurezza migliorate, un nuovo layout del file system e configurazione chroot(8) automatica.
DNS è coordinato su Internet attraverso un sistema alquanto complesso di name server autoritativi, ed altri name server di più piccola scala che ospitano e gestiscono cache di informazioni individuali sui domini.
Al momento corrente, BIND è mantenuto dall'Internet Software Consortium http://www.isc.org/.
Per comprendere questo documento, alcuni termini relativi al DNS devono essere capiti.
Termine | Definizione |
---|---|
Forward DNS | La mappa da hostname ad indirizzi IP. |
Origine | Si riferisce al dominio coperto in un particolare file di zona. |
named, BIND, name server | Nomi comuni per il pacchetto name server BIND all'interno di FreeBSD. |
Risolutore | Un processo di sistema attraverso il quale una macchina fa query su un name server per informazioni di zona. |
DNS inverso | L'opposto del forward DNS; mappare indirizzi IP su nomi host. |
Zona root | L'inizio della gerarchia della zona Internet. Tutte le zone cadono sotto la zona root, analogamente a come tutti i file nel file system cadono sotto la directory root. |
Zona | Un dominio individuale, sottodominio, o porzione del DNS amministrato dalla stessa autorità |
Esempi di zone:
. è la zona root
org. è una zona Top Level Domain (TLD) sotto la zona root
example.org. è una zona sotto la zona org. TLD
1.168.192.in-addr.arpa è una zona che referenzia tutti gli indirizzi IP che cadono sotto lo spazio IP 192.168.1.*.
Come si può vedere, la parte più specifica di un nome host appare a sinistra. Per esempio example.org. è più specifico di org., come org. è più specifico della zona root. La disposizione di ogni parte di un nome host è analoga ad un file system: la directory /dev cade all'interno della root, e così via.
Attualmente vengono usati due tipi di name server: un name server autoritativo, ed un name server cache.
Un name server autoritativo è necessario quando:
uno vuole servire informazioni DNS a tutto il mondo, rispondendo in maniera autoritativa alle query.
un dominio, tipo example.org, è registrato e gli indirizzi IP devono essere assegnati ad hostname sotto questo.
un blocco di indirizzi IP richiede entry di DNS inverso (da IP ad hostname).
un name server di backup, chiamato uno slave, deve rispondere alle query.
Un name server cache è necessario quando:
un server locale DNS può tenere in cache e rispondere più velocemente rispetto ad effettuare query ad un name server all'esterno.
una riduzione nel traffico complessivo di rete è desiderato (è stato calcolato che il traffico DNS conta più del 5% sul traffico totale di Internet).
Quando uno fa una query per risolvere www.FreeBSD.org, il risolutore di solito fa una query al name server dell'ISP a cui si è connessi, ed ottiene una risposta. Con un server DNS locale, che fa cache, la query deve essere effettuata una volta sola dal server DNS che fa cache. Ogni query aggiuntiva non dovrà cercare all'esterno della rete locale, dato che l'informazione è tenuta in cache localmente.
In FreeBSD, il demone BIND è chiamato named per ovvie ragioni.
File | Descrizione |
---|---|
named(8) | Il demone BIND. |
rndc(8) | Programma di controllo del name server. |
/etc/namedb | Directory dove risiedono le informazioni di zona di BIND. |
/etc/namedb/named.conf | File di configurazione del demone. |
A seconda di come certe zone sono configurate sul server, i file relativi a quelle zone possono essere trovate nelle sottodirectory master, slave, or dynamic della directory /etc/namedb. Questi file contengono le informazioni DNS che saranno distribuite dal name server in risposta alle query.
Dato che BIND è installato di default, configurarlo è relativamente semplice.
La configurazione di default di named è quella di un name server basilare, eseguito in ambiente chroot(8). Per avviare il server una volta con questa configurazione, usa il seguente comando:
# /etc/rc.d/named forcestart
Per assicurarsi che il demone named sia avviato alla partenza, metti la seguente riga in /etc/rc.conf:
named_enable="YES"
Ci sono ovviamente molte opzioni di configurazione per /etc/namedb/named.conf che sono al di là dello scopo di questo documento. Comunque, se siete interessati nelle opzioni di avvio per named su FreeBSD, dai un'occhiata ai flags named_ in /etc/defaults/rc.conf e consulta la pagina di manuale rc.conf(5). Anche la sezione Sezione 11.2 è una buona base di partenza.
I file di configurazione per named al corrente risiedono nella directory /etc/named e necessiteranno di modifiche prima dell'uso, a meno che non si voglia un semplice resolver. Qui è dove la maggior pare della configurazione viene effettuata.
Per configurare una zona master per il localhost visita la directory /etc/namedb ed esegui il seguente comando:
# sh make-localhost
Se tutto è andato bene, un nuovo file dovrebbe esistere nella sottodirectory master. I nomi dei file dovrebbero essere localhost.rev per il local domain name elocalhost-v6.rev per le configurazioni IPv6. Come il file di configurazione di default, l'informazione richiesta sarà presente nel file named.conf.
// $FreeBSD$ // // Refer to the named.conf(5) and named(8) man pages, and the documentation // in /usr/share/doc/bind9 for more details. // // If you are going to set up an authoritative server, make sure you // understand the hairy details of how DNS works. Even with // simple mistakes, you can break connectivity for affected parties, // or cause huge amounts of useless Internet traffic. options { directory "/etc/namedb"; pid-file "/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; // If named is being used only as a local resolver, this is a safe default. // For named to be accessible to the network, comment this option, specify // the proper IP address, or delete this option. listen-on { 127.0.0.1; }; // If you have IPv6 enabled on this system, uncomment this option for // use as a local resolver. To give access to the network, specify // an IPv6 address, or the keyword "any". // listen-on-v6 { ::1; }; // In addition to the "forwarders" clause, you can force your name // server to never initiate queries of its own, but always ask its // forwarders only, by enabling the following line: // // forward only; // If you've got a DNS server around at your upstream provider, enter // its IP address here, and enable the line below. This will make you // benefit from its cache, thus reduce overall DNS traffic in the Internet. /* forwarders { 127.0.0.1; }; */
Proprio come dicono i commenti, per beneficiare di una cache di un server superiore, può essere abilitato forwarders. Sotto circostanze normali, un name server farà query ricorsive attraverso Internet cercando certi name server fino a chè non trova la risposta che sta cercando. Averlo abilitato farà sì che sarà fatta prima una query verso il name server superiore (o il name server fornito), avvantaggiandosi della sua cache. Se il name server superiore è un name server molto trafficato e veloce, può valere la pena di abilitarlo.
Avvertimento: 127.0.0.1 non funzionerà qui. Cambia questo indirizzo IP in un name server superiore.
/* * If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND versions 8 and later * use a pseudo-random unprivileged UDP port by default. */ // query-source address * port 53; }; // If you enable a local name server, don't forget to enter 127.0.0.1 // first in your /etc/resolv.conf so this server will be queried. // Also, make sure to enable it in /etc/rc.conf. zone "." { type hint; file "named.root"; }; zone "0.0.127.IN-ADDR.ARPA" { type master; file "master/localhost.rev"; }; // RFC 3152 zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA" { type master; file "master/localhost-v6.rev"; }; // NB: Do not use the IP addresses below, they are faked, and only // serve demonstration/documentation purposes! // // Example slave zone config entries. It can be convenient to become // a slave at least for the zone your own domain is in. Ask // your network administrator for the IP address of the responsible // primary. // // Never forget to include the reverse lookup (IN-ADDR.ARPA) zone! // (This is named after the first bytes of the IP address, in reverse // order, with ".IN-ADDR.ARPA" appended.) // // Before starting to set up a primary zone, make sure you fully // understand how DNS and BIND works. There are sometimes // non-obvious pitfalls. Setting up a slave zone is simpler. // // NB: Don't blindly enable the examples below. :-) Use actual names // and addresses instead. /* An example master zone zone "example.net" { type master; file "master/example.net"; }; */ /* An example dynamic zone key "exampleorgkey" { algorithm hmac-md5; secret "sf87HJqjkqh8ac87a02lla=="; }; zone "example.org" { type master; allow-update { key "exampleorgkey"; }; file "dynamic/example.org"; }; */ /* Examples of forward and reverse slave zones zone "example.com" { type slave; file "slave/example.com"; masters { 192.168.1.1; }; }; zone "1.168.192.in-addr.arpa" { type slave; file "slave/1.168.192.in-addr.arpa"; masters { 192.168.1.1; }; }; */
In named.conf, ci sono esempi di linee slave per zone di forward ed inverse.
Per ogni nuova zona servita, una nuova linea di zona deve essere aggiunta a named.conf.
Per esempio, la più semplice entry per example.org può assomigliare a:
zone "example.org" { type master; file "master/example.org"; };
La zona è una master, come indicato dall'entry type
, e
conserva le informazioni di zona su /etc/namedb/master/example.org indicata dalla entry file
.
zone "example.org" { type slave; file "slave/example.org"; };
Nel caso slave, l'informazione di zona è trasferita dal name server master per quella zona particolare, e salvata nel file specificato. Se e quando il master muore o è irraggiungibile, il name server slave avrà le informazioni di zona trasferite e sarà in grado di servirlo.
Un esempio di file di zona master per example.org (che esiste all'interno di /etc/namedb/master/example.org ) è la seguente:
$TTL 3600 ; 1 hour example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 86400 ; Minimum TTL ) ; DNS Servers IN NS ns1.example.org. IN NS ns2.example.org. ; MX Records IN MX 10 mx.example.org. IN MX 20 mail.example.org. IN A 192.168.1.1 ; Machine Names localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5 ; Aliases www IN CNAME @
Nota che ogni hostname che finisce in un “.” è un nome esatto, mentre ogni entità senza un “.” è referenziato all'origine. Per esempio www è trasformato in www.origin. Nel nostro file di zone fittizio, la nostra origine è example.org, così www si trasformerebbe in www.example.org.
Il formato di un file di zona è il seguente:
recordname IN recordtype value
I record DNS usati più di frequente:
inizio di una zona di autorità
un name server autoritativo
un indirizzo host
il nome canonico per un alias
mail exchanger
un puntatore a nome di dominio (usato nel DNS inverso)
example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 day
il nome di dominio, inoltre è l'origine per questo file di zona.
il name server primario/autoritativo per questa zona.
la persona responsabile per questa zona, un indirizzo email con “@”
sostituito. (<admin@example.org>
diventa admin.example.org)
il numero di serie del file. Questo deve essere aumentato ogni volta che il file di zona è modificato. Al giorno d'oggi molti amministratori preferiscono un formato yyyymmddrr per il numero di serie. 2006051501 significherebbe modificato l'ultima volta il 05/15/2006, l'ultimo 01 essendo la prima volta che il file di zona è stato modificato in questo giorno. Il numero di serie è importante dato che avverte name server slave per una zona quando questa ` modificata.
IN NS ns1.example.org.
Questa è una linea NS. Ogni name server che replicherà in maniera autoritativa la zona deve avere una di queste linee. Il @ come visto potrebbe essere stato example.org. Il @ si traduce nell'origine.
localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5
Il record A indica un nome macchina. Come visto sopra, ns1.example.org risolverebbe in 192.168.1.2.
IN A 192.168.1.1
Questa linea assegna l'indirizzo IP 192.168.1.1 alla corrente origine, in questo caso example.org.
www IN CNAME @
Il record nome canonico è usato per dare alias ad una macchina. Nell'esempio, www è tramutato in alias nella macchina “master” che corrisponde al domain name example.org (192.168.1.1). CNAME possono essere usati per fornire alias ad hostname o distribuire in round robin un hostname fra molte macchine.
IN MX 10 mail.example.org.
Il record MX ` usato per specificare quali mail server sono responsabili per gestire mail entranti per la zona. mail.example.org è l'hostname del mail server, e 10 è la priorità di quel mail server.
Uno può avere molti mail server, con priorità di 10, 20 e così via. Un mail server che cerca di consegnare una mail a example.org proverà prima l'MX con la più alta priorità (il record con il numero di priorita' minimo) poi il secondo, etc., fino a chè la mail non sia consegnata correttamente.
Per file di zona in-addr.arpa (DNS inverso), lo stesso formato è usato, eccetto con linee PTR al posto di A o CNAME.
$TTL 3600 1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 3600 ) ; Minimum IN NS ns1.example.org. IN NS ns2.example.org. 1 IN PTR example.org. 2 IN PTR ns1.example.org. 3 IN PTR ns2.example.org. 4 IN PTR mx.example.org. 5 IN PTR mail.example.org.
Questo file da la corretta mappa da indirizzi IP ad hostname per il nostro dominio fittizio.
Un name server caching è un name server che non è autoritativo per nessuna zona. Fa semplicemente query, e ne memorizza le risposte per uso successivo. Per impostarne uno, configura il name server come al solito, omettendo ogni inclusione di zona.
Anche se BIND è la più comune implementazione del DNS, c'è sempre la questione della sicurezza. Talvolta vengono trovati possibili e sfruttabili buchi di sicurezza.
Mentre FreeBSD tiene named automaticamente in un ambiente chroot(8), ci sono molti altri meccanismi di sicurezza che potrebbero essere sfruttati per attacchi al servizio DNS.
È una buona idea leggere gli avvisi sulla sicurezza di CERT e sottoscrivere le mailing list sugli avvisi di sicurezza su FreeBSD per stare aggiornato con le questioni correnti di sicurezza di Internet e FreeBSD.
Suggerimento: Se sorge un problema, tenere i sorgenti aggiornati e fare una compilazione al volo di named non farebbe male.
Questo, ed altri documenti, possono essere scaricati da ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
Per domande su FreeBSD, leggi la documentazione prima di contattare <questions@FreeBSD.org>.
Per domande su questa documentazione, invia una e-mail a <doc@FreeBSD.org>.