EL SERVICIO DE DIRECTORIO DNS Alvaro del Castillo San Félix 1998, GNU FDL Publicado en Linux Actual. Introducción

Transcripción

1 EL SERVICIO DE DIRECTORIO DNS Alvaro del Castillo San Félix 1998, GNU FDL Publicado en Linux Actual Introducción En el presente artículo se describe el servicio de DNS que permite el acceso de los usuarios a Internet utilizando nombres significativos y semánticos como o news.mozilla.org. En futuros artículos de la revista se describirá una implementación particular del servicio de DNS (BIND) ampliamente utilizada en sistemas GNU/Linux y se profundizará en los aspectos más avanzados. En Internet el servicio más utilizado es sin lugar a dudas el de DNS. Cada vez que navegamos a través del web, o leemos nuestro correo electrónico, o consultamos los grupos de noticias y charlamos en el IRC, el DNS ha sido el que nos ha permitido acceder a dichos servicios dando un nombre, y evitar el acceso a ellos mediante las complicadas direcciones IP. El servicio DNS es el encargado de traducir en Internet los nombres de los recursos por direcciones IP, es decir, hace de puente entre el mundo semántico de los humanos y el mundo numérico de los máquinas que pueblan Internet. Las RFCs 1034 [1] y 1035 [2] son las que describen el servicio de DNS y como implementarlo, y en su descripción lo presentan como: << el servicio de DNS (Domain Name Server) Servidor de Nombres de Dominio tiene como objetivo la creación de un mecanismo para dar un nombre a los recursos que existen en una red de ordenadores, permitiendo el uso de nombres en diferentes máquinas, redes, familias de protocolos y organizaciones de administrativas. >> El funcionamiento básico es el siguiente: dentro de la máquina del usuario de la red existe un agente local conocido como resolver que se encarga de obtener la información asociada a los dominios: quien es el servidor de correo del dominio, a que dirección IP corresponde una máquina perteneciente al dominio, una descripción del dominio, quien el servidor de nombres del dominio en fin, toda la información necesaria para el uso y disfrute de un dominio en Internet. Dicho agente local utilizará el servicio DNS, constituido por una base de datos distribuida formada por los servidores de nombre, para dar al usuario del sistema dicho servicio. Historia del servicio Desde sus orígenes se detectó la necesidad de un sistema de nombrado de los recursos en las redes, de forma que el acceso a los recursos de las mismas se pudiera hacer de forma sencilla para los usuarios humanos, y no mediante complejos números difíciles de recordar.

2 Inicialmente el sistema funcionaba de una forma centralizada: en el Centro de Información de Redes (NIC) se mantenía un fichero conocido como HOSTS.TXT que era transmitido por FTP a todas las máquinas que formaban la red. Este sistema poco a poco demostró su poca escalabilidad ya que en el NIC cada vez se consumían más recursos en la transferencia de dicho fichero y, el fichero a transmitir cada vez era más voluminoso y de más difícil consulta. Y al tenerlo centralizado, si el servidor del NIC dejaba de funcionar, toda la red se veía severamente afectada. Por último, las organizaciones que formaban la red quería poder administrar sus nombres de una forma independiente, sin tener que esperar a que el NIC diera de alta los cambios para poder ser ampliamente visibles en la red. Como solución a los problemas expuestos de propuso el sistema de DNS cuya principal novedad fue la descentralización total del servidor de nombres y la jerarquización del espacio de nombres. Cada organización (dominio de internet) pasaba a tener su propia administración, y tan solo se mantenía centralizado el control de los dominios primarios (org, com, edu, net y gov ) Cabe destacar entre los criterios de diseño de este nuevo sistema de directorio aspectos como la distribución de la base de datos de nombres, ser independiente del tipo de comunicaciones sobre la que este soportado, que lo requerimientos en las máquinas fueran mínimos para poder aplicar el sistema a entornos muy heterogéneos, y ser un sistema general aplicable a todo tipo de recursos, sin que ello suponga ningún tipo de atadura a los nombres internos que se utilicen en la red. Descripción del servicio Para la descripción del servicio vamos a centrarnos en un ejemplo en particular: el dominio debian.org. Supongamos que queremos acceder desde nuestra máquina al servidor de web cuyo dominio es debian.org. Cuando un usuario utiliza su máquina para acceder a los recursos de Internet, dichos recursos son invocados mediante nombres. Dichos nombres son procesados en la máquina del usuario mediante el agente local resolver el cual se encarga de obtener la información referente a dicho dominio. En nuestro caso el resolver ha de buscar le dirección IP correspondiente a para lo que debe en primer lugar localizar el servidor del dominio debian.org. El agente se encarga de investigar por la base de datos distribuida que forma el DNS el servidor de dominio adecuado que le informe sobre el dominio al que quiere acceder el usuario.

