Servidor DNS en Fedora9

PRIMERA PARTE
Servidor DNS en Fedora

[BIND 9.5 EN FEDORA 9]
Ing. Agustn Ros Reyes 18/02/2009
Este documenta trata la configuracin bsica de un servidor DNS en Linux fedora 9, con el paquete BIND 9.5.esta configuracin representa un ejemplo en una LAN, y solo trata la configuracin del servidor DNS, posterior mente se tratara la configuracin de otros servicios como correo electrnico y un servidor web, pero esto ser en la segunda entrega.
BIND 9.5
9 Servidor DNS en Fedora. 2009
ndice
ndice...2 Introduccin3 1.Conceptos previos4 1.1.Qu significa DNS? 4 1.2.Porque usar un servidor DNS? ...4 1.3.Cmo funciona el DNS? .4 1.3.1.El Espacio de Nombres de Dominio..4 1.3.2.El Espacio de Nombres de Dominio en Internet5 1.3.3.Delegacin..6 2. Componentes de un DNS6 2.1. Clientes DNS6 2.2. Servidores DNS6 2.3. Zonas de Autoridad..7 2.3.1. Zonas de Reenvo..8 2.3.2. Zonas de Resolucin Inversa8 3. Instalacin de los paquetes..8 3.1. Paquetes necesarios para la configuracin...8 3.2. Comprobando que los paquetes estn instalados. ...9 3.3. Instalar los paquetes necesarios. .9 4. Configuracin del servidor..9 4.1. Archivos de configuracin. ...10 4.1.1. El archivo named.conf ...10 4.1.2. El archivo named.rfc1912.zones 10 4.1.3. Archivos de zonas. .10 4.1.3.1. Archivo de zona de reenvi (nitsugario.com.zone) .11 4.1.3.2. Archivo de zona de resolucin inversa (192.168.1 )11 4.2. Configuracin de los archivos y creacin del los archivos de zonas.11 4.2.1. Creacin de archivos de zonas. ..11 4.2.1.1. Zona de reenvi nitsugario.com...11 4.2.1.1.1. Descripcin del archivo nitsugario.com.zone..12 4.2.1.2. Zona de resolucin inversa 1.168.192.in-addr.arpa14 4.2.1.2.1. Descripcin del archivo 192.168.1...15 4.2.2. Configuracin del archivo named.rfc1912.zones...15 4.2.2.1. Descripcin del archivo named.rfc1912.zones16 4.2.3. Configuracin del archivo named.conf...17 4.2.3.1 Descripcin del contenido del archivo named.conf.17 5. Comprobando que funcione la configuracin...18 5.1. Iniciando el servidor...18 5.2. Parando el servidor 19 5.3. Reiniciando el servidor: 19 5.4. Aadir el servidor al arranque del sistema.19 5.5. Depuracin de la configuracin.19 5.6. Pruebas con ping20 Bibliografa21
Ing. Agustn Ros Reyes
nitsugario@gmail.com
BIND 9.5
Introduccin
En la actualidad ay millones de computadoras conectadas a internet, las cuales brindan servicios web y otras que son de usa privado de empresas. Todas estas computadoras estn identificadas con una direccin IP, pero como hacer para identificar y mantener la pista de todas estas computadoras cuando pertenecen a tantos pases, redes y grupos administrativos distinto? Para esta tarea titnica ay dos elementos que mantienen todo esto junto y en orden: El sistema de nombres de dominio DNS (Domain Name System), cuya funcin es saber quin es cada host con respecto a una direccin IP y un Nombre nico en la red. El otro elemento es el sistema de enrutamiento de internet, que se encarga de conocer cmo estn conectadas entre s todas estas computadoras y equipos. Este documento solo abarcaremos la parte concerniente al Sistema de nombres de dominio. Estudiaremos sus definiciones, elementos caractersticas, y el modo de configurar uno en nuestra casa. Utilizaremos el sistema operativo Linux Fedora 9 y el paquete por excelencia para hacer esta tarea BIND en su versin 9.5. BIND (acrnimo de Berkeley Internet Name Domain) es una implementacin del protocolo DNS y provee una implementacin libre de los principales componentes del Sistema de Nombres de Dominio, los cuales incluyen: Un servidor de sistema de nombres de dominio (named). Una biblioteca resolutoria de sistema de nombres de dominio. Herramientas para verificar la operacin adecuada del servidor DNS (bind-utils). El Servidor DNS BIND es ampliamente utilizado en la Internet (99% de los servidores DNS) proporcionando una robusta y estable solucin.
Alguna duda o comentario sobre este documento enviar un mensaje a mi correo: nitsugario@gmail.com
Recuerda que si te equivocas o cometes un erro en algo, recuerda has aprendido una forma de cmo no hacerlo (Agustn Ros).
Este documento y su contenido pueden ser copiados o distribuido siempre que se mantenga el nombre del autor.
BIND 9.5
1. Conceptos previos
1.1. Qu significa DNS?
DNS acrnimo de Domain Name System que interpretado en espaol es Sistema de Nombres de Dominio.
1.2.
Porque usar un servidor DNS?
Al comienzo de TCP/IP, puesto que las redes no eran muy extensas, o en otras palabras que el nmero de equipos conectados a la misma red era bajo, los administradores de red crearon archivos llamados tablas de conversin manual. Estas tablas de conversin manual eran archivos secuenciales, por lo general llamados hosts o hosts.txt, y asociaban en cada lnea la direccin IP del equipo con el nombre literal relacionado, denominado nombre del ordenador. Sin embargo, el anterior sistema de tablas de conversin exiga una actualizacin manual de las tablas para la totalidad de los equipos en caso de incluir o modificar el nombre de una mquina. Por lo tanto, con el aumento en tamao de las redes y sus interconexiones, fue necesario implementar un sistema de gestin para los nombres que fuese jerrquico y fcil de administrar. El sistema llamado Sistema de Nombres de Dominio (DNS) fue desarrollado en noviembre de 1983 por Paul Mockapetris (RFC 882 y RFC 883) y luego revisado en 1987 en las RFC 1034 y 1035. El DNS ha sido sometido a varias RFC. Este sistema ofrece: un espacio de nombre jerrquico que permite garantizar la singularidad de un nombre en una estructura arbrea, como por ejemplo sistemas de archivo Unix. un sistema de servidores de distribucin que permite que el espacio de nombre est disponible. un sistema de cliente que permite "resolver" nombres de dominio, es decir, interrogar a los servidores para encontrar la direccin IP que corresponde a un nombre.
1.3.
Cmo funciona el DNS?
El Sistema de Nombres de Dominio permite a los usuarios de una red TCP/IP utilizar nombres jerrquicos y descriptivos para localizar fcilmente ordenadores (hosts) y otros recursos en dicha red, evitando de esta manera tener que recordar la direccin IP de cada ordenador al que se desea acceder. En esencia, DNS es una base de datos distribuida que contiene asociaciones de nombres simblicos (de hosts) a direcciones IP. El hecho de que sea distribuida permite delegar el control sobre diferentes segmentos de la base de datos a distintas organizaciones, pero siempre de forma que los datos de cada segmento estn disponibles en toda la red, a travs de un esquema cliente-servidor. Los programas denominados servidores de nombres (name servers) constituyen la parte servidora del esquema cliente-servidor. Los servidores de nombres contienen informacin sobre algunos segmentos de la base de datos y los ponen a disposicin de los clientes, llamados solucionadores o resolvers.
1.3.1. El Espacio de Nombres de Dominio

