Vamos a entrar en los detalles que deben tenerse en cuenta cuando se conecta una máquina Linux a una red TCP/IP. De este modo, hablaremos de direcciones IP, nombres y cuestiones sobre el encaminamiento. Este capítulo le enseñará la base con la que podrá entender los pasos para su configuración particular, pasos que son cubiertos exhaustivamente en otros capítulos.

Para ocultar la diversidad de hardware que puede usarse en una red, TCP/IP define una interfaz a través de la cual accedemos al hardware. Esta interfaz ofrece un conjunto de operaciones idénticas en cualquier tipo de hardware y que básicamente consisten en operaciones para enviar y recibir paquetes.

Para cada dispositivo que quiera utilizarse para conectarse a la red, se mantendrá en el núcleo del sistema la correspondiente interfaz. Por ejemplo, las interfaces con Ethernet en Linux son eth0 y eth1, mientras que las interfaces SLIP se llaman sl0, sl1, etcétera. Estos nombres de interfaz se deben conocer durante la configuración de la red, cuando queramos referirnos a un dispositivo hardware concreto.

Para que podamos usarlo en una red TCP/IP, la interfaz deberá tener asignada una dirección IP que sirva como identificación de ésta ante los demás ordenadores de la red. Esta dirección es diferente del nombre de interfaz considerado anteriormente; puede realizarse la siguiente analogía: la interfaz sería la "puerta" de su sistema, mientras que la dirección vendría a ser un número enmarcado y colgado de la "puerta".

Por supuesto, hay otros parámetros configurables para cada dispositivo, como el número máximo de datagramas que pueden ser procesados por el dispositivo, conocido como Unidad Máxima de Transferencia o MTU1. Otros parámetros serán introducidos mas tarde.

Como se dijo en el capítulo anterior, las direcciones utilizadas en el protocolo de red IP la forman números de 32 bits, y cada máquina debe tener una dirección propia. Si las máquinas se encuentran en una red TCP/IP que no se conecta a otras redes, dichas direcciones podrán asignarse a las máquinas libremente. Sin embargo, si las máquinas se conectan a Internet, las direcciones de los ordenadores serán asignadas por una autoridad principal, el NIC2 o Centro de Información de la Red3.

Para facilitar la lectura, las direcciones IP se dividen en cuatro números de 8 bits llamados octetos. Por ejemplo, si la máquina quark.physics.groucho.edu tiene una dirección IP 0x954C0C04, normalmente la escribiremos con la notación de puntos divisorios, que separa los octetos, de esta forma: 149.76.12.4.

Otra razón para usar esta notación es que las direcciones IP se pueden dividir en el número de red y el número de nodo. Cuando pedimos al NIC un conjunto de direcciones, este organismo nos concederá, no una dirección para nuestra máquina, sino un rango de direcciones validas, que en realidad es un número de red concreto (el número de nodo lo pondremos nosotros, contando con todos esos nodos disponibles).

Dependiendo del tamaño de la red, la parte de la dirección correspondiente al nodo puede ser mas o menos grande. Para adaptarse a diferentes necesidades, se conceden diferentes clases de redes, que definen diferentes maneras de dividir la dirección IP en parte de red y parte del nodo.

Clase A La clase A comprende redes desde 1.0.0.0 hasta 127.0.0.0. El número de red esta 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.

Clase B La clase B comprende redes desde 128.0.0.0 hasta 191.255.0.0; siendo el número de red de 16 bits (los dos primeros octetos). Esto permite 16320 redes de 65024 nodos cada una.

Clase C Las redes de clase C tienen el rango de direcciones desde 192.0.0.0 hasta 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áximo de 254 nodos cada una.

Clases D, E, y F Comprenden las direcciones entre 224.0.0.0 y 254.0.0.0, y están reservadas para uso futuro, o con fines experimentales4. No especifican, pues, ninguna red de Internet.

_____________________________________________
1 N. del T.: MTU son las siglas de "Maximum Transfer Unit".
2 N. del T.: Network Information Center
3 Frecuentemente, las direcciones IP le serán 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 hostmaster@internic.net.

Volviendo al ejemplo del capítulo anterior, veremos que en la dirección 149.76.12.4 de la máquina quark, 12.4 es el identificativo del nodo dentro de la red de clase B 149.76.0.0.  

