UNIVERSIDAD POLITÉCNICA DE PACHUCA SERVIDOR DNS

Transcripción

1 SERVIDOR DNS Un servidor DNS (Domain Name System) se utiliza para proveer a las computadoras de los usuarios (clientes) un nombre equivalente a las direcciones IP. El uso de este servidor es transparente para los usuarios cuando éste está bien configurado. Cada LAN (Red de área local) debería contar con un servidor DNS. Estos servidores trabajan de forma jerárquica para intercambiar información y obtener las direcciones IP de otras LANs. NIC (Network Information Center) es el organismo encargado de administrar el DNS a nivel mundial. NIC México se encarga de administrar todos los nombres (dominios) que terminen con la extensión mx. En la rectoría del sistema se encargan de administrar los nombres que terminen con itesm.mx. El Campus Ciudad de México cuenta con un Servidor DNS primario y un Servidor DNS secundario, los cuales mantienen las tablas de los nombres que terminen con ccm.itesm.mx. Normalmente la IP no cambia cada día, si entras 100 veces en un sitio para qué preguntarle al servidor cada vez por la IP?, un cache evita eso: guarda un listado de las peticiones para no tener que estar preguntando cada vez. La latencia causada por preguntar al servidor DNS por cada sitio desaparece si ya se tiene el dato en local. Historia del DNS En la década de los 70, la red Arpanet, antecesora de Internet, estaba formada por un número pequeño de servidores. En un sencillo archivo HOST.TXT figuraban los pocos centenares de servidores que la componían. Para realizar cambios en este fichero, los administradores de los diferentes servidores enviaban las modificaciones por correo electrónico y recibían el nuevo fichero HOST.TXT actualizado por FTP. El organismo encargado de mantener el fichero era SRINIC. Con el crecimiento de Arpanet la capacidad de NIC para mantener el fichero original se vió desbordada. Además apareció el problema de servidores con nombre duplicado. En 1984 se creó el sistema de nombres de dominio DNS (Domain Name System), documentado en las RFC 882 y 883. En caso de que el servidor DNS se caiga, se puede seguir entrando en los sitios que anteriormente ya se había entrado. El sistema DNS El sistema DNS es en esencia una base de datos distribuida. Esta base de datos es jerárquica, al estilo de como lo son los sistemas de ficheros de UNIX. La raíz de la base de datos está representada por el nodo "." y cada uno de los nodos que descienden de ella reciben el nombre de dominios. En el sistema DNS cada dominio se hace cargo de la base de datos que depende de él. MFGP Página 1

2 En cada dominio puede haber a su vez servidores y otros dominios. Cada nombre de dominio se construye escribiendo los sucesivos nombres de dominio a los que pertenece el dominio hasta llegar al dominio raíz. Cada nombre se separa del siguiente mediante un punto y se escriben colocando a la izquierda los nodos inferiores. Por ejemplo el departamento imasd de la compañía acme, que operase en España recibiría el nombre: imasd.acme.es El punto raíz no se pone. A un nombre de dominio que incluye todos los nodos hasta el raíz se le denomina nombre de dominio completamente cualificado (FQDN Full Cuallified Domain Name). En Internet por debajo del raíz los primeros nodos corresponden normalmente a países u organizaciones internacionales. Cada país tiene su propio dominio, y además existen otros para otro tipo de organizaciones. En el caso de Estados Unidos, la mayoría de los dominios pertenecen por razones históricas a los dominios edu, com, mil y gov. Otros dominios que dependen del raíz son: int para organizaciones internacionales, como la OTAN (nato.int) org para organizaciones no gubernamentales net para otras redes que se han unido a Internet arpa para la transición de Arpanet a Internet También están incluídos los diferentes países, identificados por el código de dos letras ISO3166, salvo Gran Bretaña, que usa uk. Dentro de cada dominio hay una organización que decide la estructura de dominios. Por ejemplo en España es EsNIC, dependiente de RedIRIS (red de investigación Española). DNSMASQ, SERVIDOR DNS Y DHCP (LINUX) Dnsmasq es un servidor (DNS, DHCP) muy ligero que tiene un efecto colateral además de funcionar como servidor DNS para tu red local (gracias a que lee el archivo /etc/hosts) y poder resolver los nombres asignados a tus equipos, también hace de servidor DNS caché, es decir almacena las IPs consultadas para no tener que repetir la consulta cuando vuelven a pedirse. El resultado es que el acceso a las páginas de Internet es más rápido. Como sabemos, antes de visualizar su contenido, debe resolverse el nombre del equipo al que le enviamos la petición a través de una compleja red de servidores, que se inicia en el (o los) que hemos definido en /etc/resolv.conf Nuestro(s) servidor(es) suelen ser dos IPs de nuestro suministrador de acceso a Internet. Con dnsmasq conseguimos reducir el proceso de consulta. Puedes confirmar la mejora en la velocidad con que se resuelven los nombres mediante el comando dig. Antes de instalar, configurar y activar dnsmasq ejecuta: $ dig google.es, y anota el valor que aparece al final de la respuesta al lado de QUERY TIME. MFGP Página 2

