Servicio DNS-Servicios Arturo

Cap tulo 2
CONFIGURACION DE UN DNS: BIND

2.1. Introduccin al concepto de DNS o
Ya sabemos que cualquier mquina accesible en nuestra LAN o en la propia Internet con capaa cidad de comunicarse con las dems tiene asignada, al menos, una direccin IP. El sistema actual1 a o de direcciones IP (IPv4) fue estandarizado en 1981 y deni una direccin como la composicin o o o de cuatro octetos de ceros y unos (cantidades binarias de 8 d gitos) separados por puntos. Las direcciones IP se catalogan en pblicas y privadas. Las pblicas son unicas, es decir no se pueden u u 2 , mientras que las privadas son utilizadas reiteradamente por las redes internas de las emrepetir presas u otras organizaciones. Un ejemplo de direccin IP privada es la 192.168.1.1. Para entablar o una comunicacin entre dos equipos es necesario que ambos tengan asignadas sendas direcciones o IP. Un buen s mil puede ser el de la red telefnica, en la que se necesitan conocer previamente los o correspondientes nmeros para establecer una llamada. u
Una vez escrito en la barra de direcciones de nuestro cliente Web preferido la URL correspondiente al sitio Web a visitar, por ejemplo http://www.google.es, tras pulsar ENTER se suceden las siguientes acciones: 1. El equipo cliente, para poder dar respuesta a la solicitud http realizada, se pregunta Quin es e el equipo que sirve el sitio Web www.google.es? Entonces se dirige al servidor DNS que tiene congurado para que resuelva el nombre del equipo indicado en la URL. 2. El servidor DNS nos devuelve la direccin IP del o equipo que sirve el sitio Web que deseamos visualizar: www.google.es = 66.249.91.104 3. El equipo cliente solicita v protocolo http al a equipo 66.249.91.104 el sitio Web que tiene alojado. 4. El servidor Web nos suministra la pgina de a inicio de google.
Figura 2.1: Pasos en la resolucin del nombre www.google.es. o
Para el ser humano es dif recordar la combinacin de d cil o gitos que se corresponde con una direccin IP y por esta razn es normal asignar un nombre a las direcciones. Todos estamos acoso o tumbrados a escribir en nuestro navegador web nombres como www.google.es, aunque en realidad
Es de suponer que en poco tiempo se imponga el sistema de direcciones IPv6. Un ejemplo de direccin IP pblica es la 202.12.27.33 (perteneciente a m.root.servers.net), nadie ms en el mundo o u a puede utilizarla para comunicarse en Internet.
2 1
33
34
CAP ITULO 2. CONFIGURACION DE UN DNS: BIND
lo que deseamos es conectarnos a una mquina con direccin 66.249.91.104 (direccin IP pblica). a o o u Alguien en Internet debe de encargarse de traducir el nombre escrito en el navegador por su correspondiente direccin IP. Las mquinas encargadas de realizar este trabajo se denominan DNS. Las o a siglas DNS signican Domain Name Server (Servidor de Nombres de Dominio). Se dice que un DNS resuelve un nombre cuando es capaz de transformar ese nombre en una direccin IP. Cualquier ordenador que permita la navegacin por Internet utilizando nombres en o o lugar de direcciones IP debe conocer al menos la direccin IP de un DNS3 . As cuando escribimos o , en el navegador, por ejemplo, www.iescomercio.com nuestro ordenador pregunta a ese DNS la direccin IP asociada al nombre que hemos escrito. El DNS se encargar, por medio de procedio a mientos que posteriormente sern explicados, de resolver la pregunta devolviendo en este caso a a nuestro ordenador la direccin IP 217.76.130.87. o Los nombres asociados a las redes de ordenadores se denominan nombres de dominio. Un nombre de dominio consta de dos o ms palabras separadas por puntos. La palabra situada ms a la a a izquierda da la mayor especidad al nombre y a medida que se llega a la de la derecha se produce una generalizacin4 . Por ejemplo pc1.aula19.cossio.net har referencia a la mquina 1, perteo a a neciente al aula 19 del I.E.S. Manuel Bartolm Cossio. La palabra de la derecha, net, se denomina e nombre de dominio de alto nivel5 . En general un nombre de dominio consta del dominio de alto nivel (es, edu, com, net, . . . ) y de un identicador de domino. Ambos conforman lo que se denomina nombre de dominio cualicado o FQDN (Fully Qualied Domain Name).
Identicador de dominio bajoaragon.com
Dominio de alto nivel
Nombre de dominio cualicado Para identicar a las mquinas de un dominio se aaden subdominios, por ejemplo: pc1. a n bajoaragon.com o pc2.bajoaragon.com. Lo normal es ir construyendo una estructura jerrquica a como la mostrada en la gura 2.2.
2.1.1.
Nombres de dominio de nivel y servidores ra z
Inicialmente los nombres de dominio de alto nivel eran: .com .edu .org .net .int .gov .mil .nato Empresas comerciales. Educacional (Universidades y colegios). Organizaciones de n no lucrativo. Redes de ordenadores independientes pero conectadas a Internet. Internacional. Gobierno y organismos ociales de USA. Organismos militares de USA. Organizacin del Tratado del Atlntico Norte (OTAN/NATO). o a
Posteriormente hubo que aadir nombres a la lista, debido a la creciente necesidad de empresas n y organismos por presentar sus productos en Internet. Algunos ejemplos son: .au (Australia), .at (Austria), .es (Espaa), . . . Los nombres de dominio que cuelgan de estos se denominan n dominios de segundo nivel6 . Los que cuelgan de los de segundo nivel se denominan de tercer nivel y as sucesivamente.
3
Recuerda que esta direccin o direcciones se encuentran en /etc/resolv.conf. o Esto no es norma, aunque lo normal es que sea as . 5 En ingles TLD, Top Level Domain name. 6 En ingls 2LD, Second Level Domain Name. e
4
2.1. INTRODUCCION AL CONCEPTO DE DNS
35
Figura 2.2: Estructura jerrquica de nombres de dominio. a
El responsable de estos dominios y del denominado dominio ra que est por encima de ellos7 z a es el ICANN8 . Una de las misiones de este organismo es gestionar la concesin de nombres de o dominio y sus direcciones IP asociadas. El ICANN posee 13 servidores de nombres distribuidos por el mundo9 . Se denominan Servidores Ra o Top Name Servers (TNS) y todos ellos tienen la misma informacin de forma que se reparten z o el trabajo de resolucin a la vez que cada uno de ellos es una copia de seguridad del resto. Estos o servidores contienen las zonas con los nombres de dominio de segundo nivel (2LD) de todo el mundo; advierte que esto es una cantidad de informacin enorme. o
Figura 2.3: Situacin mundial de los DNS ra o z.
El dominio ra no tiene ningn nombre asociado, ver gura 2.2. z u ICANN son las iniciales de Internet Corporation for Assigned Names and Numbers. 9 Decimos distribuidos por el mundo, pero como puede verse en la gura 2.3 la mayor estn en USA, dos en a a Europa y otro en Japn. o
8
36
Lo dicho no signica que los TNS sean los encargados de hacer todas las resoluciones de nombres de dominio de segundo nivel. Existen gran cantidad de servidores de nombres pertenecientes a empresas y particulares que realizan tambin esta funcin, si tienen autoridad para ello. Por ejemplo e o el nombre de dominio iescomercio.com es de segundo nivel y tiene asignada la direccin IP o 217.76.130.87; uno de los servidores que tiene autoridad para hacer la resolucin de dicho nombre o es dns7.servidoresdns.net que a su vez tiene la direccin IP 217.76.128.131 y que evidentemente o no es ninguno de los trece servidores ra z. Cuando alguien hace una consulta a la url www.iescomercio.com se env la peticin al sera o vidor DNS que tenemos congurado en nuestro ordenador (chero /etc/resolv.conf), como seguramente no tendr autoridad para hacer la resolucin vuelve a realizar una peticin que cona o o ducir nalmente a dns7.servidoresdns.net. Este ultimo buscar en su denominada zona de a a autoridad el nombre www.iescomercio.com, que estar enlazado a la direccin IP 217.76.130.87. a o Est ser devuelta a quien hiz la peticin en un principio completando as la resolucin. a a o o o
2.1.2.
Tipos de servidores de nombre de dominio
En el mundo existen miles de servidores. No todos se comportan de la misma forma ante una solicitud de resolucin. Bsicamente se pueden distinguir cuatro tipos: o a 1. Servidores de tipo cach. Este tipo de servidores no tienen autoridad sobre ninguna zona. e Tras el arranque un servidor de este tipo no es capaz de hacer ninguna resolucin por s solo. o Cuando inicialmente le hacen una consulta, l debe reenviarla a los servidores que saben e responderla, cuando estos le contestan el servidor cach almacena la respuesta en memoria e para no tener que volverla a preguntar. Normalmente las consultas las hacen a los TLD. Junto a la gura 2.4 se da una explicacin de su funcionamiento. o
Figura 2.4: Funcionamiento de un DNS cache.

Comentarios a la gura 2.4 Los pasos seguidos en la resocin de un nombre de dominio a travs de un servidor DNS de tipo cache son: o e 1. El equipo cliente realiza una consulta a su DNS (en el chero /etc/resolv.conf debe gurar nameserver 131.25.91.15) con la nalidad de conocer la direccin IP asociada al equipo que tiene asignado el nombre de o dominio www.iesrioarba.com. 2. El servidor 131.25.91.15 consulta la lista de todas las resoluciones de nombres de dominio que tiene cachea-
2.1. INTRODUCCION AL CONCEPTO DE DNS
37
das en memoria como consecuencia de consultas anteriores. En caso de no encontrar la informacin solicitada o es reenviada la peticin a los DNS ra para que estos le informen donde poder encontrar el equipo servidor con o z autoridad sobre la zona en cuestin iesrioarba.es. o 3. Los DNS ra consultan el nombre de segundo nivel (2LD) e informan de la direccin IP del servidor DNS z o que gestiona los nombres de equipo para ese dominio: iesrioarba.es = 13.99.8.1 4. El servidor 13.99.8.1 recibe la peticin, lleva a cabo la resolucin del nombre (www.iesrioarba.com = o o 23.18.1.211), y le entrega dicha informacin al servidor 131.25.91.15. o 5. El servidor 131.25.91.15 al recibir la informacin la almacena (cachea) en memoria con la nalidad de poder o responder en el futuro a solicitudes relacionadas con el mismo nombre de dominio. 6. El servidor 131.25.91.15 suministra al equipo cliente la informacin solicitada. o
2. Servidores esclavos o secundarios. Contienen informacin sobre algunas zonas. Estos datos o son copias de los que contienen los servidores maestros. Cuando la informacin cambia en o un servidor maestro el esclavo simplemente la copia para actualizarse. Ver la gura 2.5 para aclarar conceptos sobre el funcionamiento de este tipo de servidores.
Figura 2.5: Funcionamiento de un DNS esclavo.

Comentarios a la gura 2.5 Tal como se puede observar en la gura los pasos seguidos en la resolucin de un nombre de dominio a o travs de un servidor DNS de tipo esclavo son: e 1. El equipo cliente realiza una consulta a su servidor DNS (en el chero /etc/resolv.conf debe gurar nameserver 131.25.91.15) con la nalidad de conocer la direccin IP asociada al equipo que tiene asignado el o nombre de dominio www.iesrioarba.com. 2. El servidor 131.25.91.15 consulta la lista de todas las zonas sobre las que tiene informacin con la nalidad o de encontrar la correspondiente a iesrioarba.es. 3. En el caso de detectar que se corresponde con una zona esclava sobre la cual no ha recibido previamente informacin por parte de su servidor maestro (por ejemplo, 13.99.8.1), le solicita ha este ultimo la informacin o o
38

necesaria para congurar el chero de zona asociado a iesrioarba.es. 4. El servidor 13.99.8.1 al recibir la peticin, suministra a su servidor esclavo la informacin necesaria. o o 5. El servidor 131.25.91.15 al recibir esa informacin genera automticamente el chero de zona correspono a diente, lo consulta y lleva a cabo la resolucin solicitada por el equipo cliente. Una vez que ya tiene congurado o el chero de zona, el servidor esclavo ya se encuentra preparado para contestar cualquier otra solicitud asociada a ese (www.iesrioarba.com) u otro nombre de equipo dentro del dominio iesrioarba.es. De esta forma se consigue distribuir el trabajo de resolucin de nuestro servidor maestro entre diferentes servidores esclavos. o
3. Servidores maestros. Son aquellos que tienen autoridad sobre una zona. La gura 2.6 da una breve explicacin de funcionamiento. o Contienen los datos que permiten hacer la resolucin correspondiente sin necesidad de reenviar o la peticin. Esos datos son una copia maestra, es decir, son los que hay que cambiar cuando la o informacin de la zona a resolver cambia. o
Figura 2.6: Funcionamiento de un DNS maestro.