Se puede observar que en la lista anterior no se consideraban todas las posibilidades en la parte que identifica al nodo; concretamente, se excluían siempre el identificador 0 y el 255. Estos dos identificadores se reservan para propósitos especiales. Una dirección 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ón de broadcast, lo que indica que un mensaje enviado a esa dirección será procesado por todos los nodos de la red). Así pues, en nuestro ejemplo la dirección de la red sería 149.76.0.0 y la de broadcast, la 149.76.255.255.

Además, otras dos direcciones de red están reservadas: la 0.0.0.0 y la 127.0.0.0. La primera se conoce como dirección de encaminamiento por defecto, y la segunda, como dirección de loopback. El encaminamiento por defecto se utiliza para saber a donde enviar los datagramas por defecto, tema que abordaremos después.

La red 127.0.0.0 se reserva para el tráfico local, dirigido al propio nodo. Normalmente, se asigna la dirección 127.0.0.1 a un dispositivo de la máquina llamado interfaz de loopback 5 o de circuito cerrado. Cualquier paquete enviado a esa dirección será recibido por el propio nodo. Esto permite probar aplicaciones de red con uno mismo, sin estar conectado a una red "real". Otra aplicación útil es la de ejecutar aplicaciones de red que afectan solo al nodo local. Por ejemplo, muchos sistemas UUCP no tienen conexión IP pero ejecutan un sistema de noticias INN. Para que esto funcione, INN utiliza la interfaz de loopback.

_____________________________________________
4 Por ejemplo, se esta utilizando la red 224.0.0.0 para la Internet multidestino o multicast
5 N. del T.: También conocida como interfaz de lazo

Ahora que conocemos que son las direcciones IP, nos preguntaremos como se utilizan en una red Ethernet. Después de todo, el protocolo Ethernet usa direcciones identificativas de seis octetos que no tienen que ver con los números IP.

En efecto, se necesita un mecanismo de traducción de direcciones IP a direcciones Ethernet o físicas. Esto se hace con el Protocolo de Resolución de Direcciones o ARP6. 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íamos para localizar al señor X entre 150 personas: preguntar por su nombre a todo el mundo; y el señor X nos responderá.

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

Por supuesto, le preocupara saber como puede funcionar esto para localizar un nodo entre millones de Ethernets conectadas en el mundo. Esto se trata en la próxima sección: se trata del encaminamiento.

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

A veces, un nodo necesita también conocer su dirección IP a partir de su dirección física. Por ejemplo, en terminales X o PCs sin disco, que cuando arrancan solo saben la dirección de su tarjeta pues esta grabada en memoria no volátil. Para ello, se usa el Protocolo de Resolución Inversa de Direcciones o RARP7: la petición RARP la hace el nodo cuando arranca, mediante mensaje broadcast, y es contestado por un servidor de direcciones que, a partir de la dirección física, consulta su base de datos y conoce la dirección IP correspondiente. Existe además otro protocolo, el BOOTP o protocolo de arranque8, que permite a las máquinas sin disco conocer como ponerse en marcha en la red.

_____________________________________________
6 N. del T.: Address Resolution Protocol
7 N. del T.: Reverse Address Resolution Protocol
8 N. del T.: Del inglés Boot Protocol

3 Cuando escribimos una carta a alguien, normalmente incluimos la dirección completa en el sobre: país, provincia, código postal, etc. De este modo el servicio de correos podrá llevar la carta a su destino: un servicio la enviara al del país que corresponda, y este último la entregara al de la provincia o ciudad de destino. La ventaja de este esquema jerárquico es que el servicio postal del remitente apenas tiene que saber acerca del destino final, sino solo a que país entregarla.

Las redes IP se organizan de manera similar. Internet consta de varias redes, conocidas como sistemas autónomos 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 entregara al encaminador correspondiente, sin preocuparse del destino final del paquete.

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ón IP. Es decir, los nodos con la misma dirección de red se encontraran en la misma red TCP/IP9.

