Lo strato applicativo di Internet

Domain Name System

Cercando tra i nomi

Esistono diversi strumenti che effettuano ricerca tra i DNS. Il più comune e semplice è il comando host, che offre una buona scelta di opzioni, con cui svolgere le query più diverse, e che permette la risoluzione sia diretta che inversa:

Usage: host [-aCdlriTwv] [-c class] [-N ndots] [-t type] [-W time]
            [-R number] hostname [server]
       -a is equivalent to -v -t *
       -c specifies query class for non-IN data
       -C compares SOA records on authoritative nameservers
       -l lists all hosts in a domain, using AXFR
       -r disables recursive processing
       -R specifies number of retries for UDP packets
       -t specifies the query type
       -T enables TCP/IP mode
       -v enables verbose output
       -w specifies to wait forever for a reply
       -W specifies how long to wait for a reply

In pratica, l'opzione -t ppermette di specificare il tipo di RR richiesto, ad esempio host -t A per conoscere l'indirizzo IP di un FQDN, host -t NS per conoscere il suo NameServer, o host -t ANY per ottenere tutti i RR associati al nome a dominio. Esercizio:

Un elenco delle possibili opzioni è piuttosto lungo, ma può valere la pena verificarlo. Altri comandi per esplorare il DNS sono dignslookup, e dnstracer.

Siti diagnostici

Alcuni siti come offrono una interfaccia web alla interrogazione del DNS, fornendo anche interessanti interpretazioni grafiche di tutte le risorse collegate a quella oggetto della richiesta.

Il proprio DNS

Come discusso, il file /etc/resolv.conf indica alla resolver library quale nameserver utilizzare, che va ovviamente specificato in termini di indirizzo IP. Ogni ISP ospita uno o più nameserver, e ne consiglia l'utilizzo ai propri utenti, in modo da accentrare le richieste degli stessi e sviluppare una cache comune, riducendo così il traffico verso l'esterno.

L'attacco più semplice

Qualora un software ostile, come ad es. un virus, riesca a modificare /etc/resolv.conf, le successive interrogazioni al DNS saranno deviate verso un nameserver gestito dall'attaccante che, pur funzionando correttamente per la maggior parte dei domini, può fornire risoluzioni falsate per alcuni di essi (ad es. siti di commercio elettronico), deviando così il navigante del computer compromesso verso siti-copia che pur del tutto simili agli originali, hanno il solo scopo di sottrarre dati sensibili come password o peggio.

DNS pubblici

Al fine di limitare il traffico DNS in ingresso/uscita dalla propria sottorete, a volte gli ISP configurano i propri nameserver in modo da rifiutare di rispondere a richieste provenienti dall'esterno. Al contrario, alcune iniziative fanno esattamente l'opposto, ossia gestiscono namesever ad accesso pubblico, come ad esempio

Inoltre, esistono iniziative per definire un insieme di root nameserver alternativi a quelli ufficiali, offrendo in tal modo garanzie di sfuggire ad operazioni di controllo globale. Infine, i fornitori di servizio DNS alternativi spesso offrono servizi aggiuntivi, come ad es. la mancata risoluzione per domini associati a siti di malware noti.

Passiamo ora a sperimentare la configurazione ed il funzionamento del DNS, con riferimento alla distribuzione Ubuntu Linux che stiamo usando, installando (ad esempio via Synaptic) il pacchetto bind9.

Il dominio .dg

Possiamo senz'altro impratichirci, replicando la configurazione esempificata nell'esempio del dominio .dg, installando (ad esempio via Synaptic) il pacchetto bind9, e quindi

  1. editare (con sudo gedit) il file /etc/bind/named.conf.local, in modo da riprodurre la situazione illustrata a lezione;
  2. creiamo nella directory /etc/bind i tre files 192.168, dg e brot.dg, con i contenuti citati nell'esempio, oppure,
  3. il DNS locale può quindi essere mandato in esecuzione mediante il comando service bind9 start, oppure
  4. verifichiamo che nel file di log non siano evidenziati errori, ovvero