Comentarios a la gura 2.6 Tal como se puede observar en la gura los pasos seguidos en la resolucin de un nombre de dominio a o travs de un servidor DNS de tipo maestro son: e 1. El equipo cliente realiza una consulta a su DNS (en el chero /etc/resolv.conf debe gurar nameserver 131.25.91.15) con la nalidad de conocer la direccin IP asociada al equipo que tiene asignado el nombre de o dominio www.ingemartin.es. 2. El servidor 131.25.91.15 consulta la lista de zonas sobre las que tiene autoridad y en caso de encontrar la zona especicada (ingemartin.es), consulta el archivo de zona asociado a ella para informar de la direccin IP o correspondiente al nombre del equipo www.ingemartin.es dentro del dominio ingemartin.es: www.ingemartin.es = 21.8.109.21 3. La informacin obtenida es devuelta al cliente que inicio la consulta. o
4. Servidores de reenvo. No poseen autoridad sobre las zonas que resuelven. Cuando se les hace una peticin ellos la reenv a los servidores que tienen congurados esperando que estos le o an devuelvan la respuesta.
Comentarios a la gura 2.7 Tal como se puede observar en la gura los pasos seguidos en la resolucin de un nombre de dominio a o travs de un servidor DNS de tipo forward (reenvio) son: e 1. El equipo cliente realiza una consulta a su servidor DNS (en el chero /etc/resolv.conf debe gurar nameserver 131.25.91.15) con la nalidad de conocer la direccin IP asociada al equipo que tiene asignado el o nombre de dominio www.ingemartin.com. 2. El servidor 131.25.91.15 reenv la solicitud al servidor DNS que tenga congurado (por ejemplo, hacia el a equipo DNS 10.168.9.18). 3. El servidor 10.168.9.18 recibe la peticin y trata de realizar la resolucin del nombre. En el caso de que o o tenga la informacin solicitada, se la suministrar al servidor 131.25.91.15. En caso contrario, se repetir el o a a proceso de reenvi hasta que algn servidor con autoridad contenga la informacin requerida. o u o
2.2. ESTRUCTURA DEL CAP ITULO
39
Figura 2.7: Funcionamiento de un DNS de reenv o.
4. Una vez que el servidor 131.25.91.15 recibe una respuesta, esta es suministrada al equipo cliente que gener la consulta, que adems la almacena en memoria cache con la nalidad de agilizar la resolucin ante futuras o a o solicitudes sobre el mismo nombre de dominio.
La estructura jerrquica de los servidores de nombre hace que con muy pocas consultas se pueda a hacer la resolucin. o
2.2.
Estructura del cap tulo
El objetivo principal de este cap tulo es ser capaces de convertir una mquina en uno de esos a miles de servidores de nombres de dominio existentes. Para ello emplearemos BIND, una aplicacin o ampliamente utilizada en Internet para este n. El cap tulo est estructura para conseguir: a 1. Instalar correctamente BIND, el software que permite convertir tu equipo en un DNS. 2. Congurar de forma sencilla tu DNS. A modo de tutorial se mostrar como crear un DNS a cach que podrs dejar funcionando, de forma que ya no dependas de los DNS que te propore a ciona tu proveedor de servicios de Internet (ISP). 3. Saber como se puede controlar BIND de forma remota. 4. Comprender algunos de los estamentos y clusulas de BIND. a 5. Manipular los archivos de conguracin y saber como se chequean. o 6. Conocer y congurar los distintos tipos de DNS que es posible encontrar.
40
PRACTICA: CONFIGURACION DE UN DNS
2.3.
Instalacin del software necesario o
Para que un ordenador desarrolle las funciones de servidor de nombres de dominio es necesario que tenga el software espec co que se encarga de hacer este trabajo. Nuestra eleccin es o BIND. Existen otras aplicaciones de software libre capaces de hacer esta funcin, como por ejemplo o DJBDNS; los motivos que justican esta decisin son que BIND est bien documentado y muchos o a de los servidores de Internet lo utilizan actualmente. El paquete software espec co que debemos instalar es bind-9.x, donde x denota la sub-versin. En el momento de escribir este documento, la o versin disponible de BIND es la 9.3.1, pero los conceptos y procedimientos que en este cap o tulo se van a describir sern vlidos para cualquier otra versin, independientemente de la utilizada aqu a a o . Su instalacin puede llevarse a cabo de dos formas: o 1. A travs de una interfaz grca de usuario (GUI), tras ejecutar el comando rpmdrake. Para e a ello escribiremos en la l nea de comandos:
[root@linux]# rpmdrake &
Aparecer un asistente grco, tal como se muestra en la gura 2.8 que nos permite elegir el a a paquete deseado, y a continuacin basta con hacer un click en instalar. o
Figura 2.8: GUI para instalacin de software en Mandriva. o
2. Una segunda opcin ms cmoda consiste en hacer la instalacin desde la l o a o o nea de comandos (CUI, Interfaz de L nea de comandos, o mediante el uso de una consola o Terminal).
[root@linux]# urpmi bind
2.4.
Conceptos bsicos sobre la conguracin de BIND a o
Una vez instalado el software, deberemos congurarlo. Puesto que el programa se encarga de transformar los nombres de dominio en direcciones IP, la conguracin consiste en escribir sobre o determinados archivos las equivalencias entre unos y otras. Esta operacin requiere de dos pasos: o
2.4. CONCEPTOS BASICOS SOBRE LA CONFIGURACION DE BIND
41
1. En primer lugar editar el chero named.conf. En l se van a denir las distintas zonas o e nombres de dominio que nuestro servidor de nombres esta autorizado a resolver. 2. En el caso de estar congurando una zona maestra se deber crear un archivo10 asociado a a cada una de estas zonas (denidas en named.conf). En l se indicarn las direcciones IP e a asociadas a los equipos que forman parte del dominio y que adems podrn ser resueltas. a a Este chero se llama archivo de conguracin de zona o simplemente archivo de zona. o
Importante!! Debes distinguir entre nombre de dominio o zona (denida en el chero named.conf), y los nombres de los equipos pertenecientes a dicha zona denidos en el archivo asociado a ella. Los equipos, y los servicios que ofrecen estos, pertenecientes a la zona se identican con un acrnimo precediendo al nombre del dominio. Por o ejemplo, un nombre de dominio podr ser ieschirinos.com, y dentro de esta ofrecerse a servicios HTTP (www.ieschirinos.com) y FTP (ftp.ieschirinos.com); o existir una mquina perteneciente al mismo que se llame pc1.depinformatica.ieschirinos.com. a
2.4.1.
Una conguracin sencilla: El DNS cach o e
La conguracin ms sencilla que podemos hacer con BIND es la de un DNS cach. Un servidor o a e de nombres cach slo tiene congurada una zona o dominio que indica que es un servidor cach. e o e Cuando el servidor recibe una solicitud de resolucin, pregunta a otro con autoridad sobre la zona o solicitada. Este le transmitir la informacin de la misma (ver gura 2.4). a o Siguiendo los pasos expuestos en la seccin 2.4 en primer lugar crearemos11 un chero llamado o /etc/named.conf. Para la conguracin como servidor cach, bastar con que el contenido del o e a 12 . mismo fuera el mostrado a continuacin o
zone "."{ type hint; file "/var/named/named.ca"; }; //Zona de tipo cach e
A travs del tipo hint le decimos a BIND que deseamos un servidor cach para cualquier e e nombre de dominio (indicado mediante zone "."). Cuando le hagamos una consulta al servidor, este buscar en alguno de los servidores contenidos en el archivo /var/named/named.ca. a La composicin del archivo /var/named/named.ca se corresponde con el paso 2 indicado en la o seccin 2.4. En realidad, nos podemos evitar construir este archivo, ya que es igual a cualquier otro o named.ca utilizado en el mundo. Es fcil encontrarlo en Internet13 , pero ms fcil es encontrarlo a a a en nuestro ordenador ya que normalmente se suministra con el programa BIND. Para encontrarlo puedes escribir14 :
[root@linux]# find /usr -name named.ca
El archivo que contiene la informacin de la zona, en este caso el chero /var/named/named.ca, o se denomina archivo de conguracin de zona o simplemente archivo de zona. El contenido inicial o del mismo es:
Es un slo archivo en el caso ms sencillo, pero pueden ser varios. Por otro lado, en la conguracin de otro tipo o a o de servidores, por ejemplo el servidor cach (ver seccin 2.4.1), ni siquiera hay que crearlo, ya que es proporcionado e o por la propia distribucin. o 11 En el caso de que ese archivo ya existiese renombralo para reemplazarlo por el que aqu se presenta. 12 Observa que en este chero los comentarios se hacen con // cuando slo ocupan una l o nea y con /* . . . */ en caso de que ocupen varias (similar a los cheros de cdigo fuente en C y C++). Adems, al igual que en los cheros de o a conguracin y script de los sistemas UNIX, se puede utilizar el s o mbolo # para hacer los comentarios. 13 Puedes encontrar una versin actualizada de este en ftp://ftp.rs.internic.net/domain con el nombre de o named.root, que debers renombrar a named.ca a 14 Tras encontrarlo debes copiarlo en el lugar especicado por el estamento zone. En nuestro caso deber copiarlo as en /var/named/
10
42
@ . A.ROOT-SERVERS.NET. ; . B.ROOT-SERVERS.NET.

IN SOA IN NS A NS A . . . localhost. lsfl.sflj. (1 21 10 100 1200) A.ROOT-SERVERS.NET. 198.41.0.4 B.ROOT-SERVERS.NET. 192.228.79.201
3600000 3600000 3600000 3600000
En secciones posteriores se explicarn detalladamente cada uno de los elementos que componen a este archivo. Por ahora saber que cada pareja de l neas como la mostrada a continuacin quiere o decir que la zona "." es resuelta, por ejemplo, por el servidor de nombres B.ROOT-SERVERS.NET.
. . . NS A . . .
. B.ROOT-SERVERS.NET.
3600000 3600000
B.ROOT-SERVERS.NET. 192.228.79.201
Este a su vez tiene asignada la direccin IP (address) 192.228.79.201. o
2.4.2.
Comprobacin del servidor cach o e
Tras realizar lo indicado anteriormente, el servidor BIND ya est congurado para dar servicio a cach. Para probar su funcionamiento y suponiendo que dispones de conexin a Internet, haremos e o lo siguiente, 1. Editaremos el chero /etc/resolv.conf15 y tras comentar su contenido escribiremos en la primera l nea nameserver localhost, de esta forma indicamos a nuestro equipo que l mismo e realizar la labor de servidor de nombres. Una forma rpida de hacer esto es ejecutar, a a
[root@linux]# echo "nameserver localhost" >/etc/resolv.conf
pero ten cuidado porque entonces machacas todo el contenido. 2. Iniciar el servicio ofrecido por BIND. El programa que ofrece el servicio en background es named. Bastar con que ejecutemos16 : a
[root@linux]# service named start Iniciando named:
[ OK ]
Pudiera ocurrir que el comportamiento fuese el siguiente,

[root@linux]# service named start named: already running
15 Recuerda que en este chero se especican el servidor o servidores de nombres para nuestra mquina. En este caso a debemos indicar que la direccin IP del servidor de nombres es la de cualquiera de las interfaces de red o simplemente o localhost. 16 En las distribuciones en las que no existe el comando service el servicio debe arrancarse por medio de:
[root@linux]# /etc/init.d/named start
2.4. CONCEPTOS BASICOS SOBRE LA CONFIGURACION DE BIND
43
Esto signica que el servicio ya estaba arrancado. En este caso, para que la conguracin o realizada sea tenida en cuenta el servicio deber reiniciarse, a
[root@linux]# service named restart Deteniendo named: rndc: connect failed: connection refused Iniciando named: [ OK ] [ OK ]
Observa que aparece un mensaje indicando que la conexin rndc ha fallado. De momento o no daremos importancia a este hecho y posteriormente, en la proxima seccin (la 2.5), se o explicar como solucionarlo. a A continuacin puedes utilizar el comando dig para comprobar que tu mquina, actuando como o a DNS, resuelve nombres. Escribe:
[user@linux]$ dig www.cossio.net
Con este comando se solicita informacin sobre la direccin IP asociada a www.cossio.net o o y los servidores de nombres que resuelven el dominio cossio.net. El resultado que obtendrs a ser parecido a esto: a
; <<>> DiG 9.3.1 <<>> www.cossio.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33509 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.cossio.net. IN ;; ANSWER SECTION: www.cossio.net. 86400 IN ;; AUTHORITY SECTION: cossio.net. 172800 IN cossio.net. 172800 IN ;; ;; ;; ;;
217.76.130.84
NS NS
dns1.servidoresdns.net. dns2.servidoresdns.net.
Query time: 1695 msec SERVER: 192.168.1.128#53(192.168.1.128) WHEN: Wed Jul 12 22:19:45 2006 MSG SIZE rcvd: 100
Observa que en la cuarta l nea empezando por el nal aparece un tiempo de 1695ms (1.695 segundos). Este indica lo que le ha costado a nuestro servidor hacer la resolucin. Esto es as porque o ha tenido que preguntar en Internet a otro/s servidor/es sobre la resolucin de www.cossio.net. o La prxima vez ya no tendr que preguntar a un servidor del exterior; nuestro servidor cach ha o a e guardado la informacin y si le volvemos a preguntar lo mismo comprobaremos que el tiempo de o respuesta es mucho menor.
44