Pero en una red puede interesar hacer una división en cientos de pequeñas redes, por ejemplo segmentos de Ethernet. Para ello se subdivide la red en subredes.

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úmero IP correspondiente a la red. Sin embargo, esa parte incluirá ahora algunos bits de la parte del nodo. Los bits que se interpretan como dirección de subred se obtienen con la llamada máscara de red. Es un número de 32 bits que especifica una máscara para identificar los bits de la subred.

La red del campus de la Universidad de Groucho Marx es un ejemplo de red de clase B, poseedora de la red 149.76.0.0, con máscara 255.255.0.0.

Internamente, la red de la UGM se divide en pequeñas subredes, como las LAN de cada departamento. Concretamente se divide en 254 subredes, desde la 149.76.1.0 hasta la 149.76.254.0. Por ejemplo, el Departamento de Física Teórica tendrá asignada la subred 149.76.12.0. La dorsal del campus es en si mismo una subred, la 149.76.1.0. Las subredes comparten el mismo número de red, pero se usa el tercer octeto de ésta para distinguir las distintas subredes. Por lo tanto, tendrán una máscara de subred igual a 255.255.255.0.

_____________________________________________
9 Los sistemas autónomos son algo mas generales. Pueden tener más de una red IP.

Figura 2.1: División de una red clase B en subredes

En la figura 2.1 se muestra como el nodo quark (149.76.12.4) se ve de distinta forma según se vea desde el punto de vista de la red de clase B, o desde el punto de vista de las subredes.

Nótese que la división en subredes es visible solo internamente a la red. Normalmente las organiza el administrador de red para reflejar diferentes ubicaciones geográficas, distinguir segmentos de red, o bien por motivos administrativos (departamentos, redes de alumnos, etc.). Pero esta división es totalmente invisible desde fuera de la organización.

La organización en subredes no sólo se hace por motivos administrativos, también es consecuencia de cuestiones del hardware. Lo que ve un nodo en una red es limitado: solo ve los nodos con los que directamente este conectado (por ejemplo, en la Ethernet), mientras que a los demás los accede a través de lo que se conoce como pasarela10, que no es mas que un nodo conectado a dos o mas redes físicas, configurado para pasar paquetes de una red a otra.

Para reconocer si una dirección IP se encuentra en la red local física, cada LAN debe tener una dirección de red IP diferente. Por ejemplo, las máquinas de la (sub)red 149.76.4.0 serian las que están en la LAN del Departamento de Matemáticas. Cuando se envía un datagrama a la máquina quark, el software de red de erdos ve que su dirección de red es otra (149.76.12.4) con lo que sabe que tiene que enviar los datagramas a través de la pasarela (sophus por defecto).

sophus se encuentra conectado a dos subredes: la del Departamento de Matemáticas y la de la dorsal del campus, accediendo a cada una a través de una interfaz diferente, respectivamente eth0 y fddi0. Nos preguntaremos entonces, que dirección IP debe tener la pasarela, una de la subred de Matemáticas o bien una de la dorsal.

_____________________________________________
10 N. del T.: Del inglés gateway

Pues bien, la respuesta es ambas. Cuando la pasarela comunique con un nodo de la LAN de Matemáticas, usara la dirección 149.76.4.1, mientras que si lo hace con un nodo de la dorsal, usara 149.76.1.4.

Es decir, la pasarela tiene tantas direcciones IP como conexiones a redes físicas tenga. En definitiva, este será el esquema de interfaces, direcciones y máscara de sophus, nuestra pasarela:

La última entrada describe el dispositivo loopback, que se comento anteriormente.

En la figura 2.2 se muestra una parte de la topología de la red de la Universidad de Groucho Marx (UGM). Los nodos que están en dos subredes tendrán dos direcciones IP.

Vamos ahora a centrarnos en como se selecciona una pasarela para entregar un datagrama a una red remota.

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

La información de encaminamiento que se usa en IP es básicamente una tabla donde se relacionan (sub)redes y pasarelas. Además, debe incluirse una entrada de encaminamiento por defecto, que se asocia en la tabla a la red 0.0.0.0. Todos los paquetes que van a una red desconocida, se enviaran a la pasarela del encaminamiento por defecto. Así pues, esta sería la tabla para sophus:

Figura 2.2: Vista parcial de la topología de la red de la UGM.