3 El resolver en primer lugar contacta con el servidor de nombres que tiene configurado, el cual le informa de cual es el servidor de nombres de dominio.org. Pasa entonces el resolver a preguntar a dicho servidor sobre quien es el servidor de nombres del dominio debian.org. Una vez localizado, se le hace la petición al servidor de nombres del dominio debian.org con el objetivo de identificar la dirección IP asociada al nombre El agente local resolver necesita inicialmente un punto de partida por el que comenzar la búsqueda, y dicho punto suele configurarse durante el proceso de instalación de la máquina, cuando se le indica a la máquina cual es el servidor de nombres (DNS) que debe utilizar la máquina. Como puede suponer el lector, la especificación de dicho servidor de nombres no se puede dar en forma de nombre sino con la dirección IP, ya que inicialmente no disponemos de acceso al sistema de DNS. Una vez logrado un punto de entrada al sistema de DNS, se puede acceder a información sobre cualquier dominio viajando por la base de datos distribuida y jerárquica que forma el DNS. La identificación de un recurso puede estar en más de un servidor de dominio a la vez, aunque siempre hay un servidor de dominio que es el principal y que es al que deben replicar los servidores secundario de dicho dominio. Los servidores de nombres se encargan de gestionar dos tipos de datos: - Información sobre la/s zona/s que gestiona, que debe ser actualizada periódicamente con los cambios que se puedan ir produciendo. Esta información depende del servidor de nombres, por lo que debe ser información real y actualizada. - Información almacenada como caché que permite aumentar el rendimiento del servidor de nombres, aunque esta información puede no estar actualizada. Con este esquema de funcionamiento se logra que todos los problemas de acceso al DNS, recuperación antes fallos y acceso distribuido del DNS se centren en el agente resolver, y que los problemas de actualización y de refresco de los nombres en la red se concentren en los servidores de nombres. El esquema básico de la arquitectura DNS se puede observar en el siguiente gráfico:

4 Figura 1: Arquitectura del servicio DNS Resumiendo, los pasos pues a seguir para traducir nuestro nombre a su dirección IP son: 1. El programa de usuario hace uso del agente local resolver y le pide que le traduzca el nombre por la dirección IP que le corresponde. 2. El resolver consulta su caché por si ya hubiera realizado la operación anteriormente y el resultando lo tuviera aún en su caché. 3. Si no estuviera el resultado en la caché, el resolver iría consultando de forma sucesiva a diversos servidores de nombres (varios accesos a Internet) con el objeto de conocer la dirección IP del servidor de nombres que gestiona el dominio debian.org. 4. Una vez localizado el servidor de nombres que gestiona el dominio debian.org, le pide que le diga la dirección IP que corresponde a 5. El servidor de nombres consulta en sus ficheros de nombres el registro con los datos de y devuelve al resolver la dirección IP que corresponde a 6. El programa de usuario utilizando la dirección IP proporcionada por el resolver accede por la red TCP/IP a la máquina que corresponde a dicha dirección IP, en particular, al puerto TCP 80 de dicha máquina donde estará escuchando el servidor de web. Puede que el lector se sorprenda de que cada vez que accede a alguna página de Internet, o a su correo, sea necesario que se repita todo este proceso, pero es realmente lo que ocurre. Gracias a la caché se evita en muchas ocasiones al resolver el tener que acceder al sistema de DNS completo, lo que permite en una velocidad de acceso mayor. El sistema de DNS requiere que para cada dominio haya dos servidores de nombres funcionando. Al principal se le conoce como primario y al de reserva como secundario. Si hay algún problema con el servidor primario de un dominio, pasa a consultarse de forma