[user@linux]$ dig www.cossio.net ; <<>> DiG 9.3.1 <<>> www.cossio.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31295 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.cossio.net. IN ;; ANSWER SECTION: www.cossio.net. 84802 IN
217.76.130.84
;; AUTHORITY SECTION: cossio.net. 171202 IN NS dns1.servidoresdns.net. cossio.net. 171202 IN NS dns2.servidoresdns.net. ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; Query time: 1 msec ;; SERVER: 192.168.1.128#53(192.168.1.128) ;; WHEN: Wed Jul 12 22:19:45 2006 ;; MSG SIZE rcvd: 100
Observa que el tiempo de respuesta se ha reducido a 1 milisegundo. Observa tambin que las e cantidades numricas que estn delante de IN tambin se han reducido, exactamente en 1598 unie a e dades. Esos nmeros son los tiempos de vida de los registros de recurso17 e indican la cantidad en u segundos que tardar nuestro servidor de nombres cach en perder la informacin que ha almacea e o nado. Por ejemplo el tiempo de vida inicial del registro A eran 86400 segundos, es decir 24 horas; transcurrido ese tiempo el registro A ser borrado. a
2.5.
Control remoto del servidor de nombres: rndc
rndc signica control remoto del servidor de nombres (remote name daemon control). Esta herramienta permite recargar, parar, comprobar el estado, mostrar estad sticas, . . . del servidor de nombres de forma remota. El funcionamiento de rndc requiere de un archivo de conguracin con una grmatica similar o a 18, pero con la salvedad de que slo acepta tres tipos de estamentos a la de /etc/named.conf o options, key y server, adems de la clusula include que puede emplearse en cualquiera de los a a estamentos.
Estamentos de /etc/rndc.conf
options La estructura es,
options{ Clusulas de configuracin ; a o };
Dentro de este estamento hay tres posibles clusulas: a

Registros de recurso son por ejemplo A y NS. El tiempo de vida se denota por TTL. Todo esto se ver posteriormente a en la seccin 2.7. o 18 El archivo /etc/named.conf y sus correpondientes estamentos y clusulas sern estudiados en la seccin 2.6. a a o
17
2.5. CONTROL REMOTO DEL SERVIDOR DE NOMBRES: RNDC
45
default-server nombre del servidor o direccin IP ; o Este ser el nombre o direccin del servidor utilizado por rndc cuando no se ejecute a o con la opcin -s. o Ejemplo:
default-server localhost;
default-key clave; Aqu debe indicarse el nombre de la clave dada en el estamento key. Ejemplo:
default-key "miclave";
default-port no de puerto; Puerto utilizado en la comunicacin con el servidor remoto. Este puerto ser empleado o a siempre y cuando no se especique ninguno al ejecutar el comando (opcin -p) o se o haya denido el puerto en el estamento server. El puerto que se usar por defecto a es el 953. Ejemplo:
default-port 953;
server La estructura es,

server direccion IP o nombre { Clusulas de configuracin ; a o };
Este estamento es opcional y en caso de no existir se tomar la conguracin dada en el a o estamento options. Dentro de este estamento hay dos posibles clusulas: a key {clave1;clave2; . . . }; Esta clusula se utiliza para vincular una clave denida en el estamento key con el a servidor. Si no se estipula ninguna se tomar la indicada en el estamento options. a Ejemplo:
key {"miclave";};
port no de puerto; Indica el puerto por el que se produce la comunicacin con el servidor. Si no se o estipula ninguna se tomar la indicada en el estamento options. a Ejemplo:
port 953;
key La estructura es,
46
key clave { Clusulas de configuracin ; a o };
Dentro de este estamento hay dos posibles clusulas: a algorithm Tipo de algoritmo; BIND slo soporta el algoritmo hmac-md5 por lo que el empleo de esta clusula es o a unico. Ejemplo:
algorithm hmac-md5;
secret Clave secreta; Sirve para indicar la clave secreta utilizada en la comunicacin segura. Debe ser o compartida por los cheros /etc/rndc.conf y /etc/named.conf para que se pueda establecer dicha comunicacin. Esta clave puede ser obtenida utilizando el comando o rndc-confgen que ser comentado despus. a e Ejemplo:
secret "yXFhgShGEZ1oMsnNe03tWg==";
Tras exponer las partes de las que est compuesto el chero /etc/rndc.conf el siguiente paso a ser crearlo. Podr a amos hacerlo escribiendolo l nea a l nea, pero existe una forma ms sencilla. a Debido a que su contenido no admite grandes modicaciones, la mayor de los rndc.conf utilizados a en el mundo son muy similares. Esto hizo que los desarrolladores de BIND desarrollaran un comando que crea automticamente el archivo de conguracin. Este comando es rndc-confgen y su uso es a o tan sencillo que basta con ejecutarlo para obtener un posible chero de conguracin de rndc para o nuestro ordenador:
[root@linux]# rndc-confgen # Start of rndc.conf key "rndc-key" { algorithm hmac-md5; secret "aPYDw+6OQCak0yRVW3cXPQ=="; }; options { default-key "rndc-key"; default-server 127.0.0.1; default-port 953;
}; # End of rndc.conf # # # # # # # # # # # Use with the following in named.conf, adjusting the allow list as needed: key "rndc-key"{ algorithm hmac-md5; secret "aPYDw+6OQCak0yRVW3cXPQ=="; }; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; }; End of named.conf
2.5. CONTROL REMOTO DEL SERVIDOR DE NOMBRES: RNDC
47
Unicamente deberemos copiar el contenido mostrado. Puesto que debe haber relacin entre el o chero /etc/rndc.conf y el /etc/named.conf, en este ultimo se deben incluir las correspondientes l neas propoporcionadas tras la ejecucin del comando rndc-confgen. As los cheros /etc/rndc. o conf y /etc/named.conf quedar an:
# Fichero /etc/named.conf options { directory "/var/named/"; }; key "rndc-key"{ algorithm hmac-md5; secret "aPYDw+6OQCak0yRVW3cXPQ=="; }; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; }; zone "."{ type hint; file "/var/named/named.ca"; };
# Fichero /etc/rndc.conf key "rndc-key"{ algorithm hmac-md5; secret "aPYDw+6OQCak0yRVW3cXPQ=="; }; options { default-key "rndc-key"; default-server 127.0.0.1; default-port 953; };
Cuando reiniciemos de nuevo el servicio named, el demonio rndc estar ya activo, a

[root@linux]# service named restart Deteniendo named: rndc: connect failed: connection refused Iniciando named: [ OK ] [ OK ]
El aviso que aparece es debido a que durante la parada del servicio no se detecta el funcionamiento de rndc. Comprueba que reiniciando de nuevo el mensaje desaparece:
[root@linux]# service named restart Deteniendo named: Iniciando named:
[ OK ] [ OK ]
El siguiente paso ser aprender a utilizar rndc. La sintaxis del comando es: a
rndc [-c config ] [-s server ] [-p port] [-y key ] command
48
Comandos y opciones de rndc Indice alfabticorndc!comandos y opciones e

Opcin -c o El lugar donde normalmente se encuentra el chero de conguracin de rndc es /etc/rndc. o conf. Esta ubicacin puede ser cambiada utilizando la opcin -c. o o Ejemplo:
[root@linux]# rndc -c /etc/named/rndc.conf restart
Opcin -s o Sirve para indicar el servidor con el que se hace la comunicacin remota rndc. Si no se indica o esta opcin se tomar el servidor por defecto dado con la clusula default-server en el o a a estamento options. Si existe el estamento server en /etc/rndc.conf, el servidor indicado ser el escogido antes que el designado en default-server. a Ejemplo:
[root@linux]# rndc -s 10.1.23.6 status
Opcin -p o Sirve para indicar el puerto por el que se realizar la comunicacin con el servidor. Si no se a o especica esta opcin se tomar el puerto asignado en el chero /etc/rndc.conf. o a Ejemplo:
[root@linux]# rndc -p 953 stop
Opcin -y o Se utiliza para indicar la clave utilizada en la comunicacin en el caso de que en /etc/rndc.conf o se hayan denido varias. Ejemplo:
[root@linux]# rndc -s 11.2.54.7 -y "rndc-key" halt
Comando reload Tras su ejecucin se recargarn por completo el archivo de conguracin /etc/named.conf y o a o todos los cheros de conguracin de zona. o Ejemplo:
2.6. EL FICHERO NAMED.CONF
49
[root@linux]# rndc reload
La ejecucin del anterior comando puede ser muy pesada para el sistema si el servidor cuenta o con miles de zonas (y sus respectivos cheros de conguracin). Normalmente no es necesario o recargar todas las zonas sino aquella que es modicada, por esta razon el comando reload ofrece la opcin de especicar una zona en concreto. o Ejemplo:
[root@linux]# rndc reload cossio.net
Comando recong Similar al comando reload, pero en este caso recarga el chero de conguracin /etc/named. o conf y las nuevas zonas creadas. No se recargan las zonas que ya exist an, aunque hayan sido cambiadas. Ejemplo:
[root@linux]# rndc reconfig
Comando stop Este comando detiene el servidor salvando los cambios recientes que se hayan podido producir por una actualizacin dinmica. As antes de parar se guardarn los cheros maestros de las o a a zonas actualizadas. Ejemplo:
[root@linux]# rndc stop
Comando halt Para el servidor inmediatamente. Las actualizaciones no sern guardadas, pero sern recupea a radas cuando el servidor sea de nuevo arrancado. Su utilizacin es similar a la de stop. o Comando status Muestra por pantalla el estado del servidor. Antes de continuar es conveniente que hagas pruebas con el comando rndc.
2.6.
El chero named.conf
El archivo named.conf, al ser un chero de conguracin, deber encontrarse dentro del direco a torio /etc/. Es posible que tras la instalacin de BIND el archivo no se encuentre en ese lugar, en o cuyo caso, tenemos dos opciones:
50
CAP ITULO 2. CONFIGURACION DE UN DNS: BIND 1. Crear el archivo /etc/named.conf completamente vac para posteriormente introducir las o l neas de conguracin necesarias. Esto es lo que se ha hecho en la conguracin del servidor o o cach. e 2. Utilizar un chero de conguracin de ejemplo que es proporcionado con la instalacin de o o BIND y que normalmente se ubica en /usr/share/doc/bind-9.2.3/chroot/named/etc/ named.conf.
Ayuda!! Si el chero de ejemplo named.conf no se encuentra en la ruta especicada puedes buscarlo en el sistema de cheros de GNU/Linux. Para ello ejecuta el comando: [root@linux]# find /usr -name named.conf
Puesto que la sencillez del chero /etc/named.conf lo permite, nosotros elegiremos la primera opcin y crearemos l o nea a l nea el archivo. Esto permitir una mejor comprensin de su contenido. a o Comenzaremos con una conguracin muy sencilla y gradualmente, a medida que avance la prctica, o a se escribirn ejemplos ms complejos. a a
2.6.1.
Contenido del chero /etc/named.conf
Supongamos que no disponemos del chero /etc/named.conf tras realizar la instalacin de o BIND. El primer paso ser crearlo nosotros mismos. Como el directorio /etc/ pertenece a root, a deberemos convertirnos en dicho usuario para crearlo19 ,
[root@linux]# touch /etc/named.conf
El contenido de este archivo normalmente est dividido en varias partes llamadas estamentos. a Algunos estamentos son: acl, controls, include, key, options, view, zone, . . . En este momento slo se van a comentar cuatro de ellos, los estamentos options, key, controls y zone. La estructura o ser a:
// Parte correspondiente al estamento options options{ Clusulas de configuracin ; }; a o // Parte correspondiente al estamento key key "clave"{ Clusulas de configuracin ; }; a o // Parte correspondiente al estamento controls controls{ Clusulas de configuracin ; }; a o //Parte para definir las diferentes zonas zone "nombre de la zona "{ Clusulas de configuracin ; }; a o
Un ejemplo podr ser: a