Las rutas a una red a la que sophus este 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 "-".

Las tablas de encaminamiento pueden construirse de varias formas. Para redes pequeñas, será mas eficiente construirlas a mano usando el comando route de Linux (véase el capítulo 5). Para redes mas grandes, las tablas se mantienen y modifican automáticamente mediante los demonios de encaminamiento. Estos corren en nodos centrales e intercambian información de encaminamiento entre ellos para tener en todo momento las rutas "optimas" entre subredes.

Dependiendo del tamaño de la red, se utilizan distintos protocolos de encaminamiento. Dentro de los sistemas autónomos (como la Universidad Groucho Marx) se utilizan los protocolos internos o IGP11. El mas utilizado es RIP12 o protocolo de información de encaminamiento, que implementa el demonio routed de BSD. Para encaminamiento entre redes se usan protocolos EGP13, como BGP. Se implementan en programas como gated de la Universidad de Cornell.14.

El encaminamiento dinámico basado en RIP elige la mejor ruta a un determinado nodo o red a partir del número de "saltos", es decir, las pasarelas que tiene que atravesar el datagrama hasta llegar a su destino. La ruta mas corta será la elegida, y si hay 16 o mas saltos se descartara por exceso de distancia.

Para usar RIP tiene que ejecutar gated en todas las máquinas. Al arrancar, gated comprueba cuantas interfaces están activas. Si hay mas de una (sin contar la de loopback) asumirá que el nodo es una pasarela. Si no, entrara en modo pasivo, dedicándose a recibir cualquier actualización RIP y cambiando sus tablas en consecuencia.

_____________________________________________
11 N. del T.: Internal Gateway Protocol
12 N. del T.: Routing Information Protocol
13 N del T.: External Gateway Protocol
14 gated también implementa RIP y en general se recomienda usarlo en lugar de routed

Para enviar a las demás pasarelas la información de su tabla local de rutas, gated cuenta la longitud de cada una a partir de una métrica especifica (que es decidida por el administrador del sistema y debe reflejar el coste de esa ruta). Así, la métrica de una ruta a una subred con conexión directa será siempre cero, mientras que una ruta que atraviese dos pasarelas deberá tener un coste de dos.

IP tiene otro protocolo aun no mencionado. Es el protocolo de mensajes de control de Internet o ICMP15, y lo usa el software de gestión de red para comunicar mensajes de error entre nodos. Por ejemplo, si estamos en la máquina erdos y hacemos un telnet al puerto 12345 del nodo quark y no hay procesos escuchando en ese puerto, recibirá un mensaje ICMP de "puerto inalcanzable".

Hay mas mensajes ICMP, muchos de ellos referidos a condiciones de error. Sin embargo, hay uno interesante que es el de redirección. Lo genera el modulo de encaminamiento al detectar que otro nodo esta usándolo como pasarela, a pesar de existir una ruta mucho mas corta. Por ejemplo, tras configurarse la tabla de encaminamiento de sophus, esta puede estar incompleta, conteniendo rutas a través del encaminador por defecto gcc1. Por lo tanto, los paquetes enviados inicialmente a quark irán por gcc1 en lugar de niels.

En este caso gcc1 notificara a sophus que esta usando una ruta costosa y reenviara el datagrama a niels, al mismo tiempo que devolverá un mensaje ICMP de redirección a sophus informándole 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ámico no es siempre una buena idea. La redirección de ICMP y el protocolo RIP no incluyen mecanismos de verificación de la autenticidad de los mensajes. Esto permite a los piratas corromper el tráfico de la red mediante mensajes ICMP. Por ello, algunas versiones del código de Linux tratan los mensajes de redirección que afectan a rutas de red como si fueran redirecciones de rutas a nodos.

3 Como se comentó antes, el direccionamiento en TCP/IP se basa en números de 32 bits. Evidentemente, esos números no son fáciles de recordar, mientras que si lo es el nombre que se le asigna a cada máquina, como gauss o strange. Existe una aplicación que es capaz de traducir nombres a direcciones IP, y es conocida como sistema de resolución de nombres o DNS16.

_____________________________________________
15 N. del T.: Internet Control Message Protocol

