Componentes de un DNS Un DNS se compone de tres componentes básicos, los cuales son: Cliente DNS Servidor DNS Zonas de Autoridad

Transcripción

1 Acerca de DNS En la mayoría de las redes modernas, incluyendo la Internet, los usuarios localizan paginas web por su nombre de dominio (ej. permite al usuario acceder a las millones de paginas web de la Internet sin necesidad de recordar todas y cada una de las direcciones IP asociadas al nombre de la pagina que desea visitar. Una forma de solucionar este problema es mediante la complementación de un mecanismo que al momento que un usuario pregunte por el nombre de una pagina web este servidor conozca que dirección IP le corresponde al sitio web por el cual pregunta el usuario. El mecanismo del cual hablamos es un servidor de nombres mayormente conocido como servidor DNS (Domain Name Server) Así mismo un servidor DNS tiene la función de almacenar la información asociada a los nombres de dominio existentes por los cuales el usuario pregunta, por ejemplo: Por lo tanto el servidor DNS es capaz de asociar distintos tipos de información a cada nombre, los usos más comunes son la asignación de nombres de dominio a direcciones IP y la localización de los servidores de correo electrónico de cada dominio. Cuando un equipo cliente solicita información desde un servidor de nombres, usualmente se conecta al puerto 53 Falsamente se asocia a un DNS con una base de datos, cosa que es totalmente falso,pues los principios fundamentales de las bases de datos especifican que no pueden contener datos redundantes es decir, los datos no pueden ser la misma información la cual es almacenada varias veces en la misma base de datos El mapeo de nombres a direcciones IP es ciertamente la función más conocida de los servidores DNS. Por ejemplo, si la dirección IP del sitio es , la mayoría de la gente para acceder a ella teclea en un navegador web la dirección web y no la dirección IP. La institución encargada de asignar nombres de dominios en Internet es conocida como NIC (acrónimo de Network Information Center o Centro de Información sobre la Red) esta institución es la encargada de asignar los nombres de dominio en Internet, ya sean nombres de dominio genéricos o por países, permitiendo personas o empresas montar sitios de Internet mediante a través de un ISP mediante un DNS. Técnicamente existe un NIC por cada país en el mundo y cada uno de éstos es responsable por todos los dominios con la terminación correspondiente a su país. Por ejemplo: NIC México es la entidad encargada de gestionar todos los dominios con terminación.mx, la cual es la terminación correspondiente asignada a los dominios de México. FQDN (acrónimo de Fully Qualified Domain Name o Nombre de Dominio Plenamente Calificado) es un Nombre de Dominio ambiguo que especifica la posición absoluta del nodo en el árbol jerárquico del DNS. Se distingue de un nombre regular porque lleva un punto al final. Ejemplos: Componentes de un DNS Un DNS se compone de tres componentes básicos, los cuales son: Cliente DNS Servidor DNS Zonas de Autoridad Cliente DNS Cuando hablamos del cliente DNS nos referimos al host o usuario que hace la petición o sea, a la computadora del usuario la cual genera la petición al DNS preguntando por el nombre de algún dominio existente en internet. Servidor DNS Existen 3 tipos de servidores básicos de un DNS los cuales son:

2 Servidor Maestro Servidor Esclavo Servidor de Cache Servidor Primario o Maestro Un servidor DNS maestro almacena los registros de las zonas originales y de autoridad. Ademas el servidor DNS maestro es el encargado de responder a las peticiones hechas por otros servidores DNS Servidor Secundario o Esclavo Un servidor DNS esclavo también tiene la capacidad de responder a las peticiones hechas por un Cliente DNS así como otro servidor de DNS, la diferencia radica en que los servidores esclavos obtienen la información acerca de los nombres de dominio desde los servidores maestros Servidor De Cache Este ofrece servicios de resolución de nombres como respuesta a las peticiones hechas por los clientes de dns, dichos servicios de resolución de nombres son guardados cierto espacio de tiempo para poder acceder a dicha información mas rápidamente. Este tipo de servidores no tiene ninguna autoridad sobre las zonas de autoridad. Los servidores DNS son los encargados de hacer las consultas producto de las peticiones solicitadas por los clientes DNS. Para ello el servidor DNS hace uso de 2 tipos de consultas: Consultas Iterativas Consultas Recursivas Consultas Recursiva Una consulta iterativa funciona de la siguiente manera: Imagine que tenemos un cliente DNS el cual hace la petición a nuestro servidor dns-1 sobre el dominio nuestro servidor dns-1 no sabe quien es pero el conoce quien puede tener ese dominio por lo que ahora dns-1 le hace la petición a dns-2, dns-2 le responde a dns-1 que no sabe quien es pero el sabe quien puede tener ese dominio registrado, por lo que ahora dns-2 le hace la petición a dns-3, dns-3 responde la petición hecha por dns-2 contestando que el si conoce quien es por lo que dns-3 enviá la dirección IP asociada a a dns-2, dns-2 le responde la petición a dns1 y dns-1 a su vez le responde a el cliente DNS. Consultas Iterativas Una consulta recursiva funciona de la siguiente manera: Imagine que tenemos un cliente DNS el cual hace la petición a nuestro servidor dns-1 sobre el dominio nuestro servidor dns-1 no sabe quien es pero el conoce quien puede tener ese dominio por lo que dns-1 le responde al Cliente DNS que le pregunte al dns-2, dns-2 no sabe quien es pero el conoce quien puede tener ese dominio por lo que dns-2 le responde al Cliente DNS que le pregunte al dns-3, dns-3 sabe quien es por lo que dns-3 responde a la petición hecha por el Cliente DNS devolviendo la IP que le corresponde a Diferencias entre las Consultas Iterativas contra las Consultas Recursivas Las diferencias entre las consultas iterativas contras las recursivas son: Cuando se hacen consultas iterativas quien asume toda la carga es nuestro cliente DNS (nuestra maquina) Cuando se hacen consultas recursivas quien asume toda la carga es el servidor DNS pues el es el encargado de proporcionar una respuesta completa a la petición hecha por el Cliente dns Conociendo esta información se puede concluir que las consultas recursivas son mejores que las consultas iterativas, debido a que las consultas recursivas liberan a nuestro cliente DNS (nuestra maquina) de la tarea de responder las peticiones solicitadas por el mismo, haciendo que toda la carga la asuma el servidor DNS.

3 Zonas de Autoridad Las zonas de autoridad contienen las características sobre las cuales nuestro dominio actuara, en ella se configuran los aspectos importantes así como las opciones especificas de cada zona, estas configuraciones hechas a las zonas son cargadas desde el servidor maestro. La información 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 como pueden ser: CNAME Canonical Name (Nombre Canónico) Se usa para crear nombres de hosts adicionales, o alias, para los hosts de un dominio. A NS MX PTR SOA HINFO TXT LOC WKS SRV Address (Dirección) Este registro se usa para traducir nombres de hosts a direcciones IP. Name Server (Servidor de Nombres) Define la asociación que existe entre un nombre de dominio y los servidores de nombres que almacenan la información de dicho dominio. Cada dominio se puede asociar a una cantidad cualquiera de servidores de nombres. Mail Exchange (Intercambiador de Correo) Define el lugar donde se aloja el correo que recibe el dominio. Pointer (Indicador) También conocido como 'registro inverso', funciona a la inversa del registro A, traduciendo IPs en nombres de dominio. Start of authority (Autoridad de la zona) Proporciona información sobre la zona. Host Information (Información del sistema informático) Descripción del host, permite que la gente conozca el tipo de máquina y sistema operativo al que corresponde un dominio. Text - ( Información textual) Permite a los dominios identificarse de modos arbitrarios. Localización - Permite indicar las coordenadas del dominio. Generalización del registro MX para indicar los servicios que ofrece el dominio. Obsoleto en favor de SRV. Servicios - Permite indicar los servicios que ofrece el dominio. Sobre BIND (Berkeley Internet Name Server) BIND es el servidor DNS mas comúnmente implementado en Sistemas Operativos Linux, y actualmente el mas usando en Internet. Originalmente BIND nació a principios de los años 80 bajo el patrocinio de DARPA (Agencia de Investigación de Proyectos Avanzados de Defensa) agencia del Departamento de Defensa de los Estados Unidos, el cual fue desarrollado en la Universidad de California, Berkeley por cuatro estudiantes. A mediados de los años 80 su desarrollo paso a manos de los empleados de DEC (Digital Equipment Corporation, compañía que mas tarde seria adquirida por Compaq y esta a su vez comprada por HP) Paul Vixie,empleado de DEC continuó trabajando en BIND luego de desvincularse de DEC. Más adelante ayudaría a fundar la ISC (Internet Systems Consortium), la cual se convirtió en la responsable del mantenimiento de BIND. El desarrollo de BIND 9 fue realizado con el auspicio conjunto del área comercial y militar. La mayoría de las funcionalidades de BIND 9 fueron impulsadas por proveedores de UNIX quienes querían asegurar que BIND se mantuviera competente con la oferta de Microsoft en el sector de soluciones DNS. La versión mas actual de BIND, en particular la versión 9.0 fue reescrita desde cero, esto con el fin de reparar algunas de sus funcionalidades arquitectónicas de la misma (problemas en la programación de Bajo Nivel) que agrega características importantes como: TSIG, notificación DNS, nsupdate, IPv6, rndc flush, vistas, procesamiento en paralelo, y una arquitectura mejorada en cuanto a portabilidad. Creando nuestro servidor de Dominio Vamos a crear nuestra primera zona de nuestro dominio. The zone file is what will contain our name records for our domain. It's a simple database, if you will, of names to IP addresses than can easily be modified with any text editor. To make things easy for us, we're going to copy a template.

4 Primero que todo, instalamos el servidor named: sudo apt-get install bind9 1. Creamos el archivo de la nueva zona, copiando un template existente: sudo cp /etc/bind/db.empty /etc/bind/db.utap.intranet 2. Abrimos el archivo de la nueva zona, con un editor de texto, como NANO ó VI. sudo nano /etc/bind/db.utap.intranet El contenido del archivo, es similar a estas lineas: BIND reverse data file for empty rfc1918 zone DO NOT EDIT THIS FILE - it is used for multiple zones. Instead, copy it, edit named.conf, and use that copy. $TTL IN SOA localhost. root.localhost. ( 1 Serial Refresh Retry Expire ) Negative Cache IN NS localhost. 3. Modificamos el archivo y lo modificamos con nuestros parametros. Nosotros necesitamos definir el Start of Authority server (SOA) el servidor primario de nuestro servidor DNS, la dirección de correo del administrador, el Name Server record (NS) para nuestro name server (ns1), y un Address record para el name server (ns1). BIND reverse data file for empty rfc1918 zone DO NOT EDIT THIS FILE - it is used for multiple zones. Instead, copy it, edit named.conf, and use that copy. $TTL IN SOA ns1.utap.intranet. admin.utap.intranet. ( 1 Serial Refresh Retry Expire ) Negative Cache IN NS IN NS ns2.utap.intranet. ns1 IN A ns2 IN A Now we add the address records (A) for the computers in our environment. BIND reverse data file for empty rfc1918 zone DO NOT EDIT THIS FILE - it is used for multiple zones. Instead, copy it, edit named.conf, and use that copy. $TTL IN SOA ns1.utap.intranet. admin.utap.intranet. ( 1 Serial Refresh

5 86400 Retry Expire ) Negative Cache IN NS IN NS ns2.utap.intranet. ns1 IN A ns2 IN A desktop01 IN A desktop02 IN A desktop03 IN A desktop04 IN A fileserver01 IN A fileserver02 IN A mailserver01 IN A Guardamos los cambios Add Your Domain to BIND 1. Open the BIND configuration file into a text editor, like Nano. sudo nano /etc/bind/named.conf 2. Adicionar las siguientes lineas al final del archivo. zone "utap.intranet" { type master file "/etc/bind/db.utap.intranet" allow-transfer { Type Specifies the name server type - Master or Slave. File The location of the zone's database file. Allow-Transfer Specify which servers, by IP address, are allowed to download the zone file. 3. Guardar los cambios y salir del editor de textos. 4. Reiniciamos el servicio Bind, para que cargue las nuevas configuraciones. sudo service bind9 reload Configure the DNS Server to Query Itself In order for your domain name server to return lookups, it needs to be able to query itself. To do this we're going to modify its client DNS settings. 1. Open the resolv.conf file into a text editor. sudo nano /etc/resolv.conf 2. Modify it so that it contains the following lines. nameserver search utap.intranet nameserver Sets the IP address of the DNS server to be queried. You can add as

6 many nameserver entries as you have DNS servers for your domain. The search option is used to append the defined domain name to all of your single-label lookups - any lookup that contains a computer name search without a domain name appended. For example, desktop01. This way you don't have to type the entire fully qualified domain name, desktop01.utap.intranet. 3. Guardar los cambios y salir del editor de textos. 4. Test your name resolution by ping a computer registered in your domain using its fully qualified domain name. ping desktop01.utap.intranet 5. Another method of testing name resolution is to use the Dig tool. It returns more detailed results about your lookup. dig desktop01.utap.intranet 6. The Dig command will return the following results, which shows the question, the return answer, and which DNS server gave the response. <<>> DiG rpz2+rl P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1.1 <<>> desktop01.utap.intranet global options: +cmd Got answer: ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 688 flags: qr aa rd ra QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 OPT PSEUDOSECTION: EDNS: version: 0, flags: udp: 4096 QUESTION SECTION: desktop01.utap.intranet. IN A ANSWER SECTION: desktop01.utap.intranet IN A AUTHORITY SECTION: utap.intranet IN NS ns1.utap.intranet. ADDITIONAL SECTION: ns1.utap.intranet IN A Query time: 1 msec SERVER: #53( ) WHEN: Fri Jan 17 23:28:17 CST 2014 MSG SIZE rcvd: 104 Configure the Secondary DNS Server 1. Log onto the secondary (slave) DNS server, NS2. 2. Open the Bind configuration file into a text editor. sudo nano /etc/bind/named.conf 3. Add a zone entry for our domain zone using the following configuration. zone "utap.intranet" { type slave master { file "/etc/bind/db.utap.intranet" Type Specifies the name server type - Master or Slave.

7 Master Specifies the IP address of the master server. File Specifices the location of the replica zone database file. 4. Guardar los cambios y salir del editor de textos. 5. Instruct Bind to reload it's configuration file. sudo service bind9 reload 6. Our domain should not be downloading to our secondary server. Check that it exits by navigating to the location specified in Bind's configuration file. Para que resuelva direcciones externas : 1. Editamos el archivo named.conf.options sudo vi /etc/bind/named.conf.options 2. Encontraremos un archivo asi : options { directory "/var/cache/bind" // If there is a firewall between you and nameservers you want // to talk to, you may need to fix the firewall to allow multiple // ports to talk. See // If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders. // Uncomment the following block, and insert the addresses replacing // the all-0's placeholder. // forwarders { // 0,0,0,0 // //================================ // If BIND logs error messages about the root key being expired, // you will need to update your keys. See //======================================================================== dnssec-validation auto 3. Quitamos los comentarios del forwarders y colocamos las ips de nuestros servidores DNS preferidos. Quedando algo asi: options { directory "/var/cache/bind" // If there is a firewall between you and nameservers you want // to talk to, you may need to fix the firewall to allow multiple // ports to talk. See // If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders.

8 // Uncomment the following block, and insert the addresses replacing // the all-0's placeholder. forwarders { //================================ // If BIND logs error messages about the root key being expired, // you will need to update your keys. See //===================================================================== === dnssec-validation auto 4. Reiniciamos el servicio: sudo service bind9 reload Comprobación del funcionamiento de las zonas activas. rndc status Explicación de los valores del SOA Mail Address : Dirección del administrador de zona del dominio. Generalmente se sustituye la arroba (@) por un punto. Refresh : Número de segundos que un servidor de nombres secundario debe esperar para comprobar de nuevo los valores de un registro. Ej : refresh: (1 día) Retry : Número de segundos que un servidor de nombres secundario debe esperar después de un intento fallido de recuperación de datos del servidor primario. Ej : Retry: 7200 (2 horas) Expire : Número de segundos máximo que los servidores de nombre secundarios retendrán los valores antes de expirarlos. Ej : Expire: (1 semana) Minimum TTL : Significa Time To Live y es el número de segundos que los registros se mantienen activos en los servidores NS caché antes de volver a preguntar su valor real. Ej : Minimum TTL: (6 horas) Cuando haga un cambio cuanto tardara? que hace el TTL? El TTL es el tiempo en que el registro tiene plena validez, por lo que cuando alguien consulta el DNS, se guarda ese valor y en ningún caso vuelve a verificarlo hasta pasado ese tiempo. Es por ello que estadísticamente el tiempo medio en el que

9 TODO Internet se da cuenta de un cambio es aproximadamente la mitad del valor de TTL. Pero evidentemente si quieres curarte en salud di a tus usuarios que tardara lo que indica el TTL. Es importante hacer crecer el serial al hacer un cambio, porque pasado el tiempo del TTL es servidor de DNS remoto verifica el Serial y si este sigue igual considerar que nada a cambiado y no reverificará de forma efectiva hasta que pase el EXPIRE. Avanzado Instalando/Configurando Bind9 Para la posterior configuración de Bind9 tenemos que instalar los siguientes paquetes: # aptitude install bind9 bind9utils dnsutils Nota: Bind9 y sus archivos de configuración se alojan en el caso de Debian en /etc/bind/ por defecto. El paquete dnsutils nos brindará algunas funcionalidades y herramientas para el trabajo con servidores DNS, para hacer comprobaciones y demás. Configuración del archivo named.conf.local. Para el trabajo con bind9 inicialmente solamente tenemos que configurar dos archivos en /etc/bind/named.conf.local y named.conf.options los cuales, después de ajustados no será necesario volverlos a tocar, pero que son los encargados del correcto funcionamiento del DNS ya que en el mismo se definen varios parámetros fundamentales para nuestra red. El primero de estos archivos, es el named.conf.local el cual contiene por defecto algo como esto: // // Do any local configuration here // // Consider adding the 1918 zones here, if they are not used in your // organization //include /etc/bind/zones.rfc1918 Es aquí donde configuraremos las opciones de nuestra red. Nota: Hay que tener en cuenta que Bind se puede configurar de diferentes formas y no todos los administradores usan el mismo método. Este método que utilizo a mi me funciona perfectamente para mostrar una vista externa y una interna. Lo primero que haremos es declarar nuestras Listas de Control de Acceso o ACL ( del inglés, Access Control List ) un concepto de seguridad informática usado para fomentar la separación de privilegios. Es una forma de determinar los permisos de acceso apropiados a un determinado objeto, dependiendo de ciertos aspectos del proceso que hace el pedido. ( Wikipedia )

10 Para este ejemplo, supongamos que tenemos un servidor con dos tarjetas de red, una interna para nuestra red local con IP y la otra con IP externa Nuestra configuración quedará de esta forma: // Establecemos el rango de nuestra red local. // Establecemos la IP o el rango de IP de nuestros servidores por la red LAN // Establecemos los IP de nuestros servidores WAN// Configuramos la vista interna. acl lan { / /24 acl servidores-lan { acl servidores-wan { // Le ponemos un nombre a la vista interna // donde los clientes son los de la red local. view lan { match-clients { lan!any allow-recursion { servidores-lan // Ahora establecemos nuestro dominio // Específicamos que el servidor es el principal o master // Declaramos donde se encuentra el archivo de zona ( que veremos más adelante ) // Y envíamos las transferencias a nuestro servidor DNS secundario ( la configuración la podemos ver aquí ) zone tudominio.com IN { type master file /var/cache/bind/nuestrodominio.cu.lan.zone allow-query { any allow-update { servidores-lan allow-transfer { notify yes // Establecemos la zona inversa de nuestra IP. zone in-addr.arpa IN { type master file /var/cache/bind/ in-addr.arpa allow-query { any allow-update { servidores-lan

11 allow-transfer { notify yes //Configuramos la vista externa. view wan { match-clients { any!lan allow-recursion { any zone tudominio.com IN { type master file /var/cache/bind/nuestrodominio.cu.wan.zone allow-query { any allow-update { servidores-wan allow-transfer { notify yes zone in-addr.arpa IN { type master file /var/cache/bind/ in-addr.arpa allow-query { any allow-update { servidores-wan allow-transfer { notify yes Como podemos apreciar es bastante sencilla y de fácil comprensión esta configuración. Este archivo sufre pequeñas modificaciones en el caso de que tengamos varios servidores DNS ya que en la opción type habría que establecer si es master (principal) o slave (secundario) en el DNS secundario como se puede ver aquí. El otro archivo que falta por configurar en este directorio es el named.conf.options el cual debe tener adentro algo similar a esto: options { directory /var/cache/bind // If there is a firewall between you and nameservers you want // to talk to, you may need to fix the firewall to allow multiple // ports to talk. See // If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders. // Uncomment the following block, and insert the addresses replacing

12 // the all-0 s placeholder. forwarders { x.x.x.x x.x.x.x auth-nxdomain no # conform to RFC1035 listen-on-v6 { any Este archivo lo único que debe llevar son los forwarders (reenviadores) de nuestra red. Los IP de los reenviadores nos lo debe dar nuestro proveedor de Internet. Sustiuimos las X por los número IP Ahora nos toca la otra parte importante en el Bind: los ficheros de zonas. Si nos fijamos en la configuración del named.conf.local esta hace referencia a unos ficheros alojados en /var/cache/bind/: zone nuestrodominio.cu IN { type master file /var/cache/bind/nuestrodominio.cu.lan.zone allow-query { any allow-update { servidores-lan allow-transfer { notify yes Configurando tudominio.com.lan.zone: Debemos crear 4 ficheros en /var/cache/bind/: tudominio.com.lan.zone, tudominio.com.wan.zone, in-addr.arpa y in-addr.arpa respectivamente. Solamente mostraré la configuración realizada en los ficheros de la Red LAN debido a que los de la red WAN, son iguales, pero con las IP de la Red WAN y solamente se especifican los CNAME o los sitios que queremos mostrarle al que acceda desde afuera. Por lo tanto, si que por ejemplo, nuestro FTP sea local, solamente tenemos que declararlo en el fichero de zona LAN y no en la WAN. Estos ficheros serán de esta forma: Configuración Local $TTL 10m Tiempo de vida de la Zona $ORIGIN tudominio.com. Nombre del IN SOA ns1.tudominio.com. admin.tudominio.com. ( Serial y modificación del archivo

13 10m ref = Tiempo para refrescar 30m ret = Tiempo de reintento para actualizacion 1d ex = Tiempo de expiracion 10m min = minimo ) Registros Principales IN NS IN NS IN MX 10 IN A Registros IN TXT Nombre de tu IN TXT v=spf1 a mx a:mx.tudominio.com include:tudominio.com HINFO Dell PowerEdge 2850 Debian GNU/Linux Registros A - mx IN A IN TXT Mail (Work Server) IN TXT v=spf1 a -all mail IN A ns1 IN A pdc IN A proxy IN A ns2 IN A webserv IN A tudominio.com. IN A tudominio.com. IN A IN A

14 Registros CNAME www IN CNAME proxy webmail IN CNAME mail foro IN CNAME webserv ftp IN CNAME webserv - Registro para el Jabber $ORIGIN A $ORIGIN _tcp.jabber.tudominio.com. _jabber SRV tudominio.com. _xmpp-server SRV tudominio.com. _xmpp-client SRV tudominio.com. En este caso establezco que en mi red exiten 4 servidores: MX con nombre MAIL para el servidor de correo. NS1 con nombre PDC para el DNS. Proxy con nombre Proxy para el Proxy de la RED. Webserv con nombre Webserv para alojar sitios web. pero podemos añadir todos los servidores que queramos que el DNS resuelva por la red interna. Nota: En el caso del fichero de zona tudominio.com.wan.zone es lo mismo pero con las IP externas. Configrando in-addr.arpa.: FQDN (acrónimo de Fully Qualified Domain Name o Nombre de Dominio Plenamente Calificado) es un Nombre de Dominio ambiguo que especifica la posición absoluta del nodo en el árbol jerárquico del DNS. Se distingue de un nombre regular porque lleva un punto al final. Como ejemplo: suponiendo que se tiene un dispositivo cuyo nombre de anfitrión es «maquina1» y un dominio llamado «dominio.com», el FQDN sería «maquina1.dominio.com.», asi es que se define de forma única al dispositivo mientras que pudieran existir muchos anfitriones llamados «maquina1», solo puede haber uno llamado «maquina1.dominio.com.». La ausencia del punto al final definiría que se pudiera tratar tan solo de un prefijo, es decir «maquina1.dominio.com» pudiera ser un dominio de otro más largo como «maquina1.dominio.com.mx». La longitud máxima de un FQDN es de 255 bytes, con una restricción adicional de 63 bytes para cada etiqueta dentro del nombre del dominio. Solo se permiten los caracteres A-Z de ASCII, dígitos y el carácter «-». No se distinguen mayúsculas y

15 minúsculas. (Definición extraída del Libro Implementación de Servidores Linux de Joel Barrios) El fichero en sí lo que llevaría adentro sería esto: DOMINIO LAN $TTL 10m Tiempo de vida de la Zona $ORIGIN IN-ADDR.ARPA. Rango de la IN SOA ns1.tudominio.com. admin.tudominio.com. ( Serial y modificación del archivo 10m ref = Tiempo para refrescar 30m ret = Tiempo de reintento para actualizacion 1d ex = Tiempo de expiracion 10m min = minimo ) Servidores IN NS IN NS ns2.tudominio.com. IP HOST 1 IN PTR ns1.tudominio.com. IN PTR pdc.tudominio.com. 2 IN PTR mx.tudominio.com. IN PTR mail.tudominio.com. 3 IN PTR proxy.tudominio.com. 4 IN PTR ns2.tudominio.com. IN PTR webserv.tudominio.com. Nota: Al igual que en el archivo anterior, en el fichero solo se tienen que cambiar los IP internos por los externos. Si se fijan bien, siempre después de tudominio.com. se pone un punto final (. ) algo que se hace necesario para que el DNS resuelva correctamente de lo contario suecede lo explicado en el concepto de FQDN. Una vez que ya tengamos configurados los otros dos ficheros para la red WAN solamente tenemos que reiniciar el bind: # /etc/init.d/bind9 restart

16 Nota: Puede que cuando reiniciemos el bind9 nos dé un error en el caso de Debian Lenny, algo que no sucedía con Etch. Si esto ocurre lo que tenemos que hacer es abrir el fichero /etc/bind/named.conf y copiar y luego comentar las siguientes lineas (ya aquí aparecen comentadas): // prime the server with knowledge of the root servers //zone. { // type hint // file /etc/bind/db.root // // be authoritative for the localhost forward and reverse zones, and for // broadcast zones as per RFC 1912 //zone localhost { // type master // file /etc/bind/db.local // //zone 127.in-addr.arpa { // type master // file /etc/bind/db.127 // //zone 0.in-addr.arpa { // type master // file /etc/bind/db.0 // //zone 255.in-addr.arpa { // type master // file /etc/bind/db.255 // Ahora estas lineas se pegan dentro de /etc/bind/named.conf.local justo antes de cada zona declarada. Fuente : -usando-bind9-en-debian/