3 Luego sigue los pasos para instalarlo: 1. Instalar dnsmasq $ sudo apt-get install dnsmasq Si la consola te dice que "no se ha podido encontrar el paquete dnsmasq" probablemente se deba a que no has activado el repositorio Universe. 2. Editar $ sudo gedit /etc/dnsmasq.conf y descomentar la siguiente línea #listen-address= luego modificarla para que quede como la siguiente listen-address= Editar $ sudo gedit /etc/dhcp3/dhclient.conf Debes asegurarte de que el contenido del archivo sea exactamente el siguiente, especialmente en la línea prepend domain-name-servers ya que debe de estar descomentada (sin el símbolo # al principio de la frase) #supersede domain-name "fugue.com home.vix.com" prepend domain-name-servers request subnet-mask, broadcast-address, time-offset, routers, 4. Editar domain-name, domain-name-servers, host-name, netbios-name-servers, netbios-scope $ sudo gedit /etc/resolv.conf Se debe poner como primer servidor el local, de forma que quede más o menos así: search tuisp (mundo-r.com, telefonica, yahoo, etc...) (Esta linea NO se debe tocar) nameserver nameserver xxx.xxx.xxx.xxx nameserver xxx.xxx.xxx.xxx MFGP Página 3

4 Los xxx.xxx.xxx.xxx se refieren a unas IPs específicas para cada conexión, pero como no tienes que modificarlas no te preocupes ni las toques. 4. Arrancar de nuevo el demonio introduciendo la siguiente línea en una terminal: $ sudo /etc/init.d/dnsmasq restart Una vez concluida la instalación y configuración puedes continuar con el experimento de comprobar la mejora de velocidad, para ello repite el comando $ dig google.es cuando funcione el dnsmasq el valor numérico de QUERY TIME tendría que ser casi 10 veces menor. Servidor DHCP Normalmente el servidor DHCP irá en el firewall, y sólo deberíamos atender las peticiones DHCP desde dentro de la red local. Si el interfaz de red conectado a la LAN es eth1, deberemos descomentar la línea: #interface= Y modificarla así: interface=eth1 Ahora activaremos el servidor DHCP integrado descomentando la línea: #dhcp-range= , ,12h Y modificándola para adaptarla al rando de IP que queramos servir: dhcp-range= , ,12h Así, las IPs que asignará el servidor irán desde la hasta la estableciendo el tiempo de asignación de la IP a 12 horas, después de las cuales esa IP puede asignarse a otro equipo si no lo reclama antes. Las direcciones IP que va asignando las registra en el fichero /var/lib/misc/dnsmasq.leases. Añadir Nombres de Dominio Una vez funcionando el servidor DNS, edita el archivo host: $ nano /etc/host Aquí se deben colocar todas las direcciones ip con sus respestivos nombres de dominio, con el objetivo de que en lo posterior solo escribas dicho nombre, en lugar de la ip. MFGP Página 4

