+La risoluzione dei nomi è associata tradizionalmente al servizio del
+\textit{Domain Name Service} che permette di identificare le macchine su
+internet invece che per numero IP attraverso il relativo \textsl{nome a
+ dominio}.\footnote{non staremo ad entrare nei dettagli della definizione di
+ cosa è un nome a dominio, dandolo per noto, una introduzione alla
+ problematica si trova in \cite{AGL} (cap. 9) mentre per una trattazione
+ approfondita di tutte le problematiche relative al DNS si può fare
+ riferimento a \cite{DNSbind}.} In realtà per DNS si intendono spesso i
+server che forniscono su internet questo servizio, mentre nel nostro caso
+affronteremo la problematica dal lato client, di un qualunque programma che
+necessita di compiere questa operazione.
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=10cm]{img/resolver}
+ \caption{Schema di funzionamento delle routine del \textit{resolver}.}
+ \label{fig:sock_resolver_schema}
+\end{figure}
+
+Inoltre quella fra nomi a dominio e indirizzi IP non è l'unica corrispondenza
+possibile fra nomi simbolici e valori numerici, come abbiamo visto anche in
+sez.~\ref{sec:sys_user_group} per le corrispondenze fra nomi di utenti e
+gruppi e relativi identificatori numerici; per quanto riguarda però tutti i
+nomi associati a identificativi o servizi relativi alla rete il servizio di
+risoluzione è gestito in maniera unificata da un insieme di routine fornite
+con le librerie del C, detto appunto \textit{resolver}.
+
+Lo schema di funzionamento del \textit{resolver} è illustrato in
+fig.~\ref{fig:sock_resolver_schema}; in sostanza i programmi hanno a
+disposizione un insieme di funzioni di libreria con cui chiamano il
+\textit{resolver}, indicate con le freccie nere. Ricevuta la richiesta è
+quest'ultimo che, sulla base della sua configurazione, esegue le operazioni
+necessarie a fornire la risposta, che possono essere la lettura delle
+informazioni mantenute nei relativi dei file statici presenti sulla macchina,
+una interrogazione ad un DNS (che a sua volta, per il funzionamento del
+protocollo può interrogarene altri) o la richiesta ad altri server per i quali
+sia fornito il supporto, come LDAP.\footnote{la sigla LDAP fa riferimento ad
+ un protocollo, il \textit{Lightweight Directory Access Protocol}, che
+ prevede un meccanismo per la gestione di \textsl{elenchi} di informazioni
+ via rete; il contenuto di un elenco può essere assolutamente generico, e
+ questo permette il manenimento dei più vari tipi di informazioni su una
+ infrastruttura di questo tipo.}
+
+La configurazione del \textit{resolver} attiene più alla amministrazione di
+sistema che alla programmazione, ciò non di meno, prima di trattare le varie
+funzioni di librerie utilizzate dai programmi, vale la pena fare una
+panoramica generale. Originariamente la configurazione del \textit{resolver}
+riguardava esclusivamente le questioni relative alla gestione dei nomi a
+dominio, e prevedeva solo l'utilizzo del DNS e del file statico
+\file{/etc/hosts}.
+
+Per questo aspetto il file di configurazione principale del sistema è
+\file{/etc/resolv.conf} che contiene in sostanza l'elenco degli indirizzi IP
+dei server DNS da contattare; a questo si affianca il file
+\file{/etc/host.conf} il cui scopo principale è indicare l'ordine in cui
+eseguire la risoluzione dei nomi (se usare prima i valori di \file{/etc/hosts}
+o quelli del DNS). Tralasciamo i dettagli relativi alle varie direttive che
+possono essere usate in questi file, che si trovano nelle rispettive pagine di
+manuale.
+
+Con il tempo però è divenuto possibile fornire diversi sostituti per
+l'utilizzo delle associazione statiche in \file{/etc/hosts}, inoltre oltre
+alla risoluzione dei nomi a dominio ci sono anche altri nomi da risolvere,
+come quelli che possono essere associati ad una rete (invece che ad una
+singola macchina) o ai gruppi di macchine definiti dal servizio
+NIS,\footnote{il \textit{Network Information Service} è un servizio, creato da
+ Sun, e poi diffuso su tutte le piattaforme unix-like, che permette di
+ raggruppare all'interno di una rete (in quelli che appunto vengono chiamati
+ \textit{netgroup}) varie macchine, centralizzando i servizi di definizione
+ di utenti e gruppi e di autenticazione, oggi è sempre più spesso sostituito
+ da LDAP.} o come quelli dei protocolli e dei servizi che sono mantenuti nei
+file statici \file{/etc/protocols} e \file{/etc/services}. Molte di queste
+informazioni non si trovano su un DNS, ma in una rete locale può essere molto
+utile centralizzare il mentenimento di alcune di esse su opportuni server.
+Inoltre l'uso di diversi supporti possibili per le stesse informazioni (ad
+esempio il nome delle macchine può essere mantenuto sia tramite
+\file{/etc/hosts}, che con il DNS, che con NIS) comporta il problema
+dell'ordine in cui questi vengono interrogati.\footnote{con le implementazioni
+ classiche i vari supporti erano introdotti modificando direttamente le
+ funzioni di liberia, prevedendo un ordine di interrogazione predefinito e
+ non modificabile (a meno di una ricompilazione delle librerie stesse).}
+
+Per risolvere questa serie di problemi la risoluzione dei nomi a dominio
+eseguira dal \textit{resolver} è stata inclusa all'interno di un meccanismo
+generico per la risoluzione di corripondenze fra nomi ed informazioni ad essi
+associate chiamato \textit{Name Service Switch}\footnote{il sistema è stato
+ introdotto la prima volta nelle librerie standard di Solaris, le \acr{glibc}
+ hanno ripreso lo stesso schema, si tenga presente che questo sistema non
+ esiste per altre librerie standard come le \acr{libc5} o le \acr{uclib}.}
+cui abbiamo accennato anche in sez.~\ref{sec:sys_user_group} per quanto
+riguarda la gestione dei dati associati a utenti e gruppi. Il \textit{Name
+ Service Switch} (cui spesso si fa riferimento con l'acronimo NSS) è un
+sistema di librerie dinamiche che permette di definire in maniera generica sia
+i supporti su cui mantenere i dati di corrispondenza fra nomi e valori
+numerici, sia l'ordine in cui effettuare le ricerche sui vari supporti
+disponibili. Il sistema prevede una serie di possibili classi di
+corrispondenza, quelle attualmente definite sono riportate in
+tab.~\ref{tab:sys_NSS_classes}.
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Classe} & \textbf{Tipo di corrispondenza}\\
+ \hline
+ \hline
+ \texttt{shadow} & corrispondenze fra username e proprietà dell'utente
+ (\acr{uid}, ecc.).\\
+ \texttt{group} & corrispondenze fra nome del gruppo e proprietà dello
+ stesso.\\
+ \texttt{aliases} & alias per la posta elettronica\\
+ \texttt{ethers} & corrispondenze fra numero IP e MAC address della
+ scheda di rete.\\
+ \texttt{hosts} & corrispondenze fra nome a dominio e numero IP.\\
+ \texttt{netgroup} & corrispondenze gruppo di rete e macchine che lo
+ compongono.\\
+ \texttt{networks} & corrispondenze fra nome di una rete e suo indirizzo
+ IP.\\
+ \texttt{protocols}& corrispondenze fra nome di un protocollo e relativo
+ numero identificativo.\\
+ \texttt{rpc} & corrispondenze fra nome di un servizio RPC e relativo
+ numero identificativo.\\
+ \texttt{services} & corrispondenze fra nome di un servizio e numero di
+ porta. \\
+ \hline
+ \end{tabular}
+ \caption{Le diverse classi di corrispondenze definite
+ all'interno del \textit{Name Service Switch}.}
+ \label{tab:sys_NSS_classes}
+\end{table}
+
+Il sistema del \textit{Name Service Switch} è controllato dal contenuto del
+file \file{/etc/nsswitch.conf}; questo contiene una riga\footnote{seguendo una
+ convezione comune per i file di configurazione le righe vuote vengono
+ ignorate e tutto quello che segue un carattere ``\texttt{\#}'' viene
+ considerato un commento.} di configurazione per ciascuna di queste classi,
+che viene inizia col nome di tab.~\ref{tab:sys_NSS_classes} seguito da un
+carattere ``\texttt{:}'' e prosegue con la lista dei \textsl{servizi} su cui
+le relative informazioni sono raggiungibili, scritti nell'ordine in cui si
+vuole siano interrogati.
+
+Ogni servizio è specificato a sua volta da un nome, come \texttt{file},
+\texttt{dns}, \texttt{db}, ecc. che identifica la libreria dinamica che
+realizza l'interfaccia con esso. Per ciascun servizio se \texttt{NAME} è il
+nome utilizzato dentro \file{/etc/nsswitch.conf}, dovrà essere presente
+(usualmente in \file{/lib}) una libreria \texttt{libnss\_NAME} che ne
+implementa le funzioni.
+
+In ogni caso, qualunque sia la modalità con cui ricevono i dati o il supporto
+su cui vengono mantenuti, e che si usino o meno funzionalità aggiuntive
+fornire dal sistema del \textit{Name Service Switch}, dal punto di vista di un
+programma che deve effettuare la risoluzione di un nome a dominio, tutto
+quello che conta sono le funzioni classiche che il \textit{resolver} mette a
+disposizione,\footnote{è cura della implementazione fattane nelle \acr{glibc}
+ tenere conto della presenza del \textit{Name Service Switch}.} e sono queste
+quelle che tratteremo nelle sezioni successive.
+
+
+\subsection{Le funzioni di interrogazione del \textit{resolver}}
+\label{sec:sock_resolver_functions}
+
+Prima di trattare le funzioni usate normalmente nella risoluzione dei nomi a
+dominio conviene trattare in maniera più dettagliata il meccanismo principale
+da esse utilizzato e cioè quello del servizio DNS. Come accennato questo,
+benché in teoria sia solo uno dei possibili supporti su cui mantenere le
+informazioni, in pratica costituisce il meccanismo principale con cui vengono
+risolti i nomi a dominio. Per questo motivo esistono una serie di funzioni di
+libreria che servono specificamente ad esseguire delle interrogazioni verso un
+server DNS, funzioni che poi vengono utilizzate per realizzare le funzioni
+generiche di libreria usate anche dal sistema del \textit{resolver}.
+
+Il sistema del DNS è in sostanza di un database distribuito organizzato in
+maniera gerarchica, i dati vengono mantenuti in tanti server distinti ciascuno
+dei quali si occupa della risoluzione del proprio \textsl{dominio}; i nomi a
+dominio sono organizzati in una struttura ad albero analoga a quella
+dell'albero dei file, con domini di primo livello (come i \texttt{.org}),
+secondo livello (come \texttt{.truelite.it}), ecc. In questo caso le
+separazioni sono fra i vari livelli sono definite dal carattere ``\texttt{.}''
+ed i nomi devono essere risolti da destra verso sinistra.\footnote{per chi si
+ stia chiedendo quale sia la radice di questo albero, cioè l'equivalente di
+ ``\texttt{/}'', la risposta è il dominio speciale ``\texttt{.}'', che in
+ genere non viene mai scritto esplicitamente, ma che, come chiunque abbia
+ configurato un server DNS sa bene, esiste ed è gestito dai cosiddetti
+ \textit{root DNS} che risolvono i domini di primo livello.} Il meccanismo
+funziona con il criterio della \textsl{delegazione}, un server responsabile
+per un dominio di primo livello può delegare la risoluzione degli indirizzi
+per un suo dominio di secondo livello ad un altro server, il quale a sua volta
+potrà delegare la risoluzione di un eventuale sottodominio di terzo livello ad
+un altro server ancora.
+
+In realtà un server DNS è in grado di fare altro rispetto alla risoluzione di
+un nome a dominio in un indirizzo IP; ciascuna voce nel database viene
+chiamata \textit{resource record}, e può contenere diverse informazioni; in
+genere i \textit{resource record} vengono classificati per la \textsl{classe
+ di indirizzi} cui i dati contenuti fanno riferimento, e per il \textsl{tipo}
+di questi ultimi. Oggigiorno i dati mantenuti nei server DNS sono
+sostanzialmente relativi soltanto ad indirizzi internet, per cui in pratica
+c'è soltanto una classe di indirizzi utilizzata, i dati invece possono essere
+di vario tipo, uno dei quali è appunto la corrispondenza fra nome a dominio e
+numero IP.
+
+L'esistenza di vari tipi di informazioni è un'altro dei motivi per cui il
+\textit{resolver} prevede, rispetto a quelle relative alla semplice
+risoluzione dei nomi, un insieme di funzioni specifiche dedicate
+all'interrogazione di un server DNS; la prima di queste funzioni è
+\funcd{res\_init}, il cui prototipo è:
+\begin{functions}
+ \headdecl{netinet/in.h} \headdecl{arpa/nameser.h} \headdecl{resolv.h}
+ \funcdecl{int res\_init(void)}
+
+Inizializza il sistema del \textit{resolver}.
+
+\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ errore.}
+\end{functions}
+
+La funzione legge il contenuto dei file di configurazione (i già citati
+\file{resolv.conf} e \file{host.conf}) per impostare il dominio di default,
+gli indirizzi dei server DNS da contattare e l'ordine delle ricerche; se non
+sono specificati server verrà utilizzato l'indirizzo locale, e se non è
+definito un dominio di default sarà usato quello associato con l'indirizzo
+locale (ma questo può essere sovrascritto con l'uso della variabile di
+ambiente \texttt{LOCALDOMAIN}). In genere è necessario eseguire questa
+funzione direttamente in quanto viene automaticamente chiamata la prima che si
+esegue una delle altre.
+
+Le impostazioni del resolver e lo stato del sistema vengono mantenute in una
+serie di variabili contenute in una apposita struttura interna che viene
+definita in \file{resolv.h} ed è utilizzata come variabile globale, così che
+anche un programma vi può accedure una volta che essa sia stata opportunamente
+dichiarata come: \includecodesnip{listati/resolv_option.c}
+
+Tutti i campi della struttura sono ad uso interno, e vengono usualmente
+inizializzati da \func{res\_init} in base al contenuto dei file di
+configurazione e ad una serie di valori di default. L'unico campo che può
+essere utile modificare è \var{\_res.options}, una maschera binaria che
+contiene una serie di bit di opzione che permettono di controllare il
+comportamento del resolver.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Costante} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{RES\_INIT} & viene attivato se è stata chiamata
+ \func{res\_init}. \\
+ \const{RES\_DEBUG} & stampa dei messaggi di debug.\\
+ \const{RES\_AAONLY} & accetta solo risposte autoritative.\\
+ \const{RES\_USEVC} & usa connessioni TCP per contattare i server
+ invece che l'usuale UDP.\\
+ \const{RES\_PRIMARY} & interroga soltanto server DNS primari.
+ \\
+ \const{RES\_IGNTC} & ignora gli errori di troncamento, non ritenta la
+ richiesta con una connessione TCP.\\
+ \const{RES\_RECURSE} & imposta il bit che indica che si desidera
+ eseguire una interrogazione ricorsiva.\\
+ \const{RES\_DEFNAMES} & se attivo \func{res\_search} aggiunge il nome
+ del dominio di default ai nomi singoli (che non
+ contengono cioè un ``\texttt{.}'').\\
+ \const{RES\_STAYOPEN} & usato con \const{RES\_USEVC} per mantenere
+ aperte le connesioni TCP fra interrogazioni
+ diverse. \\
+ \const{RES\_DNSRCH} & se attivo \func{res\_search} esegue le ricerche
+ di nomi di macchine nel dominio corrente o nei
+ domini ad esso sovrastanti.\\
+ \const{RES\_INSECURE1} & blocca i controlli di sicurezza di tipo 1.\\
+ \const{RES\_INSECURE2} & blocca i controlli di sicurezza di tipo 2.\\
+ \const{RES\_NOALIASES} & blocca l'uso della variabile di ambiente
+ \texttt{HOSTALIASES}.\\
+ \const{RES\_USE\_INET6} & restituisce indirizzi IPv6 con
+ \func{gethostbyname}. \\
+ \const{RES\_ROTATE} & ruota la lista dei server DNS dopo ogni
+ interrogazione.\\
+ \const{RES\_NOCHECKNAME}& non controlla i nomi per verificarne la
+ correttezza sintattica. \\
+ \const{RES\_KEEPTSIG} & non elimina i record di tipo \texttt{TSIG}.\\
+ \const{RES\_BLAST} & \\
+ \const{RES\_DEFAULT} & è l'insieme di \const{RES\_RECURSE},
+ \const{RES\_DEFNAMES} e \const{RES\_DNSRCH}.\\
+ \hline
+ \end{tabular}
+ \caption{Costanti utilizzabili come valori per \var{\_res.options}.}
+ \label{tab:resolver_option}
+\end{table}
+
+Per utilizzare questa funzionalità per modificare le impostazioni direttamente
+da programma occorrerà impostare un opportuno valore per questo campo ed
+invocare esplicitamente \func{res\_init}, dopo di che le altre funzioni
+prenderanno le nuove impostazioni. Le costanti che definiscono i vari bit di
+questo campo, ed il relativo significato sono illustrate in
+tab.~\ref{tab:resolver_option}; trattandosi di una maschera binaria un valore
+deve essere espresso con un opportuno OR aritmetico di dette costanti; ad
+esempio il valore di default delle opzioni, epsresso dalla costante
+\const{RES\_DEFAULT}, è definito come:
+\includecodesnip{listati/resolv_option_def.c}
+
+Non tratteremo il significato degli altri campi non essendovi necessità di
+modificarli direttamente; gran parte di essi sono infatti impostati dal
+contenuto dei file di configurazione, mentre le funzionalità controllate da
+alcuni di esse possono essere modificate con l'uso delle opportune variabili
+di ambiente come abbiamo visto per \texttt{LOCALDOMAIN}. In particolare con
+\texttt{RES\_RETRY} si soprassiede il valore del campo \var{retry} che
+controlla quante volte viene ripetuto il tentativo di connettersi ad un server
+DNS prima di dichiarare fallimento; il valore di default è 4, un valore nullo
+significa bloccare l'uso del DNS. Infine con \texttt{RES\_TIMEOUT} si
+soprassiede il valore del campo \var{retrans},\footnote{preimpostato al valore
+ della omonima costante \const{RES\_TIMEOUT} di \file{resolv.h}.} che è il
+valore preso come base (in numero di secondi) per definire la scadenza di una
+richiesta, ciascun tentativo di richiesta fallito viene ripetuto raddoppianto
+il tempo di scadenza per il numero massimo di volte stabilito da
+\texttt{RES\_RETRY}.
+
+La funzione di interrogazione principale è \funcd{res\_query}, che serve ad
+eseguire una richiesta ad un server DNS per un nome a dominio
+\textsl{completamente specificato} (quello che si chiama FQDN, \textit{Fully
+ Qualified Domain Name}); il suo prototipo è:
+
+\begin{functions}
+\headdecl{netinet/in.h}
+\headdecl{arpa/nameser.h}
+\headdecl{resolv.h}
+\funcdecl{int res\_query(const char *dname, int class, int type,
+ unsigned char *answer, int anslen)}
+
+ Esegue una interrogazione al DNS.
+
+\bodydesc{La funzione restituisce un valore positivo pari alla lunghezza dei
+ dati scritti nel buffer \param{answer} in caso di successo e -1 in caso di
+ errore.}
+\end{functions}
+
+La funzione esegue una interrogazione ad un server DNS relativa al nome da
+risolvere passato nella stringa indirizzata da \param{dname}, inoltre deve
+essere specificata la classe di indirizzi in cui eseguire la ricerca con
+\param{class}, ed il tipo di \textit{resource record} che si vuole ottenere
+con \param{type}. Il risultato della ricerca verrà scritto nel buffer di
+lunghezza \param{anslen} puntato da \param{answer} che si sarà opportunamente
+allocato in precedenza.
+
+
+Una seconda funzione di ricerca, analoga a \func{res\_query}, e che prende gli
+stessi argomenti, ma esegue l'interrogazione con le funzionalità addizionali
+previste dalle due opzioni \const{RES\_DEFNAMES} e \const{RES\_DNSRCH}, è
+\funcd{res\_search}, il cui prototipo è:
+\begin{functions}
+\headdecl{netinet/in.h}
+\headdecl{arpa/nameser.h}
+\headdecl{resolv.h}
+\funcdecl{int res\_search(const char *dname, int class, int type,
+ unsigned char *answer, int anslen)}
+
+ Esegue una interrogazione al DNS.
+
+ \bodydesc{La funzione restituisce un valore positivo pari alla lunghezza dei
+ dati scritti nel buffer \param{answer} in caso di successo e -1 in caso di
+ errore.}
+\end{functions}
+
+In sostanza la funzione ripete una serie di chiamate a \func{res\_query}
+aggiungendo opportunamente il dominio di default da cercare nella stinga
+\param{dname}, fermandosi non appena trova un risultato. Il risultato di
+entrambe le funzioni viene scritto nel formato opportuno (che sarà diverso a
+seconda del tipo di record richiesto) nel buffer di ritorno; sarà compito del
+programma (o di altre funzioni) estrarre i relativi dati, esistono una serie
+di funzioni interne usate per la scansione di questi dati, per chi fosse
+interessato una trattazione dettagliata è riportata nel capitolo 14 di
+\cite{DNSbind}.
+
+Le classi di indirizzi supportate da un server DNS sono tre, ma di queste in
+pratica oggi viene utilizzata solo quella degli indirizzi internet; le
+costanti che identificano dette classi come valore per l'argomento
+\param{class} sono riportate in
+tab.~\ref{tab:DNS_address_class}.\footnote{esisteva in realtà anche una classe
+ \const{C\_CSNET} per la omonima rete, ma è stata dichiarata obsoleta.}
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Costante} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{C\_IN} & indirizzi internet, in pratica i soli utilizzati oggi.\\
+ \const{C\_HS} & indirizzi \textit{Hesiod}, utilizzati solo al MIT, oggi
+ completamente estinti. \\
+ \const{C\_CHAOS}& indizzi per la rete \textit{Chaosnet}, un'altra rete
+ sperimentale nata al MIT. \\
+ \const{C\_ANY} & indica un indirizzo di classe qualunque.\\
+ \hline
+ \end{tabular}
+ \caption{Costanti identificative delle classi di indirizzi per l'argomento
+ \param{class} di \func{res\_query}.}
+ \label{tab:DNS_address_class}
+\end{table}
+
+Come accennato le tipologie di dati che sono mantenibili su un DNS sono
+diverse, ed a ciascuna di essa corriponde ad un diverso tipo di
+\textit{resource record}; l'elenco dei valori possibili\footnote{come
+ ottenibile dai file di dichiarazione \file{arpa/nameser.h} e
+ \file{arpa/nameser_compat.h}.} che si possono indicare per l'argomento
+\param{type} è riportato in tab.~\ref{tab:DNS_record_type}; le costanti (tolto
+il \texttt{T\_} iniziale) usano gli stessi valori usati per identificare i
+record nei file di zona di BIND, e che normalmente sono anche usati come
+\textsl{nomi} per indicare i record.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Costante} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{T\_A} & indirizzo di una stazione.\\
+ \const{T\_NS} & server DNS autoritativo per il dominio richiesto.\\
+ \const{T\_MD} & destinazione per la posta elettronica.\\
+ \const{T\_MF} & redistributore per la posta elettronica.\\
+ \const{T\_CNAME} & nome canonico.\\
+ \const{T\_SOA} & inzio di una zona di autorità.\\
+ \const{T\_MB} & nome a dominio di una casella di posta.\\
+ \const{T\_MG} & nome di un membro di un gruppo di posta.\\
+ \const{T\_MR} & nome di un cambiamento di nome per la posta.\\
+ \const{T\_NULL} & record nullo.\\
+ \const{T\_WKS} & servizio noto.\\
+ \const{T\_PTR} & risoluzione inversa di un indirizzo numerico.\\
+ \const{T\_HINFO} & informazione sulla stazione.\\
+ \const{T\_MINFO} & informazione sulla casella di posta.\\
+ \const{T\_MX} & server cui instradare la posta per il dominio.\\
+ \const{T\_TXT} & stringhe di testo (libere).\\
+ \const{T\_RP} & nome di un responsabile (\textit{responsible person}).\\
+ \const{T\_AFSDB} & database per una cella AFS.\\
+ \const{T\_X25} & indirizzo di chiamata per X.25.\\
+ \const{T\_ISDN} & indirizzo di chiamata per ISDN.\\
+ \const{T\_RT} & router.\\
+ \const{T\_NSAP} & indirizzo NSAP.\\
+ \const{T\_NSAP\_PTR}& risoluzione inversa per NSAP (deprecato).\\
+ \const{T\_SIG} & firma digitale di sicurezza.\\
+ \const{T\_KEY} & chiave per firma.\\
+ \const{T\_PX} & corrispondenza per la posta X.400.\\
+ \const{T\_GPOS} & posizione grografica.\\
+ \const{T\_AAAA} & indirizzo IPv6.\\
+ \const{T\_LOC} & informazione di collocazione.\\
+ \const{T\_NXT} & dominio successivo.\\
+ \const{T\_EID} & identificatore di punto conclusivo.\\
+ \const{T\_NIMLOC}& posizionatore \textit{nimrod}.\\
+ \const{T\_SRV} & servizio.\\
+ \const{T\_ATMA} & indirizzo ATM.\\
+ \const{T\_NAPTR} & puntatore ad una \textit{naming authority} .\\
+ \const{T\_TSIG} & firma di transazione.\\
+ \const{T\_IXFR} & trasferimento di zona incrementale.\\
+ \const{T\_AXFR} & trasferimenzo di zona di autorità.\\
+ \const{T\_MAILB} & trasferimento di record di caselle di posta.\\
+ \const{T\_MAILA} & trasferimetno di record di server di posta.\\
+ \const{T\_ANY} & valore generico.\\
+ \hline
+ \end{tabular}
+ \caption{Costanti identificative del tipo di record per l'argomento
+ \param{type} di \func{res\_query}.}
+ \label{tab:DNS_record_type}
+\end{table}
+
+
+L'elenco di tab.~\ref{tab:DNS_record_type} è quello di \textsl{tutti} i
+\textit{resource record} definiti, con una breve descrizione del relativo
+significato. Di tutti questi però viene impiegato correntemente solo un
+piccolo sottoinsieme, alcuni sono obsoleti ed altri fanno riferimento a dati
+applicativi che non ci interessano, pertanto non entreremo nei dettagli del
+significato di tutti quanti, ma solo di quelli usati dalle funzioni del
+\textit{resolver}, che sono sostanzialmente i seguenti:
+\begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
+\item[\texttt{A}] per indicare la corripondenza fra un nome a dominio ed un
+ indirizzo IPv4, ad esempio la corrispondenza fra \texttt{dodds.truelite.it}
+ e l'indirizzo IP \texttt{62.48.34.25}.
+\item[\texttt{AAAA}] per indicare la corrispondenza fra un nome a dominio ed
+ un indirizzo IPv6; è chiamato in questo modo dato che la dimensione di un
+ indirizzo IPv6 è quattro volte quella di un indirizzo IPv4.
+\item[\texttt{PTR}] per provvedere la mappatura inversa fra un indirizzo IP ed
+ un nome a dominio si utilizza questo tipo di record (il cui nome sta per
+ \textit{pointer}).
+\item[\texttt{CNAME}] qualora si abbiamo più nomi che corrispondono allo
+ stesso indirizzo (come ad esempio \texttt{www.truelite.it}, o
+ \texttt{sources.truelite.it}, che fanno sempre riferimento a
+ \texttt{dodds.truelite.it}) si può usare questo tipo di record per creare
+ degli \textit{alias} in modo da associare un qualunque altro nome al
+ \textsl{nome canonico} della macchina (quello associato al record
+ \texttt{A}).
+\end{basedescript}
+
+Come accennato in caso di successo le due funzioni di richiesta restituiscono
+il risultato della interrogazione al server, in caso di insuccesso l'errore
+invece viene segnalato da un valore di ritorno pari a -1, ma in questo caso, a
+differenza delle funzioni viste finora, non può essere utilizzata la variabile
+\var{errno} per riportare un codice di errore, in quanto questo viene
+impostato per ciascuna delle chiamate al sistema utilizzate, e può non avere
+nessun significato nell'indicare quale parte del procedimento di risoluzione è
+fallita.
+
+Per questo motivo all'interno del resolver è stata definita una apposita
+variabile di errore, \var{h\_errno} che viene utilizzata dalle funzioni del
+resolver per indicare quale problema ha causato il fallimento della
+risoluzione del nome. Ad essa si può accedere una volta che la si dichiara
+con:
+\includecodesnip{listati/herrno.c}
+ed i valori che può assumere sono riportati in tab.~\ref{tab:h_errno_values}.
+
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{10cm}|}
+ \hline
+ \textbf{Costante} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{HOST\_NOT\_FOUND} & l'indirizzo richiesto non è valido e la
+ macchina indicata è sconosciuta. \\
+ \const{NO\_ADDRESS} & il nome a dominio richiesto è valido, ma non ha
+ un indirizzo associato ad esso
+ (alternativamente può essere indicato come
+ \const{NO\_DATA}). \\
+ \const{NO\_RECOVERY} & si è avuto un errore non recuperabile
+ nell'interrogazione di un server DNS. \\
+ \const{TRY\_AGAIN} & si è avuto un errore temporaneo
+ nell'interrogazione di un server DNS, si può
+ ritentare l'interrogazione in un secondo
+ tempo. \\
+ \hline
+ \end{tabular}
+ \caption{Valori possibili della variabile \var{h\_errno}.}
+ \label{tab:h_errno_values}
+\end{table}
+
+
+Insieme alla nuova variabile vengono definite anche due nuove funzioni per
+stampare l'errore a video, analoghe a quelle di sez.~\ref{sec:sys_strerror},
+ma che usano il valore di \var{h\_errno}; la prima è \funcd{herror} ed il suo
+prototipo è:
+\begin{functions}
+\headdecl{netdb.h}
+\funcdecl{void herror(const char *string)}
+
+Stampa un errore di risoluzione.
+\end{functions}
+
+La funzione è l'analoga di \func{perror} e stampa sullo standard error un
+messaggio di errore corrispondente al valore corrente di \var{h\_errno}, a cui
+viene anteposta la stringa \param{string} passata come argomento. La seconda
+funzione è \funcd{hstrerror} ed il suo prototipo è:
+\begin{functions}
+\headdecl{netdb.h}
+\funcdecl{const char *hstrerror(int err)}
+
+Restituisce una stringa corripondente ad un errore di risoluzione.
+\end{functions}
+\noindent e come per l'analoga \func{strerror} restituise una stringa con un
+messaggio di errore già formattato corrispondente al codice passato come
+argomento (che si presume sia dato da \var{h\_errno}).
+
+
+
+
+\subsection{La risoluzione dei nomi a dominio}
+\label{sec:sock_gethostbyname}
+
+La principale funzionalità del \textit{resolver} resta quella di risolvere i
+nomi a dominio in indirizzi IP, per cui non ci dedicheremo oltre alle funzioni
+di richiesta generica ed esamineremo invece le funzioni a questo dedicate. La
+prima funzione è \funcd{gethostbyname} il cui scopo è ottenere l'indirizzo di
+una stazione noto il suo nome a dominio, il suo prototipo è:
+\begin{prototype}{netdb.h}
+{struct hostent *gethostbyname(const char *name)}
+
+Determina l'indirizzo associato al nome a dominio \param{name}.
+
+\bodydesc{La funzione restituisce in caso di successo il puntatore ad una
+ struttura di tipo \struct{hostent} contente i dati associati al nome a
+ dominio o un puntatore nullo in caso di errore.}
+\end{prototype}
+
+La funzione prende come argomento una stringa \param{name} contenente il nome
+a dominio che si vuole risolvere, in caso di successo i dati ad esso relativi
+vengono memorizzati in una opportuna struttura \struct{hostent} la cui
+definizione è riportata in fig.~\ref{fig:sock_hostent_struct}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includestruct{listati/hostent.h}
+ \end{minipage}
+ \caption{La struttura \structd{hostent}.}
+ \label{fig:sock_hostent_struct}
+\end{figure}
+
+Quando un programma chiama \func{gethostbyname} e questa usa il DNS per
+effettuare la risoluzione del nome, è con i valori contenuti nei relativi
+record che vengono riempite le varie parti della struttura \struct{hostent}.
+Il primo campo della struttura, \var{h\_name} contiene sempre il \textsl{nome
+ canonico}, che nel caso del DNS è appunto il nome associato ad un record
+\texttt{A}. Il secondo campo della struttura, \var{h\_aliases}, invece è un
+puntatore ad vettore di puntatori, terminato da un puntatore nullo. Ciascun
+puntatore del vettore punta ad una stringa contenente uno degli altri
+possibili nomi associati allo stesso \textsl{nome canonico} (quelli che nel
+DNS vengono inseriti come record di tipo \texttt{CNAME}).
+
+Il terzo campo della struttura, \var{h\_addrtype}, indica il tipo di indirizzo
+che è stato restituito, e può assumere soltanto i valori \const{AF\_INET} o
+\const{AF\_INET6}, mentre il quarto campo, \var{h\_length}, indica la
+lunghezza dell'indirizzo stesso in byte.
+
+Infine il campo \var{h\_addr\_list} è il puntatore ad un vettore di puntatori
+ai singoli indirizzi; il vettore è terminato da un puntatore nullo. Inoltre,
+come illustrato in fig.~\ref{fig:sock_hostent_struct}, viene definito il campo
+\var{h\_addr} come sinonimo di \code{h\_addr\_list[0]}, cioè un riferimento
+diretto al primo indirizzo della lista.
+
+Oltre ai normali nomi a dominio la funzione accetta come argomento
+\param{name} anche indirizzi numerici, in formato dotted decimal per IPv4 o
+con la notazione illustrata in sez.~\ref{sec:IP_ipv6_notation}. In tal caso
+\func{gethostbyname} non eseguirà nessuna interrogazione remota, ma si
+limiterà a copiare la stringa nel campo \var{h\_name} ed a creare la
+corrispondente struttura \var{in\_addr} da indirizzara con
+\code{h\_addr\_list[0]}.
+
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/myhost.c}
+ \end{minipage}
+ \normalsize
+ \caption{Esempio di codice per la risoluzione di un indirizzo.}
+ \label{fig:myhost_example}
+\end{figure}
+
+Vediamo allora un primo esempio dell'uso di queste funzioni, in
+fig.~\ref{fig:myhost_example} è riportato un estratto del codice di un
+programma che esegue una semplice interrogazione al resolver usando
+\func{gethostbyname} e stampa a video i risultati. Al solito il sorgente
+completo, he comprende il trattamento delle opzioni ed una funzione per
+stampare un messaggio di aiuto, è nel file \texttt{myhost.c} dei sorgenti
+allegati alla guida.
+
+
+
+Con l'uso di \func{gethostbyname} normalmente si ottengono solo gli indirizzi
+IPv4, se si vogliono ottenere degli indirizzi IPv6 occorrerà prima impostare
+l'opzione \const{RES\_USE\_INET6} nel campo \texttt{\_res.options} e chiamare
+\func{res\_init} (vedi sez.~\ref{sec:sock_resolver_functions}) per modificare
+le opzioni del resolver; dato che questo non è molto comodo è stata definita
+un'altra funzione, \funcd{gethostbyname2}, il cui prototipo è:
+\begin{prototype}{netdb.h}
+{struct hostent *gethostbyname2(const char *name, int af)}
+
+Determina l'indirizzo di tipo \param{af} associato al nome a dominio
+\param{name}.
+
+\bodydesc{La funzione restituisce in caso di successo il puntatore ad una
+ struttura di tipo \struct{hostent} contente i dati associati al nome a
+ dominio o un puntatore nullo in caso di errore.}
+\end{prototype}
+
+
+In questo caso la funzione prende un secondo argomento \param{af} che indica
+la famiglia di indirizzi da usare come
projects / gapil.git / blobdiff