Una aplicación que desee encontrar la dirección IP correspondiente a una máquina de la que conoce su nombre, no tiene que incluir rutinas para ello, ya que en las librerías estándares (libc) existen ya rutinas preparadas, como gethostbyname(3) o gethostbyaddr(3).

En otros sistemas se encuentran en otras librerías distintas de la libc pero esto no sucede en Linux. Al conjunto de rutinas que hacen estas tareas se les conoce como "sistema de resolución".

En una red pequeña no es difícil mantener una tabla /etc./hosts en cada máquina, y modificarla al agregar, eliminar o modificar nodos. Pero resulta complicado cuando hay muchas máquinas ya que, en principio, cada una necesita una copia de /etc./hosts.

Una solución a esto es compartir ésta y otras bases de datos con el NIS, o sistema de información de red 17, desarrollado por Sun Microsystems y conocido también como paginas amarillas. En este caso, las bases de datos como la de /etc./hosts se mantienen en un servidor NIS central y los clientes accederán a ellas de forma transparente al usuario. En todo caso, esta solución solo es aconsejable para redes pequeñas o medianas, ya que implican mantener un fichero central /etc./hosts que puede crecer mucho, y luego distribuirlo entre los servidores NIS.

En Internet, se comenzó almacenando la información en un fichero similar al hosts, mantenido por el NIC, y obtenido regularmente por los demás servidores. Cuando la red creció comenzaron los problemas de sobrecarga de servidores, además de que el NIC tenia que ocuparse de todos los nombres de los nodos de Internet, y evitar la duplicidad de los mismos.

Por esto, en 1984 se diseño y adopto oficialmente un nuevo sistema, el DNS o sistema de nombres por dominios, diseñado por Paul Mockapetris.

DNS organiza los nombres de los nodos en una jerarquía de dominios. Un dominio es una colección de nodos relacionados de alguna manera, como estar en la misma red o pertenecer a una misma organización o país. Por ejemplo, las universidades norteamericanas se agrupan en el dominio edu, y cada universidad mantiene un subdominio dentro de edu. Nuestro ejemplo, la Universidad de Groucho Marx, mantendría el dominio gmu.edu y las máquinas del departamento de Matemáticas se encontrarían dentro del dominio maths.gmu.edu.

_____________________________________________
16 N. del T.: Domain Name System
17 N. del T.: Network Information System

De este modo el nombre completo de la máquina erdos será erdos.maths.gmu.edu. El nombre completo se conoce como nombre totalmente cualificado o FQDN18, e identifica a ese nodo en todo el mundo.

Figura 2.3: Parte del espacio de dominios

En la figura 2.3 se muestra una sección del espacio de dominios. La entrada de la raíz del árbol, que se indica con un punto, se puede denominar dominio raíz, y agrupa al resto de los dominios. Para indicar que un nodo se expresa en notación FQDN, se puede terminar el nombre en un punto, indicando así que el nombre incluye al del dominio raíz.

Dependiendo de su localización en la jerarquí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:

• edu Aquí se incluyen casi todas las universidades o centros de investigación norteamericanos.
• com Compañías u organizaciones con fines comerciales.
• org Organizaciones no comerciales. Las redes UUCP privadas se encuentran aquí.
• net Pasarelas y otros nodos administrativos de la red.
• mil Nodos militares norteamericanos.
• gov Nodos del gobierno norteamericano.
• uucp Oficialmente, todos los nombres de nodos UUCP sin dominio han sido movidos a este nuevo dominio, .uucp.

_____________________________________________
18 N. del T.: Fully Qualified Domain Name

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

Fuera de los Estados Unidos, existe un dominio de primer nivel para cada país, de dos letras según se define en la norma ISO-3166. Finlandia, por ejemplo, usa el dominio fi; el dominio de corresponde a Alemania y el dominio es corresponde a España. Cada paí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 com.au o edu.au) o directamente por organizaciones, como sucede en España (con dominios como upm.es para la Universidad Politécnica de Madrid).

Por supuesto, un nodo dentro del dominio de un país puede no estar físicamente en él. El dominio únicamente identifica al nodo como registrado en el NIC de ese país. Así, un comerciante sueco puede tener una delegación en Australia, y tener sus nodos australianos registrados dentro del dominio de primer nivel sueco, se.

