27.6. Domain Name System (DNS)

Grazie al contributo di Chern Lee, Tom Rhodes e Daniel Gerzo.

27.6.1. Uno sguardo d'insieme

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/.

27.6.2. Terminologia

Per comprendere questo documento, alcuni termini relativi al DNS devono essere capiti.

TermineDefinizione
Forward DNSLa mappa da hostname ad indirizzi IP.
OrigineSi riferisce al dominio coperto in un particolare file di zona.
named, BIND, name serverNomi comuni per il pacchetto name server BIND all'interno di FreeBSD.
RisolutoreUn processo di sistema attraverso il quale una macchina fa query su un name server per informazioni di zona.
DNS inversoL'opposto del forward DNS; mappare indirizzi IP su nomi host.
Zona rootL'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.
ZonaUn 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.

27.6.3. Ragioni per Avere in Esecuzione un Name Server

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.

27.6.4. Come Funziona

In FreeBSD, il demone BIND è chiamato named per ovvie ragioni.

FileDescrizione
named(8)Il demone BIND.
rndc(8)Programma di controllo del name server.
/etc/namedbDirectory dove risiedono le informazioni di zona di BIND.
/etc/namedb/named.confFile 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.

27.6.5. Avviare BIND

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, «Configurazione Iniziale» è una buona base di partenza.

27.6.6. File di Configurazione

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.

27.6.6.1. Usando make-localhost

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.

27.6.6.2. /etc/namedb/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.

27.6.6.3. File di Zona

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:

SOA

inizio di una zona di autorità

NS

un name server autoritativo

A

un indirizzo host

CNAME

il nome canonico per un alias

MX

mail exchanger

PTR

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
example.org.

il nome di dominio, inoltre è l'origine per questo file di zona.

ns1.example.org.

il name server primario/autoritativo per questa zona.

admin.example.org.

la persona responsabile per questa zona, un indirizzo email con «@» sostituito. ( diventa admin.example.org)

2006051501

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.

27.6.7. Caching Name Server

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.

27.6.8. Sicurezza

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.

27.6.9. Ulteriori letture

Pagine di manuale di BIND/named: rndc(8) named(8) named.conf(5)

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>.