Boletín de RedIRIS n. 52

Web-DNS. Actualización descentralizada del Servidor de Nombres de Dominio de la Universidad de Sevilla

Daniel Daza y Gustavo Rodríguez

1.- ¿Que es Web-DNS

Web-DNS es una aplicación basada en Web para la gestión descentralizada de la Base de Datos del Servidor DNS de la Universidad de Sevilla.

2.-Introducción. Un poco de historia

El mantenimiento del servidor primario del DNS de la Universidad de Sevilla (dominio us.es), está encomendado al Centro de Proceso de Datos (CPD) que tiene la responsabilidad de la gestión del espacio de direcciones IP propio y la asignación de éstas, a las distintas redes de área local que forman la Red Informática de la Universidad de Sevilla (RIUS).

Una característica peculiar de ésta Universidad es la dispersión geográfica que presentan sus campus, de los que existen tres de gran tamaño con más de 15.000 alumnos y varias facultades y escuelas, dos de tamaño medio con más de 3.000 alumnos y otros cinco con una sola escuela o facultad, pero con un número mínimo de 1.500 alumnos; lo que hace un total de veinticinco escuelas o facultades, a los que hay que añadir otros centros de menor tamaño, que proporcionan servicios a la comunidad universitaria.

Por otro lado si bien existe en algunos campus, personal que puede realizar labores de apoyo informático, la mayor parte de los centros carecen de él, por lo que las tareas han de hacerse por el propio personal del CPD.

La Universidad de Sevilla no ha sido ajena al BOOM general que se ha producido en la demanda de conexiones a la red en los últimos años, aumentado más si cabe en nuestro caso, por la coincidencia con la dotación de una infraestructura de comunicaciones basada en ATM, que ha permitido al usuario la obtención de un ancho de banda apreciable.

En un principio el usuario que quería conectarse a la red, solicitaba al CPD una dirección IP y para ello rellenaba un formulario, en el que indicaba los datos más esenciales de la maquina (tipo, modelo, número de serie, dirección ethernet, etc.) y los suyos propios (nombre, teléfono, etc.). Estos datos se completaban con otros añadidos por los responsables del servicio (dirección IP, máscara de red, gateway, etc.) y el conjunto constituía el documento formal de control que permitía la conexión. Sin embargo, era el propio usuario el que explícitamente tenía que solicitar que se diera de alta la máquina en el DNS, aunque posteriormente en cualquier momento podía solicitarlo.

(Figura 1)

Como es natural cuando la demanda no era grande, no había muchos problemas derivados de la recepción y el proceso manual de las solicitudes, pero en el caso de que se diera una actuación sobre el DNS (alta, baja, modificación), si había que afrontar la posibilidad de errores al manipular los ficheros de la Base de Datos del DNS.

Al aparecer en la red la posibilidad de acceder a la información por medio de navegadores Web, se diseñó una página en el servidor del CPD con un formulario similar al de papel cuyo acceso, en un principio, se restringió por medio de un nombre de usuario y una palabra de paso y posteriormente mediante la colocación del formulario en un Servidor Web seguro. A este sistema solo podían acceder el personal de apoyo de cada Campus y el personal del CPD. Cada solicitud generaba un correo que formalizaba la petición. Con esto se consiguió reducir el tiempo de llegada de la solicitud.

Una vez recibida la petición, esta debía ser procesada manualmente. Se tenían que comprobar los datos de la petición y modificar la Base de Datos del Servidor DNS con toda la problemática que esto lleva consigo: realización de una copia de seguridad, actualización "a mano" de los ficheros de la Base de Datos, re-inicializar el servidor de DNS para que los cambios tuvieran efecto, comprobar el correcto funcionamiento, archivar la petición y comunicar que la petición se había realizado.

(Figura 2)

3.- Necesidades

Se planteó la posibilidad de agilizar todo lo posible este proceso. Conseguir al mismo tiempo simplificarlo y reducir la posibilidad de errores. Crear una aplicación que automatizara todo lo posible la parte manual del proceso.

