Altra roba, res_query.
[gapil.git] / sockctrl.tex
index 7a7d12fd6c7ad7e8efb9f6fd6df074f9b259df5b..62989d4a2deaa2922461f33ff4c9e966f0a82500 100644 (file)
@@ -37,10 +37,14 @@ propriet
 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}. 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.
+  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
@@ -111,21 +115,22 @@ dell'ordine in cui questi vengono interrogati.\footnote{con le implementazioni
   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 il sistema del \textit{resolver} è
-stato incluso 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}.
+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
@@ -170,13 +175,12 @@ 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.
 
-Ciascun 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, che per ciascuno di essi sarà realizzata in
-un file \texttt{libnss\_NAME} dove \texttt{NAME} è appunto il nome 
-
-
-
+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
@@ -188,6 +192,184 @@ disposizione,\footnote{
 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, la manutenzione dei dati è mantenuta in tanti server
+distinti ciascuno dei quali si occupa della risoluzione del proprio
+\textsl{dominio}; i nomi a dominio sono poi organizzati in una struttura ad
+albero analoga a quella dell'albero dei file in un sistema unix-like, 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. 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 contiene comunque una serie di altre informazioni;
+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 ottenibili da un server DNS è
+un'altro dei motivi per cui il \textit{resolver} prevede un insieme di
+funzioni dedicato rispetto a quelle della semplice risoluzione dei nomi; la
+prima di queste è \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 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. In genere si deve eseguire questa funzione prima di
+chiamare tutte le altre. 
+
+Le impostazioni del resolver e lo stato del sistema vengono mantenute in una
+serie di variabili globali contenuti in una apposita struttura interna,
+definita in \file{resolv.h}, che può essere acceduta una volta che la si
+dichiara con:
+\includecodesnip{listati/resolv_option.c}
+
+Tutti i campi della struttura sono ad uso interno, l'unico che può essere
+utile modificare è il campo \var{\_res.options}, che è una maschera binaria
+che permette di controllare il comportamento del resolver, modificandone
+alcune impostazioni direttamente da programma prima di invocare
+\func{res\_init}. Le costanti che definiscono i vari bit di questo campo, con
+il relativo significato sono illustrate in tab.~\ref{tab:resolver_option}, un
+valore deve essere espresso con un opportuno OR aritmetico di dette costanti;
+ad esempio il valore di default dato dalla costante \const{RES\_DEFAULT} è 
+definito come: 
+\includecodesnip{listati/resolv_option_def.c}
+
+\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}
+
+La funzione di richiesta principale è \funcd{res\_query}, che serve ad
+eseguire una richiesta ad un server DNS per un nome a dominio 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 0 in caso di successo e -1 in caso di
+  errore.}
+\end{functions}
+
+
+Per quanto ci interessa i tipi di \textit{resource record} che vengono
+utilizzati dal \textit{resolver} sono sostanzialmente i seguenti:
+\begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
+\item[\texttt{A}] indica 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}] chiamato in questo modo dato che la dimensione è quattro
+  volte quella di un indirizzo IPv4, questo record contiene la corrispondenza
+  fra un nome a dominio ed un indirizzo IPv6.
+\item[\texttt{PTR}] per provvedere la mappatura inversa fra un indirizzo IP ed
+  un nome a dominio si utilizza invece questo tipo di record (il cui nome sta
+  per \textit{pointer}).
+\item[\texttt{CNAME}] qualora si abbiamo più nomi con i quali si voglia
+  indicare lo stesso indirizzo (ad esempio \texttt{www.truelite.it}, o
+  \texttt{sources.truelite.it}, che comunque fanno sempre riferimento alla
+  macchina \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}
+
+
+
+
+
+
+Per questo motivo il \textit{resolver} prevede delle funzioni che permettono
+sia di eseguire direttamente delle interrogazione ad un server DNS, che di
+controllare le modalità con cui queste vengono eseguite; diventa così
+possibile modificare da programma buona parte dei parametri controllati da
+\file{/etc/resolv.conf}.
+
+
 
 \subsection{La risoluzione dei nomi a dominio}
 \label{sec:sock_gethostbyname}
@@ -246,35 +428,6 @@ ed i valori che pu
   di un server DNS, si può ritentare l'interrogazione in un secondo tempo. 
 \end{basedescript}
 
-Per capire meglio il contenuto della struttura \struct{hostent} conviene
-spendere alcune parole sul funzionamento del DNS. Questo in sostanza è un
-database distribuito organizzato in maniera gerarchica, interrogando il quale
-si possono avere una serie di informazioni, la principale delle quali è la
-corrispondenza fra un nome (a dominio) ed indirizzo IP.  Un server DNS
-contiene comunque una serie di altre informazioni; ciascuna voce nel database
-viene chiamata \textit{resource record} e vi è associato un certo
-\textsl{tipo}, identificato da una sigla.  Per quanto ci interessa i tipi di
-\textit{resource record} che vengono utilizzati dal \textit{resolver} sono
-sostanzialmente i seguenti:
-\begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
-\item[\texttt{A}] indica 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}] chiamato in questo modo dato che la dimensione è quattro
-  volte quella di un indirizzo IPv4, questo record contiene la corrispondenza
-  fra un nome a dominio ed un indirizzo IPv6.
-\item[\texttt{PTR}] per provvedere la mappatura inversa fra un indirizzo IP ed
-  un nome a dominio si utilizza invece questo tipo di record (il cui nome sta
-  per \textit{pointer}).
-\item[\texttt{CNAME}] qualora si abbiamo più nomi con i quali si voglia
-  indicare lo stesso indirizzo (ad esempio \texttt{www.truelite.it}, o
-  \texttt{sources.truelite.it}, che comunque fanno sempre riferimento alla
-  macchina \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}
-
 Quando un programma chiama \func{gethostbyname} e questa usa il DNS per
 effettuare la risoluzione del nome, è con i valori di questi record che
 vengono riempite le varie parti della struttura \struct{hostent}. Il primo
@@ -289,14 +442,14 @@ 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.
-
-
+lunghezza dell'indirizzo stesso in byte. La funzione ritorna sempre una
+struttura 
+
+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