DNS: Domain Name System

Presentazione sul tema: "DNS: Domain Name System"— Transcript della presentazione:

1 DNS: Domain Name System
Alma Mater Studiorum - Universita' di Bologna Sede di Cesena II Facolta' di Ingegneria Reti di Calcolatori DNS: Domain Name System Vedi: A.S. Tanenbaum, Computer Networks, 4th ed., Prentice Hall: sez. 7.1, pagg D. Comer, Internetworking con TCP/IP - Principi, protocolli e architetture, vol. 1, Addison-Wesley, cap. 24, pagg Copyright © by Claudio Salati. Lez. 11

2 Perche' il DNS Quando si scrivevano programmi in linguaggio macchina era necessario utilizzare esplicitamente i codici numerici delle istruzioni e gli indirizzi numerici in memoria. Il primo passo verso la programmazione ad alto livello e' avvenuto con la sostituzione dei codici numerici delle istruzioni con acronimi simbolici, e con quella degli indirizzi numerici con etichette simboliche (programmazione assembler). In modo analogo, nel caso della programmazione di rete, si vorrebbe che fosse possibile nominare una macchina attraverso il suo nome simbolico anziche' attraverso il (un) suo indirizzo IP. Il nome di una macchina Unix e' ad esempio ottenibile attraverso la system call: int gethostname(char *name, int maxNameLen); Cosi' come nel caso dell'HW dei calcolatori l’unica cosa che una CPU sa interpretare sono codici operativi e indirizzi numerici, a livello di rete l'unico meccanismo utilizzabile per riferire un nodo rimane ovviamente il (un) suo indirizzo IP.

3 Perche' il DNS L'uso di nomi simbolici per riferire un nodo della rete non e' vantaggioso solo perche' e' piu' conveniente per gli esseri umani. Se mi mandate una all'indirizzo il gestore del sistema puo' cambiare (o spostare) la macchina su cui e' allocato il mail server senza che il mio indirizzo debba cambiare di conseguenza (ho un indirizzo rilocabile). I problemi da affrontare sono 2: 1. E' possibile definire una regola per la costruzione dei nomi simbolici dei nodi tale che sia possibile assegnare facilmente dei nuovi nomi avendo la garanzia che non sorgano dei conflitti con nomi gia' utilizzati? E' possibile definire un sistema di gestione dei nomi simbolici (name service) che sia facilmente operabile (e.g. sia facile inserire/cancellare nodi) sia in grado di effettuare in modo efficiente il mapping tra i nomi simbolici e i corrispondenti indirizzi di rete?