19
Para crearlo y editarlo a la vez escribiremos,

[root@linux]# vi /etc/named.conf

options{ directory "/var/named/"; allow-query {any}; }; key "mikey"{ algorithm hmac-md5; secret "KdVONf9FplriTVubw85SgQ=="; }; controls { inet 192.168.19.12 port 953 allow { 192.168.19.12; } keys { "mi-key"; }; }; zone "cosmegarcia.org"{ type master; file "maestra.cosmegarcia.org"; notify no; }; //Directorio de trabajo //Se permite el uso a todos
51
//Zona de tipo maestra
A continuacin describiremos algunos de los parmetros que pueden contener los estamentos o a options, key, controls y zone.
Parmetros del estamento options a

directory Este parmetro indica el directorio de trabajo del servidor. Todos los cheros indicados en a /etc/named.conf se podrn escribir con una ruta relativa a la indicada en este parmetro. a a En el ejemplo mostrado antes, el chero maestra.cosmegarcia.org tiene como ruta absoluta: /var/named/maestra.cosmegarcia.org. Si no se utiliza directory se deben indicar las rutas absolutas. Si suponemos que en el ejemplo anterior no se ha estipulado el directorio de trabajo, la l nea correspondiente a file deber a haberse escrito como:
file "/var/named/maestra.cosmegarcia.org";
pid-le Aqu se indica la ruta absoluta, o relativa con respecto a directory, del chero en el que el servidor escribe los identicadores de los procesos (PID) que ejecuta el servicio named. Si no se especica nada el chero por defecto es /var/run/named/named.pid. El chero de pid es utilizado por los programas que quieren enviar seales al servidor de n nombres.
port
52
Aqu se indica el nmero de puerto que el servidor usa para recibir y enviar el trco causado u a por el protocolo DNS. El protocolo es de tipo udp y por defecto el puerto es el 53. Se recomienda cambiar de puerto unicamente en procesos de testeo del servidor, ya que otro puerto diferente al 53 har imposible la comunicacin global del DNS. a o Ejemplo:
options{ port 5353; };
Para comprobar su funcionamiento puedes utilizar dig con el parmetro -p: a

dig -p 5353
allow-query Especica a que hosts se les permite hacer preguntas de resolucin de nombres al servidor. Por o defecto se permite que cualquier host pregunte al servidor, tal y como se muestra en el ejemplo anterior. Ejemplo:
options{ allow-query {192.168.19.0/24;}; /*Se permite a los ordenadores de la red 192.168.19.0 con mscara 255.255.255.0 */ a };
Para hacer referencia a una o varias redes simultneamente es posible denir lo que se denomia nan listas de acceso (access lists). Para ello se utiliza el estamento acl. Evidentemente por su catergor de estamento debe colocarse fuera del de options. a Ejemplo:
acl "redescossio" {192.168.19.0/24; 192.168.17.0/24; }; options{ allow-query {"redescossio";}; /*Se permite a los ordenadores de las redes 192.168.19.0 y 192.168.17.0 */ };
notify Es una variable que puede tomar los valores yes, explicit y no. Por defecto vale yes y esto hace que cuando se produce algn cambio en las zonas maestras que el servidor debe resolver, u se env mensajes de noticacin a aquellos servidores listados en los registros de recurso NS an o (los registros de recurso son descritos en una seccin posterior; en particular el NS est denido o a en la pgina 61) contenidos en el correspondiente archivo de conguracin de zona (el archivo a o de conguracin de zona se describe en la seccin 2.7). o o
53
Si a notify se le asigna explicit las noticaciones unicamente son enviadas a las servidores listados en el parmetro also-notify; y si se le asigna no, no env noticaciones a ningn a a u servidor. Ejemplo:
options{ notify yes; };
//Valor por defecto
also-notify Dene una lista global de las direcciones IP de los servidores a los que tambin se les ene viar noticacin cuando una zona es recargada con nueva informacin, en adicin a la lista de a o o o servidores contenidos en los registros de recurso NS. Esto ayuda a asegurar que la nueva actualizacin de la zona se difunde rpidamente entre todos o a los servidores. Ejemplo:
options{ also-notify {202.12.27.33;192.203.230.10;198.32.64.12;}; };
forward Cuando se le pide a named que resuelva un nombre de dominio hay varias opciones; una de ellas es que reenv la pregunta a otro servidor. Este es el comportamiento forward. e Esta opcin slo tiene sentido si no est vac la lista de forwarders. Por defecto el valor o o a a asignado a forward es first, esto provoca que el servidor pregunte en primer lugar a los forwarders y si no encontrara respuesta de los mismos tratar de encontrarla por s mismo. a Cuando se da el valor only a forward signica que el servidor slo preguntar a los forwarders o a (si ellos no responden no podr hacer la resolucin). a o Ejemplo:
options{ forward only; };
//Funcionamiento de solo reenvo
forwarders Permite especicar una lista de direcciones IP que ser usada para hacer reenv (forwarding). a o Ejemplo:
54
options{ forward first; forwarders {192.168.19.1;192.168.17.1; }; };
Aunque el forwarding se puede hacer desde el estamento options de forma general, es posible indicarlo directamente en cada zona que as se desee, teniendo diferentes forwarders para cada una. He incluso se pueden denir diferentes comportamientos first/only (ver seccin 2.10). o
Parmetros del estamento key a

algorithm y secret La sintaxis y las clusulas contenidas en este estamento ya fueron explicadas en la pgina 46. a a Invitamos al lector que tenga alguna duda sobre su uso a que se remita a dicha pgina. a
Parmetros del estamento controls a

inet El estamento controls se utiliza para declarar los canales de control que pueden usar los administradores del sistema para modicar la operacin del servidor de nombres. Los canales o de control son usados por medio del comando rndc. Un control inet permite denir un canal de comunicacin v TCP especicando una direccin o a o IP de comunicacin y un puerto. o
allow Aunque se abra un canal de cominicacin por medio de inet, el acceso al mismo est restringido o a por las clusulas allow y keys. a Con allow se ja una lista de direcciones IP correspondientes a los hosts permitidos a entrar en el canal abierto por inet.
keys Establece una lista de identicadores de clave vlidos para entrar en el canal. Cada uno de los a identicadores de las claves contenido en la lista se podr utilizar para autenticar, v rma a a digital, los comandos y respuestas de control dadas en el canal abierto por inet.
Parmetros del estamento zone a

type master
55
Un servidor de tipo maestro es aquel que contiene una copia maestra de los datos de la zona con autoridad para responder consultas sobre la misma. En la seccin 2.8 se mostrarn ejemplos de o a uso.
type slave
Una zona de tipo slave (esclava) es una rplica de una zona maestra. Junto con el tipo slave e se debe aadir el parmetro masters que establece una lista con una o ms direcciones IP de n a a servidores maestros con los que el esclavo puede contactar para actualizar la copia de la zona. Adems es aconsejable, aunque no obligatorio, el uso del parmetro file para indicar el chero a a en el que se escribirn los datos de la zona cada vez que sea recargada, y del cual se leeran a cuando el servicio se reinicie. Esto har ms rpido al servidor y reducir el consumo de ancho a a a a de banda.
type stub Una zona tipo stub es similar a la tipo slave con la diferencia que en esta se replican unicamente los registros de recurso NS en lugar de la zona completa. La zona stub no es parte del estndar a DNS, sino que es una caracter stica espec ca de BIND y algunos de los usos para los que fue creada ya no estn recomendados. Por esta razn en este libro no va a ser utilizada. a o
type hint Con este tipo de zona se crean los servidores cach. Dentro de este tipo de zona debe hacerse uso e del parmetro file para indicar el chero en el que estarn recogidos los nombres y direcciones a a de los servidores ra Junto con la instalacin de BIND se suele proporcionar el chero named.ca z. o que contiene esa lista. En la pgina 41 se expuso su uso. a
type forward Esto permite crear una zona de reenv Cuando un servidor tiene una zona de este tipo no o. es l quien hace la resolucin sino que pregunta a otra mquina (descrita en el parmetro e o a a forwarders, pgina 53) que ser la encargada de hacer la resolucin. a a o Es importante no confundir la zona tipo forward type forward con las clusulas forward y a forwarders, ya que son cosas muy diferentes. En una zona de tipo forward es donde normalmente se incluyen dichos estamentos (aunque tambin pueden ser incluidos en el estamento e options). El proceso de reenv sucede cuando el servidor no tiene la respuesta en la cach. Una descripcin o e o de su uso puede verse en la seccin 2.10. o
le
56
El parmetro file se utiliza dentro del estamento zone. A file se le asigna un chero, este es a el chero de conguracin de zona. o En relacin al contenido del chero, en el caso del servidor maestro es una copia maestra de o la misma, en el caso de la zona esclava es una rplica, en el caso de la zona hint contiene una e lista de los servidores ra (TLDs), . . . A lo largo del cap z tulo se vern muchos ejemplos de uso. a
masters El parmetro se utiliza dentro del estamento zone y unicamente cuando esta zona es de tipo a esclavo (slave). Permite indicar quin o quienes son los servidores maestros de esa zona. Esto signica que e cuando la zona deba ser actualizada las solicitudes de actualizacin se harn a los servidores o a contenidos en la lista masters. Ejemplo:
masters {19.128.9.4;12.68.7.61; };
notify y also-notify notify es un parmetro que actuar de forma genrica para todas las zonas si se incluye en a a e el estamento options o que actuar de forma local al ser incluido en el estamento zone. Lo a mismo ocurre con el parmetro also-notify. a La descripcin de ambos parmetros es similar a la dada anteriormente. o a
2.7.
Los cheros de conguracin de zona o
Como ya se ha comentado, cada zona denida en /etc/named.conf debe tener un chero asociado en el que se expongan las relaciones entre las diferentes direcciones IP pertenecientes al dominio y sus nombres. Para facilitar la comprensin de este archivo supongamos que disponemos de una estrutura de o red como la mostrada en la gura 2.9. En el chero de zona aparecern las relaciones entre nombres a de dominio y direcciones correspondientes a la supuesta estructura del dominio iesbajoaragon. com. Observa que por ejemplo la mquina con direccin IP 62.167.122.10 ofrece dos servicios, web a o y ftp. Pese a que slo es una mquina tenemos dos servicios y por tanto deberemos asignar a dos o a nombres diferentes la misma direccin. Como cada servicio se ofrece por un puerto diferente, no o habr ninguna posible confusin cuando se solicite alguno de los dos. a o El nombre dado al chero de zona asociado al dominio puede ser cualquiera, pero una nomenclatura del mismo al azar podr convertir el mantenimiento de BIND en un trabajo tedioso. a Como existen diferentes tipos de zonas y cada una de ellas puede tener uno o ms archivos de a conguracin asociados, recomendamos nombrar a estos archivos con la siguiente estructura: o
tipo de zona.nombre de zona
Esto permitira hacer ms legibles los listados (comando ls) de los archivos de conguracin de zona, a o que nosotros almacenaremos en /var/named/. Por ejemplo, el archivo de conguracin asociado a o la zona de tipo maestro iesbajoaragon.com se llamar a
maestra.iesbajoaragon.com
2.7. LOS FICHEROS DE CONFIGURACION DE ZONA
57
Figura 2.9: Ejemplo de una estructura de red donde se ofrecen servicios a Internet de tipo WEB, FTP Y DNS.
Un ejemplo del contenido de /var/named/maestra.iesbajoaragon.com podr ser el siguiente: a

$TTL 24h $ORIGIN iesbajoaragon.com. iesbajoaragon.com. IN SOA ns.iesbajoaragon.com. root.localhost. (3001200602; 21600; 10800; 604800; 21600; )
iesbajoaragon.com. iesbajoaragon.com. ns.iesbajoaragon.com. www.iesbajoaragon.com. ftp correo
IN IN IN IN IN IN
NS MX 10 A A A A
ns.iesbajoaragon.com. correo 62.167.122.9 62.167.122.10 62.167.122.10 62.167.122.11
En general este chero contendr dos tipos de elementos bien diferenciados. En el primero de a estos tipos, se encuentran las llamadas directivas (directives); el segundo tipo se corresponde con los registros de recurso (resource records). Las directivas van precedidas por el s mbolo $, y pueden ser cuatro: $ORIGIN, $INCLUDE, $TTL y $GENERATE. Por su parte los registros de recurso representan el conjunto de informacin asociada a un nombre de dominio. En principio el orden o de los registros dentro del chero no es importante, con la salvedad de que el registro SOA debe ser el primero. Existen muchos registros de recurso, algunos de ellos son SOA, A, CNAME, PTR, . . . A cotinuacin comentaremos algunos registros y directivas, lo que nos permitir entender el contenido o a del chero ejemplo mostrado.
Descripcin del contenido de maestra.iesbajoaragon.com o

