Si vamos a tener una red TCP/IP, hay algunas tareas importantes que
realizar. Algunas de ellas son simplemente de tipo administrativo. La más
importante es crear un registro central de nombres y direcciones IP. Existen
organizaciones que realizan esta labor para toda la red Internet. Si estamos
conectados a Internet, el administrador de nuestro sistema necesita
registrarse a una de estas organizaciones, para que cualquier demanda por
parte de otra institución sobre nuestros hosts
sean dirigidos a
nuestros servidores.
Queremos mantener una base de datos que contenga la información de cada
sistema de la red. Como mínimo, necesitaremos el nombre y la dirección IP de
cada sistema. Probablemente, el registro central será el encargado de
asignar las direcciones IP. Si nuestra red está estructurada en subredes, o
si usamos varios números de clase C, el registro posiblemente asignará los
números de red a las nuevas redes o subredes. Pero, habitualmente, se
permitirá que los propios administradores de los hosts
elijan el nombre
del host. Sin embargo, el registro debe de, al menos, verificar que no haya
nombres duplicados. Si estamos trabajando con una gran red, puede que sea
buena idea delegar algunas de estas tareas a subregistros, posiblemente uno
para cada departamento.
Se recomienda asignar las direcciones de la forma más simple: empezando por
1. Así, si nuestra red es la 128.6, podríamos asignar como 128.6.1 a la
primera subred; 128.6.2, a la segunda, etc. La asignación de direcciones IP
para hosts
individuales podrían empezar por 2. De esta manera
reservamos la dirección 1 de cada subred para que sea usada por el
gateway
correspondiente. Por consiguiente, el primer host
de la
subred 128.6.4 sería el 128.6.4.2; el siguiente sería 128.6.4.3, y así
sucesivamente. Hay una razón básica para mantener las direcciones tan cortas
como sean posibles. Si tenemos una gran organización, podríamos quedarnos
sin números de subred. Si esto ocurriera, y nuestros hosts
tienen
números de red bajos, podríamos asignar otro bit para el direccionamiento de
las subredes. Si, por ejemplo, usamos el tercer octeto como número de
subred, en tanto en cuanto nuestros hosts
tengan unos números
inferiores a 128, podremos ampliar el número de red a 9 bits. Así, por
ejemplo, la subred 128.6.4 podría dividirse en dos subredes distintas:
128.6.4.0 y 128.6.4.128. Si hubiésemos asignado a los hosts
números por
encima de 128, la división habría sido imposible.
La asignación de nombres de los hosts
no es tan sistemática. Pueden ser
cualquier expresión compuesta de letras, números y guiones. Es más seguro
que el primer carácter sea una letra. Y, desde el punto de vista de los
usuarios, es recomendable que los nombres sean lo más cortos posibles
(incluso hay software
que tiene problemas trabajando con nombres más
largos de 16 caracteres). Muchas veces, los departamentos o proyectos
eligen un tema o nombre relacionado con ellos. Por ejemplo, las máquinas
usadas por los estudiantes de Informática de Rutgers tienen nombres de
bandas de rock: OASIS, BLUR, IRONMAIDEN, SAVOY, etc. Nuestro departamento de
Matemáticas usa el nombre de famosos matemáticos: GAUSS, FERMAT, etc. Si la
institución no tiene ninguna relación con el mundo exterior, cualquier
nombre es adecuado.
Si estamos conectados a Internet, nuestra organización necesitará un "nombre de dominio" (domain name). Al igual que en el caso del espacio de direcciones IP, la autoridad máxima del espacio de nombres de Internet (DNS, Domain Name System) es la IANA (Internet Assigned Number Authority). La raíz del DNS es gestionada por el InterNIC por delegación de la IANA. Bajo la raíz se encuentran los distintos dominios de primer nivel (Top Level Domains o TLD's) gestionados por distintos registros delegados de Internet. Algunos de ellos son: Dominios "especiales" como COM, ORG, NET, EDU,... controlados por InterNIC ( nodo central del Network Internet Center ); y dentro de los dominios nacionales, el dominio ES, correspondiente a España, está delegado a ES-NIC.
A diferencia del número de red, podremos arreglárnosla sin él si la red está aislada. Si posteriormente lo necesitamos, es fácil de añadir un nombre de dominio. (Recomendamos usar un número de red desde el principio, porque cambiar números de red posteriormente puede ser traumático). Los nombres de dominio, normalmente, terminan en .EDU para las instituciones educativas, .COM, para las compañías, etc. Por ejemplo, la Universidad de Rutgers tiene como nombre de dominio RUTGERS.EDU. El formato de los nombres completos de dominio consiste en un nombre interno, seguido del nombre de dominio de la organización. Así, si un ordenador es conocido internamente como GAUSS, su nombre completo será GAUSS.RUTGERS.EDU. Si tenemos una gran organización, es posible tener subdominios. Por ejemplo, puede que haya un subdominio para cada departamento; esto añadiría otro término en los nombres. Si, por ejemplo, el departamento de Matemáticas decide crear su subdominio, el anterior ordenador se llamaría GAUSS.MATHS.RUTGERS.EDU. Una vez asignado el nombre de dominio, se procede a cambiar los ficheros de configuración donde aparece la forma completa del nombre. En algunos casos, se pueden usar apodos o nombres cortos, de manera que no será necesario incluir el nombre completo.
Si tenemos más de uno o dos sistemas, necesitaremos tener algún mecanismo
para tener al día la información de los distintos hosts
. El
software
TCP/IP necesita ser capaz de traducir nombres de hosts
en
direcciones IP. Cuando un usuario intenta conectarse con otro sistema,
generalmente se referirá a él usando su nombre. El software
tendrá que
traducir el nombre en una dirección IP, para poder abrir la conexión. La
mayoría del software
incluye dos vias para hacer esta traducción: una
tabla estática o un servidor de nombres. La solución de la tabla está
indicada para pequeñas organizaciones, siempre y cuando no estén conectadas
a otra red. Simplemente se crea un fichero que lista los nombres y
direcciones de todos los hosts
. Veamos parte de una tabla de este tipo:
HOST: 128.6.4.2, 128.6.25.2: ARAMIS.RUTGERS.EDU, ARAMIS: SUN-3-280: UNIX ::
HOST: 128.6.4.3: GAUSS.RUTGERS.EDU, GAUSS: SUN-3-180: UNIX ::
HOST: 128.6.4.4, 128.6.25.4: ATHOS.RUTGERS.EDU, ATHOS: SUN-4-280: UNIX ::
Como se puede apreciar, el formato es el siguiente: una línea para cada
sistema y listar sus direcciones, nombres y otra información sobre él. En el
ejemplo, tanto ARAMIS como ATHOS están en dos redes, así que tienen dos
direcciones. Además, ambos tienen un nombre principal, por ejemplo
ARAMIS.RUTGERS.EDU, y apodos, por ejemplo ARAMIS. En caso de estar
conectados a Internet, el nombre principal será el nombre de dominio
completamente especificado. Se incluyen apodos cortos, para facilitar la
tarea a nuestros usuarios. Hay otro formato muy frecuente para las tablas de
hosts
. Veamos un ejemplo:
128.6.4.2 aramis.rutgers.edu aramis
128.6.25.2 aramis.rutgers.edu aramis
128.5.4.3 gauss.rutgers.edu gauss
128.6.4.4 athos.rutgers.edu athos
128.6.25.4 athos.rutgers.edu athos
En este formato, cada línea representa una dirección IP. Si el sistema tiene dos interfaces, hay dos líneas de él en la tabla. Se debe procurar poner, en primer lugar, aquellas direcciones de uso más común. La documentación de su sistema le informará sobre el formato usado por él.
En la configuración más simple, cada ordenador tiene su propia copia de la
tabla de hosts
en /etc/hosts. En caso de elegir esta configuración,
deberemos establecer procedimientos para asegurarnos que todas las copias
son actualizadas regularmente. 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. Aunque 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 ( Network Information System ), desarrollado por Sun Microsystems y conocido también como páginas amarillas o YP. 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 sólo 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 redes grandes, y todos aquellos que están conectados a Internet, debemos
adoptar un nuevo sistema, el DNS o sistema de nombres por dominios (Domain
Name System) diseñado por Paul Mockapetris. Técnicamente, el DNS es una
inmensa base de datos distribuída jerárquicamente por toda la Internet;
existen infinidad de servidores que interactúan entre si para encontrar y
facilitar a las aplicaciones clientes que los consultan la traducción de un
nombre a su direccion de red IP asociada, con la que poder efectuar la
conexión deseada. Cada parte de la base de datos está replicada en, al
menos, dos servidores, lo que asegura una debida redundancia. Un servidor de
nombres es un programa que se ejecuta en algunos de nuestros sistemas para
tener conocimiento de los nombres. Cuando un programa necesita buscar un
nombre, en lugar de hacerlo en una copia de la tabla de host
, envía una
petición al servidor de nombres. Este enfoque tiene dos ventajas:
Usar un servidor de nombres es el único camino para tener un acceso completo
a la información del resto de los hosts
de Internet.
Es importante comprender la diferencia entre un servidor de nombres y un
resolvedor. Un servidor de nombres es un programa que tiene acceso a una
base de datos de hosts
, y responde peticiones de otros programas. Un
resolvedor es un conjunto de subrutinas que pueden cargarse con un programa.
El resolvedor genera las peticiones que se enviarán al servidor de nombres,
y procesa sus correspondientes respuestas. Cada sistema debería usar un
resolvedor (en general, el resolvedor es cargado por cada programa que va a
hacer uso de la red, puesto que sólo es un conjunto de subrutinas). Hay que
recalcar que sólo se necesitarán unos pocos servidores de nombres. Mucha
gente confunde los dos enfoques y llega a creer que es necesario tener un
servidor de nombres en cada ordenador.
Para usar un resolvedor, cada ordenador necesitará un fichero de
configuración, u otro método, para especificar la dirección del servidor de
nombres al que enviar nuestras peticiones. Por regla general, se pueden
declarar varios servidores de nombres, para el caso de que alguno de ellos
no funcione correctamente. En el caso de que nuestro sistema no pudiera
contactar satisfactoriamente con ningún servidor, la mayoría de nuestro
software
empezaría a fallar. Por tanto, hay que ser muy cuidadoso y
declarar tantos servidores como podamos para intentar asegurar un buen
funcionamiento.
Los servidores de nombres, generalmente, tienen un conjunto de opciones para
su configuración. En lugar de dar algunos consejos sobre cómo configurar un
servidor de nombres, vamos a recomendar dos documentos oficiales de los
estándares de Internet. El RFC 1032 contiene las instrucciones sobre cómo
conseguir un nombre de dominio del Centro de Información de Red, incluyendo
los formularios necesarios. El RFC 1033 contiene las instrucciones sobre
cómo configurar un servidor de nombres. Todos estos documentos son de tipo
conceptual. Seguramente, también necesitará documentación sobre el
software
específico de su servidor de nombres.
En algunos casos, puede que se necesiten, a la vez, tablas y servidores de
nombres. Si tenemos alguna implementación de TCP/IP que no incluyan
resolvers
, estamos obligados a instalar tablas de hosts
en estos
sistemas. Si nuestra red está conectada a Internet, vamos a tener problemas
con aquellos sistemas que no dispongan de resolvers, ya que Internet es
demasiado grande para tener unas tablas de hosts
de todos sus
hosts
. Por lo tanto, lo que se puede hacer es incluir una tabla de
hosts
con los hosts
que realmente se tiene pensado usar. InterNIC
tiene a su cargo una tabla de host
que puede ser un buen punto de
comienzo, aunque no es completa de ningún modo. Así que tendremos que añadir
los hosts
favoritos de los usuarios. Los sistemas que usan
resolvers
no tendrán este problema, puesto que un servidor de nombres
es capaz de traducir cualquier nombre legal de host
.
Los nombres de hosts
y la asignación de números son los únicos elementos que
deben de tener una estructura centralizada. Sin embargo, puede haber otros
elementos susceptibles de centralización. Es bastante frecuente tener uno o
dos ordenadores que se hagan cargo de todo el correo electrónico. Si estamos
conectados a Internet, es bastante simple establecer comunicaciones con
otros ordenadores de Internet. No obstante, hay muchas instituciones que
quieren comunicarse con sistemas de otras redes, como Bitnet o Usenet. Hay
gateways
entre varias de estas redes. Pero la elección del gateway
correcto, y transformar la dirección de correo electrónico correctamente, es
una tarea muy especializada. Por esto, en muchas ocasiones se configura el
software
apropiado sólo en un lugar, y todo el correo externo (o todo
el correo externo a hosts
que no están en Internet) se dirige a este
sistema.