5 BIND 9 BIND (Berkeley Internet Name Domain, anteriormente: Berkeley Internet Name Daemon) es el servidor de DNS más comúnmente usado en Internet, especialmente en sistemas Unix, en los cuales es un Estándar de facto. Es patrocinado por la Internet Systems Consortium. BIND fue creado originalmente por cuatro estudiantes de grado en la University of California, Berkeley y liberado por primera vez en el 4.3BSD. Paul Vixie comenzó a mantenerlo en 1988 mientras trabajaba para la DEC. Una nueva versión de BIND (BIND 9) fue escrita desde cero en parte para superar las dificultades arquitectónicas presentes anteriormente para auditar el código en las primeras versiones de BIND, y también para incorporar DNSSEC (DNS Security Extensions). BIND 9 incluye entre otras características importantes: TSIG, notificación DNS, nsupdate, IPv6, rndc flush, vistas, procesamiento en paralelo, y una arquitectura mejorada en cuanto a portabilidad. Es comúnmente usado en sistemas GNU/Linux. BIND fue escrito originalmente a principios de los 80 bajo el patrocinio de la DARPA. A mediados de los 80, el desarrollo del BIND quedó a cargo de empleados de DEC. Uno de estos empleados era Paul Vixie, quien continuó trabajando en BIND luego de desvincularse de DEC. Más adelante ayudaría a fundar la ISC, la cual se convirtió en la organización 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, y las funcionalidades relativas a DNSSEC fueron impulsadas por el ejército de Estados Unidos quien sintió que la seguridad en DNS era importante. Como otras herramientas que estuvieron presentes desde los primeros días de Internet, BIND 4 y BIND 8 han tenido un número grande de vulnerabilidades de seguridad a través del tiempo. BIND 9, habiéndose reescrito, tiene un historial mucho mejor en cuanto a este tema. Los nombres de dominio completamente calificados o FQDN (fully qualified domain name) se componen por lo general del nombre del host, un nombre de dominio secundario y un nombre de dominio primario o de nivel máximo (top-level domain), que son secciones organizadas jerárquicamente. Por ejemplo: Leyéndolo de derecha a izquierda tenemos un dominio primario ( COM ), un dominio secundario ( EJEMPLO ) y el nombre del host ( WWW ). Algunos dominios primarios son: org - Organizaciones no lucrativas. com - Organizaciones lucrativas. net - Organizaciones en Internet. gob - Agencias gubernamentales en latinoamérica. MFGP Página 5

6 mx - Sufijo de México. es - Sufijo de España. Existen cuatro tipos diferentes de servidores de resolución de nombres: Master (maestro o primario). Aloja los registros autoritarios de una zona, responde las peticiones de resolución de nombres como servidor de autoridad y delega copias a los servidores esclavo. Slave (esclavo o secundario). Responde a las peticiones de resolución de nombres como servidor de autoridad, pero la información es distribuida por los servidores primarios. Se considera que como medida de seguridad, se requiere al menos uno de estos, preferentemente independiente de la infraestructura del primario (red, energia eléctrica y ubicación geográfica). Caching-only (sólo de cache). Responde a las peticiones de resolución de nombres pero no es servidor de autoridad, las respuestas las guarda en memoria por un período determinado. Forwarding (de reenvío). Reenvia las peticiones a una lista de servidores de nombres. Tipos de registros Para ofrecer suficiente flexibilidad en la configuración, se pueden declarar diversos tipos de registros, que hacen referencia a la función del host. A continuación veremos los más importantes. A (Address). Es el registro más usado, que define una dirección IP y el nombre asignado al host. Generalmente existen varios en un dominio. MX (Mail exchanger). Se usa para identificar servidores de correo, se pueden definir dos o más servidores de correo para un dominio, siendo que el orden implica su prioridad. Debe haber al menos uno para un dominio. CNAME (Canonical Name). Es un alias que se asigna a un host que tiene una dirección IP valida y que responde a diversos nombres. Pueden declararse varios para un host. NS (Name Server). Define los servidores de nombre principales de un dominio. Debe haber al menos uno y pueden declararse varios para un dominio. SOA (Start Of Authority). Este es el primer registro de la zona y sólo puede haber uno en cada archivo de la zona y sólo está presente si el servidor es autoritario del dominio. Especifica el servidor DNS primario del dominio, la cuenta de correo del administrador y tiempo de refresco de los servidores secundarios. MFGP Página 6