Directiva $TTL
58
El tiempo de vida general para los registros de recurso se designa por medio de la directiva $TTL, que signica Time To Live. Esta directiva se coloca en la primera l nea del archivo de conguracin, antes del registro SOA. o Es utilizado por los servidores cach para saber cuando tienen que actualizar los registros de e las zonas descargadas y guardadas en memoria. Esto fue explicado en la seccin 2.4.1 (pgina o a 44). Si la cantidad asignada a $TTL es cero, signica que el registro o registros de recursos no pueden ser cacheados. Las unidades de la cantidad asociada a $TTL son segundos y puede estar comprendida entre 0 y 2147483647 (esto corresponder aproximadamente a 68 aos). Tambin puede ser indicada a n e en otras unidades utilizando los siguientes sujos para la cantidad numrica: e Sujo s m h d w Unidades segundos minutos (60 s) horas (3600 s) d (86400 s) as semanas (604800 s)
El tiempo asignado por la directiva $TTL es utilizado por los registros de recursos que no lo tienen denido espl citamente. En cada registro es posible asignar de forma particular un tiempo de vida. En el siguiente ejemplo se muestran claramente las partes de la denicin de o un registro de recurso,
Nombre www TTL 600 Clase IN Tipo A Datos 62.123.0.1
En cualquier caso es un buen criterio establecer una directiva $TTL al principio del archivo de conguracin, y as lo haremos en adelante. o
Directiva $ORIGIN La segunda l nea del ejemplo contiene a esta directiva. La sintaxis es:
$ORIGIN nombre dominio
Establece el nombre de dominio por omisin. En otras palabras, mediante esta directiva se o indica el nombre de dominio que ser aadido a los nombres de mquinas que acompaan a a n a n los registros de recurso que no acaban en punto (.). La repercusin de esta l o nea en el ejemplo anterior se pone de maniesto por ejemplo en la l nea,
ftp IN A 62.167.122.11
que es equivalente a escribir,

ftp.iesbajoaragon.com. IN A 62.167.122.11
59
Como ftp no termina en punto, el nombre se completa con lo establecido en $ORIGIN. Observa que el contenido de la directiva $ORIGIN no se aade al nombre especicado cuando este acaba n en punto.
www.miempresa.com. IN A 62.167.122.10
Comentarios adicionales sobre el uso de $ORIGIN El uso de esta directiva no es necesario en caso de que la zona declarada en el chero /etc/ named.conf se corresponda con el nombre de dominio que se quiere utilizar. As en nuestro ejemplo , podr amos haber prescindido de ella y todo hubiese funcionado correctamente. Su utilidad aparece cuando el archivo de conguracin de zona est compuesto por otros archivos y en alguno de estos o a utilizamos otro nombre de dominio. La inclusin de otros archivos se realiza utilizando la directiva $INCLUDE. El contenido del chero o se incluye en la misma posicin en la que se encuentra $INCLUDE. Un ejemplo de verdadero uso de o $ORIGIN e $INCLUDE podr ser el siguinte: a Imaginad que en /etc/named.conf se ha denido la zona cossio.net de tipo master, y que su chero de conguracin asociado, maestra.cossio.net, es o
cossio.net. IN SOA ns root.localhost. (3001200602 21600 10800 604800 21600 )
www $INCLUDE ftp
IN NS ns IN A 62.167.122.10 /var/named/cossio/maestra.aula19 IN A 62.167.122.11
El signicado de cada una de las l neas se podr deducir de las explicaciones dadas en apartados a posteriores. El objetivo aqu es el de mostrar que en este chero no se utiliza $ORIGIN y sin embargo BIND entender perfectamente que www equivale a www.cossio.net, ya que al no terminar el a nombre "www" en punto, BIND lo completa con el nombre de dominio. Observa tambin que la e penltima l u nea indica que se debe incluir el contenido del archivo maestra.aula19 perteneciente al directorio /var/named/cossio. Imagina que el contenido de este archivo es,
$ORIGIN aula19.cossio.net. equipo1 A 192.168.19.1 equipo2 A 192.168.19.2 equipo3 A 192.168.19.3
en l s se ha incluido la directiva $ORIGIN. El uso de la misma provoca que, por ejemplo, la e l nea,
equipo1 A 192.168.19.1
equivalga a,
equipo1.aula19.cossio.net. A 192.168.19.1
60
CAP ITULO 2. CONFIGURACION DE UN DNS: BIND Si la directiva $ORIGIN no hubiese sido incluida, la l nea asociada al equipo1 hubiera equivalido
a,
equipo1.cossio.net. A 192.168.19.1
ya que se hubiese completado con el nombre de dominio tomado por defecto. Por ultimo es importante sealar que la directiva $ORIGIN slo tiene inuencia en el archivo maestra.aula19, es n o decir se comporta como una directiva local. Por tanto, la l nea,
ftp IN A 62.167.122.11
contenida en el archivo maestra.cossio.net y escrita posteriomente a la llamada del archivo maestra.aula19 es equivalente a,
ftp.cossio.net. IN A 62.167.122.11
Registro SOA Dene el comienzo de una zona de autoridad (SOA siginifca Start Of Authority). Es un registro de uso obligatorio, de hecho ser el primer registro que nos encontremos en los cheros de a conguracin de zona. Su sintaxis es: o
nombre de dominio IN SOA servidor responsable (parmetros) a
En nombre de dominio se debe indicar el nombre de dominio que se va a resolver; en el ejemplo anterior (pgina 57) el nombre de dominio era iesbajoaragon.com, que normalmente a coincidir con el nombre de zona dado en el chero /etc/named.conf. Si coincide es posible a prescindir de su escritura y sustituirlo por el comod @: n
@ IN SOA servidor responsable (parmetros) a
En servidor se indica el nombre de la mquina que hace de DNS. Se suele utilizar como a nombre ns (name server) seguido del nombre de dominio, por ejemplo ns.iesbajoaragon.com, pero puede darse cualquier nombre permitido. En responsable debe escribirse una cuenta de correo o un alias de la misma en la que el mantenedor o mantenedores del servicio encontrarn las incidencias que se produzcan. a Por ultimo en parmetros se especicarn en este orden: a a Numero de serie. Para este se suele elegir la fecha en la que se produjo la ultima actualizacin. Por ejemplo, si el d 30 de enero de 2006 se hicieron dos actualizaciones o a en el nmero de serie se podr indicar la siguiente cantidad 3001200602. u a Periodo de refresco. Los sevidores esclavos hacen la resolucin de nombres a partir o de la informacin proporcionada por los servidores maestros que tienen congurados. o Esta informacin es actualizada cada vez que transcurre el tiempo indicado en este o parmetro. El funcionamiento de los servidores esclavos ser descrito en la seccin a a o 2.9. En realidad cada periodo de refresco se hace una solicitud de actualizacin, pero o el esclavo slo actualizar en caso de haberse producido algn cambio en el servidor o a u maestro. Los cambios sern detectados por el esclavo comprobando si el nmero de a u serie ha cambiado.
61
Frecuencia de reintentos. Indica el tiempo que debe esperar el DNS esclavo para solicitar de nuevo la informacin de actualizacin al maestro en caso de que este o o ultimo no le haya respondido transcurrido el periodo de refresco. Tiempo de expiracin. Tiempo mximo que ser mantenida la informacin sin aco a a o tualizar en el servidor esclavo en caso de que el maestro no responda a las solicitudes. Transcurrido ese tiempo la informacin de la zona se perder. o a TTL M nimo. Esta cantidad es asignada por el servidor a los registros de recurso en caso de no utilizar la directiva $TTL. Indica el m nimo tiempo que permanecer la a informacin obtenida por el DNS en memoria en caso de funcionar como servidor o cach (el funcionamiento como servidor cach fue explicado en el apartado 2.4.1). e e Valor mximo 3 horas. a As un ejemplo podr ser: , a
@ IN SOA ns root.localhost. ( 3001200602; Numero de serie 21600; Periodo de refresco en sg (6h) 10800; Frecuencia de reintentos en sg (3h) 604800; Tiempo de expiracin en sg - (1semana) o 21600; Tiempo de vida de registros en cach (6h) e );
Comentarios adicionales sobre el uso del registro SOA Observad que en el ejemplo anterior los tiempos se han colocado en segundos y que lo escrito tras un punto y coma se entiende como un comentario20 . Como ya ha sido comentado, la @ del principio de la l nea del registro SOA es un comodn para indicar que el nombre de dominio es el mismo que el denido en el archivo /etc/named.conf. Es decir, si estuvieramos hablando del ejemplo de la pgina 57, la @ signicar iesbajoaragon.com. a a: A continuacin y despus de SOA aparece ns; al no acabar en punto (.), BIND lo completar con o e a el nombre del dominio. En nuestro ejemplo, escribir ns es similar a escribir ns.iesbajoaragon.com. Por ultimo indicar que una de las caracter sticas de cualquier registro de recurso (como por ejemplo SOA) es la clase a la que pertenece; existen varios tipos de clases21 , pero para las aplicaciones usuales emplearemos la clase IN, que indica que es un registro que hace referencia a la Internet. De hecho, si no se especica ninguna clase BIND tomar por defecto la clase IN. a Registro NS Indice alfabticoregistro!NS e NS signica nombre del servidor (Name Server). Sirve para indicar el nombre de los servidores de nombres de dominio que tienen autoridad sobre la zona denida. Se suele colocar a continuacin o del registro SOA. Su sintaxis es la que se muestra a continuacin: o
nombre de dominio IN NS servidor con autoridad sobre la zona
Un ejemplo podr ser el indicado anteriormente: a

En este archivo no se pueden emplear los // o /* . . . */ del named.conf Adems de la clase IN existen otros, como por ejemplo HS (hesiod) o CHAOS ambos desarrolladas por el MIT a (Massachusetts Institute of Technology).
21 20
62
bajoaragon.com.
IN NS
ns.bajoaragon.com.
Tras lo explicado sobre $ORIGIN sabemos que esta l nea podr simplicarse por, a
bajoaragon.com. IN NS ns
Como ns se ha escrito sin el punto nal BIND lo completar con el nombre de dominio (o lo a que se haya indicado en la directiva $ORIGIN). Incluso puede simplicarse todav ms, ya que a a como en el SOA ya se ha denido el nombre de dominio, en este registro puede obviarse. As se podr escribir simplemente, a
IN NS ns
Recuerda que la clase IN es la tomada por defecto, luego tambin pod haberse omitido. e a Por ultimo sealar que se pueden aadir tantos registros NS como se desee. Un dominio puede n n estar resuelto por varias mquinas con autoridad. a
Registro A Indice alfabticoregistro!A e El nombre "A" proviene de Address (direccin). Mediante este registro se establecen las asociao ciones entre nombres de dominio y las correspondientes direcciones IP. Su sintaxis se muestra a continuacin: o
nombre de dominio IN A direccin IP o
Para decir que la mquina con direccin IP 192.168.19.1 va a ser identicada con el nombre a o equipo1.cossio.net escribir amos:
equipo1.cossio.net. IN A 192.168.19.1
Para indicar, tal como se mostr en el ejemplo de la pgina 57, que la mquina que ofrece el o a a servicio web www.iesbajoaragon.com tiene direccin 62.167.122.10 deber escribirse o a
www.iesbajoaragon.com. IN A 62.167.122.10
De forma similar a como ocurr con el registro NS es posible simplicar la l a nea anterior y escribir,
www A 62.167.122.10
Comentarios adicionales sobre el uso del registro A Los ejemplos mostrados corresponden a IPs del tipo IPv4, con bind tambin es posible asociar e IPs del tipo IPv6. En este caso se debe utilizar el registro A6, por ejemplo

