I file di zona di bind 9

In questo articolo vediamo come è fatto un file di zona autoritativo per un dominio locale denominato “local”, quale può essere quello deputato alla risoluzione dei nomi host di una lan interna con indirizzo 10.1.0.0

Non vuole essere un documento esaustivo per tutte le direttive ed i tipi di Resource Record ( RR ), solo un aiuto a comprendere i file di zona più comuni

Il server a cui facciamo riferimento è una distribuzione debian stretch su cui gira il servizio bind 9.

Non ci occuperemo della configurazione di bind, diciamo solo che il file di zona in questione viene caricato tramite il file /etc/bin/named.conf.local che contiene la definizione

La zona pertanto è contenuta in /var/cache/bind/db.local

Il file di zona

Una configurazione minimale deve riportare un record SOA ed un record NS con un nome host che viene poi dichiarato con un record A

Anche se per il momento non serve a molto, questo file è sufficiente a definire la zona “local.”, con un name server denominato “ns1” che risponde all’ indirizzo “ns1.local” e che viene risolto in “10.1.0.1”.
Il record A che segue il record NS serve a risolvere il nome “local” ( senza host ) in “10.1.0.1”
Il secondo record A invece server a risolvere il nome “ns.local” in “10.1.0.1”

I commenti

I commenti iniziano con un ; e finiscono con il terminatore di riga. Possono essere inseriti in qualunque punto del file

Le direttive

Le direttive disponibili in bind sono ORIGIN, TTL, INCLUDE e GENERATE. Qui parleremo solo delle prime tre ed ignoreremo GENERATE

La direttiva $ORIGIN

Durante l’elaborazione della zona, questa direttiva definisce il nome base con cui verranno accodati tutti i nomi “non qualificati” ( che non terminano con un . ) che seguono
Se è presente, deve sempre terminare con un . e se è presente in più punti del file significa che da li in poi quel valore sostituisce quello precedente.

Nella nostra zona, la prima $ORIGIN vale “.” quindi il nome non qualificato “local” ( senza . ) che è nella definizione del record SOA, viene letto come “local.” ( con il . )

La seconda $ORIGIN invece vale “local.” quindi “ns1”  del record A che segue viene letto come “ns1.local.”

La direttiva $ORIGIN non è obbligatoria, però rende tutto più leggibile.

Se non è presente il suo valore viene assegnato tramite il nome della zona presente nel file /etc/bin/named.conf che nel nostro caso vale “local.”
L’assenza di $ORIGIN impone di inserire valori validi nei nomi di zona perché in questo modo diventa l’unica cosa che identifica il nostro dominio

Il valore di questa direttiva deve sempre terminare con “.” per qualificare i nomi

Vediamo come potrebbe essere il nostro file di zona senza la direttiva $ORIGIN

In questo caso, il valore di $ORIGIN è il nome della zona definito nel file di configurazione di bind, che vale “local.” Tutti i valori che prima venivano espansi in “qualcosa.local.” ora possono essere scritti come “qualcosa” quindi le “@” verrano espanse in “local.”, “ns1” in “ns1.local.”, “hostmaster” in “hostmaster.local.” ecc…
In questo caso però se modificassimo il nome alla zona, anche solo il “.” finale, significherebbe non avere più una definizione di zona valida, quindi è più sicuro e pulito usare la direttiva ORIGIN

La direttiva $TTL

Significa Time To Live, ed imposta l’ammontare di tempo in secondi per cui i record che seguono possono essere tenuti nella cache dai risolutori di nomi prima che debbano essere richiesti nuovamente. I risolutori di nomi possono anche non tenere conto di questo valore specialmente quando è troppo basso.

La prima $TTL deve precedere ogni record, quindi va scritta prima del SOA, per indicare il periodo di validità di tutta la zona.

Le successive, hanno valore da quel punto in poi e possono essere utilizzate per indicate il time to live anche di un singolo record.

Il tipico valore di TTL per un record SOA è di un giorno, cioè 84600 secondi, ma se si ha la necessità di inserire nuovi host con una certa frequenza, probabilmente non si vuole attendere un giorno intero prima che tutti i risolutori si allineino aggiornando le loro cache.

Il valore 0 ( zero ) indica di non cachare i record che seguono, ma i risolutori possono decidere di ignorare valori troppo piccoli

La direttiva $INCLUDE

Per terminare l’elenco delle direttive, anche se non è presente nella nostra zona, citiamo anche $INCLUDE

Viene utilizzata nella definizione di zone di grandi dimensioni per includere file contenenti definizioni di host

La sintassi è

Gli host elencati nel file, vengono espansi in host.dominio. come se al loro interno fossero preceduti da una direttiva ORIGIN solo che questa viene valorizzata all’ esterno, come avviene quando $ORIGIN viene impostata dal nome della zona. In questo modo con uno stesso file che contiene i record A per www, mail ecc è possibile definire www.dominio1. mail.dominio1. www.dominio2. mail.dominio2. ecc…

Formato del generico resource record dns