5 automática el secundario, por lo que el sistema es muy robusto. El secundario debe preocuparse de tener sus datos actualizados respecto al primario, por lo que de forma periódica actualiza sus datos con los del primario. Espacio de Nombres de Dominio Junto con el resolver y el servidor de nombres, el otro elemento principal del sistema de DNS es la especificación del Espacio de Nombres de Dominio. En el se describen cual ha de ser el formato de los dominios, y estructura dichos dominios en forma de árbol. Cada nodo del árbol representa un conjunto de recursos. Para describir cada nodo se utiliza una etiqueta con una longitud máxima de 63 octetos de longitud. Los nodos de un mismo nivel no pueden tener la misma etiqueta, y el nombre nulo está reservado para el nodo raíz del árbol. El nombre de dominio de un nodo se forma uniendo las etiquetas que van formando el camino en el árbol hasta llegar al nodo. En la siguiente figura podemos ver un pequeño ejemplo: Del nodo raíz cuelgan todos los dominios primarios, entre ellos el org, y de éste cuelga el nodo de debian, por lo que nombre del dominio es debian.org, la concatenación uniendo las etiquetas por puntos, de las etiquetas que forman el camino desde la raíz hasta el nodo último del dominio. El número máximo de bytes que puede ocupar un nombre en Internet es de 255 octetos, algo que parece más que suficiente en la actualidad, pero que en futuras aplicaciones puede obligar a ciertas restricciones. Una de las principales características de los etiquetas de los nodos es que para comparar dichas etiquetas, se pone todo en minúsculas, por lo que por ejemplo, en la actualidad es lo mismo que pero se recomienda utilizar el nombre oficial de cara a futuras modificaciones en esta regla. También es de destacar que dichas etiquetas de los nodos han de estar formadas por caracteres ASCII de 7 bits, ya que el bit 8 está puesto a cero. Sin lugar a dudas esto se deberá de cambiar si se quiere un uso genérico de este sistema, y el uso de la codificación universal UNICODE se terminará imponiendo.

6 Ficheros maestros Los ficheros maestros son los que contienen los RR (Registros de Recursos) y describen los recursos asociados a un nodo del árbol de dominios. Estos ficheros los utiliza el servidor de nombres, entre otras cosas, para traducir los nombres de los recursos a direcciones IP. Estos ficheros son totalmente legibles y son mantenidos por el administrados del dominio. Los ficheros maestros están distribuidos por todo Internet, en cada servidor de nombres aparecen los suyos propios, y son estos ficheros la esencia de la distribución del servicio de directorio. Es la principal labor del administrador de un dominio la creación y el mantenimiento de estos ficheros ya que son ellos los que describen el dominio. Por ello vamos a detallar a continuación el contenido de dichos ficheros, formados por los conocidos como Registros de Recursos (RR). Para describir cada recurso perteneciente a un dominio dado se utiliza un RR diferente. Cada RR esta formado por un dueño (el dominio al que pertenece), un tipo (que identifica el tipo de recurso en un campo de 16 bits), la clase a la que pertenece (normalmente IN de Internet), un tiempo de vida (TTL) durante el que la información de dicho registro es válida en una caché, y finalmente un campo de datos conocido como RDATA. NAME TYPE CLASS TTL RDATA Figura 2: Estructura de un RR Esta estructura de cada registro aparece en los ficheros maestros en la forma: [dominio] [ttl] [class] type rdata El [dominio] indica a que demonio pertenece el registro de recurso. El campo de [ttl] indica la duración en segundos de la validez de la información desde que fue obtenida del servidor. Así se obliga a las cachés de los resolver a actualizarse pasado un cierto tiempo. El campo más complejo de los descritos es el del tipo que describe que tipo de datos almacena el registro. Los tipos principales son:

7 - A: una dirección de máquina del dominio - CNAME: nombre canónico de un alias - HINFO: identificación de la CPU y el SO de la máquina - MX: identifica un servidor de correo para el dominio - NS: servidor de nombres principal del dominio - PTR: un puntero a otra parte del espacio de nombres de dominio - SOA: identifica la zona de inicio de autoridad Para que el lector comprenda un poco mejor los RR vamos a ir introduciendo pequeños ejemplos que aclaren los conceptos presentados hasta el momento. A continuación vamos a presentar el contenido posible de un fichero maestro describiendo un dominio. Como ya se ha citado dicho fichero está compuesto por registros de recursos. Dicho fichero vamos a suponer que es /var/named/named.linux. De los ficheros maestros, hay uno que viene junto con el servidor de nombres y que es el que indica cuales son los servidores de nombres raíz, fichero que normalmente se conoce como named.root. Es con estos datos con los que el servidor de nombres puede comenzar a funcionar de una forma integrada con el sistema de DNS. RR SOA En primer lugar al describir un dominio siempre aparece el denominado registro SOA, que describe una zona de autoridad, es decir, una zona donde los datos que aparecen el fichero maestro son los que tienen prioridad y deben ser tomados como referencia. Es el registro más complicado pero que una vez descrito es bastante sencillo. Un ejemplo de dicho registro lo observamos a continuación: ; ; /var/named/named.linux: descripción del dominio linux.es. linux.es. IN SOA ns.linux.es. hostmaster.linux.es ( 1 ; serie ; refresco: una vez al día 3600 ; reintento: una hora ; expira: 42 días ; mínimo: 1 semana ) El registro está formado por varias líneas por lo que su contenido se encierra entre paréntesis. En la primera línea indicamos que vamos a describir el SOA del dominio linux.es.. Es obligatorio que siempre que se hable de un dominio, este acabe en un punto, que representa a la raíz de todos los dominios. En esta primera línea indicamos el nombre canónico del servidor de nombres para este dominio ( ns.linux.es. ) y quien debe recibir

8 los correos de administración del sistema, sustituyendo del correo electrónico por un., es decir, que los correos de administración los va a recibir hostmaster@linux.es. Respecto a los parámetros numéricos, la mayoría son para detallar la coordinación entre el servidor primario y el secundario.el primer parámetro numérico conocido como número serie se debe ir incrementando cada vez que se cambia algo en el servidor de nombres, de cara a que el servidor secundario sepa que debe actualizarse. El siguiente parámetro (refresco) indica cada cuantos segundos el servidor secundario ha de actualizarse con los datos del servidor primario. El parámetros de reintento indica cada cuantos segundo el servidor secundario debe intentar reconectarse al primario para actualizar los datos en caso de error. El parámetro de expiración indica cuanto tiempo ha de pasar para que el servidor secundario deseche toda la información que tenía del primario. Por último el parámetro mínimo indica el ttl de los registros que no lo indiquen explícitamente. Los demás RR Los registros de recursos restantes son mucho más sencillos que el de SOA. Los RR de tipo A asocian a direcciones IP nombres: ns.linux.es. IN A Con IN indicamos que el tipo de protocolo es INTERNET, ya que el sistema de DNS puede utilizarse en otras redes diferentes. Si una máquina tiene más de un nombre utilizamos aliases mediante los registros CNAME www IN CNAME ns correo IN CNAME ns Si no se especifica el dominio se toma por defecto el dominio que se está describiendo en el presente fichero (linux.es.). IN NS ns.linux.es. El registro de tipo NS indica quien el servidor de nombres para el dominio que se está describiendo (linux.es.). Es necesario que a dicho nombre se le asocie una dirección IP mediante un registro de tipo A.