Lo ideal seria que desde los centros periféricos en los que fuera posible, se pudiera actualizar directamente la Base de Datos del Servidor DNS de manera automática, pero manteniendo dos criterios: que dicha actualización fuera segura y fácil de realizar. Crear una aplicación que accediera a la Base de Datos, pero aislando la complejidad del formato de la misma de manera que fuera fácil realizar las actualizaciones y al mismo tiempo, que las actualizaciones fueran correctas, sin errores e inmediatas.

Para los casos en que se tuviera que modificar los datos de un sistema y éste se encontrara en un Centro que no dispusiera de personal de apoyo, se podría seguir realizando la petición mediante el formulario en papel, pero en vez de actualizar la Base de Datos del DNS manualmente, la realizaría algún miembro del Grupo de Comunicaciones del CPD utilizando la aplicación.

Insistiendo en el criterio de la seguridad, se pretendía además de impedir que personas desconocidas pudieran manipular los datos del Servidor DNS, garantizar que las personas que accedieran a la aplicación solo pudieran manipular la información que les afectara directamente. Cada centro periférico tiene un rango de direcciones asignadas, ciertas subredes sobre las que tienen una responsabilidad más directa. No debería ser posible que desde un Centro Periférico se pudieran hacer modificaciones que afectaran a otro Campus o más aun a la generalidad de la Red de la Universidad.

Por otra parte se exigía que el proceso manual continuara siendo posible, para casos especiales, aquellos que no contemplara la aplicación o simplemente para el control por parte de los gestores del Servidor DNS.

Otro requisito era que se siguiera teniendo constancia de las modificaciones que se realizan sobre la Base de Datos del Servidor DNS, en forma de correo para su posterior archivo en papel.

En general estos fueron los requisitos previos que se tuvieron en cuenta al desarrollar la aplicación, pero luego surgieron otros. Por ejemplo, se planteo lo útil que seria tener una base de Datos que guardara las direcciones Ethernet asociadas a las direcciones IP. Hasta ese momento, ésta información solo constaba en los archivos en papel de cada petición y dicha información no es posible almacenarla en la base de datos del Servidor DNS.

También se planteo que dicha aplicación pudiera ser utilizada como herramienta de consulta de la Base de Datos del DNS y poder realizar por ejemplo: listados por subredes, consultas por nombres de Host, estadísticas de ocupación de subredes, o obtener esa información que siempre resulta tan importante a la hora de configurar el protocolo TCP/IP en una maquina, como es su gateway de salida y su máscara de red.

4.- Solución

De éstas necesidades surge la aplicación Web-DNS. Ésta consta de una serie de páginas Web con formularios de entrada de datos, páginas Web de salida de resultados, programas CGI y tres ficheros de configuración. La aplicación es muy modular: hay un proceso CGI para cada acción típica (un CGI para dar de alta, un CGI para realizar consultas por dirección IP, etc.) por lo que resultaría muy fácil ampliarla con nuevas funciones.

A la aplicación se accede desde uno de los Servidores Web Seguros del CPD de la Universidad de Sevilla, de tal forma que su uso está restringido a determinados usuarios que desde los centros periféricos realizan las actualizaciones y a los miembros del grupo de Comunicaciones del CPD.

De manera fácil y a través de menús, el usuario puede realizar las tareas típicas que se pueden realizar con cualquier aplicación de Base de Datos: altas, bajas, modificaciones, consultas, listados y estadísticas. Cualquier persona que tenga acceso al Servidor Seguro, puede acceder a la aplicación en modo consulta, en este caso, además de los operadores de los Centros Periféricos, todo el personal del Centro de Proceso de Datos.

(Figura 3)

5.- Entorno Tecnológico

La aplicación se desarrolló con herramientas muy simples: un editor de texto para hacer las páginas Web y los script, y un par de compiladores de C (Borland C 3.1 para DOS durante la programación y depuración y GNU C 2.7.2.3 para obtener la aplicación definitiva). La primera versión de la aplicación se realizo en unos 6 meses. Gracias a la modularidad y a la buena acogida por parte de los usuarios, se ha seguido ampliando las capacidades de la aplicación a lo largo de estos dos últimos años.

