DNS Domain Name System Dott. Ing. Ivan Ferrazzi V1.2 del 28/02/2013

Transcript

1 DNS Domain Name System Dott. Ing. Ivan Ferrazzi V1.2 del 28/02/2013 1/17

2 Copyright 2013 Dott.Ing. Ivan Ferrazzi Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. 2/17

3 3/17

4 Indice generale Introduzione...4 Risoluzione dei nomi di dominio e degli indirizzi IP...4 Risoluzione DNS...4 Risoluzione inversa...5 Installazione di Bind9...5 File di configurazione...5 /etc/bind/named.conf...5 /etc/bind/named.conf.options...7 /etc/bind/named.conf.local...7 Esempio...7 Esempio di zona per il resolving DNS...8 File di configurazione per la zona test.lan...8 Esempio di zona per il reverse resolving (risoluzione inversa) DNS...10 File di configurazione per la zona in-addr.arpa...10 Verificare il corretto funzionamento...11 DNS primario e secondario...12 Configurazione del DNS primario...13 Configurazione del DNS secondario...13 Ultimi accorgimenti /17

5 Introduzione Domain Name System, chiamato comunemente DNS, è il sistema utilizzato in rete per la risoluzione dei nomi di dominio. Un DNS viene utilizzato come un libro telefonico virtuale: per un determinato nome viene restituito il numero di telefono. Quando utilizziamo il telefono possiamo utilizzare solamente i numeri, per questo motivo diventa fondamentale avere un sistema di ricerca efficace. Con il DNS abbiamo esattamente la stessa cosa: per un nome di dominio viene restituito l'apposito indirizzo IP. Risoluzione dei nomi di dominio e degli indirizzi IP La funzione di risoluzione dei nomi avviene in due modi diversi. Uno permette di risolvere un nome di dominio e restituire l'apposito indirizzo IP (risoluzione DNS), mentre l'altro restituisce il nome di dominio per uno specifico indirizzo IP (risoluzione inversa). Risoluzione DNS Il classico esempio di risoluzione DNS lo troviamo nelle connessioni browserwebserver. Nel browser inseriamo il nome di dominio del quale vogliamo vedere il relativo sito internet. Quando inseriamo il nome di dominio all'interno del nostro browser come prima cosa viene contattato un DNS. Questo restituisce al nostro browser l'indirizzo IP relativo al nome di dominio che ci interessa. Con l'indirizzo Ip ricevuto viene stabilita la connessione con il webserver desiderato. La risoluzione del nome di dominio avviene da destra verso a sinistra. Prima di inviare la relativa richiesta al DNS il browser aggiunge un punto (.) dopo al nome di dominio inserito. Se prendiamo come esempio: la richiesta che verrà inviata sarà Il punto finale identifica DNS Root, ossia i DNS principali presenti in internet. Dai Root-DNS si passerà ai DNS che gestiscono la parte di dominio info, poi quelli che gestiscono la parte ferrazzi, ed infine si arriva ai DNS che allo al loro interno le informazioni relative al hostname www del rispettivo dominio. 5/17

6 Risoluzione inversa Ci sono alcuni casi dove è indispensabile la risoluzione inversa. Uno di questi casi è nella gestione di trasferimento della posta elettronica. Quando un MTA (Message Transfer Agent) deve contattare un altro MTA per l'invio di un messaggio di posta elettronica, questo richiede come prima cosa la risoluzione del dominio di appartenenza dell'indirizzo di destinazione. Per essere sicuro dell'esistenza del corretto MTA di destinazione l'mta di partenza richiede una risoluzione inversa dell'indirizzo IP inviatoli dal rispettivo DNS. Se questi due valori corrispondono manda avanti l' , altrimenti no. Quando viene inviata al DNS la richiesta di risoluzione inversa l'indirizzo IP viene mandato all'incontrario con l'aggiunta di in-addr.arpa. Se viene richiesta la risoluzione inversa per l'indirizzo IP come richiesta verrà mandata la seguente struttura in-addr.arpa Capire queste strutture aiuta a configurare in maniera corretta il nostro server DNS. Installazione di bind9 Come DNS utilizziamo bind9 e lo installiamo concatenando apt-get install bind9 File di configurazione Dopo l'installazione troviamo tutti i file di configurazione necessari all'interno della cartelle /etc/bind. /etc/bind/named.conf Questo è il file principale che contiene la configurazione di bind9. Vediamo un esempio: include /etc/bind/named.conf.options ; 6/17

