Dns en linux debían squeeze 6

861 views
757 views

Published on

Dns en linux debían squeeze 6

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
861
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
29
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Dns en linux debían squeeze 6

  1. 1. DNS en Linux Debían Squeeze 6.0
  2. 2. Servidor DNS DNS Maestro Primario para una LAN en Debian 6.0 (I) Comenzamos la serie de posts sobre ¿Cómo instalar y configurar un DNS Maestro Primario y Caché en Debian Squeeze?, con los cuales pretendemos dar un Punto de Entrada al fascinante mundo de éste servicio imprescindible para el funcionamiento de la Red de Redes que es Internet. Todos los artículos están desarrollados para que puedan utilizarse de forma secuencial. La 1ra y 2da parte contienen el mínimo de conocimientos teóricos necesarios para que el Nuevo o Newbie pueda entender y desarrollar la instalación de un DNS. A ellos le recomendamos no se amilanen. Lean y apliquen lo escrito y seguro que obtendrán resultados positivos. Y a los Sospechosos Habituales de caer en la Desesperación, les recomendamos calma, mucha calma si quieren entender en realidad como configurar éste imprescindible servicio. Me perdonan el uso de palabras en inglés y algún que otro anglicismo. Se ha hecho para ganar claridad técnica en lo escrito. Los aspectos que desarrollaremos en esta Primera Parte son los siguientes: Introducción Definiciones útiles Configuraciones más comunes de un DNS Zonas y Registros Tiempos de expiración de Zonas Tips Introducción Dicen en la Aldea WWW que el DNS es una de las áreas más obscuras de los servicios de redes. Afortunadamente no es así -sobre todo para una LAN- como lo demostraremos a través de los artículos siguientes. Por mucho que uno no lo desee, es casi obligatorio leer una pequeña parte teórica. Definición según Wikipedia: El DNS es una base de datos distribuida y jerárquica que almacena información asociada a nombres de dominio en redes como Internet. Aunque como base de datos el DNS es capaz de asociar diferentes 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. La asignación de nombres a direcciones IP es ciertamente la función más conocida de los protocolos DNS. Por ejemplo, si la dirección IP del sitio FTP de prox.mx es 200.64.128.4, la mayoría de la gente llega a este equipo especificando ftp.prox.mx y no la dirección IP. Además de ser más fácil de recordar, el nombre es más fiable. La dirección numérica podría cambiar por muchas razones, sin que tenga que cambiar el nombre. Inicialmente, el DNS nació de la necesidad de recordar fácilmente los nombres de todos los servidores conectados a Internet. En un inicio, SRI (ahora SRI International) alojaba un archivo llamado HOSTS que contenía todos los nombres de dominio conocidos (técnicamente, este archivo existe, y la mayoría de los sistemas operativos actuales pueden ser configurados para revisar su archivo hosts). El crecimiento explosivo de la red causó que el sistema de nombres centralizado en el archivo hosts no resultara práctico y en 1983, Paul Mockapetris publicó los RFCs 882 y 883 definiendo lo que hoy en día ha evolucionado hacia el DNS moderno. (Estos RFCs han quedado obsoletos por la publicación en 1987 de los RFCs 1034 y 1035). A las computadoras en las que se ejecuta éste servicio se les denomina “Servidores de Nombres”. Debian trae en sus repositorios varios programas para tener un DNS funcional y entre ellos se encuentra el más utilizado en Internet: El BIND o “Berkley Internet Naming Domain”. BIND es el estándar de facto como servidor DNS. Es Software Libre y se distribuye con la mayoría de las plataformas UNIX y
  3. 3. Linux. También se refieren al BIND como “named” (demonio named). Puede encontrar aquí (Wikipedia en ingles) una comparación de distintos tipos de servidores DNS. Definiciones útiles NetBIOS: Network Basic Input/Output System (NetBIOS): Sistema básico de entrada y salida de red (NetBIOS). Interfaz de programación de aplicaciones (API) que pueden utilizar los programas en una red de área local (LAN). NetBIOS proporciona a los programas un conjunto uniforme de comandos para solicitar los servicios de bajo nivel necesarios para administrar nombres, dirigir sesiones y enviar “datagramas” entre los nodos de una red. Nombre NetBIOS: Nombre de 16 bits de un proceso que utiliza el sistema básico de entrada y salida de red (NetBIOS). Nombre reconocido por el servicio WINS (Windows Internet Name System) de Microsoft, el cual asocia o “mapea” un nombre de equipo o host a una determinada dirección IP. FQDN: “Fully Qualified Domain Name” o Nombre de Dominio Plenamente Calificado. Como el traducir nombres creados en inglés técnico es a menudo tremendo, recomiendo se aprendan el nombre en inglés y para propósitos prácticos se refieran a él como el FQDN. No es más que el Nombre de dominio DNS que se ha establecido para indicar su ubicación absoluta en el árbol de espacio de nombres de dominio. En oposición a los nombres relativos, un FQDN va precedido por un punto para indicar su posición en la raíz del espacio de nombres. Ejemplo: freake.amigos.cu. es el FQDN del host cuyo nombre NetBIOS es freake y pertenece al dominio amigos.cu. amigos.cu. freake.amigos.cu. otrofreake.amigos.cu. mail.amigos.cu. Configuraciones más comunes de un DNS Podemos configurar un Servidor de Nombre de Dominio o DNS de distintas formas para que brinden servicios diferentes. Las más utilizadas son: Servidor Caché (“Caching Nameserver”): Las solicitudes o peticiones hechas al servidor serán resueltas por los Forwarders que le declaremos en su configuración. Las respuestas se almacenaran y “recordarán” para cuando el Servidor Caché sea consultado nuevamente, lo cual aumenta considerablemente la velocidad de respuesta. Maestro Primario (“Primary Master”): Las solicitudes o peticiones hechas al servidor serán resueltas mediante la lectura de los datos almacenados en los archivos locales de las Zonas creadas. Como su nombre indica, será un Servidor de Nombres Autoritario para la Zona consultada. Maestro Secundario (“Secondary Master”): Las solicitudes o peticiones hechas al servidor serán resueltas mediante la consulta directa a un servidor Maestro Primario Autoritario para la Zona consultada. Mantiene una copia actualizada de las Zonas del Maestro Primario. También lo podemos configurar de forma que realicen varias funciones a la vez, como el ser un Maestro Primario y Caché al mismo tiempo, lo cual es muy común en nuestras redes empresariales. Zonas y Registros Las Zonas son archivos de texto plano que nos permiten organizar los Registros DNS. Cada nombre de zona concuerda con el nombre de un dominio, o con un rango de direcciones IP tal como el de una o varias subnets. Contiene, además de otros datos, varios Registros de diferentes Clases o Tipos, de los cuales mencionaremos solo los siguientes: SOA: “Start of Authority”. Comienzo de la Autoridad. Es un registro obligatorio en cada Zona, y debe existir solamente uno sólo en cada archivo. Es el preámbulo de todos los archivos de zona. Describe la zona en si misma; de cual máquina o host proviene; quien es el responsable de su contenido; cual es la versión del archivo de zona, y otros aspectos concernientes al propio funcionamiento del servidor DNS. Es imprescindible que en cada archivo de zona exista un registro tipo A que identifique a la máquina o host donde radica el servidor DNS. NS: Mapea un nombre al Servidor de Nombres. Cada dominio debe tener al menos un registro NS. Este registro apunta a un Servidor DNS que puede responder las consultas concernientes al dominio. Puede apuntar al Maestro Primario o al Maestro Secundario.
  4. 4. A: “Address” – (Dirección). Este registro se usa para traducir nombres de hosts a direcciones IPv4. AAAA: “Address” – (Dirección). Este registro se usa para traducir nombres de hosts a direcciones IPv6. CNAME: “Canonical Name” – (Nombre Canónico). Tipo de registro mediante el cual podemos dar varios nombres a un mismo host o crear Alias de él. Digamos que tenemos el host web.amigos.cu. en el cual tenemos instalado un servidor web y queremos que se refieran a el como www.amigos.cu. Entonces en la Zona amigos.cu debemos tener entre los demás registros: web IN A 192.168.10.20 www IN CNAME web.amigos.cu. MX: “Mail Exchange” o Servidor de Correo. Información utilizada por otros servidores de correo para saber adonde enviar un correo dada una dirección IP. Cada registro MX tiene una prioridad, donde la más alta la tiene el registro con el menor número. Ejemplos: 10 mail1.amigos.cu. 20 mail2.amigos.cu. PTR: Mapeo de una dirección IP a un nombre. Tipos de registros almacenados en las denominadas “Zonas Inversas”. Por ejemplo, la Zona 10.168.192.in-addr.arpa es la que contiene el mapeo inverso de todas las direcciones del rango de direcciones IP 192.168.10.0/24 Por supuesto que la lista de tipos de registros continúa… Tiempos de expiración o caducidad de zonas Cuando estamos creando los archivos de las Zonas de registros DNS, debemos configurar los Tiempos de Expiración en segundos. Sin embargo podemos especificarlos de una forma más corta acorde a la siguiente tabla: Segundos Unidades Descripción 60 1M A un minuto 1800 30M A 30 minutos 3600 1H Una Hora 10800 3H 3 horas 21600 6H 6 horas 43200 12H 12 horas 86400 1D Un día 259200 3D 3 días 604800 1W Una semana Tips Debemos ser muy cuidadosos al escribir en los archivos de zonas. Los FQDN tienen que terminar en un “.” (o sea, punto), y no podemos dejar espacios en blanco al final de cada línea. Por esa razón recomendamos fuertemente el uso de editores de consola como el vi o el nano. Nosotros emplearemos el nano, el cual a nuestro criterio es más fácil de usar. Por supuesto que también podemos usar editores de texto plano con ambiente gráfico o GUI. Espero no se hayan aburrido pues aun queda un poco para entrar en materia.
  5. 5. DNS Maestro Primario para una LAN en Debian 6.0 (II) Continuamos con nuestra serie de artículos y en éste trataremos los siguientes aspectos: Instalación Directorios y archivos principales Antes de continuar, les recomendamos no dejar de leer: DNS Maestro Primario para una LAN en Debian 6.0 (I) Instalación En una Consola y como el usuario root instalamos el bind9: aptitude install bind9 También debemos instalar el paquete dnsutils el cual tiene las herramientas necesarias para hacer consultas DNS y diagnosticar el funcionamiento: aptitude install dnsutils Si desean consultar la documentación que viene en el repositorio: aptitude install bind9-doc La documentación se almacenará en el directorio /usr/share/doc/bind9-doc/arm y el archivo índice o de la Tabla de Contenidos es el Bv9ARM.html. Para abrirlo ejecute: firefox /usr/share/doc/bind9-doc/arm/Bv9ARM.html Cuando instalamos el bind9 en Debian, también lo hace el paquete bind9utils el cual nos aporta varias herramientas muy útiles para mantener una instalación de trabajo de un BIND. Entre ellas encontraremos rndc, named-checkconf y named-checkzone. Por otra parte, el paquete dnsutils aporta toda una serie de programas clientes del BIND entre los que estarán el dig y el nslookup. Todas estas herramientas o comandos las usaremos en los artículos siguientes. Para conocer todos los programas de cada paquete debemos ejecutar como el usuario root: dpkg -L bind9utils dpkg -L dnsutils O ir al Synaptic, buscar el paquete, y ver cuales son los archivos instalados. Sobre todo los que se instalan en las carpetas /usr/bin o /usr/sbin. Si queremos conocer más sobre cómo utilizar cada herramienta o programa instalado, debemos ejecutar: man <nombre del programa> Directorios y archivos principales Cuando instalamos Debian se crea el archivo /etc/resolv.conf. Este archivo o “Fichero de configuración del servicio resolver”, contiene varias opciones que por defecto son el nombre del dominio y la dirección IP del servidor DNS declarado durante la instalación. Como el contenido de la ayuda del archivo viene en español y es muy claro, recomendamos la lean mediante el comando man resolv.conf. Después de instalado el bind9 en Squeeze, se crean al menos los directorios siguientes: /etc/bind /var/cache/bind /var/lib/bind En el directorio /etc/bind nos encontramos, entre otros, con los siguientes archivos de la configuración: named.conf named.conf.options named.conf.default-zones
  6. 6. named.conf.local rndc.key En el directorio /var/cache/bind crearemos los archivos de las Zonas Locales las cuales trataremos posteriormente. Por curiosidad ejecuten en una Consola los siguientes comandos como el usuario root: ls -l /etc/bind ls -l /var/cache/bind Por supuesto que el último directorio no contendrá nada, pues aun no hemos creado ninguna Zona Local. El dividir la configuración del BIND en varios archivos se hace por comodidad y claridad. Cada archivo tiene una función específica como veremos a continuación: named.conf: Archivo principal de configuración. En él se incluyen los archivosnamed.conf.options, named.conf.local y named.conf.defaultzones. named.conf.options: Opciones generales del servicio DNS. La directiva: directory “/var/cache/bind” le indicará al bind9 donde buscar los archivos de las Zonas Locales creadas. También declaramos aquí los servidores “Forwarders” o en una traducción aproximada “Adelantadores” hasta un número máximo de 3, los cuales no son más que servidores DNS externos que podemos consultar desde nuestra red (a través de un Firewall por supuesto) que responderán a las preguntas o solicitudes que nuestro DNS local no sea capaz de responder. Por ejemplo, si estamos configurando un DNS para la LAN192.168.10.0/24, y queremos que uno de nuestros Forwarders sea un Servidor de Nombres de la UCI, debemos declarar la directiva forwarders { 200.55.140.178; }; dirección IP que corresponde al servidor ns1.uci.cu. De esta forma podremos consultarle a nuestro servidor DNS local cual es la dirección IP del host yahoo.es (el cual evidentemente no está en nuestra LAN), ya que nuestro DNS le preguntará al de la UCI si el sabe cual es la dirección IP de yahoo.es, y luego nos dará a nosotros un resultado sea satisfactorio o no. También y en el propio archivo named.conf.option declararemos otros aspectos importantes de la configuración como veremos más adelante. named.conf.default-zones: Como su nombre lo indica son las Zonas por Defecto. Aquí se le configura al BIND el nombre del archivo que contiene la información de los Servidores Raíces o Root Servers necesarios para iniciar la caché DNS, más concretamente el archivodb.root. También se le indica al BIND que tenga plena Autoridad (que sea Autoritario) en la resolución de nombres para el localhost, tanto en consultas Directas como Inversas, y lo mismo para las zonas “Broadcast”. named.conf.local: Archivo donde declaramos la configuración local de nuestro servidor DNS mediante el nombre de cada una de las Zonas Locales, y cuales serán los Archivos de Registros DNS que mapearan los nombres de los equipos conectados a nuestra LAN con su dirección IP y viceversa. rndc.key: Archivo generado que contiene la Clave para controlar el BIND. Mediante la utilidad de control del servidor BIND rndc, seremos capaces de recargar la configuración del DNS sin necesidad de reiniciarlo con el comando rndc reload. Muy útil cuando hacemos cambios en los archivos de las Zonas Locales. En Debian los archivos de las Zonas Locales se pueden ubicar también en /var/lib/bind; mientras que en otras distribuciones como Red Hat y CentOS normalmente se ubican en /var/lib/named u otros directorios en dependencia del grado de seguridad implementado. Nosotros seleccionamos el directorio /var/cache/bind pues es el que sugiere por defecto Debian en el archivo named.conf.options. Podemos emplear cualquier otro directorio siempre y cuando le indiquemos al bind9 donde buscar los archivos de las zonas, o le demos el camino absoluto de cada una de ellas en el archivo named.conf.local. Es muy saludable utilizar los directorios recomendados por la distribución que estemos usando. Está fuera del alcance de este artículo el tratar sobre la seguridad adicional que implica el crear una Jaula o “Chroot” para el BIND. También lo está el tema de la seguridad mediante el contexto SELinux. Aquellos que necesiten implementar tales características, deben acudir a manuales o a literatura especializada. Recuerden que el paquete de documentación bind9-doc se instala en el directorio /usr/share/doc/bind9-doc. Bueno Señores, hasta aquí la 2da Parte. No queremos extendernos más en un solo artículo debido a las buenas recomendaciones de nuestro Jefe. ¡Al fin! entraremos en el meollo de la Configuración y Pruebas del BIND… en el próximo capítulo.
  7. 7. DNS Maestro Primario para una LAN en Debian 6.0 (III) Es tremendo esfuerzo reducir en 5 pequeños artículos los Conocimientos Previos, la Instalación, la Configuración, y la Creación de las Zonas y Comprobaciones de un BIND, de forma que pueda ser entendido por la mayor cantidad de lectores el cual es nuestro propósito fundamental. Los que hayan tenido la paciencia de leer con cuidado la 1era y 2da parte de este artículo, están preparados para continuar con la configuración y puesta a punto de un Servidor de Nombre de Dominio para una LAN. A los Nuevos, y a aquellos que no tengan bien claros los muy resumidos conceptos dados en las partes precedentes, les recomendamos las lean y estudien antes de proseguir. ¡Sospechosos habituales de la Desesperación! hacia atrás si no leyeron cuidadosamente . Veremos a continuación: Datos principales de la LAN Configuraciones mínimas del host Modificaciones al archivo /etc/resolv.conf Modificaciones al archivo /etc/bind/named.conf Modificaciones al archivo /etc/bind/named.conf.option Modificaciones al archivo /etc/bind/named.conf.local Datos principales de la LAN Nombre del Dominio de la LAN: amigos.cu Subnet de la LAN: 192.168.10.0/255.255.255.0 IP del servidor BIND: 192.168.10.10 Nombre NetBIOS del servidor: ns Aunque sea evidente, recuerden cambiar los datos anteriores por los suyos propios. Configuraciones mínimas del host Muy importante es tener correctamente configurados los archivos /etc/network/interfaces y/etc/hosts para obtener un buen funcionamiento del DNS. Si durante la instalación se declararon todos los datos, no será necesaria ninguna modificación. Los contenidos de cada uno de ellos deben ser los siguientes: # contenido del archivo /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet static address 192.168.10.10 netmask 255.255.255.0 network 192.168.10.0 broadcast 192.168.10.255 gateway 192.168.10.2 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 192.168.10.10 dns-search amigos.cu
  8. 8. # contenido del /etc/hosts 127.0.0.1 localhost 192.168.10.10 ns.amigos.cu ns # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters Modificaciones al archivo /etc/resolv.conf Para que nuestras consultas y comprobaciones funcionen correctamente es necesario declarar en la configuración local del host, cual será nuestro dominio de búsqueda y cual será nuestro DNS local. Sin los parámetros anteriores como mínimo, cualquier consulta DNS será fallida. Y éste es un error en el cual caen muchos principiantes. Por tanto, editemos el archivo /etc/resolv.conf y lo dejamos con el siguiente contenido: # contenido de /etc/resolv.conf search amigos.cu nameserver 192.168.10.10 En el equipo donde tenemos instalado el servidor DNS podemos escribir: search amigos.cu nameserver 127.0.0.1 En el contenido anterior, la declaración nameserver 127.0.0.1, indica que las consultas serán hechas al localhost. Después que tengamos nuestro BIND correctamente configurado podemos realizar cualquier consulta DNS desde nuestro host, sea el propio servidor bind9 u otro conectado a la red y que pertenezca a la misma subnet y tenga la misma máscara de red. Para conocer más acerca del archivo ejecuten man resolv.conf. Modificaciones al archivo /etc/bind/named.conf Para limitar las consultas a nuestro BIND de forma que respondan solamente a nuestra subnet y evitar un ataque Spoofing, declaramos en el archivo named.conf la Lista de Control de Acceso o ACL (Access Control List) y la denominamos mired. El archivonamed.conf debe quedar de la forma siguiente: // /etc/bind/named.conf // This is the primary configuration file for the BIND DNS server named. // // Please read /usr/share/doc/bind9/README.Debian.gz for information on the // structure of BIND configuration files in Debian, *BEFORE* you customize // this configuration file. // // If you are just adding zones, please do that in /etc/bind/named.conf.local // // Los comentarios en español son nuestros // Los originales los dejamos en inglés // OJO con el copiar y pegar // NO DEJEN ESPACIOS EN BLANCO AL FINAL DE CADA LINEA // // Lista de Control de Acceso: // Permitirá consultas desde el dominio local y de nuestra subnet // En el archivo incluido named.conf.options haremos referencia a ella. acl mired { 127.0.0.0/8;
  9. 9. 192.168.10.0/24; }; include "/etc/bind/named.conf.options"; include "/etc/bind/named.conf.local"; include "/etc/bind/named.conf.default-zones"; // fin del archivo /etc/bind/named.conf Comprobemos la configuración del BIND hasta ahora y reiniciemos el servicio: named-checkconf -z service bind9 restart Modificaciones al archivo /etc/bind/named.conf.options En la primera sección “options“, sólo declararemos los Forwarders, y quienes serán los que podrán consultar nuestro BIND. Luego declaramos la Clave o key mediante la cual podemos controlar al bind9, y por último desde que host podemos controlarlo. Para conocer cual es la clave o key, debemos hacer cat /etc/bind/rndc.key. Copiamos la salida y la pegamos en el archivo named.conf.options. Al final, nuestro archivo debe quedar así: // /etc/bind/named.conf.options options { // OJO CON EL COPIAR Y PEGAR, POR FAVOR... // Directorio por defecto para ubicar nuestros archivos de Zonas 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 http://www.kb.cert.org/vuls/id/800113 // 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; // 0.0.0.0; // } // Los Forwarders. No tengo mejor traducción // Las direcciones son de servidores de ceniai.net.cu // Si NO Tiene salida a la Internet NO es necesario // declararlos, a menos que tenga una LAN más compleja // con servidores DNS que actuen como Forwarders fuera // del rango de direcciones IP de su subnet. En ese caso // debe declarar las IP(s) de esos servidores. // Las consultas a Forwarders son en Cascada. forwarders { 169.158.128.136; 169.158.128.88; }; // En una LAN bien configurada, TODAS las consultas DNS // se deben hacer al servidor local DNS de esa LAN, // NO a servidores externos a la LAN.
  10. 10. // Máxime cuando se tiene acceso a Internet, // sea Nacional o Internacional. Para eso // declaramos los Forwarders auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; // Proteger contra el spoofing allow-query { mired; }; }; // Contenido del archivo /etc/bind/rndc-key // obtenido mediante cat /etc/bind/rndc-key // Recuerden cambiarlo si regeneramos la clave key "rndc-key" { algorithm hmac-md5; secret "dlOFESXTp2wYLa86vQNU6w=="; }; // Desde cual host controlaremos y mediante cual clave controls { inet 127.0.0.1 allow { localhost; } keys { rndc-key; }; }; // fin archivo /etc/bind/named.conf.options Comprobemos la configuración del BIND hasta ahora y reiniciemos el servicio: named-checkconf -z service bind9 restart Hemos decidido incluir como // Comentarios los aspectos fundamentales que pueden servir de referencia para futuras consultas. El hecho de declarar los Forwarders, convierte a nuestro servidor BIND Local en servidor Caché manteniendo su funcionalidad de Maestro Primario. Cuando le preguntemos por un host o por un dominio externo, la respuesta -de ser positiva- la almacenará en su caché, de forma que cuando le preguntemos nuevamente por el mismo host o por el mismo dominio externo, obtengamos una rápida respuesta al no consultar nuevamente a DNSs externos. Modificaciones al archivo /etc/bind/named.conf.local En éste archivo declaramos las zonas locales de nuestro dominio. Debemos incluir las Zonas Directa e Inversa como mínimo. Recuerden que en el archivo de configuración/etc/bind/named.conf.options declaramos en cual directorio alojaremos los archivos de las Zonas mediante la directiva directory. Al final, el archivo debe quedar de la siguiente forma: // /etc/bind/named.conf.local // // Do any local configuration here // // Consider adding the 1918 zones here, if they are not used in your // organization //include "/etc/bind/zones.rfc1918"; // Los nombres de los archivos de cada zona, son a // gusto del consumidor. Escogimos amigos.cu.hosts // y 192.168.10.rev por que nos dan claridad de sus // contenidos. No hay más misterio // // Los Nombres de las Zonas NO SON ARBITRARIOS
  11. 11. // y corresponderán al nombre de nuestro dominio // y a la subnet de la LAN // Zona Principal Maestra: tipo "Directa" zone "amigos.cu" { type master; file "amigos.cu.hosts"; }; // Zona Principal Maestra: tipo "Inversa" zone "10.168.192.in-addr.arpa" { type master; file "192.168.10.rev"; }; // Fin del archivo named.conf.local Para comprobar la configuración del BIND hasta ahora: named-checkconf -z El comando anterior nos devolverá un error hasta tanto no existan los archivos de las zonas. Lo fundamental es que nos avisa de que las Zonas declaradas en named.conf.local no serán cargadas, pues los archivos de registros DNS simplemente no existen, lo cual es cierto por ahora. Podemos seguir adelante. Reiniciemos el servicio para que se tenga en cuenta los cambios: service bind9 restart Como no queremos hacer muy largo cada post, abordaremos el tema de la creación de los archivos de las Zonas Locales en la próxima 4ta parte. ¡Hasta entonces amigos!
  12. 12. DNS Maestro Primario para una LAN en Debian 6.0 (IV) Los que hayan estudiado la 1era, 2da y 3era parte de esta serie se habrán dado cuenta de que hemos tratado de seguir un orden lógico y hacia adelante de forma que no nos perdamos a la hora de instalar y configurar un BIND. Ahora abordaremos la creación de los archivos de las Zonas Locales que son los que en definitiva contienen los registros de datos de nuestro dominio. Creación del archivo de la Zona Principal Maestra del tipo “Directa” amigos.cu En named.conf.options declaramos que los archivos de las Zonas estarán en el directorio/var/cache/bind. Tomaremos como plantilla para la creación de nuestra zona el archivo/etc/bind/db.local. A nuestro gusto denominaremos el archivo amigos.cu.hosts: cp /etc/bind/db.local /var/cache/bind/amigos.cu.hosts Posteriormente editamos el archivo /var/cache/bind/amigos.cu.hosts el cual deberá quedar de la forma siguiente: ;/var/cache/bind/amigos.cu.hosts ; ; Archivo de datos del BIND para la Zona Maestra (Directa) amigos.cu ; OJO con el punto al final de cada FQDN ; OJO con dejar espacios en blanco al final de cada línea ; OJO con el Copia y Pega ; Este archivo es una base de datos ; Los comentarios Aquí se hacen después de un punto y coma (;) ; Los nombres de host pueden incluir caracteres del alfabeto inglés ; a-z, números 0-9 y el guión o "dash" "-" ; no se distinguen mayúsculas de minúsculas, aunque recomendamos ; el uso de minúsculas todo el tiempo ; $TTL 1W @ IN SOA amigos.cu. root.amigos.cu. ( 2 ; Serial 1W ; Refresh 1D ; Retry 4W ; Expire 1W ) ; Negative Cache TTL ; @ IN NS ns.amigos.cu. @ IN MX 10 mail.amigos.cu. @ IN TXT "Amigos Cubanos. Su Red de Referencia" ns IN A 192.168.10.10 gandalf IN A 192.168.10.1 fedex IN A 192.168.10.100 mail IN A 192.168.10.9 web IN A 192.168.10.20 www IN CNAME web.amigos.cu. Una explicación detallada de cada registro la puede encontrar en la documentación del paquete bind9-doc o en la Wiki del Grupo Usuarios Tecnologías Libres. Nosotros explicaremos los registros siguientes: $TTL 1W: Time To Live o tiempo de vida de la información. 1 semana. @ IN SOA: Start of Authority o comienzo de la autoridad del dominio amigos.cu. y el administrador del dominio root.amigos.cu. 2 ; Serial: número de serie de la zona el cual se debe incrementar cada vez que la modifiquemos. Si hacemos varios cambios en una misma ocasión, podemos incrementarlo una sola vez antes de reiniciar el BIND o recargar la zona mediante el comando rndc reload.
  13. 13. @ IN NS: nuestro BIND está en el host ns.amigos.cu. y es OBLIGATORIO que este host tenga un registro tipo A que lo identifique de forma unívoca. @ IN MX: el correo del dominio lo maneja el host mail.amigos.cu. con la prioridad más alta la cual corresponde al número más bajo @ IN TXT: Comentario aclaratorio www IN CNAME: alias www.amigos.cu. al host web.amigos.cu. ns IN A 192.168.10.10: al host ns.amigos.cu. le corresponde la dirección IP 192.168.10.10. Respetamos los valores por defecto de los tiempos de: o o o o o vida de la información refrescar la información re-intentar la conexión expiración (caducidad) de la validez de la información cache negativa o tiempo de almacenamiento de los DNS externos en la caché. Antes de reiniciar el bind9, comprobemos la sintaxis de la zona creada: named-checkzone amigos.cu /var/cache/bind/amigos.cu.hosts La respuesta al comando deberá ser: zone amigos.cu/IN: loaded serial 2 OK Reiniciemos el servicio: service bind9 restart Comprobemos: dig amigos.cu ns dig maigos.cu mx dig amigos.cu axfr dig amigos.cu txt Las respuestas en cada caso deben ser las correctas. # dig amigos.cu ns ---;; ANSWER SECTION: amigos.cu. 604800 IN NS ns.amigos.cu. 604800 IN MX 10 mail.amigos.cu. mail.amigos.cu. 604800 IN A 192.168.10.9 ns.amigos.cu. 604800 IN A 192.168.10.10 ---# dig amigos.cu mx ---;; ANSWER SECTION: amigos.cu. ------;; ADDITIONAL SECTION: ---# dig amigos.cu axfr ; <<>> DiG 9.7.2-P3 <<>> amigos.cu axfr ;; global options: +cmd amigos.cu. 604800 IN SOA amigos.cu. root.amigos.cu. 2 604800 86400 2419200 604800 amigos.cu. 604800 IN NS ns.amigos.cu. amigos.cu. 604800 IN MX 10 mail.amigos.cu. amigos.cu. 604800 IN TXT "Amigos Cubanos. Su Red de Referencia" fedex.amigos.cu. 604800 IN A 192.168.1.100 gandalf.amigos.cu. 604800 IN A 192.168.10.1
  14. 14. mail.amigos.cu. 604800 IN A 192.168.10.9 ns.amigos.cu. 604800 IN A 192.168.10.10 web.amigos.cu. 604800 IN A 192.168.10.20 www.amigos.cu. 604800 IN CNAME web.amigos.cu. IN SOA amigos.cu. root.amigos.cu. 2 604800 86400 2419200 604800 TXT "Amigos Cubanos. Su Red de Referencia" amigos.cu. 604800 ;; Query time: 0 msec ;; SERVER: 192.168.10.10#53(192.168.10.10) ;; WHEN: Fri Jan 4 16:46:01 2013 ;; XFR size: 11 records (messages 1, bytes 307) # dig amigos.cu txt ---;; ANSWER SECTION: amigos.cu. 604800 IN ---- Observen en las salidas anteriores como responde a nuestra consulta en la sección “ANSWER SECTION:”. Además, nos dice que la Autoridad, como se indica en el registro SOA (AUTHORITY SECCTION:) y que responde a la consulta hecha al dominio amigos.cu., la tiene el host ns.amigos.cu., tal y como lo declaramos en el archivo de la zona amigos.cu.hosts Cuando hagamos cambios en las Zona Directa y/o en la Inversa, no será necesario reiniciar el servidor. Sólo necesitaremos aumentar el número de serie “Serial” en uno, y recargar las zonas mediante el comando rndc reload. Ahhh, ¿Cómo se crea y mantiene una Zona Inversa? Lo veremos en el 5to y último capítulo. Hasta entonces, amigos!
  15. 15. DNS Maestro Primario para una LAN en Debian 6.0 (V) y final Los que siguieron la 1era, 2da, 3era y 4ta parte de éste artículo y las consultas hechas a su BIND devolvieron resultados satisfactorios, ya son expertos en el tema.:-) Y sin más dilación entremos en la última parte: Creación del archivo de la Zona Principal Maestra del tipo “Inversa” 10.168.192.in-addr.arpa Solución de problemas Resumen Creación del archivo de la Zona Principal Maestra del tipo “Inversa” 10.168.192.in-addr.arpa El nombre de la zona se las trae, ¿no?. Y es que las Zonas Inversas son obligatorias para tener una resolución de nombres correcta acorde a las normas de Internet. No nos queda más remedio que crear la correspondiente a nuestro dominio. Para ello usamos como plantilla el archivo /etc/bind/db.127: cp /etc/bind/db.127 /var/cache/bind/192.168.10.rev Editamos el archivo /var/cache/bind/192.168.10.rev y lo dejamos así: ; /var/cache/bind/192.168.10.rev ; ; BIND reverse data file for master zone 10.168.192.in-addr.arpa ; Archivos de datos del BIND para la Zona Maestra (Inversa) 10.168.192.in-addr.arpa ; $TTL 604800 @ IN SOA ns.amigos.cu. root.amigos.cu. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 604800 ) ; Expire ; Negative Cache TTL ; @ IN NS ns. 10 IN PTR ns.amigos.cu. 1 IN PTR gandalf.amigos.cu. 9 IN PTR mail.amigos.cu. 20 IN PTR web.amigos.cu. 100 IN PTR fedex.amigos.cu. ; podemos escribir también la dirección IP completa. Ej: ; 192.168.10.1 IN PTR gandalf.amigos.cu. Observen como en éste caso hemos dejado los tiempos en segundos tal y como se crea por defecto cuando se instala el bind9. Funciona igual. Son los mismos tiempos que los indicados en el archivo amigos.cu.host. Ante la duda, compruebe. Observen además que sólo declaramos los registros inversos de los hosts que tienen una IP asignada o “real” en nuestra LAN, y que la identifica de forma unívoca. Recuerden actualizar el archivo de la Zona Inversa con TODAS las direcciones IP correctas declaradas en la Zona Directa.
  16. 16. Recuerden incrementar el Número de Serie de la Zona cada vez que modifiquen el archivo y antes de reiniciar el BIND. Comprobemos la zona recién creada: named-checkzone 10.168.192.in-addr.arpa /var/cache/bind/192.168.10.rev Comprobamos la configuración: named-checkconf -z named-checkconf -p Si todo salió OK, reiniciamos el servicio: service bind9 restart En lo adelante, cada vez que modifiquemos los archivos de las zonas, sólo debemos ejecutar: rndc reload Para eso declaramos la clave en /etc/bind/named.conf.options, ¿no? Solución de problemas Muy importante es el correcto contenido del archivo /etc/resolv.conf como ya vimos en capítulo anterior. Recuerden indicar en él al menos lo siguiente: search amigos.cu nameserver 192.168.10.20 Comando dig del paquete dnsutils. En una consola, teclee los comandos precedidos por #: # dig -x 127.0.0.1 ..... ;; ANSWER SECTION: 1.0.0.127.in-addr.arpa. 604800 IN PTR localhost. .... # dig -x 192.168.10.9 .... ;; ANSWER SECTION: 9.10.168.192.in-addr.arpa. 604800 IN PTR mail.amigos.cu. .... # host gandalf gandalf.amigos.cu has address 192.168.10.1 # host gandalf.amigos.cu gandalf.amigos.cu has address 192.168.10.1 # dig gandalf ; <<>> DiG 9.7.2-P3 <<>> gandalf ;; global options: +cmd ;; connection timed out; no servers could be reached # dig gandalf.amigos.cu .... ;; ANSWER SECTION: gandalf.amigos.cu. .... 604800 IN A 192.168.10.1
  17. 17. Sí tienen salida a la Internet Cubana o Global, y los Forwarders están correctamente declarados prueben: # dig debian.org .... ;; QUESTION SECTION: ;debian.org. IN A ;; ANSWER SECTION: debian.org. 3600 IN A 86.59.118.148 debian.org. 3600 IN A 128.31.0.51 .... # host bohemia.cu bohemia.cu has address 190.6.81.130 # host yahoo.es yahoo.es has address 77.238.178.122 yahoo.es has address 87.248.120.148 yahoo.es mail is handled by 10 mx-eu.mail.am0.yahoodns.net. # dig -x 77.238.178.122 ;; ANSWER SECTION: 122.178.238.77.in-addr.arpa. 429 IN PTR w2.rc.vip.ird.yahoo.com. …y en general con otros dominios externos a nuestra LAN. Consulte y entérese de cosas interesantes de Internet. Una de las mejores formas de comprobar el funcionamiento de un servidor bind9, y en general de cualquier otro servicio instalado, es leyendo la salida de los Mensajes del Registro del Sistema mediante el comando tail -f /var/log/syslog ejecutado como el usuarioroot. Es muy interesante ver la salida de ese comando cuando le hacemos una pregunta a nuestro BIND local sobre un dominio o host externo. En ese caso se nos puede presentar varios escenarios: Sino tenemos acceso a Internet nuestra consulta será fallida. Si tenemos acceso a Internet y NO tenemos declarados Forwarders, lo más probable es que no obtengamos una respuesta. Si tenemos acceso a Internet y tenemos declarados los Forwarders, obtendremos una respuesta ya que ellos se encargarán de consultar al o a los servidores DNS que sean necesarios. Si estamos trabajando en una LAN Cerrada en la cual es imposible de cualquier forma salir al exterior y no tenemos Forwarders de ningún tipo, podemos eliminar los mensajes de búsqueda de los Servidores Raíces “vaciando” el archivo /etc/bind/db.root. Para ello primero guardamos el archivo con otro nombre y luego borramos todo su contenido. Luego comprobamos la configuración y reiniciamos el servicio: cp /etc/bind/db.root /etc/bind/db.root.original cp /dev/null /etc/bind/db.root named-checkconf -z named-checkconf -p service bind9 restart Resumen Hasta aquí, colegas, una pequeña introducción al servicio DNS. Lo que hemos hecho hasta ahora nos puede servir perfectamente para nuestra pequeña empresa. También para la casa si creamos máquinas virtuales con diferentes sistemas operativos y diferentes direcciones IP, y no queremos referirnos a ellas por la IP sino por su nombre. Siempre instalo un BIND en el host de mi casa para instalar, configurar y probar servicios que dependen fuertemente del servicio
  18. 18. DNS. Hago uso extensivo de Desktops y Servidores virtuales, y no me gusta mantener un archivo /etc/hosts en cada una de las máquinas. Me equivoco demasiado. Si nunca han instalado y configurado un BIND, por favor, no de desanime si al primer intento le sale algo mal y tenga que empezar desde cero nuevamente. Recomendamos siempre en éstos casos partir de una instalación limpia. ¡Vale la pena intentarlo! Para aquellos que necesiten de una alta disponibilidad en el servicio de resolución de nombres, la cual se puede lograr mediante la configuración de un servidor Maestro Secundario, recomendamos continúen con nosotros en la próxima aventura: DNS Maestro Secundario para una LAN.

×