4 Un sistema dei nomi piatto e' possibile? NO!
Ci vorrebbe un'autorita' centralizzata per garantire l'univocita' dei nomi. (in un sistema come Internet con centinaia di milioni di nodi collegati la probabilita' di conflitto sarebbe elevatissima) Sarebbe necessario mantenere o un sistema di mappaggio dei nomi centralizzato, ma questo e' impossibile perche' non riuscirebbe a rispondere abbastanza velocemente a tutte le query, sarebbe difficile mantenerlo aggiornato a fronte dei continui cambiamenti di mapping nome-indirizzo, o un sistema di mappaggio dei nomi replicato, ma mantenere aggiornate le diverse copie di un database cosi' enorme sarebbe anch'esso difficile.

5 Un sistema dei nomi gerarchico!
Si e' gia' visto nel caso degli OBJECT IDENTIFIER ASN.1 come attraverso il principio di delega gerarchica sia possibile costruire degli identificatori la cui unicita' e' garantita a priori. Lo stesso principio puo' essere utilizzato in questo caso sostituendo gli interi utilizzati per la costruzione degli OBJECT IDENTIFIER con delle label simboliche (N.B.: case insensitive per il DNS). L'insieme dei nomi definiti sara' quindi rappresentato da un albero, ciascuno dei cui nodi e' marcato con una label (univoca rispetto alle label dei suoi fratelli). Il nome di un nodo dell'albero sara' quindi costituito dalla sequenza di label ottenuta concatenando le label che si incontrano tra quel nodo (compreso) e la radice. Non tutti i nomi rappresenteranno dei nodi della rete: alcuni nomi (in particolare, quelli dei nodi intermedi) rappresenteranno delle autorita' di denominazione. Ciascun nodo dell'albero dei nomi e' denominato domain.

6 DNS (Domain Name System): cosa e'
Tanenbaum: DNS is defined in RFCs 1034 and 1035. The essence of DNS is the invention of a hierarchical, domain-based naming scheme, and a distributed database system for implementing this naming scheme. It is primarily used for mapping host names and destinations to IP addresses but can also be used for other purposes. The way DNS is used is as follows. To map a name onto an IP address, an application program calls a library procedure called the resolver, passing it the name as a parameter. The resolver sends a UDP packet to a local DNS server, which then looks up the name and returns the IP address to the resolver, which then returns it to the caller. Armed with the IP address, the program can then procede.

7 Una porzione del domain name space Internet
+ eu! Esempio di domain name: linda.cs.yale.edu Ogni domain e' autonomo nell'assegnazione dei nomi al proprio interno. In Internet, i nomi gerarchici dei nodi sono assegnati secondo la struttura delle organizzazioni che ottengono l'autorita' per parti dello spazio di denominazione, non secondo la struttura della rete fisica (a differenza, ad esempio, dei numeri della rete telefonica fissa).

8 Lo spazio dei nomi del DNS
L’albero dei nomi non e’ correlato con gli indirizzi IP delle sottoreti e dei nodi ES e IS che esso contiene ma solo a regole amministrative. Consideriamo una multinazionale XXX che ha sedi in diverse parti del mondo. Ogni sede utilizzera’ probabilmente una o piu’ sottoreti IP, ciascuna con un suo indirizzo. Gli indirizzi IP di queste sottoreti, e quindi quelli dei nodi ad esse connessi, non hanno in linea di principio alcuna correlazione reciproca. E tuttavia la amministrazione di tutte queste sottoreti potrebbe essere centralizzata. Quindi ci sarebbe un domain XXX.com per rappresentare questo dominio amministrativo. Banalmente: i nomi di tutti i nodi terminerebbero per XXX.com, indipendentemente dalla loro localizzazione geografica.

9 Lo spazio dei nomi del DNS
I domini di livello piu' elevato (top-level domain) sono amministrati centralmente. Esistono due gerarchie parallele: Quella basata su top-level domain che rappresentano stati. Quella basata sui top-level domain generici. COM EDU GOV MIL NET ORG INT ARPA BIZ INFO NAME PRO AERO COOP MUSEUM Notare che una stessa macchina puo' avere assegnati due nomi, uno secondo ciascuna gerarchia (e, ricorsivamente, anche piu' di due nomi). Esempi: deis.unibo.it flits.cs.vu.nl 9

10 Classi e tipi dei nomi DNS consente di mantenere altre relazioni oltre che quella fra nomi di macchine e relativi indirizzi IP. Tra l'altro: Non tutti i domain name sono nomi di nodi della rete. Non c'e' niente nel formato di un nome che indichi se esso e' o no il nome di un nodo di rete. Ad ogni nome possono essere associate informazioni di diverso tipo. Ad ogni nome possono essere associate piu’ informazioni di uno stesso tipo. Ogni entry (record) in DNS e' caratterizzata da un tag di tipo dell'informazione associata: questo tag indica ad esempio se la entry mi fornisce un mapping (nome  indirizzo IP) piuttosto che un mapping (indirizzo  nome della macchina server ). Quando un cliente DNS effettua una query su un domain name deve specificare quale e' il tipo di informazione che gli interessa: Il DNS gli ritorna un valore di quel tipo associato al domain name. Ogni entry e ogni query devono anche riferire la classe del nome, cioe' la protocol family cui il nome e' relativo. In pratica la classe e' sempre AF_INET (o IN, in termini DNS).

11 Principali tipi di record DNS
Quando una applicazione usa DNS per risolvere un nome, essa specifica che il tipo della risposta deve essere mail exchange (MX). Questo implica che il valore che gli verra' restituito conterra': Il domain name di un nodo che puo' operare come mail server per il dominio indicato. Un intero che indica la priorita' di quel nodo rispetto ad altri nodi che possono anch'essi operare come mail server per il dominio indicato.

12 Tipi di record DNS A : host address
Un record di tipo A mappa un domain name sul relativo indirizzo IP. Ogni nodo puo' avere diversi indirizzi IP. Ad uno stesso nome possono quindi essere associati piu' record di tipo A, uno per ogni indirizzo. Un server DNS puo' essere configurato per ciclare tra i diversi record di uno stesso tipo associati ad uno stesso domain name. Record di tipo A possono esistere solo per domain name di nodi della rete.

13 Tipi di record DNS MX : mail exchanger
Specifica il nome di uno host che e' disponibile ad accettare per un certo dominio (host disponibile ad accettare = macchina server SMTP). Esempio: Per mandare una a bisogna in realta' indirizzarla al mail server sul nodo zephyr.cs.vu.nl. Un record MX specifica il mapping (cs.vu.nl  zephyr.cs.vu.nl) relativo al servizio di . In un dominio ci possono essere piu' host che offrono il servizio di mail. Ad uno stesso domain name possono quindi essere associati piu' record di tipo MX, uno per ogni host che ospita un mail server disponibile. Ogni record MX fornisce anche la priorita' relativa del mail server rispetto ad altri mail server disponibili per il dominio.

14 Esempio Comer When sending , the user specifies an address of the form The mail system uses DNS to resolve domain-part with query type MX. DNS returns a set of resource records that each contains a preference field and a host's domain name. The mail system steps through the set from highest preference to lowest (lower numbers mean higher preference). For each MX resource record, the mailer extracts the domain name and uses a type A query to resolve that name to an IP address. It then tries to contact the host and deliver mail. If the host is unavailable, the mailer will continue trying other hosts on the list.

15 Tipi di record DNS CNAME : Canonical name
Un record CNAME consente di definire un alias per un domain name. Consente ad esempio di associare il nome logico permanente di un servizio (e.g. con il domain name dell'host che implementa in questo momento il servizio (e.g. atrproxy2.unibo.it). PTR : Pointer Un record PTR serve per operazioni di reverse lookup, operazioni cioe' in cui si fornisce al DNS un indirizzo IP e si vuole conoscere il domain name dell'host che ha quell'indirizzo. Il domain name del record codifica l'indirizzo IP nello speciale dominio dedicato in-addr.arpa secondo la regola: IP address Domain name aaa.bbb.ccc.ddd ddd.ccc.bbb.aaa.in-addr.arpa

16 Tipi di record DNS SOA : Start of Authority
Il valore di un record SOA e' composto di piu' campi che descrivono diverse proprieta' delle parti dello spazio gerarchico dei nomi che sono implementate dal name server. I domain name compresi nella "zona", l'indirizzo del suo amministratore, . . . NS : Name server Fornisce il nome di un name server autorevole per il dominio. HINFO : Host description Un record HINFO fornisce informazioni sulla macchina riferita dal domain name, e sul relativo sistema operativo. TXT : Arbitrary text Un record TXT ha come valore un campo di testo non strutturato e senza significato predefinito. Un record TXT e' quindi interpretabile solo da esseri umani, serve solo come documentazione.

17 Parte di un possibile database DNS per cs.vu.nl

18 Mapping e Name Server DNS e' un sistema distribuito:
Il problema del name mapping e' risolto da un insieme di server distribuiti (name server) sulla rete e che cooperano tra loro. In che termini cooperano tra di loro i name server? Come si correla l’architettura distribuita dei name server con l’albero dei domain name? Un programma applicativo che vuole accedere al servizio DNS lo fa attraverso un SW cliente chiamato name resolver, che utilizza i name server per rispondere effettivamente alle richieste che riceve. Il resolver rivolgera’ (ovviamente) la sua richiesta al name server piu’ vicino! Perche' il sistema sia efficiente la maggior parte delle operazioni di mapping devono essere risolte localmente, senza generare traffico in rete. Se possibile dal resolver stesso, se no dal server piu’ vicino cui il resolver si e’ rivolto; se nemmeno questo sa rispondere …

19 Mapping e Name Server Il name space DNS e' suddiviso in zone.
Ogni zona contiene alcune parti dell'albero dei nomi e un insieme di name server capaci di fornire informazioni sui nodi (in generale, sui domain) appartenenti alla zona. Ogni zona ha un name server primario che e' la fonte autorevole di informazioni per la zona. Nessun name server ha l’informazione su tutta la rete (e non ha nemmeno bisogno di averla). Ogni name server possiede solo l’informazione relativa alla sua zona Per informazioni relative ad altre zone deve chiedere ai name server che la posseggono. 19

20 Partizionamento dello spazio dei nomi (zone)
Il name server primario mantiene tutte le informazioni sulla zona come un insieme di record DNS gestito amministrativamente. Gli altri eventuali name server della zona ottengono dinamicamente copia delle informazioni sulla zona dal name server primario.

21 Risoluzione dei nomi .1 Secondo un modello logico semplificato di funzionamento del DNS ogni zona coincide con un nodo dell'albero dei nomi, e il name server della zona e' in grado di mappare le label che identificano i figli del nodo, siano essi veri e propri domini o host name. Il root name server sa mappare i domini di primo livello (top-level). Il name server di un dominio di primo livello sa mappare i nomi dei domini di secondo livello in esso contenuti, e cosi' via. In questo modello logico semplificato il mapping di un nome inizia sempre dal root name server, che processa la label piu' a destra del nome, identifica di conseguenza il name server di primo livello che sa processare il nome, e delega a questo il processamento del nome stesso. Il name server di primo livello si comporta in modo analogo, ma processa la seconda label a destra del nome. La procedura si ripete ricorsivamente fino all'avvenuto processamento della prima label a sinistra del nome.

22 Risoluzione dei nomi .2 In realta' si e' visto che la risoluzione dei nomi inizia con il resolver che interroga il name server locale della sua zona. Ma come fa il resolver a conoscere l'indirizzo IP del nodo che ospita il name server locale? N.B.: ovviamente la porta su cui il name server DNS offre il suo servizio e' una porta ben nota (53 UDP). E come fa il name server locale, se non riesce a mappare il nome, a localizzare un name server che puo' farlo al posto suo? Ad esempio il root name server? Attraverso meccanismi locali (e manuali!) di configurazione! E.g. questi indirizzi IP sono scritti in un file. Ogni resolver deve conoscere a priori l'indirizzo IP di almeno un name server. Ogni name server deve conoscere a priori l'indirizzo IP di almeno un root name server. Ogni name server deve conoscere a priori l'indirizzo IP del name server del dominio immediatamente superiore.

23 Configurazione di una interfaccia IP/Ethernet
O:\>ipconfig /all Configurazione IP di Windows Nome host : csalati-xp Suffisso DNS primario : dl.net Routing IP abilitato : No Elenco di ricerca suffissi DNS : dl.net datasensor.corp psc.pscnet.com pscnet.com Scheda Ethernet connessione alla intranet Datalogic: Suffisso DNS specifico per connessione: dl.net Descrizione : Broadcom NetXtreme 57xx Gigabit Controller Indirizzo fisico : B-9D DHCP abilitato : Sì Configurazione automatica abilitata : Sì Indirizzo IP : Subnet mask : Gateway predefinito : Server DHCP : Server DNS : “Nome” della macchina: csalati-xp.dl.net Per query al DNS Indirizzo IP del router da utilizzare 2 server DNS.

24 DHCP In realta’ con l’introduzione di indirizzi dinamici e DHCP le cose sono cambiate parecchio per DNS. Condideriamo l’informazione di configurazione persente sul nostro PC, dove sono abilitati DHCP e configurazione automatica: L’indirizzo del server DHCP a’ auto-appreso (protocollo DHCP). Indirizzo IP, subnet mask e gateway predefinito sono acquisiti tramite DHCP. L’indirizzo dei server DNS e’ anch’esso appreso tramite DHCP. Ma come fa DNS a sapere quale e’ l’indirizzo IP che DHCP ha assegnato al nostro PC? E’ evidente che DNS deve essere informato dinamicamente di cio’!

25 Risoluzione dei nomi .3 Si e' detto che il name server di una zona deve conoscere l'indirizzo di almeno un root name server. Cio' significa che di root name server ce ne sono diversi (agli inizi del millennio una dozzina, 13 per l'esattezza). Questo e' necessario: Per ragioni di affidabilita' del sistema (che deve continuare a funzionare anche a fronte del fallimento di un root name server). Per ragioni di prestazioni (load sharing tra i root name server). In realta' l'architettura ridondata si applica come requisito a tutte le zone. Ogni zona amministrativa, per essere autorizzata, deve garantire l’esistenza di almeno 2 name server. Per ragioni di efficienza poi: Il name server locale non si rivolge a name server di gerarchia superiore se e' gia' in grado di risolvere un nome, ma risponde direttamente (la maggior parte delle query ha significato locale). Un singola zona puo' contenere parti estese della gerarchia dei nomi, cosi' da minimizzare il numero dei server coinvolti nella risoluzione di una singola query.

26 Risoluzione dei nomi .4 Comer
I collegamenti nell'albero concettuale dei nomi non indicano connessioni fisiche della rete. Esse mostrano invece quali altri name server un certo server conosce e puo' contattare. L'albero concettuale dei nomi e' una astrazione che usa Internet per la comunicazione. La gerarchia dei nomi e’ una suddivisione amministrativa, non topologica, della rete. Di uno stesso sottoalbero possono fare parti sottoreti completamente disgiunte ma gestite da una stessa amministrazione (e.g. le diverse sedi di una stessa azienda in giro per il mondo) I server possono essere allocati in posti qualunque su Internet, e in particolare un server di una zona puo' essere localizzato fuori dalla zona.

27 Processamento delle interrogazioni .1
Un resolver puo' generare/gestire due tipi di interrogazioni verso il servizio DNS. Puo' chiedere al name server locale di risolvere ricorsivamente (recursive query) un nome. Se il server non e' in grado di risolvere direttamente il nome si rivolgera' ricorsivamente ad un altro server, cosi' da essere comunque in grado di fornire la risposta richiesta al resolver. Questa e' la modalita' operativa che abbiamo assunto fino ad adesso. Puo' chiedere al server di fornirgli comunque una risposta in base alle sole informazioni disponibili localmente (iterative query). Se il server non e' in grado di risolvere direttamente il nome inviera' al resolver una risposta negativa, ma questa conterra' il nome del server che e' in grado di processare ulteriormente la query. A questo punto e' responsabilita' del resolver interrogare direttamente questo nuovo server (e cosi' iterativamente) fino a che non riceve l'informazione desiderata.

28 Processamento delle interrogazioni .2
In ogni caso l'interrogazione generata dal resolver contiene le seguenti informazioni: Il domain name che si vuole risolto. La classe del domain name. Il tipo dell'informazione associata al domain name cui il resolver e' interessato. La modalita' dell'interrogazione, ricorsiva o meno. Quando il server della zona riceve la richiesta, per prima cosa verifica la propria autorevolezza rispetto ad essa. Se il name server e' autorevole, e' anche (per definizione) in grado di generare la risposta (positiva o negativa). Se non e' autorevole processera' l'interrogazione in base alla modalita' di questa. In ogni caso ogni server che origina una risposta registra se stesso come sorgente di quella risposta.

29 Caching .1 I name server DNS utilizzano una politica di caching per ottimizzare il costo di elaborazione di interrogazioni relative a nomi non locali. Ogni server mantiene una cache relativa a: I domain name remoti risolti di recente. I name server che hanno fornito le risoluzioni (finali) di questi nomi. Quando un name server riceve una interrogazione su un nome per il quale non e' autorevole, per prima cosa consulta la cache. Se l'informazione richiesta e' presente nella cache il server risponde al client fornendogli questa informazione, ma supplementandola con: Una marca che questa informazione e' non autorevole. Il domain name del name server che aveva fornito l'informazione. Il client a questo punto puo' Provare ad utilizzare l'informazione ottenuta. Rivolgere l'interrogazione al name server che l'aveva fornita per essere sicuro di avere una informazione attendibile.

30 Caching .2 Il caching funziona bene nel caso del DNS perche' il binding dei nomi cambia poco frequentemente. Pero' cambia! Come puo' un name server evitare di mantenere (e rispondere con) binding obsoleti? Ad ogni record della cache e' associato un time-out. Quando questo time-out scade il record viene cancellato. Il valore del time-out non e' uguale per tutti i record, non e' nemmeno determinato dal server che mantiene la cache (e lo utilizza).

31 Caching .3 E' il server che ha autorevolezza su quel binding che quando lo diffonde in rete (rispondendo ad una query) gli associa una informazione di TimeToLive. Ad ogni record DNS e' associato (sul server autorevole che lo mantiene) un campo (configurabile) TimeToLive. Quando il name server risponde ad una interrogazione utilizzando quel record, associa alla risposta la informazione di TimeToLive. I name server che basandosi su questa risposta creano un record nella loro cache usano il TimeToLive come time-out del record. Nell’esempio del database DNS per cs.vu.nl: cs.vu.nl IN MX 1 zephyr.cs.vu.nl (=60*60*24 s) e’ il valore in secondi del TimeToLive di queste informazioni.

32 Caching .4 Il caching non e' limitato ai name server.
Anche i resolver possono applicare politiche di caching. La prima cosa che un resolver puo' inserire in cache e' la copia del database del suo name server locale! In questo modo: La risoluzione dei nomi locali e' immediata, perche' il resolver e' direttamente capace di fornire la risposta. La risoluzione dei nomi locali non genera traffico di rete di nessun genere. Il sistema e' capace di tollerare il fallimento del name server locale. Diminuendo il carico di lavoro sul name server gli consente di gestire un numero maggiore di client.

33 Risoluzione dei nomi: esempio .1
Un resolver su flits.cs.vu.nl vuole sapere l'indirizzo IP dell'host linda.cs.yale.edu. Nel passo 1 esso invia la richiesta al name server locale della zona, su cs.vu.nl (il cui indirizzo IP gli e' noto a priori). Supponiamo che il name server locale non abbia alcuna informazione su linda.cs.yale.edu (e quindi non abbia alcuna informazione relativa nella cache). Nel passo 2 il name server su cs.vu.nl prolunga la richiesta al root name server che sa mappare la label edu. L'indirizzo IP di questo name server gli e' noto a priori. Il name server responsabile della zona edu e' per definizione in grado di mappare (almeno) la label yale, e puo' quindi prolungare la richiesta al name server di yale.edu (passo 3).

34 Risoluzione dei nomi: esempio .2
Il name server responsabile della zona yale.edu e' per definizione in grado di mappare (almeno) la label cs, e puo' quindi prolungarela richiesta al name server di cs.yale.edu (passo 4). Il name server della zona cs.yale.edu e' il name server autorevole per tutti i nomi che appartengono a questo dominio: sa mappare sia linda.cs.yale.edu che robot.ai.cs.yale.edu. Esso puo' quindi rispondere autorevolmente alla richiesta (passo 5). Le riposte percorrono in senso inverso il percorso delle interrogazioni innestate fino a raggiungere il resolver (passi 6-8). Il name server cs.vu.nl che processa la risposta puo' mantenere l'informazione acquisita in una cache, ma non ha autorevolezza sul nome, per cui se risponde con questa informazione ad una nuova richiesta, marchera' la sua risposta come non autorevole.

35 DNS: struttura del database
Un record DNS e' composto di 5 campi: Domain name Domain name di cui il record descrive un mapping. Rappresenta la chiave di ricerca primaria nel database DNS. Normalmente ad ogni domain name sono associati piu' record. TimeToLive Indica la stabilita' del mapping descritto dal record. E' espresso in numero di secondi. Class Classe (protocol family) cui e' relativo il domain name. In pratica ha sempre valore IN (AF_INET). Type Tipo del valore definito dal record. Rappresenta la chiave di ricerca secondaria nel database DNS. Value La struttura di questo campo dipende dal valore del campo Type del record. Il database DNS e' normalmente realizzato tramite valori binari, anche se la sua descrizione e' di solito data in forma testuale.

36 DNS: struttura del PDU Il PDU DNS e' descritto tramite una mappa di byte. I valori dei suoi campi sono espressi in codifica binaria. Le stringhe di caratteri che descrivono i domain name sono rappresentate in modo complesso per effettuarne la compressione e per accorciarle sfruttandone le caratteristiche di localita'.

37 Inverse mapping e pointer query
Comer Inverse queries allow the client to ask a server to map backwards by taking an answer and generating the question that would produce that answer. Although inverse queries have been part of DNS since it was first specified, they are generally not used because there is no way to find the server that can resolve the query without searching the entire set of servers. C'e' pero' una inverse query fondamentale, che e' supportata da uno specifico tipo di record DNS (PTR): una pointer query, dato un indirizzo IP, ritorna il relativo domain name. La forma del domain name in una pointer query e' ddd.ccc.bbb.aaa.in-addr.arpa Il name server locale puo' essere o meno autorevole per il dominio arpa o uno dei suoi sotto-domini (e.g. bbb.aaa.in-addr.arpa se la sottorete di classe B aaa.bbb.0.0 appartiene alla zona). Per velocizzare le pointer query i root name server mantengono un database di indirizzi IP validi insieme al riferimento ai name server che sanno risolvere ciascun indirizzo.

38 nslookup C:\Users\csalati>nslookup *** I server predefiniti non sono disponibili Server predefinito: UnKnown Address: :53 (porta well known di DNS) > help Comandi: (gli identificatori sono indicati in maiuscolo, [] significa facoltativo) NOME - stampa informazioni sul NOME host/dominio utilizzando il server predefinito NOME1 NOME2 - come sopra, ma usa NOME2 come server help o ? - stampa informazioni su comandi comuni server NOME - imposta server predefinito su NOME, utilizzando il server corrente predefinito lserver NOME - imposta server predefinito su NOME, utilizzando server iniziale finger [UTENTE] - usa finger per il NOME opzionale all'host corrente root - imposta server corrente predefinito su root

39 nslookup ls [opt] DOMINIO [> FILE] - elenca indirizzi nel DOMINIO (facoltativo: output a FILE) opt -a - elenca nomi canonici e alias -d - elenca tutti i record -t TIPO - elenca record del tipo indicato (es. A,CNAME,MX,NS,PTR e così via) view FILE - ordina un file di output 'ls' e visualizzalo con pg exit - esci dal programma set OPZIONE - imposta una opzione

40 nslookup: opzioni all - stampa opzioni, server corrente e host [no]debug - stampa informazioni di debug [no]d2 - stampa informazioni dettagliate di debug [no]defname - aggiungi nome dominio a ogni query [no]recurse - per risposte ricorsive alla query [no]search - usa elenco di ricerca dominio [no]vc - usa sempre un circuito virtuale domain=NOME - imposta il NOME predefinito del dominio srchlist=N1[/N2/.../N6] - imposta dominio su N1 ed elenco di ricerca su N1,N2, ecc. root=NOME - imposta server radice su NOME retry=X - imposta numero tentativi su X timeout=X - imposta l'intervallo iniziale di scadenza su X secondi

41 nslookup: opzioni type=X - imposta tipo query (es. A,AAAA,ANY,CNAME,MX,NS,PTR,SOA,SRV) querytype=X - come tipo class=X - imposta classe query (es. IN (Internet), ANY) [no]msxfr - usa trasferimento di zona rapido MS ixfrver=X - versione corrente da usare nelle richieste di trasferimento IXFR

42 DNS API These routines are used for making, sending, and interpreting query and reply messages with Internet domain name servers. L'uso di queste funzioni e' deprecato perche' esse si appoggiano su una struttura dati statica, la variabile globale _res, per mantenere lo stato di una query. La variabile _res viene inizializzata con valori di default tramite la funzione res_init(). Tra le altre cose res_init() registra in _res l'indirizzo del server DNS cui rivolgersi. La funzione res_mkquery() viene utilizzata per preparare il testo di una query. Quando la query e' pronta, essa viene trasmessa al server DNS usando la funzione res_send(), che si occupa anche di ricevere la risposta. res_query() e res_search() combinano le funzionalita' di res_mkquery() e res_send().

43 gethostbyname() .1 Poiche' la funzione normale di un name service e' quella di tradurre il nome di una macchina nel suo indirizzo IP, esiste una funzione (un resolver) dedicata a questo scopo. Fornendo alla funzione un nome di una macchina essa ne ritorna la descrizione completa secondo la struttura hostent. #include <netdb.h> struct hostent { char *h_name; /* canonical name of host */ char **h_aliases; /* alias list */ int h_addrtype; /* host address type */ int h_length; /* length of address */ char **h_addr_list; /* list of addresses */ }; struct hostent *gethostbyname(const char *name);

44 gethostbyname() .2 Nel nostro caso h_addrtype==AF_INET e la lista di indirizzi e' una lista di struct in_addr. Se la funzione non trova alcun host con il nome (domain name) indicato ritorna NULL. Entrambi i campi che rappresentano liste sono implementati tramite un puntatore ad un vettore che contiene i puntatori agli elementi della lista. I vettori sono terminati da un puntatore di valore NULL. DNS opera solo su domain name completi. Di norma e' pero' sufficiente fornire a gethostbyname() solo il nome locale, senza il suffisso di dominio, perche' e' la funzione stessa che concatena il nome indicato con una lista configurabile di suffissi. E' ovvio che se il nodo che cerchiamo non appartiene ad uno dei domini configurati e' necessario invocare gethostbyname() passando il domain name completo. N.B.: questa funzione e' considerata obsoleta e di uso pericoloso perche' ritorna il suo risultato su memoria allocata staticamente.

45 gethostbyaddr() Anche per la query di reverse lookup che consente di risalire al nome di una macchina in base al suo indirizzo IP esiste una funzione (un resolver) dedicata. Fornendo alla funzione un indirizzo IP di una macchina essa ne ritorna la descrizione completa secondo la struttura hostent. #include <netdb.h> struct hostent *gethostbyaddr(const char *addr, int len, int type); La funzione e' in realta' piu' generica, e consente di cercare il nome di un nodo di una delle reti ammesse in <sys/socket.h>. Nel caso di una query relativa ad un indirizzo IP deve essere type==AF_INET e addr deve riferire una variabile di tipo struct in_addr. Se la funzione non trova alcun host con l'indirizzo IP indicato ritorna NULL.

46 Esempio .1 Acquisisce e visualizza informazioni si di uno host di cui l’utente fornisce l’indirizzo IP in decimal dotted notation #include <stdio.h> #include <string.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> int main(int argc, const char **argv) { struct in_addr addr; struct hostent *hp; char **p; char **q; if (argc != 2) { printf("usage: %s\n", argv[0]); exit(1); }

47 Esempio .2 if ((int)(addr.s_addr=inet_addr(argv[1])) == -1) {
printf("Wrong IP-address format\n"); exit(2); } hp = gethostbyaddr((char *)&addr, sizeof(addr), AF_INET); if (hp == NULL) { printf("host %s not found\n", argv[1]); exit(3);

48 Esempio .3 printf("\nIP addresses for host %s\n", hp->h_name);
for (p = hp->h_addr_list; *p != NULL; p++) { struct in_addr in; memcpy(&in.s_addr, *p, sizeof(in.s_addr)); printf("\t%s\n", inet_ntoa(in)); } printf("Aliases for host %s\n", hp->h_name); for (q = hp->h_aliases; *q != NULL; q++) { printf("\t%s\n", *q); exit (0);