En cuanto a los requisitos para la instalación y ejecución de la aplicación en el servidor, es aconsejable que tanto el Servidor primario DNS como el Servidor Web en el que se ejecute la aplicación, estén en la misma maquina, ya que los CGI de la aplicación acceden directamente a los ficheros de la Base de Datos. Si la aplicación y el Servidor DNS no se encontraran en la misma maquina, se podría utilizar algún sistema que permitiera exportar el directorio de la Base de Datos para que fuera accesible por la aplicación. La aplicación se ha desarrollado para Sistemas tipo Unix. Por otra parte, dadas las necesidades de seguridad, el servidor Web debe de usar el protocolo SSL y autentificación de cliente.

En nuestro caso tanto el Servidor primario de DNS como el Servidor Web seguro residen en un IBM Risc 6000 con Sistema Operativo Aix versión 4.2, 128 Megabytes de memoria, 1'5 Gigabytes de disco, Servidor Web Netscape Enterprise Server versión 2.01 e inicialmente Bind versión 8.1 aunque recientemente se ha cambiado a la versión 8.2.2. El Servidor Web ejecuta exclusivamente la aplicación Web-DNS.

En cuanto a los requisitos en los clientes, a nivel de software: Una pila TCP/IP y disponer de un navegador de Web compatible con el protocolo SSL y que disponga capacidades de visualización de Frames (marcos) y ejecución de JavaScript. En cuanto al hardware, cualquier ordenador que sea capaz de ejecutar dicho software. Lo más habitual es el uso de PC con sistema operativo Windows 95 y Netscape Comunicator Versión 4.5 como navegador Web.

6.- Uso de Web-DNS

La aplicación Web-DNS es muy fácil e intuitiva de usar. Al acceder a la misma mediante un navegador aparecen dos zonas bien diferenciadas. En la parte superior, el menú de la aplicación con los botones de todas las opciones disponibles, y en la parte inferior el formulario de Altas que aparece por defecto siempre al iniciar el programa Web-DNS. Pulsando sobre los distintos botones del menú aparecerán en la parte inferior las páginas con los formularios asociados a las distintas opciones del programa. La aplicación consta de dos opciones de menú: uno para realizar operaciones sobre Host, y otro para realizar operaciones sobre direcciones e intercambiadores de correo.

Cuando se accede a la aplicación Web-DNS, lo hacemos usando un cierto usuario. El Servidor Web seguro recibe el certificado del cliente e identifica el certificado con un nombre de usuario y éste nombre se le proporciona a la aplicación. Dependiendo del usuario, Web-DNS nos permitirá realizar ciertas acciones de acuerdo con el perfil definido en la aplicación para ese usuario.

Se han creado una serie de usuarios que se corresponden con los operadores que existen en los distintos Campus de la Universidad de Sevilla, además de los que existen dentro del propio CPD. Dependiendo del usuario con el que se accede a la aplicación, se pueden realizar modificaciones sobre ciertas redes y ciertos dominios. Esto permite mantener la seguridad de que una persona no pueda realizar modificaciones en redes o dominios que son responsabilidad directa de otras personas o son generales de toda la Red Universitaria.

Si una persona intenta realizar una modificación que no esta de acuerdo con su perfil, se genera un mensaje de error. Este mensaje aparece en el navegador y además es notificado al CPD mediante un correo.

Las restricciones de seguridad solo afectan a las altas, bajas y modificaciones. Para las demás operaciones, Web-DNS no comprueba la identidad y, por tanto, pueden realizarlas cualquier persona que pueda acceder al Servidor Web seguro (cualquier persona que disponga de un certificado de nuestra Autoridad de Certificación).

Si por ejemplo queremos realizar un alta de una maquina, se accede a la página respectiva, se rellenan los campos del formulario que se nos presenta y se pulsa el botón para enviar los datos. La aplicación en el servidor, procesa los datos y si son correctos actualiza la Base de Datos del DNS y nos devuelve el resultado. Si los datos introducidos en el formulario no son correctos, se muestra una página de error informando al usuario de dicha circunstancia.

(Figura 4) (Figura 5)