Host.ejemplo.com. IN A6 0 3ffe:8050:201:1860:42::1
63
Para terminar, sealar que en ocasiones es necesario escribir muchas l n neas similares, sobre todo si se est congurando un DNS para una Intranet. Imagina que deseas escribir en el archivo las a l neas que permiten resolver las direcciones IP de las 52 mquinas pertenecientes a un subdominio a de cossio.net al que se ha llamado aula19.cossio.net; deber escribir las siguientes 52 l as neas
equipo1.aula19.cossio.net. equipo2.aula19.icossio.net. equipo52.aula19.cossio.net. A A . . . A 192.168.19.1 192.168.19.2 192.168.19.52
Para evitar este trabajo repetitivo apareci la directiva $GENERATE. Su uso se entender fcilo a a mente al mostrar la solucin para el ejemplo anterior. Las 52 l o neas anteriores podr ser reducidas an a una sola22 :
$GENERATE 1-52 equipo$.aula19.cossio.net. A 192.168.19.$
Observa que el s mbolo $ es un elemento iterador que variar entre 1 y 52. La directiva $GENERATE a puede ser usada con cualquier conjunto de registros de recurso que unicamente dieran entre s por un iterador. Registro MX Indice alfabticoregistro!MX e Las siglas MX signican Mail eXchanger. Es el registro consultado por un servidor de correo para conocer la direccin IP de otro servidor de correo, al que desea transferir un email. o Para entender este registro imagina dos servidores de correo en la situacin mostrada en la gura o 2.10, el primero es mail.cossio.net que tiene denidos varios usuarios entre ellos carmen con direccin carmen@cossio.net y el segundo correo.aulir.com en el que uno de los usuarios o es juan, con direccin juan@aulir.com. o Cuando carmen manda un correo a juan, este llegar hasta su servidor mail.cossio.net. Lo a primero que har este servidor ser comprobar que carmen es una de las usuarias permitidas. a a En caso de que as sea, tomar el nombre de dominio asociado a la direccin de correo del a o destinatario; en este caso el dominio asociado es aulir.com, ya que el destinatario es juan@ aulir.com. Este nombre de dominio asociado es el que se recoge en un servidor de nombres por medio del registro MX. Este es el registro consultado por mail.cossio.net para conocer la direccin IP del servidor de correo destino. o El servidor de nombres al recibir una peticin de mail exchange devolver la direccin asociada o a o al servidor de correo de aulir.com. Esta direccin deber ser la de correo.aulir.com. o a
Comentarios adicionales sobre el uso del registro MX Habrs observado que en el ejemplo del iesbajoaragon.com el registro MX contiene adems una a a cantidad numrica, un 10. e
22
Podr hacerse uso tambin de la directiva $ORIGIN: a e

$ORIGIN aula19.cossio.net. $GENERATE 1-52 equipo$
192.168.19.$
64
Figura 2.10: Ejemplo comunicacin entre dos servidores de correo utilizando los registros MX. o
iesbajoaragon.com.
IN MX 10
correo
Esta cantidad especica el orden de prioridad para responder a una consulta de mail exchange, la mayor prioridad se da a la cantidad numrica menor. Si existen varios registros con igual prioridad e se elige uno de ellos de forma aleatoria. Y en el caso de que los servidores de mayor prioridad no respondan se trasladar la peticin a los registros con menor prioridad. Las cantidades numricas a o e no tienen ningn signicado especial simplemente sirven para hacer una comparacin relativa al u o resto de registros MX. Supongamos que parte de un archivo de conguracin es el siguiente, o
cosmegarcia.com. IN IN IN IN IN MX 10 MX 10 MX 20 A A mail.cosmegarcia.com. mail2.cosmegarcia.com. correo.backup.es. 11.34.123.2 11.34.123.3
mail.cosmegarcia.com. mail2.cosmegarcia.com.
Una peticin de mail exchange a cosmegarcia.com ser atendida por mail.cosmegarcia.com o a o mail2.cosmegarcia.com de forma aleatoria y en el caso de que ninguno de los dos respondiese, la peticin se trasladar a correo.backup.es. o a Es importante sealar que un registro MX debe tener asociado siempre una direccin IP por n o medio de un registro "A". No es suciente con que tenga asignado un registro CNAME. En el caso en que un dominio tenga asignado un registro CNAME y un registro MX, la direccin o IP apuntada por el MX ser ignorada y la peticin de mail exchange ser resuelta devolviendo la a o a direccin apuntada por CNAME. o Indice alfabticoregistro!CNAME e Registro CNAME CNAME signica Canonical NAME. Sirve para identicar el verdadero nombre de un alias. Un ejemplo real de esto lo podemos encontrar con google. Parte del contenido del chero de conguracin de zona de google.es es el siguiente: o
www.google.es. www.google.com. www.l.google.com. www.l.google.com. www.l.google.com. 47225 IN 604188 IN 13 IN 13 IN 13 IN CNAME CNAME A A A www.google.com. www.l.google.com. 66.249.91.147 66.249.91.99 66.249.91.104
2.8. SERVIDOR DE NOMBRES DE DOMINIO MAESTRO
65
Aqu se observa que www.google.es es un alias de www.google.com, que a su vez es alias de www.l.google.com. A este ultimo nombre de dominio se le asignan varias direcciones IP. Cuando hacemos esto la resolucin va rotando entre las diferentes direcciones provocando un o equilibrio (o balanceo) entre las diferentes mquinas. a Lo anterior puede ser una buena solucin cuando un sitio web es muy visitado. Para evitar o retardos se pueden congurar varias mquinas con el mismo sitio web y que sea el DNS el a encargado de resolver c clicamente las direcciones de dichas mquinas con el n de conseguir a el equilibrado de la carga. Observa en el ejemplo, que lo importante es refrescar los servicios www.l.google.com y no los alias; por eso tienen unos tiempos de vida tan bajos. Por otro lado, el registro CNAME tiene muchos detractores entre los administradores de DNS y como en realidad no es un registro necesario para realizar las conguraciones en este libro se evitar usarlo. a
2.8.
Servidor de nombres de dominio maestro
Como ya se comento en la seccin 2.6 una zona de tipo maestro es aquella que tiene una copia o maestra del archivo de conguacin de zona, es decir, no es ninguna copia efectuada por alguna o transferencia de zona. Para describir la conguracin de un DNS maestro nos apoyaremos en la gura 2.11. Para o que el DNS resuelva las direcciones de las mquinas del dominio mostrado deber incluirse en el a a chero /etc/named.conf la zona iesrioarba.com. Posteriormente se debe crear el llamado archivo de zona que contendr las relaciones entre nombres y direcciones IP de los equipos y servicios a contenidos en las redes 192.168.1.0/24 y 192.168.2.0/24.
Figura 2.11: Ejemplo de funcionamiento de servidor maestro.
2.8.1.
Contenido de /etc/named.conf
En la seccin 2.6 se coment que el chero /etc/named.conf estaba compuesto por diferentes o o secciones o partes. Aqu nos vamos a centrar en la parte correspondiente al estamento zone. La estructura de una zona tipo maestro y su correspondiente sintaxis es similar a la que se muestra a continuacin: o
66
zone

