DNS
Estructura de la resolución de nombres
Dentro de la red inalámbrica, una vez que el tamaño permite la amplitud de cobertura y la gran cantidad de equipos conectados facilita la aparición de servicios, se hace necesario disponer de un servicio de resolución de nombres no solo exterior, si no tambien de los recursos internos de la red inalámbrica.
Existen muchas formas de hacer coexistir la resolución de nombres de internet con los servicios internos, pero no todas ellas resultan cómodas de mantener ni similares en el modo de funcionamiento a como en internet se estructura este servicio.
El objetivo del presente documento es explicar la estructura de dns elegida y el porqué, para conseguir que cualquier máquina cliente en el interior de la red inalámbrica pueda acceder a los recursos de forma óptima, independientemente de si el recurso se encuentra en el interior de la red inalámbrica o en el exterior (internet), esto es, si el recurso se encuentra en el interior, directamente, y si no, a través de internet.
Para ello, tambien deseamos permitir que cualquier persona pueda mantener su propio servidor dns en el que publique la zona que precise, y que todos los servidores dns de la red sepan, que es él, quien mantiene dicha zona. Para este último requerimiento, se hace necesario instalar un conjunto de servidores DNS raiz o que al menos actuen de forma similar a como lo hacen los servidores raiz en internet (más adelante veremos que no son realmente servidores zonales de la raiz ".").
Un espacio de nombres dns es el conjunto de nombres dns que son resolubles a dirección ip utilizando un determinado servidor dns.
Internet tiene un espacio de nombres principal, el que todos conocemos como "Espacio de nombres dns de Internet" o "Espacio de nombres ICANN/NSI", aunque no es el único (podemos encontrar por ejemplo OpenNIC, AlterNIC y The Pacific Root).
En el interior de la red inalámbrica es interesante disponer de un espacio de nombres propio para dotar a la red de autonomía en cuanto a resolución de nombres, aspecto este crítico para la disponibilidad de los servicios que se apoyan en nombres en vez de en direcciones ip (en la práctica, la gran mayoria de los servicios pueden apoyarse en direcciones ip, pero lo normal es que todos se apoyen en nombres dns).
Sin embargo, que este nuevo "Espacio de Nombres" interno sea capaz de resolver nombres, tanto internos como externos, es una necesidad, ya que, de solo disponer de resolucion de nombres interna, del nuevo espacio de nombres, no sería posible acceder a servicios del exterior de la red, detalle que a estas alturas no tiene ningún sentido.
Hacer que un conjunto de servidores de nombres dns resuelvan direcciones primero de un espacio de nombres y en caso de no encontrar respuesta consultar sobre otro espacio de nombres no es taréa facil, ya que el servicio de nombres dns no ha sido diseñado para ello, si para consultar sobre una bd y si no encuentra respuesta consultar sobre otra, pero ambas del mismo espacio de nombres. Pero existen formas de hacerlo mediante forwarding (más adelante).
NOTA IMPORTANTE: Dado el nivel de establecimiento de enlaces entre las comunidades wireless no parece lógico pensar en un solo espacio de nombres para el conjunto de todas las comunidades, si no de "islas" de grupos y nodos unidos que compartan un espacio de nombres. De momento parece lógico pensar que solo las comunidades "fuertemente enlazadas" compartan un espacio de nombres común. Esto provoca que puedan existir multiples espacios de nombres en las redes wireless libres en la actualidad.
Como es de esperar, la resolución interna debe evitar el uso de direcciones ip para el acceso a los servicios.
Algunos de estos servicios puede desearse que sean accesibles desde el exterior (Internet), por lo que en algún lugar otro servidor dns externo resolverá los nombres de dichos servicios.
Hasta este momento, la opinión general es de la linea de que resulta importante que la forma de nombrar a los servicios sea la misma en el interior que en el exterior, esto es, que un servicio se llame con un nombre independientemente del lugar desde el cual se acceda al servicio.
En ocasiones, además, estos servidores de nombres serán los mismos tanto para la resolución interna como externa, por lo que en dichos servidores se deberá utilizar el sistema de vistas (views) del servidor de nombres. Este tipo de configuraciones deberán ser realizadas de forma absolutamente manual y bajo las condicioes del servidor de nombres de que se trate, esto es, decidida por completo por el administrador de dicho dominio.
Uno de los deseos de la arquitectura de DNS buscada es que sea posible que cualquier persona aloje su propio servidor de nombres con el/los dominios que desee, al igual que en internet, esto es, que todo el conjunto de dominios que tengan servicios en el interior de la red wireless no precise estar alojado sobre un grupo reducido de servidores.
Este detalle complica el diseño, aunque en realidad lo asimila más a la forma de trabajo de internet.
Los servidores raiz del espacio de nombres interno de la red wireless tendrán que tener en cuenta este detalle para redirigir las peticiones de estos dominios a los servidores que alojan los servicios.
Entre las posibles arquitecturas, la única que hemos conseguido verificar que cumple los requerimientos sin necesidad de modificar código del servidor de nombres utilizado se basa en un sistema de forwarding directo, evitando la resolución iterativa típica de los servidores dns de internet. Esta ha sido la utilizada. En resumen, se trata de zonas forward en los servidores raiz con destino al servidor real de cada zona, y forwarders sobre estos anteriores sin servidores raiz para el resto de servidores dns.
La arquitectura que originalmente se pensaba montar era identica a la utilizada en internet, con servidores raiz realmente autoritativos para las zonas raiz (.net, .org, etc.), de manera que los servidores dns que desearan pertenecer a este espacio de nombres solo requerian cambiar su archivo de servidores raiz (típicamente db.root). Si embargo, con esta arquitectura no era posible de forma sencilla resolver nombres externos sin modificar el código del servidor de nombres utilizado.
Otra forma sobre la que se realizaron pruebas consistía en servidores raiz con zonas forward sobre los dominios internos, en vez de ser servidores de nombre de las zonas raiz, y los servidores dns no de raiz consultando a estos como raiz, sin embargo la resolución recursiva provocaba que las peticiones "se escaparan" del espacio de nombres cuando un cliente consultaba a un servidor no de raiz por un dominio interno, ya que este obtenía el servidor de nombres raiz de internet y la petición no alcanzaba a los servidores de nombres raiz internos.
Antes de "abandonar" el espacio de nombres de internet, el administrador de un nodo deberá estar seguro de lo que desea hacer. El procedimiento descrito a continuación solo es recomendable para servidores dns sin conexión directa con internet, en cuyo caso no habrá ningún tipo de pérdida de funcionalidad ni rendimiento, respecto a no tener servidor de nombres. Para los nodos con conexión a internet, la resolución de nombres será ligeramente más lenta, aunque la cache dns y el rápido funcionamiento del servicio lo harán casi inapreciable.
El siguiente procedimiento deberá ser modificado, no aplicado tal cual se describe, sobre los nodos con conexión directa a internet que publiquen en internet alguna zona dns.
Para hacer que un servidor de nombres utilice el espacio de nombres interno de la red wireless, hay que proceder a separarlo del espacio de nombres de internet, con el siguiente procedimiento:
-
comentar la sección de la zona "." en el fichero de configuración del servidor de nombres (named.conf para bind9):
// prime the server with knowledge of the root servers
// zone "." {
// type hint;
// file "/etc/bind/db.root";
// };
-
establecer la lista de forwarders a los que realizar consultas dns, mediante include, por comodidad de mantenimiento posterior, comentando el forwarders global, que estará en el interior del fichero "incluido":
include "/etc/bind/forwarders.conf";
// forwarders {
// 10.0.1.1;
// };
-
preparar procedimiento de autoactualización de fichero de forwarders. Existe un script en el servidor raiz central, accesible mediante ftp anónimo, en la url ftp://10.34.210.151/pub/rootserver, que deberá quedar en /etc/cron.daily, con permisos de ejecución, para que se realice la actualización del fichero de forwarders, diariamente, de manera que siempre se encuentre actualizado con los cambios que puedan surgir.
Un servidor raiz será recomendable, para evitar inconvenientes al conjunto de equipos del espacio de nombres, que cumpla en la medida de lo posible y de la major manera los siguientes requerimientos:
-
máxima disponibilidad (evidentemente, si varios servidores raiz fallan simultaneamente habrá grandes inconvenientes para los equipos que utilizan dicho espacio de nombres)
-
seguridad (física, del sistema operativo, etc., hasta donde sea posible)
-
alimentación ininterrumpida (siempre muy recomendable para un servicio de infraestructura)
-
menor número posible de servicios simultaneos además del servidor de nombres (si un servicio requiere intervención, reinicio, reconfiguración o provoca errores se verá afectada su disponibilidad, y dada su importancia este detalle debería tenerse en cuenta)
-
no alojar otros dominios ni utilizar vistas (servidor de nombres lo menos complejo posible para evitar errores derivados de configuraciones complejas)
-
buena conectividad con la mayor parte posible de la red (igualmente para evitar indisponibilidades y que los cortes en las comunicaciones lo "separen" del resto de servidores de nombres raiz). Inicialmente no parece buena idea comunicar dos servidores de nombres raiz por un tunel a través de internet, ya que el estado de las conexiones a internet utilizadas puede afectar negativamente en su comunicación y sincronización.
Es una buena y habitual recomendación ejecutar el demonio del servidor de nombres enjaulado en un chroot para mejorar su seguridad, aunque no es totalmente imprescindible.
En este momento (11 de Noviembre de 2003) están configurados como servidores raiz los servidores popi del cpd de GuadaWireless (en la subred del nodo guada02-cpd) y el nodo guada09. Ambos disponen de alojamiento con acceso "seguro", fuente de alimentación ininterrumpida y pocos servicios que puedan estorbarles.
Para la sincronización de las zonas forward entre los servidores raiz se utiliza el mismo script de la url ftp://10.34.210.151/pub/rootserver, que deberá quedar en /etc/cron.daily tambien, pero en su comienzo, se cambiará el valor de la variable ROLE por "secondary", para que el script actualice el fichero de dominios, y no el de forwarders. Los servidores raiz no cambian sus db.root de internet, para poder resolver los nombres externos, y en named.conf solo es necesario añadir al final la linea include que añade el fichero de reenvios de zonas que el script rootserver actualiza diariamente:
include "/etc/bind/domains.conf";
Los tipos de servidores que a continuación se muestran están siendo nombrados con los nombres que recibirian si en realidad la arquitectura no tratase de mezclar dos espacios de nombres, es decir, se les nombra por la función que desempeñarian en un entorno de espacio de nombres igual que el de internet, aunque físicamente actuan como servidores zonales o cache (no hay en realidad servidores raiz):
-
Tipo 1: Servidor raiz (en realidad implementado con un servidor zonal): tiene una gran lista de zonas forward hacia los servidores que sirven cada una de ellas. No sirve peticiones de clientes. Si un dominio no está en su lista, consulta en internet y devuelve resultado. Mantiene cache propia. Necesitan tener conexion a internet fiable para resolver las consultas de nombres externas.
-
Tipo 2:Servidor cache y opcionalmente zonal que NO publica dns en Internet: sirve peticiones a clientes. No consulta nunca en internet directamente (carece de root servers de internet en su configuración), y hace forward hacia los servidores raiz salvo para los dominios que aloje (en caso de que además de cache sea zonal). No necesitan conexion directa a internet.
-
Tipo 3: Servidor cache y opcionalmente zonal que publica dns en internet. Idem que el anterior, pero con vistas, y configuracion manual mantenida por el administrador, el decidirá si hace forward sobre un servidor raiz de la red inalámbrica o replica la lista de forward que mantienen los servidores raiz para poder usar su conexion a internet directamente y poder resolver a la vez todos los dominios internos. Puede o no tener servidores raiz de internet para resolver directamente sus peticiones al exterior, a decisión del administrador.
Ejemplo:
-
A es raiz
-
B es cache sin Internet master de zona dom1.com
-
C es cache con Internet master de zona dom2.com
Con la estructura propuesta, todos hacen forward sobre los raiz (estos deben ser confiables, disponibles y bien comunicados con internet, además de ser suficientes para que no se caigan todos a la vez), y solo hace falta mantener la lista de zominios forward en los raiz. La configuración de todos los cache/zonal sin conexion a internet es exactamente igual, salvo dominios publicados por determinados servidores, y la mayoría de los cache/zonal con conexion a internet tambien, salvo que publiquen dns en internet, en cuyo caso el administrador decidirá que hace, si usar forward sobre uno o varios servidores raiz o mantener la lista de forwarders para todos los dominios del espacio de nombres de la red inalámbrica.
A día 22/03/2006
-
10.34.210.152 (cpd-server): primario de guadawireless.net, n.guadawireless.net, guadawireless.org, 10.34.16-19.*, 10.34.208-211.*, secundario de 172.16.98.*, forward a root servers para el resto de dominios internos
-
10.34.16.1 (guada01): secundario de guadawireless.net, n.guadawireless.net, guadawireless.org, 10.34.16-19.*, 10.34.208-211.*, forward a root servers para el resto de dominios internos
-
10.34.17.97 (guada12): secundario de guadawireless.net, n.guadawireless.net, guadawireless.org, 10.34.16-19.*, 10.34.208-211.*
-
10.34.156.1 (azuq01): primario de azuquecawireless.net, 10.34.156-159.*, 172.16.98.*, 172.16.99.*, forward fisrt autoactualizable para el resto de dominios internos
-
10.34.158.1 (alov01): secundario de azuquecawireless.net, 10.34.156-159.*, 172.16.98.*, 172.16.99.*, forward first autoactualizable para el resto de dominios internos
-
10.34.210.151 (CPD): root server que hace forwarding a cada NS correspondiente a cada dominio publicado internamente
-
Varios en la red: primarios y secundarios del resto de dominios internos.
Se utiliza este script para las actualizaciones automáticas hechas a medida que cada cual quiera:
http://azuq01.azuquecawireless.net/dominios_internos_redlibre.php
Este documento es Copyright (C) 2003 Andrés Seco, GuadaWireless y otros.
Tienes permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia de Documentación Libre GNU (GNU Free Documentation License), versión 1.2 o posterior publicada por la Fundación para el Software Libre (Free Software Foundation), sin secciones invarientes, sin textos de portada y sin textos de trasera. Una copia de la licencia puedes encontrarla en http://www.gnu.org/copyleft/fdl.html, en la sección titulada "GNU Free Documentation License".
La información y otros contenidos que hay en este documento son lo mejor de nuestros conocimientos, sin embargo, hemos podido cometer errores. De manera que tu debes determinar si quieres seguir las intrucciones que aquí se te dan.
Nadie es responsable por cualquier daño que pueda sufrir tu ordenador y otras pérdidas derivadas del uso de la información contenida aquí.
LOS AUTORES Y MANTENEDORES NO SON RESPONSABLES POR CUALQUIER DAÑO PRODUCIDO POR ACCIONES TOMADAS EN BASE A LA INFORMACION CONTENIDA EN ESTE DOCUMENTO.
Por supuesto, estamos abiertos a todo tipo de sugerencias y correcciones sobre el contenido de este documento.