La base de datos distribuida de DNS est indexada por nombres de dominio. Cada nombre de dominio es esencialmente una trayectoria en un rbol invertido denominado espacio de nombres de dominio. La estructura jerrquica del rbol es similar a la estructura del sistema de ficheros UNIX. El rbol tiene una nica raz en l nivel superior llamada raz (root). Cada nodo del rbol puede ramificarse en cualquier nmero de nodos de nivel inferior. La profundidad del rbol est limitada a 127 niveles.
BIND 9.5
Cada nodo en el rbol se identifica mediante una etiqueta no nula que puede contener hasta 63 caracteres, excepto el nodo raz, identificado mediante una etiqueta nula. El nombre de dominio completo de cualquier nodo est formado por la secuencia de etiquetas que forman la trayectoria desde dicho nodo hasta la raz, separando cada etiqueta de la siguiente mediante un punto. De esta forma, el nombre del nodo especifica de forma unvoca su localizacin en la jerarqua. A este nombre de dominio completo o absoluto se le conoce como nombre de dominio completamente cualificado o Fully Qualified Domain Name (FQDN). Al ser nula la etiqueta que identifica el nodo raz, el FQDN de cualquier nodo del rbol siempre acaba con un punto. La nica restriccin que se impone en el rbol de nombres es que los nodos hijos del mismo padre tengan etiquetas diferentes. Como ejemplo: suponiendo que se tiene un dispositivo cuyo nombre de anfitrin es maquina1 y un dominio dominio.com, el FQDN sera maquina1.dominio.com., de modo define de modo nico al dispositivo mientras que pudieran existir muchos anfitriones llamados maquina1, solo puede haber uno llamado maquina1.dominio.com.. La ausencia del punto al final definira que se pudiera tratar tan solo de un prefijo, es decir maquina1.dominio.com pudiera ser de un dominio ms largo como maquina1.dominio.com.mx. La longitud mxima de un FQDN es de 255 bytes, con una restriccin adicional de 63 bytes para cada etiqueta dentro del nombre del dominio. Solo se permiten los caracteres A-Z de ASCII, dgitos y el carcter -. No se distinguen maysculas y minsculas. En el esquema jerrquico de nombres DNS, se denomina dominio a cualquier subrbol del espacio de nombres de dominio. De esta forma, cada dominio puede contener, a su vez, otros dominios. Generalmente, los hosts estn representados por las hojas del rbol, aunque es posible nombrar a un host con una etiqueta correspondiente a un nodo intermedio del rbol (en este caso, tendramos un dominio y un nodo que se llaman igual). La informacin sobre los nombres de dominio DNS se guarda mediante los denominados registros de recursos en los servidores DNS de la red. Concretamente, cada servidor DNS contiene los registros de recursos necesarios para responder a las consultas sobre la parte del espacio de nombres en la que tiene autoridad.
1.3.2. El Espacio de Nombres de Dominio en Internet

