%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%                       Legal Notice                            %
%                                                               %
% This document is copyright by Olaf Kirch, okir@monad.swb.de   %
%                                                               %
% For copying conditions, please refer to the file COPYING.     %
%                                                               %
% The author is not liable for any damages, direct or indirect, %
% resulting from the use of information provided in this        %
% document.                                                     %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% When viewing this document with vi on an 80-columns screen,   %
% do a ':se nonumber' first.                                    %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Traduccion realizada por Juan Jose Amor
% Envie sus comentarios a:
%       jjamor@ls.fi.upm.es (INTERNET)
%       2:341/12.19         (FIDONET)
%
% Revisado en 7-Febrero-1999 por:
%   Juan Jose Amor <jjamor@ls.fi.upm.es>
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Cuestiones sobre redes TCP/IP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% TCP/IP networking                                             %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip}
\index{TCP/IP|(}

Vamos a entrar en los detalles que deben tenerse en cuenta cuando se
conecta una m\'aquina \linux{} a una red TCP/IP. De este modo,
hablaremos de direcciones~IP, nombres y cuestiones sobre el
encaminamiento. Este cap\'{\i}tulo le ense\~nar\'a la base con la que podr\'a
entender los pasos para su configuraci\'on particular, pasos que son
cubiertos exhaustivamente en otros cap\'{\i}tulos.



 
\section{Interfaces de Red}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.interfaces}
\index{hardware de acceso a la red|see {interfaz}}
\index{red!interfaz|see {interfaz}}
\index{interfaz}

Para ocultar la diversidad de hardware que puede usarse en una red,
TCP/IP define una \emph{interfaz} a trav\'es de la cual accedemos al
hardware. Esta interfaz ofrece un conjunto de operaciones id\'enticas en
cualquier tipo de hardware y que b\'asicamente consisten en operaciones
para enviar y recibir paquetes.


Para cada dispositivo que quiera utilizarse para conectarse a la red, se
mantendr\'a en el n\'ucleo del sistema la correspondiente interfaz. Por
ejemplo, las interfaces con Ethernet en \linux{} son \file{eth0} y
\file{eth1}, mientras que las interfaces SLIP se llaman \file{sl0},
\file{sl1}, etc\'etera. Estos nombres de interfaz se deben conocer
durante la configuraci\'on de la red, cuando queramos referirnos a un
dispositivo hardware concreto.


Para que podamos usarlo en una red TCP/IP, la interfaz deber\'a tener
asignada una direcci\'on~IP que sirva como identificaci\'on de \'esta ante
los dem\'as ordenadores de la red. Esta direcci\'on es diferente del
nombre de interfaz considerado anteriormente; puede realizarse la siguiente
analog\'{\i}a: la interfaz ser\'{\i}a la ``puerta'' de su sistema, mientras que
la direcci\'on vendr\'{\i}a a ser un n\'umero enmarcado y colgado de la ``puerta''.


Por supuesto, hay otros par\'ametros configurables para cada
dispositivo, como el n\'umero m\'aximo de datagramas que pueden ser
procesados por el dispositivo, conocido como \emph{Unidad M\'axima de
Transferencia} o MTU\footnote{N. del T.: MTU son las siglas de
``Maximum Transfer Unit''.}. Otros par\'ametros ser\'an introducidos m\'as tarde.


\section{Direcciones IP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.ip-addresses}
\index{IP!redes}
\index{IP!direcci\'on|(}

Como se dijo en el cap\'{\i}tulo anterior, las direcciones utilizadas en el
protocolo de red~IP la forman n\'umeros de 32 bits, y cada m\'aquina debe
tener una direcci\'on propia. Si las m\'aquinas se encuentran en una red
TCP/IP que no se conecta a otras redes, dichas direcciones podr\'an
asignarse a las m\'aquinas librememente. Sin embargo, si las m\'aquinas se
conectan a Internet, las direcciones de los ordenadores ser\'an
asignadas por una autoridad principal, el NIC\footnote{N. del T.:
Network Information Center} o Centro de Informaci\'on
de la Red\footnote{Frecuentemente, las direcciones~IP le ser\'an
asignadas directamente por el proveedor que le conecte a la red. No
obstante, se puede contactar directamente con el NIC para obtener
direcciones, escribiendo a \email{hostmaster@internic.net}.}.


\index{Puntos divisorios}
Para facilitar la lectura, las direcciones IP se dividen en cuatro
n\'umeros de 8~bits llamados \emph{octetos}. Por ejemplo, si la m\'aquina
\host{quark.physics.groucho.edu} tiene una direcci\'on~IP
\host{0x954C0C04}, normalmente la escribiremos con la notaci\'on de
puntos divisorios, que separa los octetos, de esta forma: \host{149.76.12.4}.


Otra raz\'on para usar esta notaci\'on es que las direcciones~IP se pueden
dividir en el n\'umero de \emph{red} y el n\'umero de \emph{nodo}. Cuando
pedimos al NIC un conjunto de direcciones, este organismo nos
conceder\'a, no una direcci\'on para nuestra m\'aquina, sino un rango de
direcciones v\'alidas, que en realidad es un n\'umero de red concreto (el
n\'umero de nodo lo pondremos nosotros, contando con todos esos nodos
disponibles).


Dependiendo del tama\~no de la red, la parte de la direcci\'on
correspondiente al nodo puede ser m\'as o menos grande. Para adaptarse a
diferentes necesidades, se conceden diferentes {\it clases} de redes,
que definen diferentes maneras de dividir la direcci\'on~IP en parte de
red y parte del nodo.


\begin{dispitems}
\ditem[Clase A]
	La clase A comprende redes desde \host{1.0.0.0} hasta
\host{127.0.0.0}. El n\'umero de red est\'a en el primer octeto, con lo
que solo hay 127 redes de este tipo, pero cada una tiene 24~bits
disponibles para identificar a los nodos, lo que se corresponde con
poder distinguir en la red unos 16 millones de nodos distintos.

\ditem[Clase B]
	La clase B comprende redes desde \host{128.0.0.0} hasta
\host{191.255.0.0}; siendo el n\'umero de red de 16 bits (los dos
primeros octetos). Esto permite 16320 redes de 65024 nodos cada una.

\ditem[Clase C]
	Las redes de clase C tienen el rango de direcciones desde
\host{192.0.0.0} hasta \host{223.255.255.0}, contando con tres octetos
para identificar la red. Por lo tanto, hay cerca de 2~millones de
redes de este tipo con un m\'aximo de 254 nodos cada una.

\ditem[Clases D, E, y F]
	Comprenden las direcciones entre \host{224.0.0.0} y
\host{254.0.0.0}, y est\'an reservadas para uso futuro, o con fines
experimentales\footnote{Por ejemplo, se está utilizando la
red 224.0.0.0 para la Internet multidestino o {\it multicast}}.
No especifican, pues, ninguna red de Internet.

\end{dispitems}


Volviendo al ejemplo del cap\'{\i}tulo anterior, veremos que en la direcci\'on
\host{149.76.12.4} de la m\'aquina \host{quark}, \host{12.4} es el
identificativo del nodo dentro de la red de clase B \host{149.76.0.0}.