Un record dns è formato da 5 campi, che possono anche essere vuoti nel qual caso il loro valore viene preso pari ad uno di default o pari a quello dell’ ultimo record precedente in cui era definito.

I campi che compongono un generico Resource Record sono questi

• name
• ttl
• class
• type
• type-data

name

E’ il nome del record e può essere qualunque combinazione di lettere, numeri e ‘-‘ ma deve inziare con una lettera. Quelli presenti nel nostro esempio sono local, ns1

Quando è presente una @ questa rappresenta una stringa vuota e viene espansa con il valore della direttiva ORIGIN

Se viene omesso, il suo valore è quello contenuto nell’ ultimo record in cui era presente. In questo modo è possibile definire uno stesso name per più record. Ad esempio si può definire www come un host che viene risolto sia in un indirizzo ipv4 sia in un ipv6 senza ripetere due volte lo stesso name

ttl

E’ il time to live specifico del record. Se viene omesso, il suo valore è quello dell’ultima direttiva $TTL

class

Definisce il protocollo, il valore tipico è IN ( Internet protocol ) ma può valere anche HS e CH per retro compatibilità con protocolli obsoleti.

Se omesso il valore di default è IN

type

Questo campo indica il tipo di record, nel nostro esempio abbiamo usato i valori SOA, NS ed A. Ci sono molti valori validi per questo campo, i più comuni sono SOA, NS, MX, A, AAAA, PTR, CNAME e TXT ma l’elenco è molto più lungo. Possono essere memorizzate anche coordinate geografiche GPS

type-data

In questo campo vengono inseriti i valori assegnati al name e dipendono dal type

Nel nostro esempio sono tutte le stringhe che seguono SOA, NS ed A fino all’ inizio del resource record successivo.

Principali tipi di Resource Record

Record SOA

Lo Start Of Authority Resource Record ( SOA RR ) definisce i parametri globali del dominio. E’ ammesso un solo SOA RR in un file di zona e deve essere il primo record elencato. Può essere preceduto solamente dalle direttive ORIGIN e TTL

Oltre al type SOA ci sono 2 campi importanti:

• name: rappresenta il nome del dominio, esplicitato con un nome host qualificato o non qualificato che viene completato dalla direttiva ORIGIN, quindi anche @ e campo vuoto sono valori validi
• type-data: è formato da 3 valori
  • name-server: un nome di host qualificato che può essere un host descritto all’interno della zona o appartenente ad un altro dominio. Nel nostro esempio vale “ns1.local.”
  • email-address: identifica l’indirizzo email del responsabile del server, il formato non è quello convenzionale casella@dominio ma casella.dominio. Nel nostro esempio vale “hostmaster.local.” ovvero hostmaster@local
  • Segue una gruppo di campi numerici racchiuso tra due parentesi i cui valori hanno questo significato
    • sn: Serial number, solitamente nel formato yyyymmddss dove ss è un numero sequenziale progressivo che parte da 0. Questo campo deve essere incrementato ogni volta che viene modificato un record nella zona. I server dns slave quando ricevono dal master un NOTIFY o durante la lettura periodica della zona master, confrontano questo valore con quello memorizzato nella loro zona locale e se trovano un valore superiore iniziano il processo di trasferimento di zona
    • refresh: Indica ogni quanti secondi un server slave deve effettuare il refresh della zona
    • retry: Definisce ogni quanti secondi un server slave deve riprovare a contattare il master se non è riuscito a collegarsi
    • expiry: Indica quanti secondi devono trascorrere affinchè un server slave che non è riuscito ad aggiornare la propria zona con il server master debba considerare la zona come non più autoritativa
    • nx domain ttl: Indica per quanti secondi un risolutore di nomi deve tenere nella propria cache le definizioni contenute nella zona. Il valore massimo è 10800 che corrisponde a 3 ore, ma viene mantenuto per retro compatibilità. Il time to live ufficiale dei resource record della zona è quello dichiarato con la direttiva TTL

Record NS

Il Name Server Record è un obbligatorio per la definizione di una zona. Identifica i server autoritativi per il dominio e vanno convenzionalmente inseriti dopo il record SOA. Per il dominio di una rete interna basta un solo NS, mentre per un dominio pubblico internet ne sono richiesti almeno due.

Possono essere elencati altri record NS all’interno del file di zona ad esempio per indicare punti di delega per i sotto domini ma in questi casi i record NS non sono autoritativi.

Oltre al type NS ci due campi importanti:

• name: contiene il dominio e può essere qualificato o meno, anche qui vale tutto quanto detto sopra
• type-data: rappresenta il nome del name server che nel nostro caso, dopo le eventuali espansioni già citate, vale “ns1.local.” Questo nome host deve essere dichiarato con un relativo record A all’interno del file

Record MX

Il record Mail Exchange specifica il nome di uno o più mail server del dominio e viene utilizzato dai client SMTP esterni per inoltrare la posta

Oltre al type MX i due campi importanti sono:

• name: come per il record NS qui troviamo il nome del dominio in forma qualificata o meno e per questo motivo lo si lascia vuoto inserendo il record dopo il SOA  in modo che venga valorizzato con il nome dichiarato nel SOA
• data-type: è composto da due valori:
  • pref: poichè possono esserci più mail server nel dominio,  questo valore numerico che indica la priorità con cui scegliere il nome host del server da utilizzare. Tipicamente questo valore è 10, un valore minore indica maggiore priorità nella scelta, viceversa un valore maggiore indica una priorità più bassa
  • name: nome dell’ host del server, in forma qualificata o meno. A questo valore deve corrispondere un record A

Anche se non è obbligatorio l’inserimento di questo record nella zona, per limitare traffico inutile generato da client SMTP che interrogano il nostro dns alla ricerca di un server mail, è buona norma inserire un NULL record dove pref vale 0 ed il nome dell’ host vale “.” come questo

Record A

L’ Address Record A traduce direttamente il nome dell’host in un indirizzo ipv4. L’associazione inversa avviene tramite il record PTR di cui parleremo in seguito. Possono essere associati diversi indirizzi ip allo stesso nome host, in questo caso la loro traduzione in indirizzo ip avviene con un meccanismo simile al round-robin ma il reverse lookup degli indirizzi può avere effetti non predicibili. Il valore di defauld del campo class per questo record è IN quindi molto spesso viene omesso mentre ttl se viene omesso vale quello specificato nella direttiva TTL

Oltre al type A ci due campi importanti:

• name: il nome dell’ host in forma qualificata o meno
• type-data: viene inserito l’indirizzo ip completo in forma ipv4. A differenza di altri tipi di record, questo non è un dominio qualificato quindi non deve terminate con un “.”

Record AAAA

In tutto e per tutto simile al record A, l’associazione inversa avviene tramite un record PTR che però sarà inserito in un diverso reverse zone file.

L’ indirizzo inserito nel campo type-data è un indirizzo di tipo ipv6

Record CNAME

Il Canonical Name Record serve a mappare un alias con un nome host reale che può essere presente nel nostro dominio o appartenere ad un dominio esterno

Oltre al type CNAME i campi importanti sono:

• name: è il nome dell’ alias
• type-data: è il canonical name, il nome dell’ host reale tradotto dall’alias che può essere un nome host qualificato o meno presente in un record A o AAAA della zona oppure essere un host esterno al dominio

Una zona più completa

Siamo ora in grado di leggere un file di zona più completo che definisce un dominio in cui è presente un name server, un mail server e diversi host

Utilizzeremo questo file per gli esempi successivi con un reverse zone file che fa riferimento a questo

Il Reverse Zone file

Queste zone servono l’operazione opposta a cui è preposto il file di zona precedente, cioè a risolvere gli indirizzi ip in nomi host

Il nome del dominio per questi tipi di zone ovviamente non può essere il nostro “local.” ma deve avere a che fare con gli indirizzi ip in questione. Come per tutte le zone, può essere valorizzato tramite il nome della zona nel config file di bind oppure essere esplicitato tramite la direttiva ORIGIN. In ogni caso, il suo formato è costituito dai campi dell’indirizzo ip, privati della porzione relativa agli host, letti da destra verso sinistra, separati da “.” e seguiti da “.in-addr.arpa.”

Quindi il Reverse Mapping Domain di un classe C di indirizzi ip 192.168.1.0/24 sarà 1.168.192.in-addr.arpa.

Casi più particolari di subnet con un numero maggiore di host vengono gestiti con sotto domini delegati, ma non è scopo di questo tutorial

In questi file sono presenti i campi PTR che traducono gli indirizzi ip in nomi host, cioè l’opposto dei record A ed AAAA

Per il nostro dominio local con indirizzi nella rete 10.1.0.0/24, come Reverse Mapping Domain ipv4 useremo “0.1.10.in-addr.arpa.” ed inseriremo la zona nel file /var/cache/bind/0.1.10.in-addr.arpa che faremo puntare dal config file di bind tramite

Il contenuto del file è questo

I campi che definiscono i record SOA, NS e MX sono identici a quelli della zona local.

Non compaiono più record A ed AAAA che vengono sostituiti dai record PTR

In questi file i record CNAME possono essere presenti e sono utili per creare delle zone delegate quando siamo in presenza di reti composte da subnet

Record PTR

I Pointer Record svolgono la funzione opposta ai record A ed AAAA, traducono gli indirizzi ip in nomi host

Oltre al type PTR, i campi importanti sono:

• name: indirizzo ip dell’host. Può essere esplicitato in forma qualificata ma sarebbe molto lungo ed appesantirebbe la lettura del file, per questo motivo dichiariamo la direttiva ORIGIN in modo da inserire qui solo l’ultimo campo dell’indirizzo dell’ host
• type-data: il nome dell’ host in forma qualificata. Qui non possiamo usare scorciatoie e dobbiamo inserire per intero host.dominio.

Riferimenti

DNS RFC

DOMAIN NAMES – CONCEPTS AND FACILITIES

DOMAIN NAMES – IMPLEMENTATION AND SPECIFICATION