El estndar DNS no impone muchas reglas sobre las etiquetas de los nombres de dominio, ni tampoco asocia un significado determinado a las etiquetas de un determinado nivel del espacio de nombres. Cuando manejamos una parte de este espacio, podemos decidir el significado y la sintaxis de nuestros nombres de dominio. Sin embargo, en el espacio de nombres Internet existente, se ha impuesto una estructura de nombres bien definida, especialmente en los dominios de primer nivel. Los dominios originales de primer nivel dividan originalmente el espacio de nombres de Internet en siete dominios: com, edu, gov, mil, net, org, e int. Posteriormente, para acomodar el crecimiento y la internacionalizacin de Internet, se reservaron nuevos dominios de primer nivel que hacan referencia a pases individuales. Actualmente, los dominios originales se denominan dominios de primer nivel genricos y han surgido nuevos nombres que se ajustan a los tiempos que corren.
BIND 9.5 1.3.3. Delegacin
Es importante resaltar que el objetivo principal del diseo del sistema de nombres de dominio fue su administracin descentralizada. Este objetivo se consigue a travs de la delegacin. La delegacin de dominios funciona de forma parecida a la delegacin de tareas en una organizacin. Un responsable de proyecto divide el proyecto en pequeas tareas y asigna (delega) la responsabilidad de las mismas a diferentes empleados. De la misma forma, una organizacin que administra un dominio puede dividirla en subdominios. Cada subdominio puede ser delegado a diferentes organizaciones, lo cual implica que esa organizacin ser responsable de mantener los datos (registros de recursos) de ese subdominio. Esa organizacin puede libremente cambiar los datos e incluso volver a dividir el dominio delegado en subdominios y delegarlos. El dominio padre solamente contiene enlaces a los responsables del subdominio delegado, de forma que pueda hacer referencia a ellos cuando se le planteen consultas sobre nombres en dicho subdominio delegado. Realmente, la subdivisin de un dominio en subdominios y la delegacin de dichos subdominios son cosas distintas. En primer lugar, un dominio que tenga capacidad de autogestin (autoridad), siempre puede decidir subdividirse en diferentes subdominios, manteniendo l en principio la autoridad sobre todos ellos. Posteriormente, la organizacin que gestiona el dominio puede decidir adems delegar la autoridad de algunos (o todos) sus subdominios en otras organizaciones. La delegacin es una accin que siempre decide el dominio padre, y ste puede revocarla cuando desee, volviendo a retomar la autoridad sobre el subdominio que haba delegado.
2. Componentes de un DNS
Los DNS operan a travs de tres componentes: Clientes DNS, Servidores DNS y Zonas de Autoridad.
2.1.
Clientes DNS
Son programas que ejecuta un usuario y que generan peticiones de consulta para resolver nombres. Bsicamente preguntan por la direccin IP que corresponde a un nombre determinado.
2.2.
Servidores DNS
Son servicios que contestan las consultas realizadas por los Clientes DNS. Hay dos tipos de servidores de nombres: Servidor Maestro(o primario) Obtiene los datos del dominio a partir de un fichero hospedado en el mismo servidor. Servidor Esclavo(o secundario) Al iniciar obtiene los datos del dominio a travs de un servidor un Servidor Maestro, realizando un proceso denominado transferencia de zona. Un gran nmero de problemas de operacin de servidores DNS se atribuyen a las pobres opciones de servidores secundarios para las zonas de DNS. De acuerdo al RFC 2182, el DNS requiere que al menos tres servidores existan para todos los dominios delegados (o zonas). Una de las principales razones para tener al menos tres servidores para cada zona es permitir que la informacin de la zona misma est disponible siempre y forma confiable hacia los Clientes DNS a travs de Internet cuando un servidor DNS de dicha zona falle, no est disponible y/o est inalcanzable. Contar con mltiples servidores tambin facilita la propagacin de la zona y mejoran la eficiencia del sistema en general la brindar opciones a los Clientes DNS si acaso encontraran dificultades para realizar una consulta en un Servidor DNS. En otras palabras: tener mltiples servidores para una zona permite contar con redundancia y respaldo del servicio.
BIND 9.5
Con mltiples servidores, por lo general uno acta como Servidor Maestro o Primario y los dems como Servidores Esclavos o Secundarios. Correctamente configurados y una vez creados los datos para una zona, no ser necesario copiarlos a cada Servidor Esclavo o Secundario, pues ste se encargar de transferir los datos de manera automtica cuando sea necesario. Los Servidores DNS responden dos tipos de consultas: Consultas Iterativas (no recursivas) El cliente hace una consulta al Servidor DNS y este le responde con la mejor respuesta que pueda darse basada sobre su cach o en las zonas locales. Si no es posible dar una respuesta, la consulta se reenva hacia otro Servidor DNS repitindose este proceso hasta encontrar al Servidor DNS que tiene la Zona de Autoridad capaz de resolver la consulta. Consultas Recursivas El Servidor DNS asume toda la carga de proporcionar la una respuesta completa para la consulta realizada por el Cliente DNS. El Servidor DNS desarrolla entonces Consultas Iterativas separadas hacia otros Servidores DNS (en lugar de hacerlo el Cliente DNS) para lograr la respuesta.
2.3.
Zonas de Autoridad
Permiten al Servidor Maestro o Primario cargar la informacin de una zona. Cada Zona de Autoridad abarca al menos un dominio y posiblemente sus sub-dominios, si estos ltimos no son delegados a otras zonas de autoridad. La informacin de cada Zona de Autoridad es almacenada de forma local en un fichero en el Servidor DNS. Este fichero puede incluir varios tipos de registros: TIPO DE REGISTRO A (Address) AAAA CNAME (Canonical Name) MX (Mail Exchange) PTR (Pointer) NS (Name Server) SOA (Start of Authority) DESCRIPCIN Registro de direccin que resuelve un nombre de un anfitrin hacia una direccin IPv4 de 32 bits. Registro de direccin que resuelve un nombre de un anfitrin hacia una direccin IPv6 de 128 bits. Registro de nombre cannico que hace que un nombre sea alias de otro. Los dominios con alias obtienen los sub-dominios y registros DNS del dominio original. Registro de servidor de correo que sirve para definir una lista de servidores de correo para un dominio, as como la prioridad entre stos. Registro de apuntador que resuelve direcciones IPv4 hacia el nombre anfitriones. Es decir, hace lo contrario al registro A. Se utiliza en zonas de Resolucin Inversa. Registro de servidor de nombres que sirve para definir una lista de servidores de nombres con autoridad para un dominio. Registro de inicio de autoridad que especifica el Servidor DNS Maestro (o Primario) que proporcionar la informacin con autoridad acerca de un dominio de Internet, direccin de correo electrnico del administrador, nmero de serie del dominio y parmetros de tiempo para la zona. Registro de servicios que especifica informacin acerca de servicios disponibles a travs del dominio. Protocolos como SIP (Session Initiation Protocol) y XMPP (Extensible Messaging and Presence Protocol) suelen requerir registros SRV en la zona para proporcionar informacin a los clientes. Registro de texto que permite al administrador insertar texto arbitrariamente en un registro DNS. Este tipo de registro es muy utilizado por los servidores de listas negras DNSBL (DNS-based Blackhole List) para la filtracin de Spam. Otro ejemplo de uso son las VPN, donde suele requerirse un registro TXT para definir una llave que ser utilizada por los clientes.
SRV (Service)
TXT (Text)
BIND 9.5
Las zonas que se pueden resolver son:
2.3.1. Zonas de Reenvo

Devuelven direcciones IP para las bsquedas hechas para nombres FQDN (Fully Qualified Domain Name). En el caso de dominios pblicos, la responsabilidad de que exista una Zona de Autoridad para cada Zona de Reenvo corresponde a la autoridad misma del dominio, es decir, y por lo general, quien est registrado como autoridad del dominio tras consultar una base de datos WHOIS. Quienes compran dominios a travs de un NIC (por ejemplo: www.nic.mx) son quienes se hacen cargo de las Zonas de Reenvo, ya sea a travs de su propio Servidor DNS o bien a travs de los Servidores DNS de su ISP. Salvo que se trate de un dominio para uso en una red local, todo dominio debe ser primero tramitado con un NIC como requisito para tener derecho legal a utilizarlo y poder propagarlo a travs de Internet.
2.3.2. Zonas de Resolucin Inversa