"nombre del dominio a resolver " in { type master; //Servidor con autoridad para resolver el dominio file "fichero de zona para el dominio ";/*El fichero se puede especificar mediante una ruta absoluta o relativa*/
};
Por ejemplo,
zone "iesrioarba.com" in { type master; file "/var/named/maestra.iesrioaraba.com";//ruta absoluta
};
En la declaracin anterior, denimos a iesrioarba.com como un nombre de dominio sobre o el que tiene autoridad completa nuestro servidor DNS GNU/Linux. Autoridad completa signica que el servidor tiene la potestad de resolver este nombre devolviendo la direccin o direcciones o IP que correspondan y que adems es dueo del archivo de conguracin /var/named/maestra. a n o iesrioaraba.com, pudiendo modicarlo cuando lo desee. Es necesario que el chero asociado al parmetro file exista antes de arrancar el servicio. Oba serva tambin que en el ejemplo anterior se ha colocado la ruta absoluta para sealar su ubicacin. e n o Se podr haber dado la ruta relativa si se hace uso de la clusula directory dentro del estamento a a options.
options { directory /var/named"; };
El contenido del chero /etc/named.conf que permite a BIND resolver el dominio iesrioarba. com utilizando rutas relativas ser a:
options { directory "/var/named"; }; zone "iesrioarba.com" in { type master; file "maestra.iesrioarba.com"; };
La conguracin del servidor maestro es tan sencillo como lo que se acaba de exponer. Por tanto o el chero de conguracin de named estar ya completo23 . o a
2.8.2.
Chequeo del archivo /etc/named.conf
Cuando nos iniciamos en la conguracin de BIND, la causa general de errores se suele deber a o problemas de sintaxis. Es muy importante colocar todas las llaves, puntos y coma, comillas, . . . tal y como se indica en el ejemplo. En otro caso el servicio no arrancar. Imaginad que el archivo a named.conf contiene lo siguiente:
options { directory "/var/named"; }; zone "iesrioarba.com" in { type master; file "maestra.iesrioarba.com";
En el ejemplo no se han incluido los estamentos key y controls. Si deseas que rndc este operativo debers a incluirlos tal como se mostr en la seccin 2.5. o o
23
67
El contenido es muy parecido al mostrado anteriormente, pero con la diferencia de que las llaves ({}) asociadas a la zona no estn cerradas24 . Al arrancar/rearrancar (start/restart) el servicio25 a se producir un error, a
[root@linux]# service named restart Deteniendo named: Iniciando named:
[ OK ] [FALL ] O
Para corregir este tipo de errores, existe una herramienta administrativa diseada para comn probar la correcta conguracin; as el chequeo del chero /etc/named.conf se realiza por medio o , del comando named-checkconf. La forma de utilizar este comando es:
[root@linux]# named-checkconf [nombre fichero ]
El parmetro nombre chero est entre corchetes porque es opcional. Si no se coloca, por defecto a a se buscar en /etc/named.conf. Un ejemplo de uso ser a a,
[root@linux]# named-checkconf /etc/named.conf
que proporcionar a,
[rootlinux]# named-checkconf /etc/named.conf /etc/named.conf:8: } expected near end of file
indicando que en la l nea 8 se esperaba un cierre de llaves } que no se ha producido.
2.8.3.
Contenido del archivo de zona
El archivo de zona correspondiente a la zona iesrioarba.com contendr la relacin entre a o direcciones IP y nombres de dominio utilizados en la red mostrada en la gura 2.11. Siguiendo el convenio adoptado en este documento (pgina 56), este archivo de zona deber llamarse a a /var/named/maestra.iesrioarba.com. El contenido del mismo podr ser algo parecido a: a
iesrioarba.com. IN SOA ns.iesrioarba.com. root.localhost. (3001200602 21600 10800 604800 21600 )
iesrioarba.com. ns.iesrioarba.com. equipo1.aula1.iesrioarba.com. equipo2.aula1.iesrioarba.com. ... equipo1.aula2.iesrioarba.com. equipo2.aula2.iesrioarba.com. ...

24
IN IN IN IN
NS A A A
ns.iesrioarba.com. 192.168.10.1 192.168.1.1 192.168.1.2 192.168.2.1 192.168.2.2
IN A IN A
Se abren tras in, pero no se cierran tras el parmetro file. a Volvemos a recordar que en sistemas basados en RedHat, como Mandriva, el control de servicios puede hacerse por medio del comando service. En otros sistemas, como por ejemplo los basados en Debian, el servicio ofrecido por BIND se arrancar escribiendo, a
25
[root@linux]# /etc/init.d/named restart
68
Los puntos suspensivos indican que el chero contina con las l u neas que relacionan nombres e IPs de los, por ejemplo, 16 equipos del aula 1 y los 18 equipos del aula 2. Como el lector habr podido deducir, este archivo puede ser reducido en gran medida si aproa vechamos las posibilidades antes descritas que posee BIND. As podr ser reescrito como, a
@ IN SOA ns root.localhost. (3005200601; 21600; 10800; 604800; 21600; )
ns $INCLUDE $INCLUDE
IN NS ns IN A 192.168.0.1 /var/named/arba/maestra.aula1 /var/named/arba/maestra.aula2
El contenido de los archivos26 /var/named/arba/maestra.aula1 y /var/named/arba/maestra. aula2 respectivamente podr ser: a

$GENERATE 1-16 equipo$.aula1.iesrioarba.com. A 192.168.1.$
$GENERATE 1-18
equipo$aula2.iesrioarba.com.
192.168.2.$
2.8.4.
Chequeo del archivo de conguracin y arranque del servicio o
Al igual que ocurre con el chero /etc/named.conf, con frecuencia se cometen errores de sintaxis al escribir los cheros de conguracin de zona. Esta es una de las razones por las que es o necesario utilizar herramientas que nos permitan detectarlos. El comando que permite realizar esta operacin para los archivos de conguracin de zona es, o o
[root@linux]# named-checkzone zona [nombrefichero ]
Por ejemplo,
[root@linux]# named-checkzone iesrioarba.com /var/named/maestra.iesrioarba.com
proporcionar a,
/var/named/maestra.iesrioarba.com:1: no TTL specified; using SOA MINTTL instead zone iesrioarba.com/IN: loaded serial 3005200601 OK
Observa que aparece algo similar a un aviso (warning) indicando que no se ha especicado un TTL. El TTL es el tiempo de vida de los registros de recursos y se den en el archivo de a zona utilizando la directiva $TTL. Si no es especicado, como es el caso, BIND asigna de forma automtica el MINTTL27 dado en el registro SOA. a Antes se ha comentado que los problemas de sintaxis son una de las razones que justican el chequeo; otra de las razones es la de comprobar la consistencia del servicio. Por ejemplo si dentro del chero de conguracin de zona se incluye una mquina no perteneciente al dominio, durante o a el chequeo se advierte esta situacin indicando que la descripcin realizada va a ser ignorada. o o Imaginad el archivo,
Para utilizar la directiva $GENERATE no es necesario incluirla en otro chero. Las l neas contenidas en maestra. aula1 y maestra.aula1 podr haberse escrito directamente en el archivo de zona. an 27 Ver en la pgina 61 la explicacin de los parmetros del registro SOA. Este parmetro fue llamado TTL m a o a a nimo.
26

@ IN SOA ns root.localhost. (3005200601; 21600; 10800; 604800; 21600; )
69
ns $INCLUDE $INCLUDE fabrica.com.
IN NS ns IN A 192.168.0.1 /var/named/arba/maestra.aula1 /var/named/arba/maestra.aula2 IN A 62.167.122.14
tras realizar el chequeo se obtiene,

/var/named/maestra.iesrioarba.com:11:ignoring out-of-zone data (fabrica.com) zone iesrioarba.com/IN: loaded serial 3005200601 OK
Esta respuesta indica que la l nea 11, correspondiente a fabrica.com, va a ser ignorada. Por ultimo, y una vez que los chequeos han sido pasados debe arrancarse el servicio named para que nuestra mquina comience a resolver nombres teniendo en cuenta la conguracin realizada. a o Ejecutaremos,
[root@linux]# service named start Iniciando named: [ OK ]
Ejercicio 2.1 Edita el chero /etc/named.conf y crea dos zonas nuevas de tipo maestro (master) denominadas ies1.com e ies2.net. Los cheros de conguracin de las zonas anteriores se llamarn o a siguiendo la norma indicada en este texto, y se ubicarn dentro del directorio predeterminado a (directory) /var/named. A continuacin, crea y edita los cheros anteriores (maestra.ies1.com y maestra.ies2.net) o de tal forma que ante una peticin de resolucin de nombres de dominio, responda con: o o www.ies1.com 192.168.43.1 ftp.ies1.com 192.168.43.2 www.ies2.net 192.168.65.3 www.ies2.net 192.168.65.4 Observa que el servicio Web del ies2 puede ser dado por dos mquinas diferentes. Esto se hace a as para evitar sobrecargas, equilibrando las peticiones al servicio Web (se produzca un balanceo) mediante las dos mquinas. a Adems de los anteriores nombres de dominio el ies1 dispone de las aulas 17 y 19 (redes a 192.168.17.0/24 y 192.168.19.0/24) con 10 y 15 ordenadores respectivamente que se denirn a dentro de los subdominios aula17.ies1.com y aula19.ies1.com como equipo1, equipo2, . . . Por su parte, el ies2 dispone de las aulas 1 y 2 (redes 192.168.1.0/24 y 192.168.2.0/24) con 15 y 16 ordenadores en cada una de ellas. Siguiendo la misma losof se desea que las mquinas a a pertenezcan a los subdominios aula1.ies2.net y aula2.ies2.net segn corresponda, y con u nombres equipo1, equipo2, . . .
70 Solucin del ejercicio 2.1 o
En primer lugar deberemos editar el chero /etc/named.conf y describir las zonas de la siguiente forma:
options { directory "/var/named"; }; "ies1.com" in { type master; file "maestra.ies1.com"; }; "ies2.net" in { type master; file "maestra.ies2.com"; };
zone
zone
A continuacin escribiremos los archivos de conguacin asociados a ambas zonas. Primero o o editamos el archivo /var/named/maestra.ies1.com. Puesto que se han de resolver dos subdominios correspondientes a las dos aulas 17 y 19 se ha decidido utilizar llamadas a cheros. As el , chero de conguracin de zona queda ms legible y estructurado. o a
$TTL 3h @ IN SOA ns root.ies1. (3001200602; 21600; 10800; 604800; 21600; )
www ftp $INCLUDE $INCLUDE
IN NS ns IN A 192.168.43.1 IN A 192.168.43.2 /var/named/ies1/maestra.aula17 /var/named/ies1/maestra.aula19
A continuacin escribiremos el contenido del chero maestra.aula19, que como se ha dicho, o contiene 15 ordenadores. Este es un caso t pico en el que conviene utilizar la directiva $GENERATE.
$GENERATE 1-15 equipo$.aula19.ies1.com. A 192.168.19.$
Como se habr podido observar, se podr haber utilizado la directiva $ORIGIN. En el chero a a maestra.aula17 haremos uso de la misma para mostrarlo,
$ORIGIN aula17.ies1.com. $GENERATE 1-10 equipo$ A 192.168.17.$
Por ultimo, en el archivo /var/named/maestra.ies2.net escribiremos la conguracin de la o zona ies2.net. Para ejemplizar el posible uso de $ORIGIN en un solo archivo, las relaciones entre nombres de mquinas y sus direcciones IP de las aulas 1 y 2 sern realizadas en un unico archivo a a llamado maestra.aulas.
$TTL 3h @ IN SOA ns root.ies2. (3001200602; 21600; 10800; 604800; 21600; )
www www $INCLUDE
IN NS ns IN A 192.168.65.3 IN A 192.168.65.4 /var/named/ies1/maestra.aulas
2.9. SERVIDOR DE NOMBRES DE DOMINIO ESCLAVO El contenido del archivo maestra.aulas ser a,
$ORIGIN aula1.ies2.net. $GENERATE 1-15 equipo$ $ORIGIN aula2.ies2.net. $GENERATE 1-16 equipo$
71
A A
192.168.1.$ 192.168.2.$
En el caso del ies2.net tenemos dos mquinas para un mismo nombre de dominio (el corresa pondiente al servicio Web). En el ejercicio se nos ped que la resolucin fuera equilibrada, es a o decir que al escribir en un navegador Web http://www.ies2.net el servidor de nombres resolver unas veces con la direccin 192.168.65.3 y otras con la 192.168.65.4. Para conseguir esto a o basta con escribir, tal y como se ha hecho, varios registros seguidos con el mismo nombre. BIND se encarga automticamente de ir alternando la resolucin, produciendo as el balanceo deseado. a o
2.9.
Servidor de nombres de dominio esclavo
Un servidor de nombres de dominio no tiene porqu tener completa autoridad sobre una zona e que resuelve, y sin embargo, puede contener el archivo de zona correspondiente. Este tipo de servidor se denomina esclavo, o secundario. Tendr autoridad sobre las zonas de las que es esclavo, a ya que posee los archivos de conguracin de zona. La autoridad no es completa porque cualquier o modicacin sobre los mismos no conlleva una actualizacin28 en el resto de los DNS. Los archivos o o de zona contenidos en los DNS esclavos son una rplica de los existentes en los servidores de nombres e maestros que poseen completa autoridad sobre esas zonas. Normalmente los archivos de zona son transferidos desde el servidor maestro, pero podr an ser transferidos desde otro DNS secundario. Es decir pueden existir DNS esclavos que a su vez dependen de otros DNS esclavos. Estos archivos sern recogidos por named que los almacenar en a a el lugar que le indiquemos, normalmente en /var/named/.
Importante!! Cuando es instalado BIND se crea el usuario named (NAME Daemon), que es el demonio o due o del proceso en background encargado de n dar el servicio DNS. Por esta razn, los cheros asociados a las zonas esclavas deben ser o accesibles por el usuario del sistema named, ya que no slo los debe leer sino que tambin o e tiene que modicarlos. Al hacer una consulta o modicacin este usuario accede a los cheros de conguracin o o asociados a las zonas como lo hace cualquier otro usuario del sistema, con las correspondientes restricciones de acceso, permisos de lectura y escritura sobre directorios y archivos. Por tanto, debemos asegurarnos de que el usuario named tenga permisos sobre el chero de conguracin asociado. o
Cuando se produce una modicacin en el archivo de zona, los servidores secundarios llamados o para actualizarse son aquellos que el servidor maestro tiene recogidos en la clusula also-notify29 a y los que se denen por medio del registro NS en el caso de que notify este puesto a yes. Los archivos de zona se almacenan exactamente igual que lo hace un servidor maestro. La diferencia con el servidor maestro es que el esclavo estar comprobando continuamente el periodo a
Observa que cuando en un DNS maestro se modica algn archivo de zona, se informa a todos los servidores que u tienen autoridad sobre la zona, para que hagan las actualizaciones oportunas. 29 Las clusulas also-notify y notify estn descritas en la pgina 53. a a a
28
72
de refresco30 y cuando este haya transcurrido solicitar una actualizacin. Esta ser efectiva si a o a el nmero de serie del registro SOA ha cambiado. u Las zonas transferidas desde el DNS maestro se deben almacenar en un chero. El nombre y el lugar de almacenamiento de este chero se dene a travs del parmetro file. e a Para comprender mejor lo que se acaba de describir vamos a declarar una nueva zona llamada ieslosenlaces.com sobre la cual no tiene autoridad nuestro equipo servidor de nombres, sino otro equipo servidor de la red con direccin IP 192.168.199.136: o
zone "ieslosenlaces.com" in { type slave; masters {192.168.199.136;}; file "esclava.ieslosenlaces.com"; /*ruta relativa del fichero de configuracin que almacenar la informacin de zona*/ o a o
};
Observa que para que el servidor secundario solicite la actualizacin es necesario que conozca la o direccin IP del maestro. Esta direccin IP se indica por medio del parmetro masters direccin o o a o IP , ya comentado en la pgina 56. a Por tanto, masters es el parmetro que nos permite indicar a BIND cual es el servidor DNS a al que tendr que consultar informacin sobre el dominio ieslosenlaces.com en el caso en que a o algn cliente requiera de la resolucin de algn nombre asociado a l. La informacin suministrada u o u e o ser almacenada en el chero de conguracin indicado por file, lo que le facilitar la resolucin a o a o de posteriores peticiones.
Ejercicio 2.2 Implementa la estructura mostrada en la gura. En la que el equipo con IP 192.168.1.6 funciona como DNS maestro de la zona correspondiete al dominio romero.es y el equipo con IP 192.168.1.128 es un DNS esclavo de la anterior zona.
www.romero.es La zona romero.es dispone de : ftp.romero.es equipo1.romero.es
192.168.1.1 192.168.1.2 192.168.1.3
1. Congura ambos equipos para cumplir con los requisitos impuestos. Recuerda que debes crear un archivo de zona vac para el servidor esclavo (touch o /var/named/esclava.romero.es). 2. Arranca el servicio en los dos equipos. Primero en el maestro y despus en el esclavo. A e continuacin lista el contenido del archivo de zona esclava Est vac o a o?
30
El periodo de refresco es uno de los parmetros del registro SOA, que fue explicado en la seccin 2.7, pgina a o a
60
2.9. SERVIDOR DE NOMBRES DE DOMINIO ESCLAVO 3. Comprueba que el esclavo resuelve los nombres de dominio asociados a la zona esclava.
73
Solucin del ejercicio 2.2 o El archivo /etc/named.conf del servidor maestro deber presentar la siguiente estructura, a
options { directory "/var/named"; }; "romero.es" in { type master; file "maestra.romero.es"; };
zone
Y segn las especicaciones marcadas su correspondiente archivo de zona ser: u a

$TTL 4h @ IN SOA ns root.localhost. (3001200602; 21600; 10800; 604800; 21600; )
ns www ftp equipo1.romero.es.
IN IN IN IN IN
NS A A A A
ns 192.168.1.6 192.168.1.1 192.168.1.2 192.168.1.3
El contenido del /etc/named.conf del servidor esclavo ser: a

options { directory "/var/named"; }; "romero.es" in { type slave; masters {192.168.1.6;}; file "esclava.romero.es"; };
zone
Deberemos crear el archivo de la zona esclava, aunque no tendr ningn contenido. Adems a u a deberemos cambiar la propiedad del mismo y drsela a named: a
[root@Linux]# touch /var/named/esclava.romero.es [root@Linux]# chown named.named /var/named/esclava.romero.es
A continuacin arrancamos los servicios en las dos mquinas. As como se inicia el servicio o a en el servidor esclavo podemos hacer un cat del archivo /var/named/esclava.romero.es para comprobar que la informacin de zona ha sido transferida: o
74

[root@localhost named]# cat esclava.romero.es $ORIGIN . $TTL 14400 ; 4 hours romero.es IN SOA ns.romero.es. root.localhost. ( 1120061 ; serial 21600 ; refresh (6 hours) 100 ; retry (1 minute 40 seconds) 1280000 ; expire (2 weeks 19 hours) 14400 ; minimum (4 hours) ) NS servidor.romero.es. $ORIGIN romero.es. ns A 192.168.1.6 www A 192.168.1.1 ftp A 192.168.1.2 equipo1.romero.es A 192.168.1.3
Por ultimo se puede comprobar que la resolucin funciona mediante dig: o

[user@linux]$ dig www.romero.es ; <<>> DiG 9.3.1 <<>> romero.es ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44758 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;www.romero.es. IN ;; ANSWER SECTION: www.romero.es. 14400 IN ;; AUTHORITY SECTION: romero.es. 14400 IN ;; ADDITIONAL SECTION: ns.romero.es. 14400 IN ;; ;; ;; ;;
217.76.130.84
NS
ns.romero.es.
192.168.1.6
Query time: 1 msec SERVER: 192.168.1.128#53(192.168.1.128) WHEN: Wed Jul 19 17:55:26 2006 MSG SIZE rcvd: 86
2.10.
Servidor de nombres de dominio forward
Este servidor hace preguntas sobre las zonas que tiene conguradas a otro DNS que comnmente u se denomina forwarder. Los forwarders son empleados normalmente cuando se desea que no todos los DNS de un sitio interacten con el resto de servidores de Internet. Un ejemplo t u pico podr a ser el siguiente: imagina una red con un rewall de salida a Internet y varios DNS, de los cuales todos menos uno son incapaces de pasar paquetes a travs de dicho rewall. De esta forma, todos e los servidores preguntan al DNS con autorizacin para salir a Internet, quien a su vez se encarga o
2.10. SERVIDOR DE NOMBRES DE DOMINIO FORWARD
75
de hacer la pregunta al exterior en nombre de ellos. La ventaja de esta implementacin es que este o servidor puede dar servicio cache a todos los dems. a La zona forward puede contener las clusulas forward y forwarders (ver pgina 53) que a a indicarn los equipos a los cuales se les reenviarn las preguntas sobre la zona en cuestin. Es a a o necesario establecer los forwarders en la zona ya que si esta lista estuviera vac no se har a a forwarding, aunque se hubiesen denido de forma general en el estamento options. Observa que este tipo de servidor ni tiene, ni necesita un archivo de conguracin de zona. No es o l quien hace la resolucin, otro la hace por l; ser este ultimo el que necesitar el correspondiente e o e a a archivo de zona.
2.10.1.
Contenido de /etc/named.conf
Un servidor de reenv se diferencia de otro tipo de servidor en la decin de las zonas. La o o estructura de una zona para un servidor de este tipo es:
zone "nombre del dominio a resolver " in { type forward; forward only|first; forwarders {lista de los DNS que nos servirn }; a
};
Con la clusula forward es posible redenir lo estipulado en el estamento options (cambiar de a first a only o viceversa). Un ejemplo podr ser, a
zone "ingemartin.es" in { type forward; forwarders {194.224.52.4;194.224.52.6;};
};
De esta forma cuando hagamos una peticin de resolucin del dominio ingemartin.es el DNS o o preguntar en primer lugar al DNS con IP 194.224.52.4 esperando respuesta, si este no le responde a la pregunta pasar a 194.224.52.6. a Si deseamos que nuestro DNS responda a cualquier peticin utilizando los forwarders bastar o a con que el chero /etc/named.conf contuviera:
options { directory /var/named"; forwarders {194.224.52.4;194.224.52.6;}; };
Donde al no incluir la clusula forward se tomar su valor por defecto: first. a a
Ejercicio 2.3 Agrupaos de tres en tres equipos o utiliza tu propio equipo con dos mquinas virtuales para a implementar la siguiente conguracin: o 1. Una de las mquinas har de cliente y tendr la direccin 192.168.19.x (la x se corresponde a a a o con el nmero de tu equipo). Este equipo tendr como DNS a la segunda de las mquinas u a a cuya direccin ser 192.168.19.x+50. o a
76
CAP ITULO 2. CONFIGURACION DE UN DNS: BIND 2. La segunda mquina (con IP 192.168.19.x+50) estar congurada como servidor de reenv a a o para cualquier zona que se le solicite. 3. El tercer equipo, que tendr direccin IP 192.168.19.x+100 ser un DNS con autoridad a o a sobre la zona ieslosenlaces.com. Una vez realizada la anterior conguracin comprueba mediante dig que el equipo o 192.168.19.x+50 recibe una respuesta al preguntar por el nombre www.ieslosenlaces.com asociado a la direccin IP 162.16.14.50. o
Solucin del ejercicio 2.3 o La conguracin solicitada en el ejercicio queda resumida en la siguiente gura. En ella se o muestran los pasos seguidos cuando desde un equipo cliente (192.168.19.1) se hace un dig a otro equipo a travs de su nombre de dominio (www.ieslosenlaces.com) e
[user@linux]$ dig www.ieslosenlaces.com
En la gura se muestran los contenidos de los archivos de conguracin. Falta por mostrar el o archivo de zona /var/named/maestra.ieslosenlaces.com, cuyo contenido podr ser: a
$TTL 4h @
IN SOA
ns
root.localhost. (3001200602 21600 10800 604800 21600 )
;Comenzamos IN ns IN www IN
a escribir los registros: NS ns.ieslosenlaces.com. A 192.168.19.101 A 162.168.14.50
Tras hacer la consulta dig desde el equipo con direccin 192.168.19.1 se obtiene como respuesta: o
2.11. RESOLUCION INVERSA

[user@linux]$ dig www.ieslosenlaces.com ; <<>> DiG 9.3.1 <<>> www.ieslosenlaces.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31295 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.ieslosenlaces.com. ;; ANSWER SECTION: www.ieslosenlaces.com.
77
IN
14400 IN
162.16.14.101
;; AUTHORITY SECTION: ieslosenlaces.com. 14400 IN NS ns.ieslosenlaces.com. ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; Query time: 3 msec ;; SERVER: 192.168.19.51#53 ;; WHEN: Wed Jul 14 20:15:42 2006 ;; MSG SIZE rcvd: 100
2.11.
Resolucin inversa o
Hasta este momento se ha estudiado como el servidor de nombres de dominio convierte los nombres a direcciones IP. Pero un DNS tambin es capaz de transformar una determinada direccin e o IP en un nombre, esto se denomina resolucin inversa. o Pueden darse situaciones en las que es necesaria este tipo de resolucin. Por ejemplo la deso crita en el cap tulo 5, cuando un servidor de correo hace una peticin de resolucin inversa para o o comprobar si una mquina tiene un nombre de dominio cualicado (FQDN). En este cap a tulo no nos preocuparemos por las situaciones en las que la resolucin inversa puede ser util y simplemente o estudiaremos como congurar BIND para que sea capaz de hacerlas. La resolucin inversa se consigue por medio del dominio in-addr.arpa y el registro de recurso o PTR. En primer lugar se debe denir en /etc/named.conf una zona de resolucin inversa. Un ejemplo o del contenido de este chero en lo referente a la zona que permitir a BIND resolver las direcciones a de la red 192.168.19.0 podr ser: a
zone "19.168.192.in-addr.arpa"{ type master; file "/var/named/inversa.19.168.192"; };
La lectura de la direccin IP por BIND se realiza desde el octeto menos signicante al ms o a signicante, al revs de como normalmente se escribe. Basndonos en el anterior ejemplo, cuando el e a servidor recibe una peticin de resolucin inversa, BIND busca un servidor arpa, a continuacin un o o o servidor in-addr.arpa, despus uno 192.in-addr.arpa, posteriormente 168.192.in-addr.arpa e y por ultimo el servidor con autoridad para la zona 19.168.192.in-addr.arpa. Cuando lo ha encontrado se dirige al chero de conguracin de zona para leer el registro que le permita responder o a la pregunta. El archivo de conguracin de zona se llama en este ejemplo /var/named/inversa.19.168.192 o y podr tener una forma similar a la mostrada a continuacin: a o
78
$TTL 1d @
IN SOA
ns
root.localhost. (1107200604; 21600; 10800; 604800; 21600; )
IN NS 1.19.168.192.in-addr.arpa. 2.19.168.192.in-addr.arpa. 3 4 ... IN IN IN IN PTR PTR PTR PTR
ns equipo1.taller19.cossio.com. equipo2.taller19.cossio.com. equipo3.taller19.cossio.com. equipo3.taller19.cossio.com.
Como el dominio es 19.168.192.in-addr.arpa es posible escribir el nmero del equipo simu plemente (sin ir seguido del punto .), siguiendo una notacin similar a la mostrada en ejemplos o anteriores en los que se hac una resolucin directa. a o Para comprobar el funcionamiento se puede utilizar dig, pero en este caso se debe colocar la opcin -x que indica solicitud de resolucin inversa. o o
[user@linux]$ dig -x 192.168.19.1 ; <<>> DiG 9.3.1 <<>> -x 192.168.19.1 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38586 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: 1.19.168.192.in-addr.arpa. ;; ANSWER SECTION: 1.19.168.192.in-addr.arpa. ;; AUTHORITY SECTION: 1.19.168.192.in-addr.arpa. ;; ;; ;; ;;
IN PTR
86400 IN
PTR
equipo1.taller19.cossio.com.
86400 IN
NS
ns.cossio.com.
Query time: 56 msec SERVER: 192.168.0.5#53 WHEN: Wed Jul 19 16:56:57 2006 MSG SIZE rcvd: 112

Servicio DNS-Servicios Arturo

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Servicio DNS-Servicios Arturo

Uploaded by

Copyright:

Available Formats

Cap tulo 2

CONFIGURACION DE UN DNS: BIND

Figura 2.1: Pasos en la resolucin del nombre www.google.es. o

CAP ITULO 2. CONFIGURACION DE UN DNS: BIND

Identicador de dominio bajoaragon.com

Dominio de alto nivel

Nombres de dominio de nivel y servidores ra z

2.1. INTRODUCCION AL CONCEPTO DE DNS

Figura 2.2: Estructura jerrquica de nombres de dominio. a

Figura 2.3: Situacin mundial de los DNS ra o z.

CAP ITULO 2. CONFIGURACION DE UN DNS: BIND

Tipos de servidores de nombre de dominio

Figura 2.4: Funcionamiento de un DNS cache.

2.1. INTRODUCCION AL CONCEPTO DE DNS

Figura 2.5: Funcionamiento de un DNS esclavo.

CAP ITULO 2. CONFIGURACION DE UN DNS: BIND

Figura 2.6: Funcionamiento de un DNS maestro.

2.2. ESTRUCTURA DEL CAP ITULO

Figura 2.7: Funcionamiento de un DNS de reenv o.

Estructura del cap tulo

CAP ITULO 2. CONFIGURACION DE UN DNS: BIND

PRACTICA: CONFIGURACION DE UN DNS

Instalacin del software necesario o

Figura 2.8: GUI para instalacin de software en Mandriva. o

Conceptos bsicos sobre la conguracin de BIND a o

2.4. CONCEPTOS BASICOS SOBRE LA CONFIGURACION DE BIND

Una conguracin sencilla: El DNS cach o e

CAP ITULO 2. CONFIGURACION DE UN DNS: BIND

3600000 3600000 3600000 3600000

Este a su vez tiene asignada la direccin IP (address) 192.228.79.201. o

Comprobacin del servidor cach o e

Pudiera ocurrir que el comportamiento fuese el siguiente,

[root@linux]# /etc/init.d/named start

2.4. CONCEPTOS BASICOS SOBRE LA CONFIGURACION DE BIND

CAP ITULO 2. CONFIGURACION DE UN DNS: BIND

Control remoto del servidor de nombres: rndc

Dentro de este estamento hay tres posibles clusulas: a

2.5. CONTROL REMOTO DEL SERVIDOR DE NOMBRES: RNDC

server La estructura es,

key La estructura es,

CAP ITULO 2. CONFIGURACION DE UN DNS: BIND

key clave { Clusulas de configuracin ; a o };

2.5. CONTROL REMOTO DEL SERVIDOR DE NOMBRES: RNDC

Cuando reiniciemos de nuevo el servicio named, el demonio rndc estar ya activo, a

CAP ITULO 2. CONFIGURACION DE UN DNS: BIND

Comandos y opciones de rndc Indice alfabticorndc!comandos y opciones e

2.6. EL FICHERO NAMED.CONF

[root@linux]# rndc reload

Contenido del chero /etc/named.conf

Un ejemplo podr ser: a

Para crearlo y editarlo a la vez escribiremos,

2.6. EL FICHERO NAMED.CONF

//Zona de tipo maestra

Parmetros del estamento options a

CAP ITULO 2. CONFIGURACION DE UN DNS: BIND

Para comprobar su funcionamiento puedes utilizar dig con el parmetro -p: a

2.6. EL FICHERO NAMED.CONF

//Valor por defecto

//Funcionamiento de solo reenvo

CAP ITULO 2. CONFIGURACION DE UN DNS: BIND

options{ forward first; forwarders {192.168.19.1;192.168.17.1; }; };

Parmetros del estamento key a

Parmetros del estamento controls a

Parmetros del estamento zone a