Ora, sarà possibile investigare tra le informazioni immesse, eseguendo ad es. il comando host -a www.brot.dg 127.0.0.1. Provare anche l'effetto delle opzioni -l e -t any, e verificare l'autorevolezza delle risposte.

Il DNS del laboratorio

Presso la macchina 192.168.100.156 è stato installato bind9, e sono stati creati i files di zona per il dominio .labint, e quelli di risoluzione inversa per la sottorete 192.168.0.0/16, in modo da poter referenziare i computer del laboratorio per nome.

192.168.100.156
named.conf.local
zone "labint" {
  type master;
  file "/etc/bind/labint";
};

zone "168.192.in-addr.arpa" {
  type master;
  file "/etc/bind/192.168";
};
file di zona risoluzioni inverse
; /etc/bind/labint

@ IN SOA ns.labint. alef.infocom.uniroma1.it. (
 2010040800 ; Serial
      28800 ; Refresh
       7200 ; Retry
     604800 ; Expire
      300 ) ; Min TTL: 5min

           NS ns
ns          A 192.168.100.156
www     CNAME ns
alef        A 192.168.100.234
damo        A 192.168.100.101
labint-102  A 192.168.100.102
nostro_nome A 192.168.100.1xx
...eccetera...
; /etc/bind/192.168

@ IN SOA ns.labint. alef.infocom.uniroma1.it. (
2010040800 ; Serial
     28800 ; Refresh
      7200 ; Retry
    604800 ; Expire
   86400 ) ; Min TTL

          NS ns.labint.
156.100  PTR ns.labint.
234.100  PTR alef.labint.
101.100  PTR damo.labint.
102.100  PTR labint-102.labint.
1xx.100  PTR nostro_ip

Usiamo il DNS su ns.labint

Per usare il DNS residente su 192.168.100.156, inseriamo nel file /etc/resolv.conf del proprio host le seguenti direttive

nameserver 192.168.100.156
domain labint

mentre per Ubuntu >= 12.04 configuriamo una nuova connessione (chiamiamola labdns) mediante il network manager, identica a quella che usiamo già, ma per la quale prescriviamo l'uso del DNS che si trova su 192.168.100.156, nonché il dominio di ricerca. Quindi, attiviamo la nuova connessione. Possiamo ora verificare

Cambiamo nome

Possiamo quindi modificare il nome con cui il computer presso il quale siamo correntemente seduti si identifica:

Al termine di tutte le modifiche, su ns.labint viene impartito il comando sudo service bind9 reload, e tutti possono verificarne l'efficacia mediante il comando host nostro_nome e host nostro_ip

Gestione di una zona delegata

La sperimentazione sul DNS può proseguire acquisendo la delega per tutto il dominio di secondo livello proprionome.labint, divenendo così in grado di definire sul proprio computer dei nomi a dominio di terzo livello (es. www.nostro_nome.labint), da associare

Per ottenere questo risultato, occorre inserire un RR di delega nel file di zona autorevole per .labint e in quello per le risoluzioni inverse 168.192.inaddr_arpa:

host 192.168.100.156
file di zona /etc/bind/labint file risoluzioni inverse /etc/bind/192.168
nostro_nome    NS   nostro_nome
1xx             NS   nostro_nome.labint.

A questo punto potremo, presso il nostro computer, dopo aver scaricato il pacchetto bind9, modificare il file /etc/bind/named.conf.local inserendovi le direttive

zone "nostro_nome.labint" {
  type master;
  file "/etc/bind/nostro_nome.labint";
};
zone "1xx.168.192.in-addr.arpa" {
  type master;
  file "/etc/bind/192.168.1xx";
};

e popolare i nostri file di zona con le informazioni relative ai nostri nomi a dominio:

host 192.168.1.1xx
file di zona /etc/bind/nostro_nome.labint file risoluzioni inverse /etc/bind/192.168.1xx
@ IN SOA ...eccetera...

        NS  nostro_nome.labint.
@        A  192.168.100.1xx
www      A  192.168.100.1xx
test     A  192.168.1xx.10
@ IN SOA ...eccetera...

         NS  nostro_nome.labint.
10      PTR  test.nostro_nome.labint.

In particolare il RR  @   A  192.168.100.1xx , inserito nel primo, serve ad assegnare al nome a dominio per il quale siamo ora autorevoli (nostro_nome.labint ) un indirizzo IP, dato che quello dichiarato come glue record presso il nameserver autorevole per .labint è esterno alla sua zona di autorità, e viene usato solo ai fini della ricorsione, e non per fornire una risoluzione ai client.

Dopo aver eseguito queste modifiche occorre far rileggere i files di configurazione a bind9, usando il comando sudo service bind9 reload, e verificare che tutto sia andato a buon fine, dirigendo una interrogazione al nostro host, ad es. impartendo host nostro_nome 127.0.0.1.

Risoluzione... dei problemi

Qualora l'esito non sia quello desiderato, possiamo trovarne la causa nel file /var/log/syslog, che conviene tenere d'occhio con il comando

tail -f /var/log/syslog

e quindi impartire la sequenza di comandi sudo service bind9 stop e sudo service bind9 start. Sicuramente, saranno evidenziati dei messaggi che indicheranno quali linee di quali files contengono errori sintattici e/o logici che ostacolano la configurazione desiderata. Correggiamoli, e iteriamo la procedura stop/start finché non si ottiene la risoluzione corretta.

Analisi del traffico

Infine, verifichiamo la correttezza della delega immessa nel nameserver autorevole per .labint, rivolgendogli una  richiesta di risoluzione mediante il comando host, come ad esempio

host test.nostro_nome 192.168.100.156

che (ispezionando il traffico sulla porta 53 con wireshark) potremo osservare dirigersi prima verso 192.168.100.156, quindi tornare al nostro bind9, quindi di nuovo indietro, e finalmente tornare verso il nostro resolver. A meno che, non sia già stata memorizzata nella cache di 192.168.100.156...

La propria sottorete

Assegnare tanti diversi indirizzi ad uno stesso computer, sebbene possa sembrare un controsenso, consente facilmente di abilitare un determinato servizio a rispondere solo quando l'host viene referenziato con un determinato nome, anziché un qualunque altro, perché la diversa risoluzione di indirizzo IP permette di eseguire la bind() del socket del server solo sul quel particolare indirizzo.

Come già noto, alla stessa interfaccia di rete possono essere assegnati altri indirizzi mediante il comando

ip addr add 192.168.1xx.y dev eth0

da ripetersi per tutti gli indirizzi usati. Per fare in modo che questi siano ancora validi alla prossima riaccensione del computer, possiamo copiare la sequenza di comandi di assegnazione nello script /etc/rc.local, che viene appunto eseguito al termine della fase di boot.

C'è posta per me

Allo scopo di poter ricevere i messaggi di posta elettronica spediti a partire da un altro host del laboratorio ed indirizzati a labint@nostro_nome.labint, ed allo stesso tempo prelevarli tramite una applicazione client in esecuzione sul nostro od un altro computer, occorre inserire nei nostri file di zona il RR MX, e volendo alcuni alias, come ad es.

host 192.168.1.1xx
file di zona /etc/bind/nostro_nome.labint file risoluzioni inverse /etc/bind/192.168.1xx
@       MX  10 mail
mail     A  192.168.1xx.20
smtp CNAME  mail
pop  CNAME  mail
imap CNAME  mail
20      PTR  mail.nostro_nome.labint.

e inserire il nuovo indirizzo IP nel file /etc/rc.local. Quindi eseguiamo (come root) rc.local, ri-lanciamo il nameserver con sudo service bind9 restart, e verifichiamo che la modifica sia divenuta effettiva mediante i comandi