Devuelven nombres FQDN (Fully Qualified Domain Name) para las bsquedas hechas para direcciones IP. En el caso de segmentos de red pblicos, la responsabilidad de que exista de que exista una Zona de Autoridad para cada Zona de Resolucin Inversa corresponde a la autoridad misma del segmento, es decir, y por lo general, quien est registrado como autoridad del segmento tras consultar una base de datos WHOIS. Los grandes ISP, y en algunos casos algunas empresas, son quienes se hacen cargo de las Zonas de Resolucin Inversa.
3. Instalacin de los paquetes

3.1. Paquetes necesarios para la configuracin
Primero que nada se requiere tener instalado los siguientes paquetes. bind: Este paquete incluye el Servidor DNS (named) y herramientas para verificar su funcionamiento. bind-libs: Este paquete contiene Bibliotecas compartida que consiste en rutinas para aplicaciones para utilizarse cuando se interacte con Servidores DNS. bind-chroot: Contiene un rbol de ficheros que puede ser utilizado como una jaula chroot seguridad adicional al servicio. bind-utils: Este paquete contiene una Coleccin de herramientas para consultar Servidores DNS. Caching-nameserver: Ficheros de configuracin que harn que el Servidor DNS acte como un cach para el servidor de nombres.
para named aadiendo
BIND 9.5 3.2.
Comprobando que los paquetes estn instalados.
Para comprobar que los paquetes estn instalados utilizremos el comando rpm -q nombrepaquete en una terminal. Este se hace para todos los paquetes que se quieran verificar, si el paquete est instalado nos devolver el nombre del paquete y su nmero de versin. Esto sera algo as: [root@nitsugario ~]# rpm -q bind bind-9.5.0-29.b2.fc9.x86_64 [root@nitsugario ~]# rpm -q bind-libs bind-libs-9.5.0-29.b2.fc9.x86_64 [root@nitsugario ~]# rpm -q bind-chroot bind-chroot-9.5.0-29.b2.fc9.x86_64 [root@nitsugario ~]# rpm -q bind-utils bind-utils-9.5.0-29.b2.fc9.x86_64 [root@nitsugario ~]# rpm -q cachinh-nameserver El paquete caching-nameserver no est instalado
3.3.
Instalar los paquetes necesarios.
si la respuesta es coma la que mostro el paquete aching-nameserver , tendremos que instalar los paquetes, una forma fcil para instalar todos los paquetes es utilizando el comando yum, de la siguiente forma: [root@nitsugario ~]# yum -y inatall bind bind-libs bind-chroot bind-utils caching-nameserver Si se utiliza de Red HatTM Enterprise Linux 4, o versiones posteriores, se puede instalar utilizando lo siguiente: [root@nitsugario ~]# up2date -i bind bind-chroot bind-utils caching-nameserver
Nota: para la utilizacin del comando yum y up2date, se requiere tener acceso a internet. Nota: recuerda que para poder instalar paquetes, debes tener privilegios de sper usuario.
Una vez instalado todo lo necesario, podemos empezar a configurar nuestro servidor.
4. Configuracin del servidor

Primero voy explicar cmo se conformara el ejemplo que vamos a utilizar. Se esta utilizando Fedora 9, el servidor est conectado a una red privada (LAN),el cual tiene una direccin IP que es la 192.168.1.2 y en la red estn otras dos maquinas que son las PCs de mi hermano Cesar (IP 192.168.1.1, SO. Windows XP) y la PC de mi hermana Luz Elena (IP 192.168.1.3, SO Windows XP). Para esta red he escogido el dominio nitsugario.com, el cual tendr los servicios y www, pop3, smtp, ftp, estor servicios sern configurados posterior mente.
BIND 9.5 4.1. Archivos de configuracin.
4.1.1. El archivo named.conf: este archivo es el principal para la configuracin de named y es el que nos indica porque puerto escuchara el servidor, porque direccin IP, es donde se agregan las zonas de los domins, indica quienes tienen permisos de realizar bsquedas y otros parmetros mas que se explicaran ms adelante. Se encuentra en el directorio /etc. Para acceder a l, usamos el comando cd de la siguiente forma. [root@nitsugario ~]# cd /etc para ver el contenido del directorio usamos el comando ls. [root@nitsugario etc]# ls
4.1.2. El archivo named.rfc1912.zones: En este archivo se declaran las zonas existentes en el servidor, zona de reenvi y zona de resolucin inversa, as como llamada a los archivos en los que se encuentra la configuracin de dichas zonas. Se encuentra en el directorio /etc. Para acceder a el, usamos el comando cd de la siguiente forma. [root@nitsugario ~]# cd /etc
4.1.3. Archivos de zonas.

Estos archivos los tenemos que crear nosotros (archivo de zona de reenvi y archivo de zona de resolucin inversa) y guardarlos con un nombre que sea representativo a la funcin que realiza o a la informacin que contienen. Estos documentos se tienen que guardar en el directorio var/named/chroot/var/named.
10
BIND 9.5
4.1.3.1. Archivo de zona de reenvi (nitsugario.com.zone): En este archivo se especifica la direccin IP asociada a un nombre de un dominio, servicio o subdominio. l nombre elegido para este archivo fue nitsugario.com.zone 4.1.3.2. Archivo de zona de resolucin inversa (192.168.1 ): En este archivo se especifica un nombre asociado a una direccin IP de un dominio, servicio o subdominio. l nombre elegido para este archivo fue 192.168.1. Que representa la direccin de red con la que se trabajara, este nombre puede ser cualquier otro.
4.2.
Configuracin de los archivos y creacin del los archivos de zonas.
4.2.1. Creacin de archivos de zonas.