El menú de mantenimiento de Host, consta de consta de 8 opciones:

  • Altas: Desde éste formulario se realizan las altas de Host en el Servidor DNS. Además también se utiliza para crear nuevos Alias de Host y añadir nuevas direcciones IP a Host ya existentes en la Base de Datos del DNS.

  • Bajas: Éste formulario se utiliza para realizar bajas de Host. Ya sea dar de baja una dirección IP de un Host (si esté tuviera varias direcciones) o dar de baja completamente el Host. También desde esté formulario se pueden dar de baja nombres de Alias de Host.

  • Modificaciones: Desde éste formulario se realizan las modificaciones en la dirección IP de un Host y/o modificaciones en el nombre de un Host. También se pueden hacer modificaciones en el nombre de un Alias de un Host y modificaciones en la dirección Ethernet de una Dirección IP.

  • Consultas: Con éste formulario se realizan consultas por dirección IP, dirección Ethernet y varios tipos de consulta por nombre (de Host o de Alias).

  • Listados: De igual forma, desde éste formulario se realizan los listados por direcciones IP y direcciones Ethernet.

  • Logs: Desde ésta opción se puede consultar los ficheros históricos de acciones y errores que se generan al ejecutar la aplicación. Por ejemplo, cada vez que un usuario realiza un alta o una consulta, o cada vez que al usar la aplicación, se produce un error, se guarda en el histórico la acción, el usuario, fecha y hora y la dirección IP desde donde se realizó. Los usuarios normales solo pueden consultar los logs de acciones o errores que han provocado ellos mismos, mientras que los administradores pueden consultar todo el Histórico.

  • Estadísticas: Desde ésta opción se pueden obtener estadísticas gráficas de la Base de Datos del Servidor DNS sobre los dominios, subredes e intercambiadores de Correo.

  • Peticiones: Está opción es una puerta abierta que permite a los usuarios que no tienen derechos para realizar una cierta acción con la aplicación Web-DNS, que soliciten una petición completando esté formulario, y un miembro del grupo de comunicaciones del CPD la comprobará y realizará.

El menú de mantenimiento de direcciones de Correo, tiene 5 opciones:

  • Altas: Desde éste formulario se realizan las altas de Direcciones de Correo. Se puede crear la relación de un Host real o una Dirección de Correo virtual con un Host que actuara como Intercambiador de Correo del Host o Dirección.

  • Bajas: De igual forma, éste formulario se utiliza para realizar bajas de Direcciones de Correo.

  • Modificaciones: Desde éste formulario se pueden realizar modificaciones en las Direcciones de correo: se pude modificar los nombres y dominios de la Dirección de Correo, del Intercambiador de Correo o el valor de preferencia.

  • Consultas: Con éste formulario se realizan consultas de Direcciones de Correo. La utilidad de éste formulario está en que si se utiliza la consulta de Host para buscar Direcciones de Correo virtuales, éstos no aparecerán ya que no existen como Host reales (no tienen dirección IP). Se puede utilizar está consulta para estos casos.

  • Logs: Igual que en el menú de mantenimiento de Host.

7.- Funcionamiento de Web-DNS

Asociado a cada formulario existe un programa CGI. Estos programas son Shell-Script que a su vez llaman a programas binarios escritos en C. Los Shell-Script se encargan fundamentalmente de crear un entorno adecuado para la ejecución de los binarios. Se definen parámetros de entorno con las rutas a los ficheros de la Base de Datos del DNS y de configuración del Web-DNS. Además, se encargan de generar la estructura general del documento HTML que se devuelve al navegador; llaman al binario y dependiendo del resultado de éste, se envía el correo al grupo de Comunicaciones de CPD con los datos del formulario y se imprimen dichos datos.

Los binarios se encargan del resto: reciben los parámetros del formulario y los comprueban. Si son correctos, se realiza una copia de seguridad de los ficheros afectados, se actualizan los Serial de los ficheros a modificar y se realiza la modificación en la Base de Datos. Una vez realizado esto, se genera el núcleo del documento HTML que se le enviara al usuario y el contenido del correo. El correo con los datos de la petición se envía tanto a la persona que la produjo como a los miembros del Grupo de comunicaciones del CPD. Si los datos son incorrectos, generan el núcleo de la página HTML con el mensaje de error.