host -t any nostro_nome
host -l nostro_nome
host smtp.nostro_nome
host imap.nostro_nome

che mostrano tutti i RR definiti per nostro_nome.labint, tutti i nomi di terzo livello, e le traduzioni per i due alias.

DHCP e DDNS

Proviamo a catturare il traffico osservato dal nostro computer, per scoprire gli eventuali messaggi DHCP di Discovery e Request. Quindi, impostiamo un laboratorio virtuale con Netkit in cui più VM guest si affacciano sulla medesima LAN, in cui una VM ospita un server DHCP, e tutte le altre acquisiscono un indirizzo IP. Per questo, usiamo dnsmasq.

Dnsmasq

Si tratta di un serverino molto intelligente (sito, man page, guida alla configurazione), che implementa un forwarder DNS, associato ad un server DHCP, il tutto incorporato in unico programma. In tal modo, si è in grado di risolvere gli IP dei computer della propria rete, in base al nome che questi hanno comunicato nella DHCP Discovery, ed in base all'IP affittato loro. Sperimentiamo ora questa nuova soluzione, in modo da confrontarla con la configurazione statica del file di zona, intrapresa precedentemente.

Inizializziamo le variabili di ambiente, e copiamo la directory /media/netkit/labs/labdhcp (versione on line) presso il nostro computer host. Osservando lab.conf, possiamo verificare dal file lab.conf che il laboratorio consta di 4 VM (r1, r2, r3, r4) tutte connesse alla stessa LAN e, visualizzando i files .startup, notiamo che mentre per le ultime tre ci si limita ad attivare l'interfaccia eth0, ad r1 si assegna anche l'indirizzo 30.0.0.1/16, e si popola il file di configurazione /etc/dnsmasq.conf mediante i comandi

echo "dhcp-range=30.0.0.100,30.0.0.200,12h" > /etc/dnsmasq.conf
echo "domain=labdhcp                     " >> /etc/dnsmasq.conf
dnsmasq -q

che impostano l'intervallo di indirizzi su cui opera il DHCP, ed il suffisso di dominio che questo comunica ai clients. Quindi, si manda in esecuzione il demone invocando /etc/init.d/ dnsmasq start.

A questo punto, possiamo catturare il traffico e salvarlo sulla macchina host, impartendo su r1 tcpdump -i any -s 0 -w /hosthome/cattura.pcap, e lanciare sulle restanti VM il comando dhclient che attiva la richiesta di assegnazione di indirizzo. Dopo che sulle rispettive finestre avremo osservato il buon esito della richiesta, potremo interrompere il tcpdump, e esaminare con wireshak il traffico relativo.

Notiamo che nelle trame catturate non viene mostrato il MAC di destinazione, ma possiamo comunque apprezzare come il DHCP, prima di emettere una offerta, provveda ad inviare dei pacchetti ARP e ICMP ECHO verso l'indirizzo che sta per proporre, onde evitare di usarne uno già impegnato. Notiamo infine come nell'offerta siano presenti tutti i valori di cui il client avrà bisogno per configurare correttamente la sua rete.

Per un motivo che non capisco però, dnsmasq sembra rifiutare le richieste DNS a lui indirizzate, investigherò.

Zeroconf

L'implementazione di Zeroconf per Linux è quella fornita da Avahi, e che prevede di installare i pacchetti

A questo punto, abbiamo tutto ciò che occorre per procedere nella nostra sperimentazione. Mantenendo aperto il capture di Wireshark

x
Logo

Lo Strato Applicativo
di Internet

Dal TCP al VoIP, dal DNS all'Email alla crittografia, tutto ciò che accade dietro le quinte di Internet, completo di cattura del traffico.
Scopri come effettuare il download, ricevere gli aggiornamenti, e contribuire!


Realizzato con Document made with Kompozer da Alessandro Falaschi -
Capitolo: Posta elettronica: SMTP, IMAP, e autenticazione