Protocollo DNS - Cremona

Protocollo DNS
Introduzione
The domain name system or domain name server (DNS) is a system that stores information
associated with domain names in a distributed database on networks, such as the Internet. The
domain name system (domain name server) associates many types of information with domain
names, but most importantly, it translates the domain name (computer hostnames) to IP addresses. It
also lists mail exchange servers accepting e-mail for each domain. In providing a worldwide
keyword-based redirection service, DNS is an essential component of contemporary Internet use.
DNS is useful for several reasons. Most well known, the DNS makes it possible to attach easy-toremember domain names (such as "wikipedia.org") to hard-to-remember IP addresses (such as
207.142.131.206). Humans take advantage of this when they recite URLs and e-mail addresses.
Less recognized, the domain name system makes it possible for people to assign authoritative
names, without needing to communicate with a central registrar each time.
Fonte: Wikipedia - http://en.wikipedia.org/wiki/Domain_Name_System
Fig. 1: Lo schema del DNS
Carlo Todeschini – [email protected]
Reti di Comunicazione e Internet – Politecnico di Milano sede di Cremona – A.A. 2010-2011 – v. 1.5
1
Fig. 2: esempio di interrogazione DNS
Fig. 3: utilizzo in ambito reale del sistema DNS
Utilizzo
Generalmente sono i programmi applicativi che chiedono autonomamente la risoluzione degli
indirizzi al resolver di riferimento
Esercizio 1
Catturare con Wireshark il traffico generato da due comandi “ping” lanciati verso un host di cui
prima si specifica il suo indirizzo letterale e successivamente il suo indirizzo IP numerico.
Come cambia l'interazione con il DNS server?
E' possibile lanciare query dirette appositamente al DNS server tramite il comando “dig” con la
seguente sintassi:
# dig <INDIRIZZO_LETTERALE>
Carlo Todeschini – [email protected]
Reti di Comunicazione e Internet – Politecnico di Milano sede di Cremona – A.A. 2010-2011 – v. 1.5
2
Esercizio 2
Eseguire una query con il comando “dig” e catturare il traffico con Wireshark; utilizzare come
esempio i siti www.gnu.org (query standard), www.vatican.va e www.google.com (vengono
eseguite query che ritornano risposte complesse con utilizzo di tecniche di tipo round robin; che
cosa significa?). Interrogare più volte il DNS per l'indirizzo di Google...
Confrontare i pacchetti sniffati con gli schemi che seguono relativi ai messaggi DNS: individuare e
riconoscere i campi del protocollo.
Header
Intestazione: sempre presente specifica quali delle altre sezioni (contenenti record di
dati) del messaggio sono presenti; specifica anche se è un domanda o una risposta
Question
Domanda: specifica la domanda fatta al DNS server; contiene i campi “query type”
(QTYPE), “query class” (QCLASS) e “query domain name” (QNAME)
Answer
Risposta: riporta la risposta del server con i record dei campi precedenti seguiti da:
TTL, lunghezza del campo indirizzo e indirizzo
Authority
Authority: specifica la lista dei server autoritativi per il nome a dominio richiesto
Additional
Additional: fornisce informazioni aggiuntive relative alle risposte fornite tramite i
record precedenti (es: indirizzo IP dei server DNS autoritativi)
Fig. 4: struttura del messaggio DNS
0 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1
0 1 2 3 4 5
ID
QR
Opcode
AA TC RD RA
Z
RCODE
QDCOUNT
ANCOUNT
NSCOUNT
ARCOUNT
Dove:
➢
➢
➢
➢
ID: identificativo a 16 bit che viene generato nella richiesta e utilizzato poi per la risposta
QR: identifica il tipo di messaggio: query (0), o response (1).
OPCODE: 4 bit che identificano il tipo di messaggio
➢ 0: query standard (QUERY)
➢ 1: query inversa (IQUERY)
➢ 2: richiesta di stato del server (STATUS)
➢ 3-15: riservati per usi futuri
AA: Authoritative Answer: specifica che la risposta è autoritativa
Carlo Todeschini – [email protected]
Reti di Comunicazione e Internet – Politecnico di Milano sede di Cremona – A.A. 2010-2011 – v. 1.5
3
➢
➢
➢
➢
➢
➢
➢
➢
➢
TC: TrunCation: specifica che il messaggi è stato troncato per via dell'eccessiva lunghezza dello stesso
RD: Recursion Desired: se questo bit è settato si chiede di invocare una query ricorsiva
RA: Recursion Available: questo bit, settato nelle risposte, indica se è stato possibile o meno eseguire una
query ricorsiva
Z: Riservato per usi futuri
RCODE: Response code: identifica il codice di risposta tra:
➢ 0: nessun errore
➢ 1: Format error
➢ 2: Server failure
➢ 3: Name Error
➢ 4: Not Implemented
➢ 5: Refused
➢ 6-15: riservati per usi futuri
QDCOUNT: numero di entry nella sezione “question”
ANCOUNT: numero di entry nella sezione “answer”
NSCOUNT: numero di entry nella sezione “name server”
ARCOUNT: numero di entry nella sezione “record addizionali”
Fig. 5: struttura dell'header del messaggio DNS
E' possibile lanciare, da utente root, il server DNS già installato in Knoppix con il seguente
comando:
# /etc/init.d/bind9 start
Si tratta di un DNS configurato come “forwarder”: ogni richiesta ricevuta viene inoltrata al DNS di
ordine superiore (nel caso di utilizzo nei laboratori delega al DNS server passato durante la
configurazione delle rete via DHCP).
Esercizio 3
Attivare il server DNS installato in Knoppix con il metodo descritto sopra; è possibile interrogare il
DNS appena attivato tramite il seguente comando:
# dig www.gnu.org @<IP_DEL_PROPRIO_HOST>
Confrontare il traffico catturato con quello dell'esercizio precedente (nota: si può rendere
necessario lo sniffing su tutte le interfacce di rete “eth0” e “lo”) e verificare che questo DNS
procede ad interrogare i root server (tramite una query ricorsiva).
Sniffare il traffico con Wireshark relativo all'interrogazione e identificare che la risposta è
autoritativa. Che cosa significa?
Lista root DNS server:
A.ROOT­SERVERS.NET ­> 198.41.0.4 B.ROOT­SERVERS.NET ­> 192.228.79.201 C.ROOT­SERVERS.NET ­> 192.33.4.12 D.ROOT­SERVERS.NET ­> 128.8.10.90 E.ROOT­SERVERS.NET ­> 192.203.230.10 F.ROOT­SERVERS.NET ­> 192.5.5.241 G.ROOT­SERVERS.NET ­> 192.112.36.4 H.ROOT­SERVERS.NET ­> 128.63.2.53 I.ROOT­SERVERS.NET ­> 192.36.148.17 J.ROOT­SERVERS.NET ­> 192.58.128.30 K.ROOT­SERVERS.NET ­> 193.0.14.129 Carlo Todeschini – [email protected]
Reti di Comunicazione e Internet – Politecnico di Milano sede di Cremona – A.A. 2010-2011 – v. 1.5
4
L.ROOT­SERVERS.NET ­> 199.7.83.42 M.ROOT­SERVERS.NET ­> 202.12.27.33
Quale di questi server viene interrogato?
E' possibile configurare il proprio DNS server per essere autoritativo per una determinata “zona”
(per le altre non di diretta competenza si comporta da forwarder, memorizzando man mano i
risultati tramite un meccanismo di cache locale). Ad esempio è possibile creare una nuova zona
privata “neta.lan” per cui il DNS server attivato sarà autoritativo nelle risposte.
In particolare si vuole poter risolvere (ovviamente senza ricorrere alla configurazione del file
“/etc/hosts”...):
➢
➢
➢
uno.neta.lan
due.neta.lan
tre.neta.lan
192.168.0.1
192.168.0.2
192.168.0.3
I file di configurazione (si tratta di file di testo ASCII, reperibili anche sul sito delle esercitazioni –
scompattare l'archivio con il comando “unzip <NOME_ARCHIVIO.ZIP>”) del server DNS devono
trovarsi nella directory “/etc/bind/”; in particolare il file “named.conf” contiene i principali settaggi
del server e provvede a caricare alcuni file di configurazione aggiuntivi relativi alle zone che
vengono gestite; tra questi viene caricato un file particolare, “db.root”, che contiene la definizione
del cosiddetti root servers ovvero gli indirizzi IP dei server principali del DNS system e che
rappresentano il vertice della piramide gerarchica del sistema di name resolving.
Per configurare la zona “neta.lan” è necessario creare il file “/etc/bind/db.neta.lan.zone” contenente:
$TTL
86400
@
IN
SOA
neta.lan. root.neta.lan.
2007061200 ; Serial
28800
; Refresh
14400
; Retry
3600000
; Expire
86400 )
; Minimum
IN
NS
localhost.
IN
IN
IN
A
A
A
192.168.0.1
192.168.0.2
192.168.0.3
uno
due
tre
(
e aggiungere al file di configurazione generale “/etc/bind/named.conf” la seguente sezione:
zone "neta.lan" IN {
type master;
file "/etc/bind/db.neta.lan.zone";
allow-update { none; };
};
NOTA: fare attenzione nel caso si faccia un “copia&incolla” dal reader acrobat; tale operazione
non rispetta gli spazi e i tab di formattazione, impedendo il corretto funzionamento del server DNS.
Per completezza è necessario configurare anche il “reverse lookup” ovvero al possibilità di ottenere
un nome host dato un indirizzo IP. Occorre quindi creare anche il file “/etc/bind/0.168.192.inaddr.arpa.zone” contenente:
Carlo Todeschini – [email protected]
Reti di Comunicazione e Internet – Politecnico di Milano sede di Cremona – A.A. 2010-2011 – v. 1.5
5
$TTL
86400
@
IN
SOA
neta.lan. root.neta.lan.
2007061200 ; Serial
28800
; Refresh
14400
; Retry
3600000
; Expire
86400 )
; Minimum
IN
NS
localhost.
IN
IN
IN
PTR
PTR
PTR
uno.neta.lan.
due.neta.lan.
tre.neta.lan.
1
2
3
(
e aggiungere al file di configurazione generale “/etc/bind/named.conf” la seguente sezione:
zone "0.168.192.in-addr.arpa" IN {
type master;
file "/etc/bind/0.168.192.in-addr.arpa.zone";
allow-update { none; };
};
A questo punto riavviare il server DNS con il seguente comando:
# killall named
# /etc/init.d/bind9 start
Nota: In realtà il metodo corretto per il riavvio del server è quello che segue, ma per un bug di
Knoppix è necessario il workaround indicato.
# /etc/init.d/bind9 restart
Esercizio 4
Sniffare il traffico chiedendo la risoluzione di uno dei nomi a dominio gestiti dal DNS con questa
nuova zona. Per esempio:
# dig uno.neta.lan @<IP_DEL_PROPRIO_HOST>
Verificare che la risposta sia autoritativa per il dominio “neta.lan”.
Eseguire anche una richiesta per la risoluzione di un reverse lookup con il seguente comando e
sniffare la risposta:
# dig -x 192.168.0.2 @<IP_DEL_PROPRIO_HOST>
E' possibile interrogare le varie registration authority che gestiscono i top level domain (TLD) per
avere informazioni sullo stato delle registrazioni dei domini Internet. Il comando da lanciare è il
Carlo Todeschini – [email protected]
Reti di Comunicazione e Internet – Politecnico di Milano sede di Cremona – A.A. 2010-2011 – v. 1.5
6
seguente:
# whois <DOMAIN>
Esercizio 5
Visualizzare, in console, il risultato del seguente comando e sniffarne il traffico generato:
#
whois comune.cremona.it
Che porte vengono utilizzate?
Che livello di “aggiornamento” presenta questo servizio in questo particolare esempio, leggendo i
dati forniti dal comando sopra?
WHOIS (pronounced "who is"; not an acronym) is a TCP-based query/response protocol which is
widely used for querying an official database in order to determine the owner of a domain name, an
IP address, or an autonomous system number on the Internet. WHOIS lookups were traditionally
made using a command line interface, but a number of simplified web-based tools now exist for
looking up domain ownership details from different databases. Web-based WHOIS clients still rely
on the WHOIS protocol to connect to a WHOIS server and do lookups, and command-line WHOIS
clients are still quite widely used by system administrators.
Fonte: Wikipedia - http://en.wikipedia.org/wiki/WHOIS
Approfondimenti
➢
BIND
http://www.isc.org/index.pl?/sw/bind/
➢
RFC 1035 (e altre RFC successive)
ftp://ftp.rfc-editor.org/in-notes/rfc1035.txt
Carlo Todeschini – [email protected]
Reti di Comunicazione e Internet – Politecnico di Milano sede di Cremona – A.A. 2010-2011 – v. 1.5
7