Esta organización por dominios soluciona el problema de la unicidad de nombres. Además, los nombres totalmente cualificados no son difíciles de recordar.

Pero DNS tiene otras ventajas: permite delegar la autoridad sobre un determinado subdominio a sus administradores. Por ejemplo, los subdominios maths y physics de la UGM son creados y mantenidos por el Centro de Calculo de dicha universidad. Y si el mantenimiento del subdominio maths.gmu.edu fuese complicado (por número elevado de nodos, existencia de subdominios internos, etc.), el Centro de Cálculo de la UGM puede delegar la autoridad sobre ese subdominio al departamento de Matemáticas. La delegación de un subdominio implica el control total del mismo por parte de la organización en la que se delego, con total libertad para crear nuevos subdominios internos, asociar nombres a nodos, etc.

Para este fin, el espacio de nombres se divide en zonas, cada una asociada a un dominio. Nótese que existe una diferencia entre zona y dominio: el dominio groucho.edu incluye todos los nodos de la UGM, mientras que la zona groucho.edu incluye sólo los nodos que mantiene directamente el Centro de Calculo, ya que los nodos del subdominio physics.groucho.edu pertenecen a la zona controlada por el Departamento de Físicas. En la figura 2.3 se marca el inicio de una zona con un pequeño circulo a la derecha del nombre del dominio.

Trataremos aquí el problema de como resolver el nombre de un determinado nodo.

DNS es una gigantesca base de datos distribuida. Se implementa a través de los llamados servidores de nombres. Cada uno de éstos mantiene la información de uno o varios dominios.

Para cada zona hay al menos dos (o mas) servidores de nombres que mantienen información autorizada sobre los nodos de esa zona. Para obtener la dirección IP del nodo erdos, lo que hay que hacer es contactar con el servidor de nombres de la zona para groucho.edu y éste nos devolverá los datos pedidos.

Esto parece fácil de decir pero difícil de implementar pues nos preguntaremos como localizar al servidor de nombres de la UGM. Si su ordenador no implementa un adivino, le ayudara el DNS. Cuando su aplicación desea encontrar información acerca de erdos, contactara en primer lugar con un servidor de nombres local, quien realizara una búsqueda por otros servidores. Empieza por preguntar a un servidor de nombres raíz por erdos.maths.groucho.edu. Al comprobar este último que él no mantiene ese dominio, contactará con los servidores del dominio edu y les preguntara las direcciones de los servidores de nombres, que retornara al servidor local. Ahora nuestro servidor preguntara a estos últimos y éstos a su vez irán haciendo llegar a nuestro servidor hasta los que mantienen la zona groucho.edu. Finalmente, se preguntara a uno de estos últimos por el nodo erdos y se enviara la respuesta al usuario.

Aparentemente esto provoca mucho tráfico, aunque en todo caso siempre será menor que preguntar siempre a los mismos servidores que mantenían el fichero HOSTS.TXT antes de que se diseñará el DNS.

Sin embargo, aun se puede mejorar algo mas. La información obtenida en una búsqueda puede que se necesite después. Por ello, el servidor de nombres local la guardara en una cache local. Así, cuando volvamos a preguntar por un nodo de groucho.edu, el servidor local ya podrá dirigirse directamente el servidor de nombres de esa zona sin pasar por los servidores raíz.

Por supuesto, el servidor de nombres no puede mantener la cache eternamente; debe descartarla cada cierto tiempo. Este tiempo de expiración se conoce como TTL19 o tiempo de vida. En la base de datos del DNS queda especificado este parámetro.

Cuando un servidor de nombres mantiene toda la información acerca de una zona se le llama autorizado para esa zona. Cualquier petición para esa zona será enviada a uno de esos servidores maestros.

_____________________________________________
19 N. del T.: Time To Live

Para tener una representación coherente de la zona, sus servidores maestros deben estar sincronizados. Para ello, a uno de ellos se le nombra servidor primario, que obtiene la información de zona a partir de unos ficheros locales, y a los demás se les nombra servidores secundarios. Estos últimos cargan la información de la zona pidiéndosela 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í, si un servidor cae, todas las peticiones se repartirán entre los demás servidores autorizados que haya. Por supuesto, esto no protege contra fallos internos o bugs del propio software DNS.