7 Configuración Veamos como configurar BIND9 para disponer de un servidor DNS en una intranet, que resuelva dominios internos. Por ejemplo, en la intranet se utilizaran dominios que terminen en marblestation.homeip.net como saturno.marblestation.homeip.net o luna.marblestation.homeip.net. El servidor DNS se encargará de resolver esos dominios en sus respectivas IPs, además de resolver otros dominios de Internet como google.com. Instalamos BIND9 y nos desplazamos a su directorio de configuración: aptitude install bind9 cd /etc/bind/ Editamos named.conf.local y añadimos la zona marblestation.homeip.net, haciendo referencia a su fichero de configuración: zone "marblestation.homeip.net" { } type master file "/etc/bind/db.marblestation" Creamos el fichero de configuración db.marblestation a partir de db.local : cp db.local db.marblestation Editamos db.marblestation, reemplazamos la palabra localhost por marblestation.homeip.net, cambiamos la IP por la que queramos asignar al dominio y añadimos al final del fichero todos los A, MX y CNAME que queramos, quedando: BIND data file for local loopback interface $TTL IN SOA marblestation.homeip.net. root.marblestation.homeip.net. ( 1 Serial Refresh Retry Expire MFGP Página 7

8 ) Negative Cache IN NS IN A IN MX 0 marblestation.homeip.net. www IN A saturno IN CNAME marblestation.homeip.net. En este ejemplo vemos primeramente el dominio a resolver, marblestation.homeip.net. y el segundo es la cuenta de correo del administrador, root.marblestation.homeip.net. (sustituyéndo el primer punto por arroba, lo que dejaría root@marblestation.homeip.net ). Debemos notar que al final de cada dominio viene un punto, que identifica la raíz de este. El resto de los parámetros son: Serial: es un identificador del archivo, puede tener un valor arbitrario pero se recomienda que tenga la fecha con una estructura AAAA-MM-DD y un consecutivo. Refresco: número de segundos que un servidor de nombres secundario debe esperar para comprobar de nuevo los valores de un registro. Reintentos: 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. Expiración: número de segundos máximo que los servidores de nombre secundarios retendrán los valores antes de expirarlos. TTL mínimo: 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. A continuación se definen los registros necesarios, cuyos tipos ya han sido explicados anteriormente en este documento. Cada vez que se cambia la configuración de BIND9, debemos reiniciar el demonio: /etc/init.d/bind9 restart Para que nuestra máquina utilice el servidor de DNS que hemos configurado, debemos editar /etc/resolv.conf y dejamos únicamente la línea: nameserver MFGP Página 8

9 Se debería hacer lo mismo con el resto de máquinas de la intranet que vayan a utilizar el servidor, con la única diferencia que habrá que substituir la IP por la IP que tenga el servidor en la red. Para comprobar el correcto funcionamiento, utilizamos el comando host el cual sirve para resolver dominios: $ host marblestation.homeip.net marblestation.homeip.net has address marblestation.homeip.net mail is handled by 0 marblestation.homeip.net. $ host saturno.marblestation.homeip.net saturno.marblestation.homeip.net is an alias for marblestation.homeip.net. marblestation.homeip.net has address saturno.marblestation.homeip.net is an alias for marblestation.homeip.net. saturno.marblestation.homeip.net is an alias for marblestation.homeip.net. marblestation.homeip.net mail is handled by 0 marblestation.homeip.net. Si deseamos también disponer de resolución de dominios inversa, es decir, que podamos preguntar por la IP y el servidor DNS nos diga que pertenece a marblestation.homeip.net, debemos añadir a /etc/bind/named.conf.local : zone "192.in-addr.arpa" { } type master file "/etc/bind/db.192" Creamos el archivo de configuración /etc/bind/db.192 a partir del /etc/bind/db.127 : cd /etc/bind/ cp db.127 db.192 Editamos /etc/bind/db.192, substituimos localhost por marblestation.homeip.net y cambiamos la última línea: BIND reverse data file for local loopback interface MFGP Página 9

10 $TTL IN SOA marblestation.homeip.net. root.marblestation.homeip.net. ( 1 Serial Refresh Retry Expire ) Negative Cache IN NS marblestation.homeip.net IN PTR marblestation.homeip.net. De forma que, la última linea indica que la IP [192.] (escrita a la inversa y omitiendo el 192 que ya se especifico en named.conf.local ) corresponde al dominio marblestation.homeip.net. Podemos comprobar su funcionamiento reiniciando el demonio BIND9 y realizando una consulta: $ /etc/init.d/bind9 restart $ host in-addr.arpa domain name pointer marblestation.homeip.net. MFGP Página 10