(Figura 6) Organigrama de funcionamiento del proceso de altas

Una de las características más interesantes de Web-DNS es la generación de formularios dinámicos. Los formularios de la aplicación contienen campos con valores por defecto, como por ejemplo los sudominios o las subredes de RIUS. Si se crea un nuevo subdominio, habría que cambiar todas las páginas Web que contienen esa información. Los formularios no contienen esta información de manera estática, sino que contienen variables que son resueltas en tiempo de ejecución consultando el fichero named.conf. Cuando un usuario pulsa uno de los botones de acciones de los menús, no recibe directamente la página Web con el formulario, sino que un proceso CGI interpreta la página con el formulario resolviendo las variables que se encuentre. Así, realizando los cambios oportunos en named.conf, siempre los formularios que recibe el usuario están actualizados.

Web-DNS permite dos modos de funcionamiento. Uno, para cada petición de alta, baja o modificación, una vez que se ha hecho la modificación sobre los ficheros de la Base de Datos, se genera una señal de re-inicialización del demonio named para que los cambios tengan efecto inmediato. El otro modo, es diferido: se realizan las modificaciones oportunas sobre los ficheros de la Base de Datos, pero no se re-inicializa el named. Hay un proceso periódico en el sistema que re-inicializa el named para que se tengan en cuenta todos los cambios realizados. Nosotros utilizamos éste segundo sistema.

Por otra parte, teniendo en cuenta que éste programa puede ser utilizado por varias personas al mismo tiempo, y que esto podría provocar problemas de concurrencia en el acceso a los ficheros de las Bases de Datos, se ha usado como método de seguridad un semáforo para la aplicación. En este caso, se ha definido un semáforo con dos posibles valores: verde y rojo, como los semáforos de circulación. Cuando un usuario realiza una petición, se ejecuta el CGI asociado a la petición. Nada mas iniciarse el CGI, intenta colocar el semáforo en rojo para apropiarse en exclusividad de las Bases de Datos y que ningún otro usuario pueda realizar una modificación mientras se este procesando la suya. Al terminar, se vuelve a colocar el semáforo en verde y finaliza su ejecución. Si un CGI intenta colocar el semáforo en rojo y ya lo está (la Base de Datos esta en uso por otro usuario), el proceso espera hasta que se libera y pueda poner el semáforo en rojo.

Los registros SOA de los ficheros de la Base de Datos del DNS tienen un elemento llamado Serial. El Serial es un código numérico que indica cuando fue la ultima vez que se modifico el fichero. El formato es aaaammddcc, donde aaaa es el año, mm es el mes, dd es el día y cc es él numero de versión dentro de ese día. Web-DNS cada vez que realiza una modificación en algún fichero que tenga Serial, actualiza el valor del mismo. Además realiza una copia de seguridad de todos los ficheros que modifica, con el mismo nombre pero añadiéndole al final del nombre el carácter '_' y el año, mes y día de la actualización. Web-DNS siempre realiza copias de seguridad ante cualquier modificación y nunca borra físicamente ninguna línea de los ficheros sino que comenta las líneas.

Como el primer código cc que se utiliza es el 01 y el mayor posible con dos dígitos es 99, se puede observar que solo son posibles un máximo de 99 modificaciones en un fichero de la Base de Datos del DNS en un día. De echo, en la actual implementación, el programa no permite mas modificaciones sobre un fichero si ya se encuentra al mismo con el valor de serial a 96. Se reserva los siguientes valores para actualizaciones "a mano" de urgencia.

8.- Ficheros de configuración de Web-DNS