\index{direcci\'on!broadcast}
Se puede observar que en la lista anterior no se consideraban todas
las posibilidades en la parte que identifica al nodo; concretamente,
se exclu\'{\i}an siempre el identificador \host{0} y el \host{255}. Estos
dos identificadores se reservan para prop\'ositos especiales. Una direcci\'on
con los bits del nodo a cero identifica a la red, mientras que si
tiene todos los bits a uno, identifica a todos los nodos de la red (lo
que se conoce como direcci\'on de {\it broadcast}, lo que indica que un
mensaje enviado a esa direcci\'on ser\'a procesado por todos los nodos
de la red). As\'{\i} pues, en nuestro ejemplo la direcci\'on de la red ser\'{\i}a
\host{149.76.0.0} y la de {\it broadcast}, la \host{149.76.255.255}.


\index{IP!encaminamiento por defecto}
\index{encaminamiento IP por defecto|see {encaminamiento, defecto}}
\index{encaminamiento, defecto}
\index{loopback!direcci\'on}
Adem\'as, otras dos direcciones de red est\'an reservadas: la
\host{0.0.0.0} y la \host{127.0.0.0}. La primera se conoce como
direcci\'on de \emph{encaminamiento por defecto}, y la segunda, como
\emph{direcci\'on de loopback}. El encaminamiento por defecto se utiliza
para saber a d\'onde enviar los datagramas por defecto, tema que
abordaremos despu\'es.


La red \host{127.0.0.0} se reserva para el tr\'afico local,
dirigido al propio nodo. Normalmente, se asigna la direcci\'on
\host{127.0.0.1} a un dispositivo de la m\'aquina llamado \emph{interfaz
de loopback}\footnote{N. del T.: También conocida como {\it interfaz de lazo}}
o de circuito cerrado. Cualquier paquete enviado a esa
direcci\'on ser\'a recibido por el propio nodo. Esto permite probar
aplicaciones de red con uno mismo, sin estar conectado a una red
``real''. Otra aplicaci\'on \'util es la de ejecutar aplicaciones de red
que afectan s\'olo al nodo local. Por ejemplo, muchos sistemas UUCP no
tienen conexi\'on IP pero ejecutan un sistema de noticias INN. Para que
esto funcione, INN utiliza la interfaz de loopback.


\index{IP!direcci\'on|)}


\section{Resoluci\'on de direcciones}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.arp}
\index{Protocolo de resoluci\'on de direcciones|see {ARP}}
\index{Protocolo de resoluci\'on inversa|see {RARP}}
\index{ARP|(}
\index{Ethernet!direcci\'on}

Ahora que conocemos qu\'e son las direcciones~IP, nos preguntaremos c\'omo
se utilizan en una red Ethernet. Despu\'es de todo, el protocolo Ethernet usa
direcciones identificativas de seis octetos que no tienen que ver
con los n\'umeros~IP.


\index{radio paquetes}
En efecto, se necesita un mecanismo de traducci\'on de direcciones~IP a
direcciones Ethernet o f\'{\i}sicas. Esto se hace con el \emph{Protocolo de
Resoluci\'on de Direcciones} o ARP\footnote{
N. del T.: Address Resolution Protocol}. ARP no se limita a las redes
Ethernet, sino que se extiende a otros tipos de redes como las de
radio paquetes. La idea es la misma que tendr\'{\i}amos para localizar al
se\~nor X entre 150 personas: preguntar por su nombre a todo el mundo; y
el se\~nor X nos responder\'a.

Cuando queremos localizar la direcci\'on f\'{\i}sica correspondiente a una
direcci\'on~IP, haremos uso de una caracter\'{\i}stica de la red Ethernet, que
es la posibilidad de enviar mensajes a escuchar por todos los nodos, o
mensajes {\it broadcast}. En el mensaje ARP, que es de este tipo, se
incluye la direcci\'on~IP cuyo propietario estamos buscando. El nodo que
posea esa direcci\'on enviar\'a una respuesta ARP al nodo llamante,
con su direcci\'on f\'{\i}sica.


Por supuesto, le preocupar\'a saber c\'omo puede funcionar esto para
localizar un nodo entre millones de Ethernets conectadas en el
mundo. Esto se trata en la pr\'oxima secci\'on: se trata del encaminamiento.


Sigamos hablando, de momento, sobre ARP. Una vez que se conoce la
direcci\'on f\'{\i}sica del nodo, el que hizo la petici\'on guardar\'a la
informaci\'on obtenida en una {\it cache ARP}, para as\'{\i} no preguntar por
lo mismo cada vez que env\'{\i}e un paquete a ese nodo. Sin embargo, no
podemos guardar esa direcci\'on para siempre ya que puede perder su
validez (por ejemplo, si cambiamos la tarjeta de red a los nodos por
aver\'{\i}a, sus nuevas direcciones f\'{\i}sicas ser\'an distintas). Por ello,
cada cierto tiempo, lo que hay en la cache ARP pierde su validez,
obligando a realizar de nuevo la pregunta ARP.


\index{clientes sin discos}
\index{BOOTP}
\index{RARP}
A veces, un nodo necesita tambi\'en conocer su direcci\'on~IP a partir de
su direcci\'on f\'{\i}sica. Por ejemplo, en terminales~X o PCs sin disco, que
cuando arrancan solo saben la direcci\'on de su tarjeta pues est\'a
grabada en memoria no vol\'atil. Para ello, se usa el {\it Protocolo de
Resoluci\'on Inversa de Direcciones} o RARP\footnote{N. del T.: Reverse
Address Resolution Protocol}: la petici\'on RARP la hace el nodo cuando
arranca, mediante mensaje {\it broadcast}, y es contestado por un
servidor de direcciones que, a partir de la direcci\'on f\'{\i}sica, consulta
su base de datos y conoce la direcci\'on~IP correspondiente. Existe
adem\'as otro protocolo, el BOOTP o {\it protocolo de arranque}\footnote{
N. del T.: Del inglés {\it Boot Protocol}}, que permite a
las m\'aquinas sin disco conocer c\'omo ponerse en marcha en la red.


\index{ARP|)}

\section{Encaminamiento IP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.routing}
\index{IP!encaminamiento|(}

\subsection{Redes IP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.routing.networks}
\index{IP!redes}

\blackdiamond
Cuando escribimos una carta a alguien, normalmente incluimos la
direcci\'on completa en el sobre: pa\'{\i}s, provincia, c\'odigo postal,
etc. De este modo el servicio de correos podr\'a llevar la carta a su
destino: un servicio la enviar\'a al del pa\'{\i}s que corresponda, y \'este
\'ultimo la entregar\'a al de la provincia o ciudad de destino. La ventaja
de este esquema jer\'arquico es que el servicio postal del remitente
apenas tiene que saber acerca del destino final, sino solo a qu\'e pa\'{\i}s
entregarla.


Las redes~IP se organizan de manera similar. Internet consta de
varias redes, conocidas como \emph{sistemas aut\'onomos} y cada una
realiza por su cuenta el encaminamiento interno entre sus nodos
miembro. Cuando un paquete tiene como destino un nodo de otra red, se
entregar\'a al encaminador correspondiente, sin preocuparse del destino
final del paquete.


\subsection{Subredes}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.routing.subnets}
\index{IP!sub-redes|see {IP, subred}}
\index{IP!subred|(}

La estructura de subredes se obtiene al dividir las direcciones~IP en
parte del nodo y parte de la red, como ya hemos explicado. Por
defecto, la red de destino se deriva de la parte de red de la
direcci\'on~IP. Es decir, los nodos con la misma direcci\'on de red se
encontrar\'an en la misma red TCP/IP\footnote{Los sistemas aut\'onomos son
algo m\'as generales. Pueden tener m\'as de una red~IP.}.

Pero en una red puede interesar hacer una divisi\'on en cientos de
peque\~nas redes, por ejemplo segmentos de Ethernet. Para ello se
subdivide la red en \emph{subredes}.


\index{interfaz!m\'ascara de red}
\index{IP!m\'ascara de red}
Una subred tiene la responsabilidad de la entrega de los datagramas a
un determinado rango de direcciones~IP de la red en la que se
encuentra. Como sucede con las clases A, B o C, se identifica en la
parte del n\'umero~IP correspondiente a la red. Sin embargo, esa parte
incluir\'a ahora algunos bits de la parte del nodo. Los bits que se
interpretan como direcci\'on de subred se obtienen con la llamada
\emph{m\'ascara de red}. Es un n\'umero de 32 bits que especifica una
m\'ascara para identificar los bits de la subred.


\begin{figure}[htbp]
\iftex
 \ifps
  \begin{center}
   \mbox{\epsffile{figures/subnet.epsf}}
  \end{center}
 \else
  \begin{center}
   \input{subnet.eepic}
  \end{center}
 \fi
\else
\fi
 \caption{
  \label{tcpip.fig.subnet}
  Divisi\'on de una red clase B en subredes
 }
\end{figure}


\index{Groucho Marx University}
La red del campus de la Universidad de Groucho Marx es un ejemplo de
red de clase B, poseedora de la red \host{149.76.0.0}, con 
m\'ascara \host{255.255.0.0}.
% It is connected to the Internet
% through a single host at the GCC Groucho Computing Centre, so all
% datagram from the outside pass this gateway machine.

Internamente, la red de la UGM se divide en peque\~nas subredes, como
las LAN de cada departamento. Concretamente se divide en 254 subredes,
desde la \host{149.76.1.0} hasta la \host{149.76.254.0}. Por ejemplo,
el Departamento de F\'{\i}sica Te\'orica tendr\'a asignada la subred
\host{149.76.12.0}. La dorsal del campus es en s\'{\i} mismo una subred, la
\host{149.76.1.0}. Las subredes comparten el m\'{\i}smo n\'umero de red, pero
se usa el tercer octeto de \'esta para distinguir las distintas
subredes. Por lo tanto, tendr\'an una m\'ascara de subred igual a
\host{255.255.255.0}.


En la figura~\ref{tcpip.fig.subnet} se muestra c\'omo el nodo
\host{quark} (\host{149.76.12.4}) se ve de distinta forma seg\'un se vea
desde el punto de vista de la red de clase B, o desde el punto de
vista de las subredes.



\index{delegaci\'on!subredes IP}
\index{subred (IP)}
Nótese que la divisi\'on en subredes es visible s\'olo internamente
a la red. Normalmente las organiza el administrador de red para
reflejar diferentes ubicaciones geogr\'aficas, distinguir segmentos de
red, o bien por motivos administrativos (departamentos, redes de
alumnos, etc). Pero esta divisi\'on es totalmente invisible desde fuera
de la organizaci\'on.

\index{IP!subred|)}

\subsection{Pasarelas}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.routing.gateway}
\index{internetworking}
\index{pasarelas|(}

La organizaci\'on en subredes no solo se hace por motivos
administrativos, tambi\'en es consecuencia de cuestiones del
hardware. Lo que ve un nodo en una red es limitado: s\'olo ve los nodos
con los que directamente est\'e conectado (por ejemplo, en la Ethernet),
mientras que a los dem\'as los accede a trav\'es de lo que se conoce como
\emph{pasarela}\footnote{N. del T.: Del inglés \emph{gateway}}, que no es mas
que un nodo conectado a dos o m\'as redes f\'{\i}sicas, configurado para
pasar paquetes de una red a otra.


Para reconocer si una direcci\'on~IP se encuentra en la red local
f\'{\i}sica, cada LAN debe tener una direcci\'on de red~IP diferente. Por
ejemplo, las m\'aquinas de la (sub)red \host{149.76.4.0} ser\'{\i}an las que
est\'an en la LAN del Departamento de Matem\'aticas. Cuando se env\'{\i}a un
datagrama a la m\'aquina \host{quark}, el software de red de
\host{erdos} ve que su direcci\'on de red es otra (\host{149.76.12.4})
con lo que sabe que tiene que enviar los datagramas a trav\'es de la
pasarela (\host{sophus} por defecto).


\host{sophus} se encuentra conectado a dos subredes: la del
Departamento de Matem\'aticas y la de la dorsal del campus, accediendo a
cada una a trav\'es de una interfaz diferente, respectivamente
\file{eth0} y \file{fddi0}. Nos preguntaremos entonces, qu\'e
direcci\'on~IP debe tener la pasarela, una de la subred de Matem\'aticas o
bien una de la dorsal.


Pues bien, la respuesta es {\it ambas}. Cuando la pasarela comunique
con un nodo de la LAN de Matem\'aticas, usar\'a la direcci\'on
\host{149.76.4.1}, mientras que si lo hace con un nodo de la dorsal,
usar\'a \host{149.76.1.4}.


Es decir, la pasarela tiene tantas direcciones~IP como conexiones a
redes f\'{\i}sicas tenga. En definitiva, \'este ser\'a el esquema de
interfaces, direcciones y m\'ascara de \host{sophus}, nuestra pasarela:

\begin{center}
\begin{tabular}{|l|r|r|}
 \hline
 interfaz               & direcci\'on           & m\'ascara             \\
 \hline\hline
 \file{eth0}    & \host{149.76.4.1}     & \host{255.255.255.0}  \\
 \file{fddi0}   & \host{149.76.1.4}     & \host{255.255.255.0}  \\
 \file{lo}      & \host{127.0.0.1}      & \host{255.0.0.0}      \\
 \hline
\end{tabular}
\end{center}

La \'ultima entrada describe el dispositivo {\it loopback}, que se
coment\'o anteriormente.


En la figura~\ref{intro.fig.ip} se muestra una parte de la topolog\'{\i}a
de la red de la Universidad de Groucho Marx (UGM). Los nodos que est\'an
en dos subredes tendr\'an dos direcciones~IP.

\begin{figure}[htbp]
\iftex
 \ifps
  \begin{center}
   \mbox{\epsffile{figures/groucho.epsf}}
  \end{center}
 \else
  % \font\egttt=cmtt8
  % \font\twltt=cmtt12
  % \font\sevrm=cmr7
  % \font\tenit=cmti10
  \begin{center}
   \input{groucho.eepic}
  \end{center}
 \fi
\else
%% This node includes an ASCII Version of the above GMU picture for texinfo.
 \verbinclude{groucho.ascii}
\fi
 \caption{
  \label{intro.fig.ip}
  Vista parcial de la topolog\'{\i}a de la red de la UGM.
 }
\end{figure}


%Generally, you can ignore the subtle difference between attaching an
%address to a host or its interface. For hosts that are on one network
%only, like \host{erdos}, you would generally refer of the host as
%having this-and-that IP~address although strictly speaking, it's the Ethernet
%interface that has this IP~address. However, this distinction is only
%really important when you refer to a gateway.


% Frequently, this involves splitting an existing subnet even further.
% For example, the Mathemeatics Department runs two Ethernets that are
% joined by the gateway that also provides the link to the FDDI campus
% backbone. To be able to perform routing between these, the network
% \host{149.76.4.0} is subdivided into two sub-subnets of 126 hosts
% each. The netmask for these is \host{255.255.255.128}, and hosts
% on each Ethernet have addresses from the ranges \host{149.76.4.1}
% through \host{149.76.4.127}, and \host{149.76.4.129}
% through \host{149.76.4.254}, respectively.

\index{pasarelas|)}

\subsection{Tablas de Encaminamiento}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.routing.table}
\index{IP!encaminamiento}
\index{IP!tabla de encaminamiento}
\index{IP!route}
\index{encaminamiento!tabla}

Vamos ahora a centrarnos en c\'omo se selecciona una pasarela para
entregar un datagrama a una red remota.


Hemos visto que \host{erdos}, cuando env\'{\i}a un datagrama para
\host{quark}, comprueba que la direcci\'on destino no se encuentra en la
red local, por lo que lo env\'{\i}a a la pasarela, \host{sophus}, quien
b\'asicamente hace lo mismo: ve que \host{quark} no est\'a en una de las
redes a las que se conecta directamente y busca otra pasarela a quien
entregarle el paquete. La elecci\'on correcta es \host{niels}, la
pasarela del Departamento de F\'{\i}sicas. \host{sophus} necesita
informaci\'on para poder tomar estas decisiones.


La informaci\'on de encaminamiento que se usa en IP es b\'asicamente una
tabla donde se relacionan (sub)redes y pasarelas. Adem\'as, debe
incluirse una entrada de encaminamiento por defecto, que se asocia en
la tabla a la red \host{0.0.0.0}. Todos los paquetes que van a una red
desconocida, se enviar\'an a la pasarela del encaminamiento por
defecto. As\'{\i} pues, \'esta ser\'{\i}a la tabla para \host{sophus}:


\begin{center}
 \begin{tabular}{|l|l|l|}
  \hline
  Red                   & Pasarela              & Interfaz      \\
  \hline\hline
  \host{149.76.1.0}     & -                     & \host{fddi0}  \\
  \host{149.76.2.0}     & \host{149.76.1.2}     & \host{fddi0}  \\
  \host{149.76.3.0}     & \host{149.76.1.3}     & \host{fddi0}  \\
  \host{149.76.4.0}     & -                     & \host{eth0}   \\
  \host{149.76.5.0}     & \host{149.76.1.5}     & \host{fddi0}  \\
  \ldots                & \ldots                & \ldots        \\
  \host{0.0.0.0}        & \host{149.76.1.2}     & \host{fddi0}  \\
  \hline
 \end{tabular}
\end{center}


Las rutas a una red a la que \host{sophus} est\'e directamente conectado
no necesitan pasarela, sino que los datagramas se entregan directamente. 
Esto se indica en la tabla anterior cuando en lugar de la
pasarela aparece un ``-''.


\index{IP!encaminamiento din\'amico}
\index{encaminamiento din\'amico}
\index{encaminamiento!demonio}
\index{encaminamiento!din\'amico}
Las tablas de encaminamiento pueden construirse de varias formas. Para
redes peque\~nas, ser\'a m\'as eficiente construirlas a mano usando el
comando \prog{route} de \linux{} (v\'ease el
cap\'{\i}tulo~\ref{iface}). Para redes m\'as grandes, las tablas se mantienen
y modifican autom\'aticamente mediante los \emph{demonios de
encaminamiento}. \'Estos corren en nodos centrales e intercambian
informaci\'on de encaminamiento entre ellos para tener en todo momento
las rutas ``\'optimas'' entre subredes.


\index{IP!protocolos de encaminamiento}
\index{encaminamiento!protocolos}
\index{Protocolo de Informaci\'on de Encaminamiento}
\index{Routing Information Protocol}
\index{RIP|see {Routing Information Protocol}}
\index{routed@\prog{routed}}
\index{gated@\prog{gated}}
Dependiendo del tama\~no de la red, se utilizan distintos protocolos de
encaminamiento. Dentro de los sistemas aut\'onomos (como la Universidad
Groucho Marx) se utilizan los protocolos \emph{internos} o
IGP\footnote{N. del T.: Internal Gateway Protocol}. El m\'as utilizado es
RIP\footnote{N. del T.: Routing Information Protocol} o {\it protocolo de
informaci\'on
de encaminamiento}, que implementa el demonio \prog{routed} de
BSD. Para encaminamiento entre redes se usan protocolos
EGP\footnote{N del T.: External Gateway Protocol}, como BGP. Se implementan en
programas como \prog{gated} de la Universidad de
Cornell.\footnote{\prog{gated} tambi\'en implementa RIP y en general
se recomienda usarlo en lugar de \prog{routed}}.


% Usually, you won't need any dynamic routing unless your network is very
% large, or richly interconnected.  For this reason, only static routing
% tables created at boot time will be discussed in this book.



\subsection{M\'etricas de Encaminamiento}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.routing.metric}
\index{Routing Information Protocol}
\index{Protocolo de Informaci\'on de Encaminamiento}
\index{IP!m\'etrica}
\index{encaminamiento!m\'etrica}
\index{m\'etrica, encaminamiento|see {encaminamiento, m\'etrica}}

El encaminamiento din\'amico basado en RIP elige la mejor ruta a un
determinado nodo o red a partir del n\'umero de ``saltos'', es decir,
las pasarelas que tiene que atravesar el datagrama hasta llegar a su
destino. La ruta m\'as corta ser\'a la elegida, y si hay 16 o m\'as saltos
se descartar\'a por exceso de distancia.


Para usar RIP tiene que ejecutar \prog{gated} en todas las
m\'aquinas. Al arrancar, \prog{gated} comprueba cu\'antas interfaces est\'an
activas. Si hay m\'as de una (sin contar la de {\it loopback}) asumir\'a
que el nodo es una pasarela. Si no, entrar\'a en modo pasivo,
dedic\'andose a recibir cualquier actualizaci\'on RIP y cambiando sus
tablas en consecuencia.


Para enviar a las dem\'as pasarelas la informaci\'on de su tabla local de
rutas, \prog{gated} cuenta la longitud de cada una a partir de una
\emph{m\'etrica} espec\'{\i}fica (que es decidida por el administrador del
sistema y debe reflejar el coste de esa ruta). As\'{\i}, la m\'etrica de una
ruta a una subred con conexi\'on directa ser\'a siempre cero, mientras que
una ruta que atraviese dos pasarelas deber\'a tener un coste de dos.

% However, note that you don't have to bother about
% metrics when you don't use \prog{RIP} or \prog{gated}.

\index{IP!encaminamiento|)}

\section{Protocolo de Mensajes de Control de Internet (ICMP)}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.icmp}
\index{Internet Control Message Protocol}
\index{Protocolo de Mensajes de Control de Internet}
\index{ICMP}

\index{ICMP!Puerto inalcanzable}
IP tiene otro protocolo a\'un no mencionado. Es el {\it protocolo de mensajes
de control de Internet} o ICMP\footnote{N. del T.: Internet Control Message
Protocol}, y lo usa el software de gesti\'on de red para comunicar
mensajes de error entre nodos. Por ejemplo, si estamos en la m\'aquina
\host{erdos} y hacemos un telnet al puerto 12345 del nodo \host{quark}
y no hay procesos escuchando en ese puerto, recibir\'a un mensaje ICMP
de ``puerto inalcanzable''.


\index{ICMP!Redirecci\'on}
\index{encaminamiento!Redirecci\'on ICMP}
\index{encaminamiento!din\'amico}
\index{IP!encaminamiento}
Hay m\'as mensajes ICMP, muchos de ellos referidos a condiciones de
error. Sin embargo, hay uno interesante que es el de redirecci\'on. Lo
genera el m\'odulo de encaminamiento al detectar que otro nodo est\'a
us\'andolo como pasarela, a pesar de existir una ruta mucho m\'as
corta. Por ejemplo, tras configurarse la tabla de encaminamiento de
\host{sophus}, \'esta puede estar incompleta, conteniendo rutas a trav\'es
del encaminador por defecto \host{gcc1}. Por lo tanto, los paquetes
enviados inicialmente a \host{quark} ir\'an por \host{gcc1} en lugar de
\host{niels}. En este caso \host{gcc1} notificar\'a a \host{sophus} que
est\'a usando una ruta costosa y reenviar\'a el datagrama a \host{niels},
al mismo tiempo que devolver\'a un mensaje ICMP de redirecci\'on a
\host{sophus} inform\'andole de la nueva ruta.


Con lo visto, queda claro que se puede evitar tener que establecer las
rutas a mano. Sin embargo, usar solo esquemas de encaminamiento
din\'amico no es siempre una buena idea. La redirecci\'on de ICMP y el
protocolo RIP no incluyen mecanismos de verificaci\'on de la
autenticidad de los mensajes. Esto permite a los piratas corromper el
tr\'afico de la red mediante mensajes ICMP. Por ello, algunas versiones
del c\'odigo de \linux{} tratan los mensajes de redirecci\'on que afectan
a rutas de red como si fueran redirecciones de rutas a nodos.

\index{TCP/IP|)}


\section{El sistema de nombres DNS}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.dns}
\index{DNS|(}
\index{Sistema de nombres|see {DNS}}

\subsection{Resoluci\'on de nombres}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.dns.resolv}
\index{nombre de nodo!resoluci\'on}
\index{nombre de nodo!conversi\'on a direcci\'on IP}
\index{IP!direcci\'on!y nombre de m\'aquina}

\blackdiamond
Como se coment\'o antes, el direccionamiento en TCP/IP se basa en
n\'umeros de 32~bits. Evidentemente, esos n\'umeros no son f\'aciles de
recordar, mientras que s\'{\i} lo es el nombre que se le asigna a cada
m\'aquina, como \host{gauss} o \host{strange}. Existe una aplicaci\'on que
es capaz de traducir nombres a direcciones~IP, y es conocida como
\emph{sistema de resoluci\'on de nombres} o DNS\footnote{N. del T.: Domain
Name System}.


Una aplicaci\'on que desee encontrar la direcci\'on~IP correspondiente a
una m\'aquina de la que conoce su nombre, no tiene que incluir rutinas
para ello, ya que en las librer\'{\i}as est\'andares (\file{libc}) existen ya
rutinas preparadas, como \func{gethostbyname(3)} o
\func{gethostbyaddr(3)}. En otros sistemas se encuentran en otras
librer\'{\i}as distintas de la \file{libc} pero esto no sucede en
\linux{}. Al conjunto de rutinas que hacen estas tareas se les conoce
como ``sistema de resoluci\'on''.


En una red peque\~na no es dif\'{\i}cil mantener una tabla \file{/etc/hosts}
en cada m\'aquina, y modificarla al agregar, eliminar o modificar
nodos. Pero resulta complicado cuando hay muchas m\'aquinas ya que, en
principio, cada una necesita una copia de \file{/etc/hosts}.


Una soluci\'on a esto es compartir \'esta y otras bases de datos con el
NIS, o \emph{sistema de informaci\'on de red}\footnote{N. del T.: Network
Information System}, desarrollado por Sun Microsystems y conocido
tambi\'en como {\it p\'aginas amarillas}. En este caso, las bases de datos
como la de \file{/etc/hosts} se mantienen en un servidor NIS central y
los clientes acceder\'an a ellas de forma transparente al usuario. En
todo caso, esta soluci\'on solo es aconsejable para redes peque\~nas o
medianas, ya que implican mantener un fichero central
\file{/etc/hosts} que puede crecer mucho, y luego distribuirlo entre
los servidores NIS.


En Internet, se comenz\'o almacenando la informaci\'on en un fichero
similar al \file{hosts}, mantenido por el NIC, y obtenido regularmente
por los dem\'as servidores. Cuando la red creci\'o comenzaron los
problemas de sobrecarga de servidores, adem\'as de que el NIC ten\'{\i}a que
ocuparse de todos los nombres de los nodos de Internet, y evitar la
duplicidad de los mismos.


Por esto, en 1984 se dise\~n\'o y adopt\'o oficialmente un nuevo sistema, el
DNS o \emph{sistema de nombres por dominios}, dise\~nado por Paul Mockapetris.


\subsection{Introducci\'on al DNS}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.dns.bind}
\index{espacio de nombres (DNS)}
\index{nombre!totalmente cualificado}
\index{nombre!y nombre de dominio}
\index{nombre de dominio|(}

DNS organiza los nombres de los nodos en una jerarqu\'{\i}a de dominios. Un
dominio es una colecci\'on de nodos relacionados de alguna manera, como
estar en la misma red o pertenecer a una misma organizaci\'on o
pa\'{\i}s. Por ejemplo, las universidades norteamericanas se agrupan en el
dominio \host{edu}, y cada universidad mantiene un subdominio dentro
de \host{edu}. Nuestro ejemplo, la Universidad de Groucho Marx,
mantendr\'{\i}a el dominio \host{gmu.edu} y las m\'aquinas del departamento
de Matem\'aticas se encontrar\'{\i}an dentro del dominio
\host{maths.gmu.edu}. De este modo el nombre completo de la m\'aquina
\host{erdos} ser\'a \host{erdos.maths.gmu.edu}. El nombre completo se
conoce como \emph{nombre totalmente cualificado} o FQDN\footnote{N. del T.:
Fully Qualified Domain Name}, e identifica a ese nodo en todo el mundo.


\begin{figure}[htb]
\iftex
 \ifps
  \begin{center}
   \mbox{\epsffile{figures/dns.epsf}}
  \end{center}
 \else
  \font\nintt=cmtt9
  \input{dns.eepic}
 \fi
\else
 \verbinclude{dns.ascii}
\fi
 \caption{
  \label{intro.fig.dns}
  Parte del espacio de dominios
 }
\end{figure}


En la figura~\ref{intro.fig.dns} se muestra una secci\'on del espacio de
dominios. La entrada de la ra\'{\i}z del \'arbol, que se indica con un punto,
se puede denominar \emph{dominio ra\'{\i}z}, y agrupa al resto de los
dominios. Para indicar que un nodo se expresa en notaci\'on FQDN, se
puede terminar el nombre en un punto, indicando as\'{\i} que el nombre
incluye al del dominio ra\'{\i}z.


\index{dominios!primer nivel}
Dependiendo de su localizaci\'on en la jerarqu\'{\i}a, un dominio puede ser
de primer, segundo o tercer nivel. Pueden existir otros niveles pero
no son frecuentes. Por ejemplo, algunos dominios de primer nivel muy
usuales son los siguientes:

\medskip
\begin{dispitems}
\ditem[\host{edu}]
	Aqu\'{\i} se incluyen casi todas las universidades o centros de
investigaci\'on norteamericanos.

\ditem[\host{com}]
	Compa\~n\'{\i}as u organizaciones con fines comerciales.

\ditem[\host{org}]
	Organizaciones no comerciales. Las redes UUCP privadas se
encuentran aqu\'{\i}.

\ditem[\host{net}]
	Pasarelas y otros nodos administrativos de la red.

\ditem[\host{mil}]
	    Nodos militares norteamericanos.

\ditem[\host{gov}]
	    Nodos del gobierno norteamericano.

\ditem[\host{uucp}]
	Oficialmente, todos los nombres de nodos UUCP sin dominio han
sido movidos a este nuevo dominio, .uucp.

\end{dispitems}


En general, los dominios anteriores pertenecen a redes
norteamericanas. Algo especialmente cierto con los dominios \host{mil}
o \host{gov}.


\index{dominios!primer nivel!ISO-3166}
\index{ISO-3166!dominios de primer nivel}
Fuera de los Estados Unidos, existe un dominio de primer nivel para
cada pa\'{\i}s, de dos letras seg\'un se define en la norma
ISO-3166. Finlandia, por ejemplo, usa el dominio \host{fi}; el dominio
\host{de} corresponde a Alemania y el dominio \host{es} corresponde a
Espa\~na. Cada pa\'{\i}s organiza por debajo del primer nivel, los dominios
de segundo nivel, de manera parecida a los americanos en algunos casos
(por ejemplo, con dominios \host{com.au} o \host{edu.au}) o
directamente por organizaciones, como sucede en Espa\~na (con dominios
como \host{upm.es} para la Universidad Polit\'ecnica de Madrid). 


Por supuesto, un nodo dentro del dominio de un pa\'{\i}s puede no estar
f\'{\i}sicamente en \'el. El dominio \'unicamente identifica al nodo como
registrado en el NIC de ese pa\'{\i}s. As\'{\i}, un comerciante sueco puede
tener una delegaci\'on en Australia, y tener sus nodos australianos
registrados dentro del dominio de primer nivel sueco, \host{se}.


Esta organizaci\'on por dominios soluciona el problema de la unicidad de
nombres. Adem\'as, los nombres totalmente cualificados no son dif\'{\i}ciles
de recordar.


\index{delegaci\'on!subdominios DNS}
\index{creaci\'on!subdominios}
\index{subdominio (DNS)}
Pero DNS tiene otras ventajas: permite delegar la autoridad sobre un
determinado subdominio a sus administradores. Por ejemplo, los
subdominios \host{maths} y \host{physics} de la UGM son creados y
mantenidos por el Centro de C\'alculo de dicha universidad. Y si el
mantenimiento del subdominio \host{maths.gmu.edu} fuese complicado
(por n\'umero elevado de nodos, existencia de subdominios internos,
etc), el Centro de C\'alculo de la UGM puede delegar la autoridad sobre
ese subdominio al departamento de Matem\'aticas. La delegaci\'on de un
subdominio implica el control total del mismo por parte de la
organizaci\'on en la que se deleg\'o, con total libertad para crear nuevos
subdominios internos, asociar nombres a nodos, etc.


\index{DNS!zona}
\index{zona, DNS|see {DNS, zona}}
Para este fin, el espacio de nombres se divide en \emph{zonas}, cada
una asociada a un dominio. N\'otese que existe una diferencia entre zona
y dominio: el \emph{dominio} \host{groucho.edu} incluye todos los
nodos de la UGM, mientras que la \emph{zona} \host{groucho.edu}
incluye s\'olo los nodos que mantiene directamente el Centro de C\'alculo,
ya que los nodos del subdominio \host{physics.groucho.edu} pertenecen
a la zona controlada por el Departamento de F\'{\i}sicas. En la
figura~\ref{intro.fig.dns} se marca el inicio de una zona con un
peque\~no c\'{\i}rculo a la derecha del nombre del dominio.


\index{nombre de dominio|)}

\subsection{B\'usquedas de nombres con DNS}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.dns.lookups}
\index{nombre!b\'usqueda}
\index{DNS!lookup}
\index{DNS!b\'usqueda}

Trataremos aqu\'{\i} el problema de c\'omo resolver el nombre de un
determinado nodo.


\index{servidor de nombres|(}
DNS es una gigantesca base de datos distribuida. Se implementa a
trav\'es de los llamados {\it servidores de nombres}. Cada uno de \'estos
mantiene la informaci\'on de uno o varios dominios. Para cada zona hay
al menos dos (o m\'as) servidores de nombres que mantienen informaci\'on
{\it autorizada} sobre los nodos de esa zona. Para obtener la
direcci\'on~IP del nodo \host{erdos}, lo que hay que hacer es contactar
con el servidor de nombres de la zona para \host{groucho.edu} y \'este
nos devolver\'a los datos pedidos.


%% ...orig: In order that you don't have to rely on magic...

\index{DNS!petici\'on}
\index{DNS!zona}
Esto parece f\'acil de decir pero dif\'{\i}cil de implementar pues nos
preguntaremos c\'omo localizar al servidor de nombres de la UGM. Si su
ordenador no implementa un adivino, le ayudar\'a el DNS. Cuando su
aplicaci\'on desea encontrar informaci\'on acerca de \host{erdos},
contactar\'a en primer lugar con un servidor de nombres local, quien
realizar\'a una b\'usqueda por otros servidores. Empieza por preguntar a
un servidor de nombres ra\'{\i}z por \host{erdos.maths.groucho.edu}. Al
comprobar \'este \'ultimo que \'el no mantiene ese dominio, contactar\'a con
los servidores del dominio \host{edu} y les preguntar\'a las direcciones
de los servidores de nombres, que retornar\'a al servidor local. Ahora
nuestro servidor preguntar\'a a estos \'ultimos y \'estos a su vez ir\'an
haciendo llegar a nuestro servidor hasta los que mantienen la zona
\host{groucho.edu}. Finalmente, se preguntar\'a a uno de estos \'ultimos
por el nodo \host{erdos} y se enviar\'a la respuesta al usuario.


Aparentemente esto provoca mucho tr\'afico, aunque en todo caso siempre
ser\'a menor que preguntar siempre a los mismos servidores que manten\'{\i}an
el fichero \file{HOSTS.TXT} antes de que se dise\~nara el DNS.

% Commonly the resolver library, instead of conducting the DNS
% query itself, will delegate it to a name server running on the local
% network. This server will perform the DNS lookup as described above, and
% return the result to the application.


Sin embargo, a\'un se puede mejorar algo m\'as. La informaci\'on obtenida en
una b\'usqueda puede que se necesite despu\'es. Por ello, el servidor de
nombres local la guardar\'a en una \emph{cache} local. As\'{\i}, cuando
volvamos a preguntar por un nodo de \host{groucho.edu}, el servidor
local ya podr\'a dirigirse directamente el servidor de nombres de esa
zona sin pasar por los servidores ra\'{\i}z.


\index{DNS!tiempo de vida}
\index{DNS!ttl|see {DNS, tiempo de vida}}
Por supuesto, el servidor de nombres no puede mantener la cache
eternamente; debe descartarla cada cierto tiempo. Este tiempo de
expiraci\'on se conoce como TTL\footnote{N. del T.: Time To Live} o
\emph{tiempo de vida}. En la base de datos del DNS queda especificado
este par\'ametro.



\subsection{Servidores de Nombres}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.dns.servers}
\index{servidor de nombres autorizado}
\index{servidor de nombres!autorizado}
\index{DNS!zona}

Cuando un servidor de nombres mantiene toda la informaci\'on acerca de
una zona se le llama \emph{autorizado} para esa zona. Cualquier
petici\'on para esa zona ser\'a enviada a uno de esos servidores maestros.


\index{sincronizaci\'on de servidores de nombres}
\index{servidor de nombres!sincronizaci\'on}
\index{servidor de nombres!secundario}
\index{servidor de nombres!primario}
Para tener una representaci\'on coherente de la zona, sus servidores
maestros deben estar sincronizados. Para ello, a uno de ellos se le
nombra servidor \emph{primario}, que obtiene la informaci\'on de zona a
partir de unos ficheros locales, y a los dem\'as se les nombra
servidores \emph{secundarios}. Estos \'ultimos cargan la informaci\'on de
la zona pidi\'endosela al primario cada cierto tiempo.


Las razones para que existan varios servidores autorizados por cada
zona son dos: repartir la carga de trabajo y lograr tolerancia a
fallos. As\'{\i}, si un servidor cae, todas las peticiones se repartir\'an
entre los dem\'as servidores autorizados que haya. Por supuesto, esto no
protege contra fallos internos o {\it bugs} del propio software DNS.


\index{servidor de nombres!solo-cache}
Pero adem\'as, tambi\'en es posible tener servidores de nombres que no
mantengan informaci\'on autorizada de ning\'un dominio\footnote{Aunque al
menos deber\'a tener informaci\'on autorizada para el \host{localhost} y
la resoluci\'on inversa de \host{127.0.0.1}}. Este tipo de servidores es
\'util pues, al mantener una {\it cache} con los nombres que resuelven,
disminuye la carga de la red y de otros servidores.


\index{servidor de nombres|)}

\subsection{La Base de Datos DNS}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.dns.records}
\index{DNS!base de datos}

En las bases de datos del DNS se mantiene m\'as informaci\'on que la
necesaria para traducir nombres a direcciones~IP. Dicho de otra forma,
en DNS se mantienen {\it distintos tipos de registros}.


\index{DNS!registros}
\index{DNS!registros de recursos}
\index{DNS!RR|see {DNS, registros}}
\index{registro de recursos|see {DNS, registros}}
\index{RR|see {DNS, registro de recurso}}
La unidad de informaci\'on en el DNS se conoce como
\emph{registro de recurso} o RR. Cada registro tiene un tipo asociado
a \'el, describiendo qu\'e clase de datos contiene, y una clase indicando
el tipo de red al que se aplica. Se trata de acomodarse a diferentes
esquemas de red, aunque para direcciones~IP se usa siempre la clase~IN
(INternet), pero hay otras como las redes Hesiod (que se usan en el
MIT\footnote{Instituto Tecnol\'ogico de Massachusets}). El registro m\'as
habitual es el de tipo A, que relaciona un nombre totalmente
cualificado con una direcci\'on~IP.


\index{nombre can\'onico}
\index{nombre de nodo!can\'onico}
\index{alias!nombre}
Un nodo puede admitir m\'as de un nombre. Pero s\'olo uno de ellos ser\'a
``oficial'' o \emph{can\'onico}, mientras que los dem\'as son alias del
primero. La diferencia es que el can\'onico se define en un registro de
tipo A, mientras que los alias se definen en registros CNAME que
apuntan al nombre can\'onico.


En un cap\'{\i}tulo posterior se trata todo esto en profundidad. Aqu\'{\i} nos
vamos a limitar a ver algunos ejemplos. En la
figura~\ref{intro.fig.hosts} se muestra una parte de la base de datos
para la zona \host{physics.groucho.edu}.


\begin{figure}[htbp]
\small
\begin{verbatim}
 ;
 ; Informacion Autorizada de physics.groucho.edu
 @                     IN    SOA          (
		      niels.physics.groucho.edu.
		      hostmaster.niels.physics.groucho.edu.
		      1034             ; serial no
		      360000           ; refresh
		      3600             ; retry
		      3600000          ; expire
		      3600             ; default ttl )
 ;
 ; Servidores de nombres autorizados
		       IN    NS       niels
		       IN    NS       gauss.maths.groucho.edu.
 gauss.maths.groucho.edu. IN A        149.76.4.23
 ;
 ; Fisica Teorica (subred 12)
 niels                 IN    A        149.76.12.1
		       IN    A        149.76.1.12
 nameserver            IN    CNAME    niels
 otto                  IN    A        149.76.12.2
 quark                 IN    A        149.76.12.4
 down                  IN    A        149.76.12.5
 strange               IN    A        149.76.12.6
 ...
 ; Laboratorio Collider (subred 14)
 boson                 IN    A        149.76.14.1
 muon                  IN    A        149.76.14.7
 bogon                 IN    A        149.76.14.12
 ...
\end{verbatim}
 \caption{
  \label{intro.fig.hosts}
  Extracto del fichero \file{named.hosts} del departamento de F\'{\i}sicas.
 }
\end{figure}


\index{SOA (registro DNS)}
\index{DNS!zona}
\index{servidor de nombres autorizado}
\index{servidor de nombres!autorizado}
\index{SOA (Start of Authority)}
\index{Comienzo de Autoridad}
Adem\'as de los registros A y CNAME, se puede ver que hay un registro
especial al principio del fichero, con varias l\'{\i}neas. Se trata del
registro SOA o de \emph{inicio de autoridad}, que mantiene
informaci\'on general sobre el servidor de nombres. Por ejemplo, el
tiempo de vida por defecto de todos los registros que mantiene.


N\'otese que aquellos nombres que no finalicen en un punto ser\'an
interpretados como relativos al dominio en cuesti\'on. El nombre
especial ``\host{@}'' usado en el registro SOA representa al dominio
completo.


Hemos visto que los servidores para el dominio \host{groucho.edu}
deben tener conocimiento sobre los servidores de la zona
\host{physics} para poder reenviarles las peticiones para \'esta. Esto
se suele incluir en los registros NS que incluyen el nombre de los
servidores en notaci\'on FQDN, y un registro A que da la direcci\'on~IP
para ese servidor. V\'ease, por ejemplo, la figura~\ref{intro.fig.nsptr}.


\begin{figure}[htbp]
\small
\begin{verbatim}
 ;
 ; Datos de zona para groucho.edu.
 @                   IN       SOA         (
		      vax12.gcc.groucho.edu.
		      hostmaster.vax12.gcc.groucho.edu.
		      233              ; serial no
		      360000           ; refresh
		      3600             ; retry
		      3600000          ; expire
		      3600             ; default ttl )

	 ....
 ;
 ; Registros de la zona.
 physics             IN     NS        niels.physics.groucho.edu.
		     IN     NS        gauss.maths.groucho.edu.
 niels.physics       IN     A         149.76.12.1
 gauss.maths         IN     A         149.76.4.23
 ...
\end{verbatim}
 \caption{
  \label{intro.fig.nsptr}
  Extracto del fichero \file{named.hosts} de la UGM.
 }
\end{figure}


\subsection{Resoluci\'on inversa}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{tcpip.dns.in-addr}
\index{DNS!resoluci\'on inversa|(}
\index{resoluci\'on inversa|(}
\index{b\'usqueda de direcciones}
\index{direcci\'on!traducci\'on a nombre}
\index{nombre!obtenci\'on desde la direcci\'on~IP}
\index{IP!direcci\'on!y nombre del nodo}
\index{dominio in-addr.arpa@dominio \host{in-addr.arpa}}
\index{IP!red}

Adem\'as de la obtenci\'on de una direcci\'on~IP a partir del nombre, a
veces interesa lo contrario: conocida la direcci\'on, obtener el nombre
can\'onico. Esto se conoce como \emph{traducci\'on inversa} y la utilizan
algunas aplicaciones de red para verificar la identidad del
llamante. Cuando se usa un fichero \file{hosts}, la resoluci\'on inversa
supone una simple b\'usqueda en el mismo. En cambio, para el DNS se ha
creado un dominio especial, el \host{in-addr.arpa}, que contiene
direcciones de los nodos en notaci\'on de puntos divisorios
invertida. Por ejemplo, a la direcci\'on~IP \host{149.76.12.4} le
corresponde el nombre \host{4.12.76.149.in-addr.arpa}. El tipo de
registro para estos datos se llama PTR.


\index{DNS!zona}
\index{servidor de nombres autorizado}
\index{servidor de nombres!autorizado}
\index{delegaci\'on!subdominios DNS}
\index{creaci\'on!subredes}
\index{IP!subred}
\index{subdominio (DNS)}
Cuando se crea una zona de autoridad suele significar que sus
administradores tienen control total sobre c\'omo asignan sus
nombres. Pero a una subred se le puede delegar un subdominio.


Esto sucede con la UGM, donde se delega la zona de F\'{\i}sicas (subdominio
\host{physics}) al correspondiente Departamento. Las direcciones de
resoluci\'on inversa tambi\'en se delegan.


En la figura~\ref{intro.fig.subnet12} se muestra el contenido del
fichero de zona para el servidor de la subred 12. Los registros
``importantes'' de delegaci\'on se muestran en la
figura~\ref{intro.fig.groucho-rev}.


\begin{figure}[htbp]
\small
\begin{verbatim}
 ;
 ; Dominio 12.76.149.in-addr.arpa
 @                IN     SOA   (
		      niels.physics.groucho.edu.
		      hostmaster.niels.physics.groucho.edu.
		      233 360000 3600 3600000 3600 )
 2                IN     PTR       otto.physics.groucho.edu.
 4                IN     PTR       quark.physics.groucho.edu.
 5                IN     PTR       down.physics.groucho.edu.
 6                IN     PTR       strange.physics.groucho.edu.
\end{verbatim}
 \caption{
  \label{intro.fig.subnet12}
  Extracto del fichero \file{named.rev} de la subred 12.
 }
\end{figure}


\begin{figure}[htbp]
\small
\begin{verbatim}
 ;
 ; Dominio 76.149.in-addr.arpa domain
 @                   IN       SOA          (
		      vax12.gcc.groucho.edu.
		      hostmaster.vax12.gcc.groucho.edu.
		      233 360000 3600 3600000 3600 )

 ...
 ; subred 4: Departamento de Matematicas
 1.4              IN     PTR      sophus.maths.groucho.edu.
 17.4             IN     PTR      erdos.maths.groucho.edu.
 23.4             IN     PTR      gauss.maths.groucho.edu.
 ...
 ; subred 12: Departamento de fisicas, zona separada
 12               IN     NS       niels.physics.groucho.edu.
		  IN     NS       gauss.maths.groucho.edu.
 niels.physics.groucho.edu. IN  A 149.76.12.1
 gauss.maths.groucho.edu. IN  A   149.76.4.23
 ...
\end{verbatim}
 \caption{
  \label{intro.fig.groucho-rev}
  Extracto del fichero \file{named.rev} de la red \host{149.76}.
 }
\end{figure}

\index{creaci\'on!zonas DNS}
\index{DNS!creaci\'on de zonas}
Una importante consecuencia de esto es que las zonas s\'olo pueden
crearse como superconjuntos de redes~IP, y adem\'as, las m\'ascaras de red
deber\'an redondearse a nivel de octeto. Es decir, las subredes de la
UGM tendr\'an una m\'ascara \host{255.255.255.0}, y para cada subred
deber\'a existir una zona \host{in-addr.arpa}. Sin embargo, si la
m\'ascara fuese \host{255.255.255.128}, la creaci\'on de zonas para la
subred \host{149.76.12.128} ser\'{\i}a imposible ya que no hay forma de
decir en DNS que el dominio \host{12.76.149.in-addr.arpa} ha sido
dividido en dos zonas de autoridad, con nombres de nodos desde el
\host{1} al \host{127}, y desde el \host{128} al \host{255},
respectivamente.

\index{DNS!resoluci\'on inversa|)}
\index{resoluci\'on inversa|)}
\index{DNS|)}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%                                                             %%
%%              E N D   O F   C H A P T E R                    %%
%%                                                             %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