Los siguientes corresponderan a los contenidos para los ficheros de zona requeridos para la red local (dominio nitsugario.com) y por el NIC con el que se haya registrado el dominio. Note por favor que en las zonas de reenvo siempre se especifica al menos un Mail Exchanger (MX) y que se utilizan tabuladores (tecla TAB) en lugar de espacio. Solo necesitar sustituir nombres y direcciones IP, y quiz aadir nuevos registros para complementar su red local o lo que quiera hacer.
4.2.1.1.
Zona de reenvi nitsugario.com
Nombre del archivo: nitsugario.com.zone Se guarda en: /var/named/chroot/var/named/ Contenido del archivo: $TTL 86400 @ IN SOA nitsugario.com. nitsugario@gmail.com. ( 2009021701; nmero de serie 28800 ; tiempo de refresco 7200 ; tiempo entre reintentos de consulta 604800 ; tiempo tras el cual expira la zona 86400 ; tiempo total de vida ) nitsugario.com. nitsugario.com. localhost nitsugario.com. ns1 cesar luz www pop3 smtp ftp IN IN IN IN IN IN IN IN IN IN NS MX IN A A A A A A A A ns1.nitsugario.com. 10 ns1.nitsugario.com. A 127.0.0.1 192.168.1.2 192.168.1.2 192.168.1.1 192.168.1.3 192.168.1.2 192.168.1.2 192.168.1.2 192.168.1.2
Nota: Cada vez que haga algn cambio en algn fichero de zona, deber cambiar el nmero de serie (serial) a fin de que tomen efecto los cambios de inmediato cuando se reinicie el servicio named, ya que de otro modo tendra que reiniciar el equipo, algo poco conveniente. Nota: un punto y coma, ";", en el archivo indica que todo lo que hay a su derecha es un comentario. 11
Ing. Agustn Ros Reyes nitsugario@gmail.com
BIND 9.5
4.2.1.1.1. Descripcin del archivo nitsugario.com.zone A continuacin desmenuzaremos el contenido del archivo nitsugario.com.zone, indicando para que sirve cada lnea escrita en el. Lnea 1. $TTL 86400 : Directiva obligatoria a partir de la versin 9 de Bind (RFC1035 y RFC2308), indica el tiempo de vida (TTL, del ingls, Time To Live) de la informacin contenida en el fichero. Es decir, el tiempo mximo de validez, tras el cual deber refrescarse o actualizarse (para comprobar que no haya cambiado). Es lo que se conoce como cach positiva/negativa (del ingls, positive/negative caching), como se especifica en el RFC2308. Por defecto se usan segundos (604800 segundos equivale a siete das exactos), pero pueden usarse tambin semanas ($TTL 1w), das ($TTL 7d), horas ($TTL 168h) y minutos ($TTL 10080m). Estas abreviaturas se usan asimismo en el registro SOA, que se explica a continuacin. Lnea 2, @ IN SOA nitsugario.com. nitsugario@gmail.com. : El registro SOA (del ingls, Start Of Authority) se encuentra siempre tras las directivas y proclama informacin relevante sobre la autoridad de un dominio al servidor de nombres. Es siempre el primer recurso en un fichero de zona. El smbolo "@" (arroba) equivale a la directiva $ORIGIN (o el nombre de la zona si dicha directiva no se ha usado caso ms frecuente) como espacio de nombres de dominio definido por este registro. Este sera el esqueleto de este registro: @ IN SOA <primarynameserver> <hostmasteremail> ( <serialnumber> <timetorefresh> <timetoretry> <timetoexpire> <minimumTTL> ) El servidor de nombres primario que es el autorizado de este dominio se usa en <primarynameserver> y el correo electrnico de la persona a contactar acerca de este espacio de nombres (del ingls, namespace) se sustituye en <hostmasteremail> (fjese el lector que no tiene porqu corresponder con una direccin del propio dominio, como es el caso de la zona nitsugario.com). El campo <serialnumber> es un nmero que se incrementa cada vez que se modifica un fichero de una zona, de forma que Bind se d cuenta de que tiene que recargar esta zona. Se recomienda usar la fecha de modificacin en formato AAAAMMDD, donde AAAA es el ao en formato de cuatro cifras, MM es el mes en dos cifras, y DD es el da de mes en dos cifras, seguido de un nmero de dos cifras, empezando por el 01. De este modo se podrn realizar hasta cien cambios por da. El campo <timetorefresh> le dice a los servidores secundarios (esclavos) cunto tiempo deben esperar antes de preguntar a su servidor principal (maestro) si se ha hecho algn cambio en la zona. El valor del campo <serialnumber> es usado por los esclavos para determinar si se est usando informacin anticuada que deba actualizarse. El campo <timetoretry> especifica a los servidores esclavos el intervalo de tiempo a esperar antes de solicitar una actualizacin en el caso de que el servidor de nombres principal no est respondiendo. Si el servidor maestro no ha respondido a la peticin de actualizacin antes de que expire el tiempo del campo <timetoexpire>, el esclavo dejar de actuar como servidor el autorizado de ese espacio de nombres (zona). El campo <minimumTTL> solicita a otros servidores de dominio que almacenen en su cach la informacin de esta zona durante al menos la cantidad de tiempo en l especificada.
12
BIND 9.5
Nota: El campo <primarynameserver> termina en un punto, que es obligatorio poner, y que representa, segn lo explicado en el apartado introductorio del artculo, el servidor de nombres raz. Asimismo, este punto aparecer en todas las referencias explcitas al dominio a lo largo del fichero. Cuando se configura un host o subdominio, por ejemplo ftp, se hace una referencia implcita y Bind aade automticamente el dominio, que saca de la "@" del registro SOA. En cualquier caso, es posible usar referencias implcitas o explcitas indistintamente.
Lnea 3, nitsugario.com. IN NS ns1.nitsugario.com. : indican los servidores de nombre que tienen autoridad sobre el dominio. Ntese que, a partir de aqu, en la zona nitsugario.com se explicita, como se ha comentado en el punto anterior, el nombre del dominio completo as como el prefijo. Lnea 4, nitsugario.com. IN MX 10 ns1.nitsugario.com. : se trata de un registro MX (del ingls, Mail eXchanger) e indica dnde mandar el correo destinado a un espacio de nombres controlado por esta zona. El dgito que sigue a la palabra MX representa la prioridad respecto a otros registros MX para la zona, que se especificaran en posteriores lneas, siguiendo el mismo formato pero variando dicho dgito (incrementndolo a medida que pierdan prioridad frente a anteriores registros). Es decir, cuanto ms bajo es el valor de preferencia, mayor prioridad adquiere. Lnea 5, localhost IN A 127.0.0.1 : Registro que relaciona el host local con su IP de loopback. Lnea 6, nitsugario.com. IN A 192.168.1.2 : Registro que relaciona el nombre de dominio de segundo nivel (el "principal" de la zona) con la IP donde est hospedado. Este es el registro ms usado, pues cualquier peticin a nitsugario.com ser resuelta mediante este registro, se use el protocolo de comunicaciones que se use (por ejemplo, http://nitsugario.com). Lnea 7, ns1 IN A 192.168.1.2: A partir de aqu empieza la traduccin de subdominios del dominio para el cual somos el autorizado: los dominios de tercer nivel y sucesivos. Fjese en que debe crearse un registro para cada uno, sin posibilidad de "agrupar" de ningn modo. Asimismo, ntese que, al ser subdominios de la zona, se ha omitido el sufijo nitsugario.com., que se encuentra implcito debido a que no termina en "." (punto).Es simplemente una cuestin de claridad y ahorro de espacio, pues las representaciones en ambas zonas son repetimos de nuevo igualmente correctas. Otros registros similares se citan, agrupados, a continuacin: cesar luz www pop3 smtp ftp IN IN IN IN IN IN A A A A A A 192.168.1.1 192.168.1.3 192.168.1.2 192.168.1.2 192.168.1.2 192.168.1.2
A propsito del concepto de alias (www, pop3, smtp y ftp son de hecho el mismo host) existe una controvertida discusin sobre si es mejor usar el tipo de registro CNAME (del ingls, Canonical NAME) o IN A. Muchos gurs de Bind recomiendan no usar registros CNAME en absoluto, si bien esa discusin se escapa de los objetivos de este artculo. En cualquier caso, es muy recomendable seguir la regla de que los registros MX, CNAME y SOA nunca deben referenciar un registro CNAME, sino exclusivamente algo con un registro tipo "A". Por lo tanto, no es aconsejable usar: web CNAME www
13
BIND 9.5
Pero s sera correcto: web CNAME ns1 Tambin es seguro asumir que un CNAME no es un host adecuado para una direccin de correo electrnico: webmaster@www.nitsugario.com, sera incorrecta dada la configuracin de arriba. La manera de evitar esto es usar registros "A" (y quizs algunos otros tambin, como el registro MX) en su lugar. El autor de este artculo se decanta por el uso de IN A y recomienda dicha prctica.
4.2.1.2.
Zona de resolucin inversa 1.168.192.in-addr.arpa
En estos momentos, los programas son ya capaces de convertir los nombres en nitsugario.com a direcciones a las cuales pueden conectarse. Pero tambin se requiere una zona inversa, capaz de permitir al DNS convertir una direccin en un nombre. Este nombre es usado por muchos servidores de diferentes clases (ftp, irc, www y otros) para decidir si quieren "hablar" con el cliente o no y, si es el caso, quizs incluso cunta prioridad se le debe asignar. Para poder tener acceso completo a todos estos servicios en Internet es necesaria una zona inversa. Nombre del archivo: 192.168.1 Se guarda en: /var/named/chroot/var/named/ Contenido del archivo: $TTL 86400 @ IN SOA nitsugario.com. nitsugario@gmail.com. ( 2009021701 ; nmero de serie 28800 ; tiempo de refresco 7200 ; tiempo entre reintentos de consulta 604800 ; tiempo tras el cual expira la zona 86400 ; tiempo total de vida ) @ 2 1 3 2 2 2 2 IN IN IN IN IN IN IN IN NS PTR PTR PTR PTR PTR PTR PTR ns1.nitsugario.com. ns1.nitsugario.com. cesar.nitsugario.com. luz.nitsugario.com. www.nitsugario.com. pop3.nitsugario.com. smtp.nitsugario.com. ftp.nitsugario.com.
Nota: Cada vez que haga algn cambio en algn fichero de zona, deber cambiar el nmero de serie
(serial) a fin de que tomen efecto los cambios de inmediato cuando se reinicie el servicio named, ya que de otro modo tendra que reiniciar el equipo, algo poco conveniente.
Nota: un punto y coma, ";", en el archivo indica que todo lo que hay a su derecha es un comentario.
14
BIND 9.5
4.2.1.2.1. Descripcin del archivo 192.168.1 A continuacin desmenuzaremos el contenido del archivo 192.168.1, indicando para que sirbe cada lnea escrita en el. De nuevo, los conceptos son los mismos (la "@" arroba indica el dominio de la zona nitsugario.com., el "." punto del final hace referencia al servidor de nombres raz y el registro "SOA" tiene exactamente la misma estructura y funcionalidad), excepto las dos ltimas lneas: Lnea @ IN NS ns1.nitsugario.com. : Indican a qu servidores de nombres debe preguntarse por la traduccin inversa de una direccin IP de esta zona. Lnea 2 IN PTR ns1.nitsugario.com. : Este es el registro que se usar para devolver el nombre que queremos que corresponda con la direccin IP que nos pertenece (cuidado al crear estos registros, pues debe hacerse referencia exclusivamente a direcciones IP que sean de nuestra propiedad o provocaramos un conflicto). En este caso se indica que la direccin 2 (implcitamente se le aade el sufijo.1.168.192.inaddr.arpa, lo que indica que se trata de "nuestra" direccin IP 192.168.1.2) equivale al host ns1.nitsugario.com. Es obvio que aqu "falta informacin", pues la direccin IP 192.168.1.2 equivale, en realidad, a ms hosts, tal y como hemos especificado en el fichero 192.168.1. Esto es cierto los cuales son: 2 2 2 2 IN IN IN IN PTR PTR PTR PTR www.nitsugario.com. pop3.nitsugario.com. smtp.nitsugario.com. ftp.nitsugario.com.
Tambin falta mencionar las dems IP de las otras dos maquinas que estn en la red. Y para estas cambia el nmero inicial que es el que corresponde a su IP. 1 3 IN PTR IN PTR cesar.nitsugario.com. luz.nitsugario.com.
Estos dos son diferentes por sus IPs que serian, para cesar la direccin 192.168.1.1 y para Luz 192.168.1.2.
4.2.2. Configuracin del archivo named.rfc1912.zones

El contenido del archivo ser: zone "nitsugario.com" { type master; file "nitsugario.com.zone"; allow-update { none; }; }; zone "1.168.192.in-addr.arpa" { type master; file "192.168.1"; allow-update { none; }; };
15
BIND 9.5 4.2.2.1.

Descripcin del archivo named.rfc1912.zones
Lnea zone "nitsugario.com" { : Indica que se est creando la zona nitsugario.com. Lnea type master; : Significa que el servidor de dominios es primario o maestro de la zona. Lnea file "nitsugario.com.zone"; : Es el fichero donde especificaremos la configuracin de esa zona, el cual guardamos en el directorio /var/named/chroot/var/named/. Y que ya explicamos. Lnea allow-update { none; }; : Significa que no admite actualizaciones automticas. En este archivo puede a ver ms para metro, los cuales son usados para aumentar la seguridad del servidor. Los cuales pueden ser. allowquery { any; }; : Significa que se permiten consultas (del ingls, queries) externas a la zona. Esto es algo til y necesario, a menos que se quiera ser muy paranoico con la seguridad. Simplemente se ofrece de forma tcnicamente ordenada la informacin que es pblicamente accesible. allowtransfer { slaves; }; : Posibilita la transferencia automtica de esta configuracin a los servidores secundarios de las zonas bajo nuestro control que se especifiquen en la lista slaves. Se profundizar ms en el punto de transferencia de zonas. Se han usado dos palabras especiales, any y slaves, que requieren una mencin especial. Efectivamente, adems de hacer notar la sintaxis similar a la del lenguaje de programacin C, con la que se debe ser extremamente cuidadoso, hay dos comentarios extras que hacer:
1. any es una palabra reservada de la sintaxis de bind que significa "cualquier direccin IP", como era lgico. Su uso es muy comn y necesario. Otras palabras reservadas importantes son none, que significa "ningn host", localhost, que significa el host local desde cualquiera de las interfaces del sistema, y localnets, que representa a todos los hosts de las redes para las cuales el sistema tiene una interfaz.
2. slaves, en cambio, no es ninguna palabra reservada de bind, sino que corresponde al concepto de lista de control de acceso (ACL, del ingls, Access Control List). Estas listas de direcciones IP nos ahorran trabajo pues, de este modo, tan slo tenemos que especificarlas una vez y, dado que les asginamos un identificador de grupo, podemos referenciarlas de forma ms simple y rpida. Este es el cdigo de la ACL usada en el ejemplo que, por supuesto, debe especificarse en algn lugar del documento antes de ser usada: acl "slaves" { 213.96.79.79; }; El lector se habr dado cuenta en seguida de las grandes ventajas de usar estas listas, an cuando, como en este caso, no gane materialmente excepto en previsin de un tercer servidor de nombres secundario. Ntese que en los identificadores de las ACL se diferencian maysculas y minsculas (en ingls, case sensitive).
16
BIND 9.5
4.2.3. Configuracin del archivo named.conf

El contenido del archivo es: options { listen-on port 53 { 192.168.1.2; }; listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { any;}; }; logging { channel default_debug { file "data/named.run"; severity dynamic; }; }; zone "." IN { type hint; file "named.ca"; }; include "/etc/named.rfc1912.zones";
4.2.3.1 Descripcin del contenido del archivo named.conf La clausula options:

Agrupa declaraciones que controlan el comportamiento general o global y tiene alcance en todas las zonas, vistas y en otras clausulas. Esta clausula puede tomar una gran cantidad de declaraciones. Sintaxis: options { // Declaraciones de opciones };
Descripcin de los parmetros de la clusula options:

Lnea: listen-on port 53 { 192.168.1.2; }; Define el puerto y la direccin IPv4 sobre el que BIND escuchar las peticiones entrantes. El puerto por defecto para el servidor DNS es el puerto 53. Se pueden hacer mltiples declaraciones de listen-on. Lnea: listen-on-v6 port 53 { ::1; }; Define el puerto y la direccin IPv6 sobre el que BIND escuchar las peticiones entrantes. El puerto por defecto para el servidor DNS es el puerto 53. Se pueden hacer mltiples declaraciones de listen-on. Lnea: directory "/var/named"; Define una ruta que define el directorio de base usado para zona y Otros archivos que usa BIND. Lnea: dump-file "/var/named/data/cache_dump.db"; Espesifica una ruta total donde BIND vuelca el cach en respuesta a un comando de dumpdb de rndc. Si no especificado, el incumplimiento es named_dump.db en la ubicacin especificado por una declaracin de directorio.
17
BIND 9.5
Lnea: statistics-file "/var/named/data/named_stats.txt"; El nombre del archivo al que el servidor aade estadstica cuando se ordena se usa estadsticas de rndc. Si no es especificado, el archivo por defecto es named.stats. Lnea: memstatistics-file "/var/named/data/named_mem_stats.txt"; El nombre del archivo al que el servidor escribe estadstica de uso de memoria. Si no especificado, el archivo por defecto es named.memstats. Lnea: allow-query { any;}; Un address_match_list definir qu anfitriones ser permitido emitir consultas al servidor. Si no especificado, todos anfitriones son permitidos hacer las preguntas.
La clausula logging:
Define las caractersticas comportamiento y formato de BINDs extensive logging.
La clausula zone:
Contiene declaraciones que definen el comportamiento para una zona en especfico. El alcance de La Declaracin es limitada a esa zona solamente.
La clausula include:
La declaracin de inclusin es nica y puede estar en cualquier lugar del archivo de named.conf, no puede estar declarada dentro o fuera de una clusula. Lo que hace esta clausula es leer el contenido del archivo especificad para procesar lo que este escrito. Su declaracin tiene la siguiente forma: include "Nombre de archivo"; El nombre de archivo es una cadena dada y puede ser una ruta total, por ejemplo, /var/named/file.name, O respectivo, por ejemplo, file.name, en este caso donde no se declar un directorio, se da por hecho que es el directorio donde esta named.conf que es normalmente /etc. La declaracin de inclusin es usada para tres propsitos tpicamente: 1. Simplificar o distribuir la administracin de named.conf presente el mantenimiento: por ejemplo, Las zonas pueden ser administradas por separado por divisiones de una compaa. 2. Para aislar y dividir los cambios y las actualizaciones: por ejemplo, si las clusulas de acl cambian frecuentemente, Puede ser deseable separarlos en archivos que pueden estar incluidos, a saber Minimizar la necesidad de editar el archivo de named.conf principal. 3. Controlar los permisos: puede ser deseable limitar el acceso usando permisos restringidos.
5. Comprobando que funcione la configuracin

Al terminar de editar todos los ficheros involucrados, solo bastar iniciar el servidor de nombres de dominio.
5.1.
Iniciando el servidor:
Para iniciar el servidor usaremos el comando service named start. Y si todo est bien tendremos un resultado como el siguiente. [root@nitsugario ~]# service named start Iniciando named:
[ OK ]
18
BIND 9.5 5.2. Parando el servidor:
Para parar el servidor usaremos el comando service named stop. Y si todo est bien, tendremos un resultado como el siguiente. [root@nitsugario ~]# service named stop Deteniendo named:
[ OK ]
5.3.
Reiniciando el servidor:
Para reiniciar el servidor usaremos el comando service named restart. Y si todo est bien tendremos un resultado como el siguiente. [root@nitsugario ~]# service named restart Deteniendo named: Iniciando named:
[ OK ] [ OK ]
5.4. Aadir el servidor al arranque del sistema: Si queremos que el servidor de nombres de dominio quede aadido entre los servicios en el arranque del sistema, deberemos ejecutar lo siguiente a fin de habilitar named junto con el arranque del sistema: [root@nitsugario ~]#chkconfig named on
5.5.
Depuracin de la configuracin:
Realice prueba de depuracin y verifique que la zona haya cargado con nmero de serie: [root@nitsugario ~]#tail -80 /var/log/messages |grep named Lo anterior, si est funcionando correctamente, debera devolver algo parecido a lo mostrado a continuacin:
Feb 18 04:13:24 nitsugario named[6898]: starting BIND 9.5.0b2 -u named -t /var/named/chroot Feb 18 04:13:24 nitsugario named[6898]: found 2 CPUs, using 2 worker threads Feb 18 04:13:24 nitsugario named[6898]: loading configuration from '/etc/named.conf' Feb 18 04:13:24 nitsugario named[6898]: the working directory is not writable Feb 18 04:13:24 nitsugario named[6898]: listening on IPv6 interface lo, ::1#53 Feb 18 04:13:24 nitsugario named[6898]: default max-cache-size (33554432) applies Feb 18 04:13:24 nitsugario named[6898]: zone nitsugario.com/IN: sending notifies (serial 2009021602) Feb 18 04:13:24 nitsugario named[6898]: zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 2009021602) Feb 18 04:13:24 nitsugario named[6898]: running
19
BIND 9.5 5.6. Pruebas con ping:
Primera prueba: se dio ping al subdominio ns1.nitsugario.com.
Segunda prueba se dio ping a la PC de Cesar, cesar.nitsugario.com.
Como se puede ver en las imgenes se el servidor ya est funcionando correctamente. Y ya con esto tenemos un servidor DNS bsico para un pequea LAN.
20
BIND 9.5
Bibliografa
Libro en ingles. pro DNS and BIND, Ronald G.F. Aitchison, Apress, ISBN (pbk): 1-59059-494-0. El Sistema de nombres de dominio: Bind 9.2.1,por Jaume Sabater, modificado el 06/03/2003, http://bulma.net Implementacin de servidores con GNU/Linux, joel Barrios Dueas, Edicion Agosto 2008, http://www.alcancelibre.org/staticpages/index.php DNS (Sistema de nombre de dominio) http://es.kioskea.net/contents/internet/dns.php3 The DNS Resources Directory, http://www.intac.com/~cdp/cptd-faq/ DNS HowTo, http://www.tldp.org/HOWTO/DNS-HOWTO.html Securing DNS with Transaction Signatures, http://www.linux.ie/articles/tutorials/dns-tsig.php All About DNS, http://www.linux.ie/articles/dns.php DNS Cmo, http://cauchy.bdat.net/dns/bind-9/DNS-HOWTO-9-es/ Los RFC que definen el sistema de DNS estn disponibles en http://www.rfceditor.org
21

Servidor DNS en Fedora9

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Servidor DNS en Fedora9

Cargado por

Copyright:

Formatos disponibles

PRIMERA PARTE

Servidor DNS en Fedora

9 Servidor DNS en Fedora. 2009

Ing. Agustn Ros Reyes

9 Servidor DNS en Fedora. 2009

Ing. Agustn Ros Reyes

9 Servidor DNS en Fedora. 2009

Porque usar un servidor DNS?

Cmo funciona el DNS?

1.3.1. El Espacio de Nombres de Dominio

Ing. Agustn Ros Reyes

9 Servidor DNS en Fedora. 2009

1.3.2. El Espacio de Nombres de Dominio en Internet

Ing. Agustn Ros Reyes

BIND 9.5 1.3.3. Delegacin

9 Servidor DNS en Fedora. 2009

Ing. Agustn Ros Reyes

9 Servidor DNS en Fedora. 2009

Ing. Agustn Ros Reyes

9 Servidor DNS en Fedora. 2009

2.3.1. Zonas de Reenvo

2.3.2. Zonas de Resolucin Inversa

3. Instalacin de los paquetes

para named aadiendo

Ing. Agustn Ros Reyes

BIND 9.5 3.2.

9 Servidor DNS en Fedora. 2009

Comprobando que los paquetes estn instalados.

Instalar los paquetes necesarios.

4. Configuracin del servidor

Ing. Agustn Ros Reyes

BIND 9.5 4.1. Archivos de configuracin.

9 Servidor DNS en Fedora. 2009

4.1.3. Archivos de zonas.

Ing. Agustn Ros Reyes

9 Servidor DNS en Fedora. 2009

Configuracin de los archivos y creacin del los archivos de zonas.

4.2.1. Creacin de archivos de zonas.

Zona de reenvi nitsugario.com

9 Servidor DNS en Fedora. 2009

Ing. Agustn Ros Reyes

9 Servidor DNS en Fedora. 2009

Ing. Agustn Ros Reyes

9 Servidor DNS en Fedora. 2009

Zona de resolucin inversa 1.168.192.in-addr.arpa

Ing. Agustn Ros Reyes

9 Servidor DNS en Fedora. 2009

4.2.2. Configuracin del archivo named.rfc1912.zones

Ing. Agustn Ros Reyes

BIND 9.5 4.2.2.1.

9 Servidor DNS en Fedora. 2009

Ing. Agustn Ros Reyes

9 Servidor DNS en Fedora. 2009

4.2.3. Configuracin del archivo named.conf

4.2.3.1 Descripcin del contenido del archivo named.conf La clausula options:

Descripcin de los parmetros de la clusula options:

Ing. Agustn Ros Reyes

9 Servidor DNS en Fedora. 2009

5. Comprobando que funcione la configuracin

Ing. Agustn Ros Reyes

BIND 9.5 5.2. Parando el servidor:

9 Servidor DNS en Fedora. 2009

Ing. Agustn Ros Reyes