Las versiones mas modernas del Bind tienen como principal fichero de configuración a 'named.conf' (Web-DNS también es capaz de manejar el fichero ‘named.boot’ que se usa en versiones anteriores). Existen además otros ficheros de configuración para la propia aplicación Web-DNS:

  • 'dns.cfg': Contiene información necesaria para dar de alta en la Base de Datos del DNS. Por cada dominio y subred, se indica en que fichero del DNS hay que realizar el alta. También incluye las distintas máscaras de red y los gateway de salida.

  • 'usersdns.cfg': Contiene la información referente a los perfiles de cada usuario con la aplicación Web-DNS.

  • 'ethernet.cfg': Contiene la ruta donde se encuentra la Base de Datos de direcciones Ethernet y sus ficheros. Por analogía podríamos decir que 'ethernet.cfg' es en la Base de Datos de direcciones Ethernet lo que 'named.conf' es en la base de Datos del DNS.

Puede darse el caso de que si usamos directivas 'include' en los ficheros directos de la Base de Datos del DNS, la información que nos proporciona 'named.conf' no sea suficiente para saber en que fichero tenemos que dar de alta una cierta dirección IP. Se usa 'dns.cfg' para obtener dicha información. Por cada dominio e intervalo de red, se indica en que fichero directo hay que realizar el alta. Además, como información que se proporcionara en las consultas, también se guarda la máscara de red y el gateway respectivo del intervalo de red.

El fichero ‘dns.cfg‘ solo se usa para altas y consultas (información sobre máscaras de red y gateways); para realizar bajas o modificaciones, Web-DNS solo necesita la información proporcionada por ‘named.conf’. Ejemplo de fichero dns.cfg:


;**********************************************************************************
; fichero dns.cfg de configuración de Web-DNS
;
; FORMATO:
; SUBDOMINIO
; IP_INICIAL    IP_FINAL         MASCARA         GATEWAY         FICHERO_A_INSERTAR
;
;**********************************************************************************
; DOMINIO us.es
;**********************************************************************************
;
us.es
150.214.9.0      150.214.9.255   255.255.255.192  150.214.9.1     vlan-default.hosts
150.214.130.0   150.214.130.255  255.255.255.0    150.214.130.1   filoygeo.hosts
...
150.214.186.64  150.214.186.127  255.255.255.192  150.214.186.65  cpd.hosts
150.214.186.128 150.214.186.255  255.255.255.128  150.214.186.129 enfrente.hosts
...
193.147.162.0   193.147.162.255  255.255.255.0    193.147.162.1   esi162.hosts
;**********************************************************************************
; DOMINIO fie.us.es
;**********************************************************************************
fie.us.es
150.214.141.0   150.214.141.255  255.255.255.0    150.214.141.1   fie.us.hosts
150.214.142.0   150.214.142.255  255.255.255.0    150.214.142.1   fie.us.hosts
;**********************************************************************************
; DOMINIO cs.us.es
;**********************************************************************************
cs.us.es
150.214.141.0   150.214.141.255  255.255.255.0    150.214.141.1   cs.us.hosts
150.214.142.0   150.214.142.255  255.255.255.0    150.214.142.1   cs.us.hosts
...

El fichero 'usersdns.cfg' contiene los privilegios de los usuarios con la aplicación. Además incluye una sección especial donde se indican rangos de direcciones IP reservadas que nadie puede manipular con la aplicación Web-DNS (sección NADIE). Con esto se evita la posibilidad de accidentes y que por ejemplo se pueda dar de baja las direcciones IP de los propios servidores DNS primario y secundarios o de cualquier otra maquina que consideremos importante. Los usuarios que no aparecen reflejados en este fichero, se les permite realizar consultas, listados y estadísticas, pero ningún tipo de alta, baja o modificación.

Si un usuario realiza una petición y al confrontarla con los datos de este fichero, se comprueba que no está permitido que pueda realizarla, se genera un Intento de Violación de Seguridad. Dicho mensaje de error se envía al CPD mediante correo y salida impresa.

Ejemplo de fichero usersdns.cfg:


;*************************************************************************
; Fichero de privilegios de los usuarios de la aplicación Web-DNS
;
; NADIE puede dar de alta o de BAJA en los intervalos ...
; en opalo.us.es y en los servidores DNS (jade.us.es, onix.us.es)
;
;*************************************************************************
nadie        ALTA               150.214.130.10    150.214.130.10
                                150.214.130.15    150.214.130.15
                                150.214.186.69    150.214.186.69
             BAJA               150.214.130.10    150.214.130.10
                                150.214.130.15    150.214.130.15
                                150.214.186.69    150.214.186.69