7 zone. { type hint; file /etc/bind/db.root ; zone localhost { type master; file /etc/bind/db.local ; zone 127.in-addr.arpa { type master; file /etc/bind/db.127 ; zone 0.in-addr.arpa { type master; file /etc/bind/db.0 ; zone 255.in-addr.arpa { type master; file /etc/bind/db.255 ; include /etc/bind/named.conf.local ; All'interno di questo file troviamo come prima cosa un include che permette di includere una parte di configurazione che si trova in un altro file. In questo caso viene incluso il contenuto del file /etc/bind/named.conf.options, spiegato qui di seguito. Poi troviamo i blocchi che definiscono le zone conosciute dal nostro DNS server. Le zone si definiscono utilizzando la parola zone seguita da una stringa che identifica la prima parte (partendo da destra verso sinistra) della richiesta fatta al DNS, così come il blocco tra parentesi graffe ({...}) che contiene i parametri che ne decidono il comportamento. Vediamo quindi brevemente a quale richiesta corrisponde quale zona. Teniamo sempre presente l'ordine delle richieste per quanto riguarda la risoluzione inversa e soprattutto l'aggiunta della sigla.in-addr.arpa: zone richiesta DNS richiesta. per.qualsiasi.dom. per.qualsiasi.dom Localhost localhost. localhost 127.in-addr.arpa x.y.z.127.in-addr.arpa 127.x.y.z 0.in-addr.arpa x.y.z.0.in-addr.arpa 0.x.y.z 255.in-addr.arpa x.y.z.255.in-addr.arpa 255.x.y.z Come configurazione per le singole zone troviamo le impostazioni type e file. L'impostazione type permette di definire il tipo di zona, quindi come verrà gestita la zona, mentre file permette di indicare il file di configurazione che definisce effettivamente la risoluzione delle richieste per una rispettiva zona. I valori che vengono più utilizzati per quanto riguarda l'impostazione type sono: hint, master, oppure slave. Con hint identifichiamo le zone che, per risolvere un 7/17

8 determinato nome, mandano avanti la richiesta ai DNS Root, ossia i DNS principali presenti all'interno di internet. Viene utilizzato master quando si identifica il proprio server come responsabile per la risoluzione di informazioni relative alla zona in questione, slave quando si configura una zona su un server DNS secondario, che recupera eventuali modifiche da un server DNS master configurato per la medesima zona. Infine troviamo un nuovo include che permette di recuperare le informazioni presenti all'interno del file /etc/bind/named.conf.local descritto più avanti. /etc/bind/named.conf.options Questo file contiene la configurazione per il comportamento base del nostro DNS server. Vediamo un esempio: options { directory /var/cache/bind ; #forwarders { # ; # ; # All'interno del blocco options viene definita con l'impostazione directory la cartella da utilizzare per memorizzare (caching) le informazioni recuperate da richieste precedenti. Per le richieste successive bind9 controllerà come prima cosa la presenza dell'eventuale risoluzione all'interno di questa cartella. In questo caso riusciamo a risolvere in maniera molto più veloce richieste eseguite precedentemente. Nel caso in cui si volesse utilizzare il DNS primario e/o secondario del nostro ISP, si dovrebbe inserire i rispettivi indirizzi IP nel blocco forwarders. Questo eviterebbe le richieste inviate direttamente ai DNS Root e permetterebbe quindi di velocizzare la risoluzione di nomi di dominio esterni. options { directory /var/cache/bind ; forwarders { ; ; /etc/bind/named.conf.local Inizialmente questo file è vuoto e lo possiamo utilizzare successivamente per aggiungere le zone relative ai nostri domini. 8/17

9 Esempio Vediamo in base ad un esempio pratico come configurare il nostro server DNS con indirizzo IP Il nostro dominio è test.lan. Al suo interno abbiamo un webserver identificato dal nome con indirizzo IP e un mailserver identificato dal nome mail.test.lan con indirizzo IP Esempio di zona per il resolving DNS Vediamo ora un semplice esempio che permetterà al nostro server DNS di risolvere i nomi di dominio presenti all'interno della nostra rete. Nel file di configurazione /etc/bind/named.conf.local dichiariamo la zona che ci interessa. Nel nostro caso vogliamo definire una zona che risponda al dominio test.lan: zone test.lan { type master; file /etc/bind/db.test.lan ; notify no; Notiamo la riga aggiuntiva notify no che evita l'invio delle informazioni relative a questa zona ai DNS server di livello superiore. File di configurazione per la zona test.lan Una volta definita la zona dobbiamo creare il rispettivo file di configurazione. Il file, come definito nella zona, deve avere il nome /etc/bind/db.test.lan. Creiamo il file e scriviamo quanto segue: $TTL IN SOA ns.test.lan. root.test.lan. ( ; Serial ; Refresh ; Retry ; Expire ) ; Negative cache TTL IN NS IN MX 10 mail.test.lan. ns IN A mail IN A www IN A L'indicazione $TTL determina in secondi il valore time to live, ossia quando 9/17

10 deve rimanere all'interno della cache risoluzione relative a questa zona. Poi troviamo il che all'interno di questo file sostituisce la stringa che identifica la zona (nel nostro caso quindi test.lan). IN definisce il tipo di richiesta ossia Internet, mentre SOA sta per Start Of Authority e identifica i parametri principali dell'authotiry, ossia del responsabile di questa zona. Poi troviamo il hostname del server (ns.test.lan) e l' del responsabile (root.test.lan). Non potendo per la definizione dell' la sostituiamo con il punto (.). Quindi trasformiamo l'indirizzo di posta elettronica root@test.lan in root.test.lan. Nel blocco tra parentesi troviamo i parametri di base, separati da un punto e virgola, che identificano il comportamento del DNS server della nostra zona in caso di DNS secondario. Partendo dal primo in alto i parametri sono: Serial Refresh Retry Expire TTL Questo numero è composto normalmente dalla data di aggiornamento scritta nella forma inversa (aaaammgg) con l'aggiunta di un numero progressivo che viene incrementato ad ogni modifica. Questo valore viene utilizzato dal serve secondario per verificare se la versione attualmente presente è da aggiornare o è già la versione più recente. Questo valore rappresenta il tempo in secondo che devono trascorrere prima che il server secondario richieda al server primario eventuali aggiornamenti. Nel caso in cui l'aggiornamento non dovesse andare a buon fine, il server secondario attende il tempo (in secondi) definito qui prima di effettuare un nuovo tentativo. Se il server secondario non dovesse riuscire ad effettuare un aggiornamento nel tempo definito da questo parametro la zone verrebbe classificata estinta. Definisce il periodo di vita di un inserimento nella cache. Attenzione! Bind riconosce come nome completo solo quelli che terminano con un punto (.), ad esempio ns.test.lan.. I nomi che non contengono un punto finale vengono automaticamente completati con un punto ed il valore ns diventerebbe quindi ns.test.lan, ma ns.test.lan (quindi senza punto finale) diventerebbe ns.test.lan.test.lan. Le righe seguenti identificano il hostname, il tipo di richiesta (normalmente IN), la classe e la rispettiva risoluzione (ad eccezione della classe MX). Le classi più utilizzate all'interno di questo file di configurazione sono: 10/17

11 NS MX CNAME A Identifica il nameserver definito per la rispettiva zona. La rispettiva risoluzione deve contenere il hostname del nameserver per il quale deve essere presente all'interno dello stesso file anche un inserimento di classe A. Almeno una di queste righe deve essere presente all'interno di questo file. Identifica l'eventuale mailserver definito per la rispettiva zona. In questo caso viene aggiunto prima della classe un numero che ne identifica la priorità. Nel caso in cui ci fossero mailserver diversi verrebbe preso prima quello con il numero di priorità più basso. La rispettiva risoluzione deve contenere il hostname per il quale deve essere presente all'interno dello stesso file anche un inserimento di classe A. Identifica un canonical name. Questa classe permette di definire degli alias, in pratica possiamo definire più hostname che vengono poi indirizzati verso ad un preciso inserimento di classe A. La rispettiva risoluzione deve contenere anche qui il hostname per il quale deve essere presente all'interno dello stesso file anche un inserimento di classe A. Identifica l'effettiva risoluzione finale, ossia l'indirizzo IP che va restituito per la rispettiva risoluzione del hostname identificato. Esempio di zona per il reverse resolving (risoluzione inversa) DNS Vediamo ora un semplice esempio che permetterà al nostro server DNS di effettuare la risoluzione inversa, ossia la risoluzione di indirizzi IP. Nel file di configurazione /etc/bind/named.conf.local dichiariamo la zona che ci interessa. Nel nostro caso vogliamo definire una zona che risponda al dominio in-addr.arpa: zone in-addr.arpa { type master; file /etc/bind/db ; notify no; File di configurazione per la zona in-addr.arpa Una volta definita la zona dobbiamo creare il rispettivo file di configurazione. Il file, come definito nella zona, deve avere il nome /etc/bind/db Creiamo il file e scriviamo quanto segue: 11/17

12 $TTL IN SOA ns.test.lan. root.test.lan. ( ; Serial ; Refresh ; Retry ; Expire ) ; Negative cache TTL IN NS ns.test.lan. 1 IN PTR ns.test.lan. 11 IN PTR mail.test.lan. 10 IN PTR La prima parte di questo blocco è (e rimane) identica alla prima parte del file precedentemente spiegato. Una delle differenze più importanti riguarda il In questo caso il nome della zona per questo file non è più test.lan, ma in-addr.arpa. Questo significa che dobbiamo scrivere per intero i vari nomi di dominio. Definire quindi all'interno di questo file un semplice ns porterebbe al risultato ns in-addr.arpa che non corrisponde a quello che si vuole ottenere. Possiamo però, come si nota nelle ultime righe, evitare di scrivere l'indirizzo richiesto per esteso. 1 diventerebbe quindi in-addr.arpa che è invece quello che interessa a noi. La classe aggiuntiva che troviamo all'interno di questo file è la seguente: PTR Identifica il puntatore (pointer) verso il hostname da restituire in caso di richieste effettuate sul rispettivo indirizzo IP. Verificare il corretto funzionamento Prima di poter verificare il corretto funzionamento dobbiamo riavviare il nostro DNS server come segue /etc/init.d/bind9 restart Poi utilizziamo il comando dig che permette di effettuare delle richieste ad uno specifico nameserver. Utilizziamo il comando come segue: dig [@nameserver] {host -x ip_address} Per verificare la corretta risoluzione del nameserver possiamo digitare: 12/17

13 per effettuare la risoluzione inversa dobbiamo utilizzare il parametro -x come segue: -x oppure in-addr.arpa La tabella che vediamo come risposta deve contenere un risultato simile a questo: ;; QUESTION SECTION: ; IN A ;; ANSWER SECTION: IN A ;; AUTHORITY SECTION: test.lan IN NS ns.test.lan ;; ADDITIONAL SECTION: ns.test.lan IN A Per rendere definito l'utilizzo del nostro DNS server possiamo inserire il rispettivo indirizzo IP nel file di configurazione /etc/resolv.conf di ogni pc che deve utilizzare il nostro server come DNS, come segue: nameserver DNS primario e secondario Per motivi di continuità di messa a disposizione del servizio DNS possiamo configurare un DNS primario ed uno secondario che vengono sincronizzati ad intervalli di tempo predefiniti. Tutti e due i server vengono installati e configurati alla stessa maniera. Vediamo qui di seguito le modifiche necessarie sui due server per rendere possibile la sincronizzazione. Prima di passare alla configurazione dei due server creiamo la chiave 13/17

14 necessaria per effettuare la sincronizzazione delle informazioni in maniera criptata. Con il seguente comando creiamo quanto serve: dnssec-keygen -a hmac-md5 -b 128 -n host test.lan Questo programma crea due file Ktest.lan*.key e Ktest.lan*.private. Il file che serve a noi è il file con estensione.private. Se lo apriamo vediamo un qualcosa di simile a: Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: SKS6HJbtRsVJAbvU2jly/Q== Bits: AAA= Il valore presente dopo a Key: verrà utilizzato più avanti per configurare la chiave necessaria alla connessione criptata. Configurazione del DNS primario Come prima cosa modifichiamo il file che definisce la zona di appartenenza /etc/bind/db.test.lan come segue: $TTL IN SOA ns.test.lan. root.test.lan. ( ; Serial ; Refresh ; Retry ; Expire ) ; Negative cache TTL IN NS IN NS IN MX 10 mail.test.lan. ns IN A ns2 IN A mail IN A www IN A Poi passiamo al file /etc/bind/named.conf.options e aggiungiamo all'interno del blocco options quanto segue: dnssec-enable yes; Nel file /etc/bind/rndc.key aggiungiamo: key TRANSFER { algorithm hmac-md5; secret SKS6HJbtRsVJAbvU2jly/Q== ; 14/17

15 Nella stringa presente vicino alla parola di comando secret va inserita la chiave presente all'interno del file *.private creato precedentemente. Poi includiamo questo file all'interno del file /etc/bind/named.conf. Ed inseriamo il blocco server che identifica la chiave da utilizzare per il server secondario. Inseriamo quindi le seguenti righe: include /etc/bind/rndc.key ; server { keys { TRANSFER; Inoltre modifichiamo il file /etc/bind/named.conf.local per abilitare il trasferimento dei file. Ricordiamoci di togliere il notify no per abilitare anche la notifica tra i due server. La zona viene quindi definita come segue: zone test.lan { type master; allow-transfer { ; file /etc/bind/db.test.lan ; Configurazione del DNS secondario Come prima cosa modifichiamo il file /etc/bind/named.conf.options e aggiungiamo all'interno del blocco options quanto segue: dnssec-enable yes; Nel file /etc/bind/rndc.key aggiungiamo: key TRANSFER { algorithm hmac-md5; secret SKS6HJbtRsVJAbvU2jly/Q== ; Nella stringa presente vicino alla parola di comando secret va inserita la chiave presente all'interno del file *.private creato precedentemente. Poi includiamo questo file all'interno del file /etc/bind/named.conf. Ed inseriamo il blocco server che identifica la chiave da utilizzare per il server primario. Inseriamo quindi le seguenti righe: include /etc/bind/rndc.key ; server { keys { 15/17

16 TRANSFER; Inoltre dobbiamo modificare leggermente la configurazione del blocco per la zona presente nel file /etc/bind/named.conf.local come segue: zone test.lan { type slave; file /etc/bind/db.slave_test.lan ; masters { ; allow-transfer { ; allow-notify { ; } Il file relativo a questa zona, ossia /etc/bind/db.slave_test.lan, non va creato manualmente ma viene creato automaticamente dopo una sincronizzazione. Pertanto dobbiamo controllare i diritti di accesso di bind9 sulla cartella in questione, ossia /etc/bind/. Il processo di bind9 viene eseguito con l'utente bind e il relativo omonimo gruppo. Per questo motivo possiamo modificare il gruppo di appartenenza della cartella assegnandole bind come segue: chown :bind /etc/bind Tutti i processi appartenenti al gruppo bind (e quindi anche bind9) dovranno avere il diritto di creare nuovi file all'interno della cartella. Modifichiamo quindi i permessi come segue: chmod 775 /etc/bind Ultimi accorgimenti Come ultima cosa riavviamo entrambi i server e installiamo ntpdate utilizzato per la sincronizzazione dei clock come segue: apt-get -y install ntpdate Verifichiamo la data e l'orario con date. Se non fossero sincronizzati possiamo far partire il comando ntpdate con uno specifico server ntp con ntpdate it.pool.ntp.org Dopodiché dovremmo vedere apparire il file /etc/bind/db.slave_test.lan che 16/17

17 verrà creato alla prima sincronizzazione (normalmente subito all'avvio del DNS secondario). Nel caso in cui dovessero visualizzarsi degli errori riguardante la chiave utilizzata possiamo ricaricarla con il comando rndc reload Possiamo comunque verificare la sincronizzazione dei due DNS dal logfile /var/log/syslog come segue: tail -f /var/log/syslog 17/17