Pero además, también es posible tener servidores de nombres que no mantengan información autorizada de ningún dominio20. Este tipo de servidores es útil pues, al mantener una cache con los nombres que resuelven, disminuye la carga de la red y de otros servidores.

En las bases de datos del DNS se mantiene mas información que la necesaria para traducir nombres a direcciones IP. Dicho de otra forma, en DNS se mantienen distintos tipos de registros.

La unidad de información en el DNS se conoce como registro de recurso o RR. Cada registro tiene un tipo asociado a él, describiendo que 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 MIT21). El registro mas habitual es el de tipo A, que relaciona un nombre totalmente cualificado con una dirección IP.

Un nodo puede admitir mas de un nombre. Pero solo uno de ellos será "oficial" o canónico, mientras que los demás son alias del primero. La diferencia es que el canónico se define en un registro de tipo A, mientras que los alias se definen en registros CNAME que apuntan al nombre canónico.

En un capítulo posterior se trata todo esto en profundidad. Aquí nos vamos a limitar a ver algunos ejemplos. En la figura 2.4 se muestra una parte de la base de datos para la zona physics.groucho.edu.

Además de los registros A y CNAME, se puede ver que hay un registro especial al principio del fichero, con varias líneas. Se trata del registro SOA o de inicio de autoridad, que mantiene información general sobre el servidor de nombres. Por ejemplo, el tiempo de vida por defecto de todos los registros que mantiene.

_____________________________________________
20 Aunque al menos deberá tener información autorizada para el localhost y la resolución inversa de 127.0.0.1
21 Instituto Tecnológico de Massachusets

Figura 2.4: Extracto del fichero named.hosts del departamento de Físicas.

Nótese que aquellos nombres que no finalicen en un punto serán interpretados como relativos al dominio en cuestión. El nombre especial "@" usado en el registro SOA representa al dominio completo.

Hemos visto que los servidores para el dominio groucho.edu deben tener conocimiento sobre los servidores de la zona physics para poder reenviarles las peticiones para ésta. Esto se suele incluir en los registros NS que incluyen el nombre de los servidores en notación FQDN, y un registro A que da la dirección IP para ese servidor. Véase, por ejemplo, la figura 2.5.

Figura 2.5: Extracto del fichero named.hosts de la UGM.

Además de la obtención de una dirección IP a partir del nombre, a veces interesa lo contrario: conocida la dirección, obtener el nombre canónico. Esto se conoce como traducción inversa y la utilizan algunas aplicaciones de red para verificar la identidad del llamante. Cuando se usa un fichero hosts, la resolución inversa supone una simple búsqueda en el mismo.

En cambio, para el DNS se ha creado un dominio especial, el in-addr.arpa, que contiene direcciones de los nodos en notación de puntos divisorios invertida. Por ejemplo, a la dirección IP 149.76.12.4 le corresponde el nombre 4.12.76.149.in-addr.arpa. El tipo de registro para estos datos se llama PTR.

Cuando se crea una zona de autoridad suele significar que sus administradores tienen control total sobre como 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ísicas (subdominio physics) al correspondiente Departamento. Las direcciones de resolución inversa también se delegan.

En la figura 2.6 se muestra el contenido del fichero de zona para el servidor de la subred 12. Los registros "importantes" de delegación se muestran en la figura 2.7.

Figura 2.6: Extracto del fichero named.rev de la subred 12.

Una importante consecuencia de esto es que las zonas solo pueden crearse como superconjuntos de redes IP, y además, las máscaras de red deberán redondearse a nivel de octeto. Es decir, las subredes de la UGM tendrán una máscara 255.255.255.0, y para cada subred deberá existir una zona in-addr.arpa. Sin embargo, si la máscara fuese 255.255.255.128, la creación de zonas para la subred 149.76.12.128 sería imposible ya que no hay forma de decir en DNS que el dominio 12.76.149.in-addr.arpa ha sido dividido en dos zonas de autoridad, con nombres de nodos desde el 1 al 127, y desde el 128 al 255, respectivamente.

Figura 2.7: Extracto del fichero named.rev de la red 149.76.