;
;Operador de Informática
;
informática  ALTA               150.214.138.0     150.214.138.255
                                150.214.141.0     150.214.141.255
                                150.214.142.0     150.214.142.255
                                150.214.187.0     150.214.187.255
             BAJA               150.214.138.0     150.214.138.255
                                150.214.141.0     150.214.141.255
                                150.214.142.0     150.214.142.255
                                150.214.187.0     150.214.187.255
             ALTA-ALIAS         fie.us.es
                                cs.us.es
                                lsi.us.es
             BAJA-ALIAS         fie.us.es
                                cs.us.es
                                lsi.us.es
              ALTA-MX           us.es              us.es
                       VIRTUAL  fie.us.es          fie.us.es
                       VIRTUAL  fie.us.es          cs.us.es
                       VIRTUAL  cs.us.es           cs.us.es
                       VIRTUAL  cs.us.es           us.es
                       VIRTUAL  lsi.us.es          lsi.us.es
                       VIRTUAL  lsi.us.es          us.es
              BAJA-MX           us.es              us.es
                       VIRTUAL  fie.us.es          fie.us.es
                       VIRTUAL  fie.us.es          cs.us.es
                       VIRTUAL  cs.us.es           cs.us.es
                       VIRTUAL  cs.us.es           us.es
                       VIRTUAL  lsi.us.es          lsi.us.es
                       VIRTUAL  lsi.us.es          us.es
              E-MAIL            pablo@fie.us.es

...
;
;operador CPD, Paco Lobato
;
operador      ALTA              *
              BAJA              *
              ALTA-ALIAS        *
              BAJA-ALIAS        *
              ALTA-MX  VIRTUAL  *                  *
              BAJA-MX  VIRTUAL  *                  *
;             E-MAIL            paco@cpd.us.es

Web-DNS, además de ser una aplicación de gestión de la Base de Datos del DNS, añade una Base de Datos de direcciones Ethernet que se relaciona con la Base de Datos del Servidor DNS. Esto nos permite por ejemplo que de igual forma que podemos realizar consultas por direcciones IP, también podamos consultar por dirección Ethernet.

Simbólicamente esta Base de Datos es una tabla en la que se almacenan el par (dirección IP, dirección Ethernet). Físicamente, esta tabla se implementa de una forma similar a como se implementa la Base de Datos del DNS, a partir de ficheros de texto planos. Por una parte existen una serie de ficheros directos, con los cuales, a partir de una dirección IP podemos obtener la dirección Ethernet, y una serie de ficheros inversos, con los cuales, a partir de una dirección Ethernet, podemos obtener la dirección IP. El fichero 'ethernet.cfg' nos proporciona la información necesaria para manipular la Base de Datos de direcciones Ethernet.

Ejemplo de fichero ethernet.cfg:

;*************************************************************************
;
; Fichero de configuración de Web-DNS ethernet.cfg
;
;*************************************************************************
;
; Directorio donde esta la Base de datos de Direcciones Ethernet
;
directorio       /etc/ethernet
;
; Ficheros directos (Búsqueda a partir de IP)
; Subred                Fichero
;
directo
150.214.9                 9.dir
150.214.130             130.dir
...
193.147.179             179.dir
;
; Ficheros inversos (Búsqueda a partir de dirección Ethernet)
; Número mágico         Fichero
;
inverso
0                        0.inv
1                        1.inv
...
96                      96.inv

Como se puede ver en el fichero de configuración, los ficheros directos se obtienen a partir de la subred de la IP. Los ficheros inversos, se obtienen calculando un número mágico a partir de la dirección ethernet. La forma de calcular éste número a partir de una dirección ethernet genérica x1:x2:x3:x4:x5:x6 es mediante una función Hashing de la forma:

(x1+x2+x3+x4+x5+x6) modulo 97

Esta formula siempre da un número comprendido entre 0 y 96, distribuyendo homogéneamente el resultado en dicho intervalo. El número 97 se decidió por ser un número primo lo suficientemente mayor que él número de subredes que actualmente dispone la Red de la Universidad de Sevilla.