9 IN MX 10 correo El registro MX indica un servidor de correo para el dominio. El número que acompaña al MX permite definir varios servidores de correo y según este número darles una prioridad mayor o menor. Así si el de menor número (mayor prioridad) esta ocupado se pueden entregar los correos para el dominio utilizando otros servidores. IN HINFO Pentium II 32 Mb RAM 3.6 Gb GNU/Linux El registro HINFO permite describir el equipo en el que está corriendo el servidor de nombres. 1 IN PTR localhost. Los registros de tipo PTR se utilizan para asociar direcciones del dominio in-addr.arpa a nombres de máquinas, con lo que se facilita las búsquedas de los nombres de las máquinas a partir de las direcciones IP, algo que es opcional dentro de los sistemas de DNS. Problemática del servicio Los servidores de nombres que controlan los dominios referentes a cada país no presentan ningún problema ya que cada país gestiona el suyo como quiera, bien directamente desde el gobierno o bien desde alguna entidad privada autorizada. Por ejemplo, en España se encarga ESNIC del control de dicho servidor de nombres. Los problemas aparecen con el control de los llamados dominios genéricos que no pertenecen a ningún país y que a sus dueños les proporcionan una imagen más abierta e internacional, por no mencionar que su obtención suele ser mucho más sencilla que sus equivalentes nacionales. Gran parte de Internet funciona en la actualidad bajo dichos dominios genéricos. Al ser el DNS un servicio esencial en Internet, el control implicaría el control de Internet en cierto modo. Inicialmente la gestión del servicio de DNS lo adjudicó la NSF [6] (The National Science Foundation) en 1993 a Network Solutions (NSI) [4] lo que implicaba la gestión de los dominios: com, org, gov, edu, net.

10 Cualquiera que quisiera un dominio por debajo de estos debía de ponerse en contacto con NSI para que actualice dicho dominio en sus servidores de nombres a dicho dominio, pagando una cuota de inscripción y una cantidad anual. En la actualidad y hasta Septiembre de este año (1998) en control de los servidores de nombre raíz sigue en manos de NSI, control que parece perderá al acabar el presente contrato y que dará pie a una dura pugna por el control de este recurso de Internet. En principio el gobierno de EEUU intentó prorrogar el contrato con NSI, algo a lo que opuso gran parte de la comunidad de Internet y entre ellos la Unión Europea. Todos los analistas saben que un posible control sobre Internet pasa por el DNS y nadie quiere que un país lo controle. La posición de EEUU con respecto a Internet, y en especial con respecto al servicio de DNS, se ha reflejado en el conocido como green paper [8] publicado en Enero de 1998 y en el dice entre otras cosas que planea controlar la mitad de los servidor raíz de DNS que son los que controlan los dominios principales, algo que como es de esperar no ha gustado en Europa. Un grupo conocido como CORE (Internet Council of Registrars) se ha opuesto al actual sistema de dominios primarios y quieren que se introduzca de forma inmediata nuevos dominios primarios, aumentando los ya existentes. Estos nuevos dominios son: ".firm," ".info," ".nom," ".rec," ".shop," ".web," and ".arts." Por otro lado está la problemática de la asignación de dominios, los enfrentamientos por personas que realizan registros masivos de nombres de dominios y luego intentan venderlos, problemática cuya solución es compleja ya que los criterios son diferentes en cada país, y a que NSI tiene su propia política de resolución de conflictos. En España los dominios los gestiona ESNIC [5] y obliga a las empresas que piden un dominio a que tengan dicho nombre registrado como su nombre de empresa. Toda la presente problemática requiere un conjunto de leyes internacionales sobre marcas. Hay un organismo internacional conocido como Organización Mundial de la Propiedad Intelectual [7] pero su peso aún no es lo suficientemente importante. DNS en su sistema GNU/Linux Dentro de una máquina GNU/Linux, siempre que este integrada dentro de una red, ha de existir el resolver. La configuración del mismo es muy sencilla, tan solo debemos indicar el nombre del servidor de nombres principal, y opcionalmente el secundario. Con esta información el agente local resolver es capaz de acceder al sistema de DNS y traducir los nombres por las direcciones IP de los recursos. La configuración del resolver se encuentra en /etc/resolv.conf.

11 También podemos encontrar en los sistemas GNU/Linux un servidor de nombres. El más utilizado es el conocido como BIND, el cual se detallará su instalación, configuración y uso en el próximo artículo de DNS de esta misma revista. URLs del artículo [1] RFC 1034 [2] RFC 1035 [3] RFC 974 [4] Network Solutions [5] ESNIC: [6] NSF: [7] [8]