Por ejemplo, si queremos saber la dirección IP de la dirección ethernet 00:01:02:03:04:05, el número mágico sería (0+1+2+3+4+5) modulo 97 = 15 y por tanto el fichero inverso donde buscar seria el 15.inv.

Como se puede observar, es muy fácil hacer modificaciones "a mano" en los ficheros directos de la Base de Datos de direcciones ethernet, pero más complejo en los ficheros inversos. Teniendo presente esto, se han incluido una serie de script en la aplicación, que se ejecutan desde terminal para poder realizar modificaciones en la Base de Datos de direcciones ethernet de forma manual.

Ejemplos de ficheros directos e inversos de la Base de Datos de direcciones Ethernet (189.dir y 36.inv):


; Direcciones Ethernet de la red 150.214.189
;
150.214.189.1      00:00:0c:01:6d:d5
150.214.189.4      00:e0:29:0f:2b:12
...
150.214.189.253    00:e0:29:0f:2b:10
150.214.189.254    00:00:c0:09:cd:e9




; Direcciones Ethernet cuyo número mágico es 36
;
00:00:c0:3c:43:69    150.214.189.165
00:a0:c9:4c:a2:d5    150.214.189.116
...
08:00:2b:e6:5d:93    150.214.189.17

Con todo esto logramos que el concepto de dirección Ethernet aparezca unido y ligado a la Base de Datos del DNS como si verdaderamente esa información se almacenara en ella.

9.- Conclusiones y líneas de trabajo

Que un operador desde un centro periférico rellene un formulario en una página Web con los datos de un alta de una dirección IP y vea que ésta se produce al instante y sin tener que esperar varios días o poder realizar consultas complejas por nombre, realizar listados, o analizar las estadísticas de ocupación de las subredes o de aquellos Host que actúan como intercambiadores de correo, ha sido un gran avance. Web-DNS ha supuesto una descarga de trabajo en las personas encargadas del mantenimiento del Servidor de Nombres de la Universidad de Sevilla sin que se haya perdido el control y la seguridad sobre el mismo.

En estos momentos, estamos trabajando en una nueva aplicación: el proyecto Pajarito (se llama pajarito porque "te lo canta todo"). La idea que subyace es la de confrontar la información que tenemos en Web-DNS con la realidad. Pajarito obtiene del Web-DNS una tabla de direcciones IP, Ethernet y nombre de Host; y por otra, vía SNMP realiza una consulta a un router y obtiene otra tabla con direcciones IP y Ethernet. La aplicación cruza ambas tablas y nos da todas las incongruencias. Por ejemplo: Host de los que no se dispone de su dirección ethernet o es distinta a la que se tiene guardada en la Base de Datos del Web-DNS. Host que sin estar dados de alta en el DNS tienen tráfico IP, o el caso contrario, Host que están dados de alta en el DNS pero que no tienen tráfico IP y desde cuando no lo tienen.

Además se va a trabajar en migrar la aplicación Web-DNS a otros sistemas operativos y servidores Web distintos de Aix y Netscape Enterprise Server (inicialmente Solaris y Apache+Mod_SSL).

Por otra parte, todos los que lean éste articulo y estén interesados, pueden usar una versión de demostración sobre una Base de Datos de pruebas, que se encuentra en http://www.cpd.us.es/dns . Hay dos usuarios definidos: 'dns' y 'dns1', con palabra de paso. El usuario 'dns' tiene derechos para acceder a todas las redes y dominios, mientras que 'dns1' solo puede acceder al dominio "us.es" y subredes 150.214.13.x y 150.214.14.x . Para saber la palabra de paso, pueden ponerse en contacto con nosotros mediante correo electrónico.

10.- Bibliografía

Daniel Daza Muñoz
dirección de correo daniel [at] cpd [dot] us.es
Gustavo Rodríguez Rodríguez
dirección de correo gusrodri [at] cpd [dot] us.es

Centro de Proceso de Datos (CPD)
http://www.cpd.us.es
 Universidad de Sevilla