Source: http://docplayer.es/7941369-Practica-2-puesta-en-marcha-de-un-servidor-dns-arquitectura-de-sistemas-y-aplicaciones-distribuidas-u-l-p-g-c.html
Timestamp: 2018-06-19 21:09:50+00:00

Document:
Práctica 2: Puesta en marcha de un servidor DNS Arquitectura de Sistemas y Aplicaciones Distribuidas U.L.P.G.C. - PDF
Download "Práctica 2: Puesta en marcha de un servidor DNS Arquitectura de Sistemas y Aplicaciones Distribuidas U.L.P.G.C."
Mario Flores Cabrera
1 Práctica 2: Puesta en marcha de un servidor DNS David Jesús Horat Flotats
2 Índice I. Introducción al protocolo DNS... 2 Funcionamiento... 3 II.Configuración de dominios sin DNS... 5 /etc/hosts... 5 /etc/host.conf...5 /etc/nsswitch.conf... 6 III.Obtención e Instalación del demonio BIND... 7 IV.Configuración y puesta en marcha de un servicio DNS para el dominio...8 Servidor DNS Primario...9 Servidor DNS Secundario dentro del mismo dominio Pruebas Realizadas Servidor DNS Primario...26 Servidor DNS Secundario del mismo dominio Servidor DNS Secuandario de otro dominio externo...34 V.Uso del servidor DNS desde un cliente Windows
3 Introducción al protocolo DNS Un DNS (Domain Name System) es un conjunto de protocolos y servicios (base de datos distribuida) que permiten a los usuarios utilizar nombres en vez de tener que recordar direcciones IP numéricas. Ésta es ciertamente la función más conocida de los protocolos DNS: la asignación de nombres a direcciones IP. Por ejemplo, si la dirección IP del sitio FTP de redes.es es , la mayoría de la gente llega a este equipo especificando redes.es 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 los DNS nacieron de la necesidad de recordar fácilmente los sitios visitados o a visitar y sustituir el antiguo sistema de identificanción de "host" en internet que consistía en un gran archivo donde estaban almacenados los nombres y las direcciones ips de cada nodo de la red con el cual se podía establecer comunicación. El funcionamiento del DNS lo exponemos en la Ilustración 1: 1. Quién es redes.es? 2. redes.es es Cliente Servidor DNS 3. Dame tu web Servidor WEB Ilustración 1: Funcionamiento del DNS 2
4 Los servidores de nombres se dividen en cuatro tipos: 1. El servidor primario, que contiene toda la información acerca de un dominio. 2. El servidor secundario, que copia la base de datos del primer servidor. 3. El servidor de sólo caché, que construye una base de datos de DNS exclusivamente para las peticiones a la caché. 4. El servidor silencioso o, que actúa con un servidor normal de tipo primario, pero sin declararse. La base de datos del DNS tiene una estructura jerárquica. En la cima de la jerarquía está el dominio raíz, etiquetado por el nulo. La información en este dominio reside en un número muy selecto de servidores raíz repartidos por toda Internet. Por debajo del dominio raíz están los dominios de primer nivel (que viene de las siglas TLD, que significan Top-Level Domains), que pueden ser tanto códigos de países como códigos de organizaciones o empresas. A continuación, y por debajo de los dominios de primer nivel, están los dominios de segundo nivel y luego los de tercer nivel, cuarto, etc... El nombre de un dominio no es más que un conjunto de etiquetas separadas por puntos que identifica un camino desde la raíz en orden inverso. Cada dominio puede ser administrado por una organización diferente, pudiendo contener hosts y subdominios. Cada organizador puede crear subdominios y repartir responsabilidad de cada uno de sus subdominios en organizaciones diferentes. Los datos asociados a los nombres de dominio se encuentran en los registros de recursos (RR), los cuales deben contar con cinco partes: nombre de dominio, tiempo de vida, tipo, clase y valor. Funcionamiento DNS utiliza un modelo cliente/servidor en el cual los servidores DNS (servidores de nombres) contienen información acerca de la base de datos DNS y la ponen a disposición de los clientes. Cuando un servidor de DNS recibe una petición por parte de un cliente sobre un host que aún no tiene en su caché, lo que hace es preguntar a alguien que lo sepa. Este alguien es un servidor autoritario, un servidor responsable de mantener la información de DNS. Un servidor es autoritario si, cuando se le pregunta acerca de una dirección de su dominio, puede certificar con seguridad que el nombre existe. Si el servidor contactado no contiene información para ese nombre de dominio pasa la 3
5 información al servidor autoritario superior en la cadena, formando una serie de preguntas que siguen hasta que la información se encuentra. En la práctica, esto significa que la petición puede ser manejada por un cierto número de servidores y las peticiones suceden a lo largo de todo el día, todos los días en la cambiante Internet. El servidor que originalmente hizo la petición almacenará la información en su caché para satisfacer futuras peticiones sin necesidad de ir a un servidor autoritario. Esta información es configurada por el administrador del servidor DNS para que caduque después de un determinado período de tiempo, para evitar el problema de tener datos antiguos o no válidos. La traducción en DNS no toma demasiado tiempo, pero se añade al tiempo que tarda nuestra petición en llegar al equipo remoto. Los servidores de nombres DNS resuelven los nombres interpretando la información de la red para encontrar una dirección IP específica. Por ejemplo, el proceso de resolución de pude resumirse en los siguientes pasos: 1. El cliente pasa una pregunta a su servidor de nombres local. 2. El servidor local de nombres envía una solicitud iterativa a uno de los servidores raíz de DNS, pidiéndole que resuelva el nombre de dominio. El servidor raíz devuelve una referencia de los servidores de nombres encargados del dominio DNS es. 3. El servidor local de nombres envía una solicitud iterativa a uno de los servidores especificados en el paso anterior, el cual devuelve una referencia de los servidores de nombres encargados del dominio google. 4. El servidor local de nombres envía una solicitud iterativa a uno de los servidores especificados en el punto anterior. El proceso anterior es el de una interrogación iterativa, pues los servidores DNS de alto nivel suelen responder de esta forma para que su carga de trabajo no sea elevada. En la interrogación recursiva es el propio servidor DNS el que interroga en busca de la resolución final, que es la que devuelve al cliente. Por su parte, la interrogación iterativa se lleva a cabo hasta que finalmente se responde al cliente con la resolución que éste solicita; hasta entonces recibe las direcciones IP de las máquinas con servidores DNS a las que debe interrogar para obtener la resolución que desee. En el ejemplo, el servidor de nombres del dominio google pasa la parte www del nombre DNS a su servidor local para que la resuelva y, una vez hecho esto, la dirección empieza a devolverse sobre los servidores anteriores hasta llegar al cliente. 4
6 Configuración de dominios sin DNS /etc/hosts La resolución de nombres de dominio se puede realizar modificando el fichero /etc/hosts. El formato de cada línea en dicho fichero es: [IP] [Hostname] [Alias] En nuestro caso lo hemos modificado el archivo para apuntar a: # Do not remove the following line, or various programs # that require network functionality will fail pasarela12.redes.dis.ulpgc.es pasarela12 localhost.localdomain localhost rodrigo.redes.dis.ulpgc.es rodrigo servidor.redes.dis.ulpgc.es servidor oscar.redes.dis.ulpgc.es oscar Para comprobar que los resultados son correctos, hacemos un ping a los aliases y los hosts: ~]# ping oscar PING oscar.redes.dis.ulpgc.es ( ) 56(84) bytes of data. 64 bytes from oscar.redes.dis.ulpgc.es ( ): icmp_seq=0 ttl=64 time=0.718 ms 64 bytes from oscar.redes.dis.ulpgc.es ( ): icmp_seq=1 ttl=64 time=0.107 ms --- oscar.redes.dis.ulpgc.es ping statistics packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 0.107/0.412/0.718/0.306 ms, pipe 2 ~]# ping rodrigo.redes.dis.ulpgc.es PING rodrigo.redes.dis.ulpgc.es ( ) 56(84) bytes of data. 64 bytes from rodrigo.redes.dis.ulpgc.es ( ): icmp_seq=0 ttl=64 time=1.03 ms 64 bytes from rodrigo.redes.dis.ulpgc.es ( ): icmp_seq=1 ttl=64 time=0.122 ms 64 bytes from rodrigo.redes.dis.ulpgc.es ( ): icmp_seq=2 ttl=64 time=0.125 ms --- rodrigo.redes.dis.ulpgc.es ping statistics packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.122/0.425/1.030/0.427 ms, pipe 2 /etc/host.conf En el fichero /etc/host.conf podemos configurar el orden en que se resuelven los nombres según los servicios usados. En nuestro caso, y generalmente por defecto, se usa primero el archivo 5
7 hosts mencionado anteriormente y luego los servidios DNS estándar. El contenido del fichero de nuestro ordenador es: order hosts,bind /etc/nsswitch.conf Se trata de un extenso archivo donde se especifica de dónde obtener las diferentes clases de tipos de datos, y de cuál archivo o base de datos. El fichero debería contener: hosts: files dns En nuestro caso no existe dicho fichero y no usaremos esta opción. 6
8 Obtención e Instalación del demonio BIND En principio, en el equipo que actuará como servidor DNS ya está instalado el demonio BIND, de modo que su instalación no es necesaria. 7
9 Configuración y puesta en marcha de un servicio DNS para el dominio Una vez sabemos que disponemos del demonio BIND en el equipo que va a actuar de servidor DNS el siguiente paso es configurarlo, como se explica en las siguientes líneas. Las características, según el guión de la práctica, que debe tener/cumplir el servicio DNS que prestaremos son: Un Servidor Primario del propio dominio. Al menos un Servidor Secundario del propio dominio. Al menos un Servidor Secundario de otro dominio. Los servidores del propio dominio sólo deben respoder recursivamente a máquinas del propio dominio y el servidor de otro dominio solo debe operar de forma no recursiva. El servidor primario sólo debe permitir descargas de zona de sus correspondientes secundarios. Debe minimizarse el tráfico de mantenimiento de los servidores secundarios con el primario. En la Ilustración 2 se observa la topología de servidores DNS que finalmente tendremos una vez se haya configurado y puesto en marcha el servicio DNS. Servidor Secundario del propio dominio Servidor Primario del propio dominio Servidor Secundario externo Ilustración 2: Topología de Servidores de Nombres de Dominio 8
10 Los ficheros que hemos tenido que configurar se enumeran, muestran y explican a continuación. Para ello se tratará por separado la configuración realizada en el servidor primario (ubicado en el equipo Pasarela) y la del secundario (ubicado en el equipo PC, situado en la red interna). Servidor DNS Primario El DNS primario será el que responderá de forma autoritativa para su dominio y contendrá las bases de datos de forma permanente o persistent, es decir, en ficheros. Dichos ficheros requieren inicialmente la configuración del demonio named, que se hará en el fichero /var/named/chroot/etc/named.conf. Su contenido será la declaracion de zonas. Seguidamente se muestra el fichero y a continuación se comenta cada una de las zonas declaradas y su funcionalidad. También aparecen ciertas zonas comentadas, como por ejemplo las zonas del servidor secundario externo a nuestro dominio. Se debe a que se tiene la versión con los nombres reales y la versión con los nombres que debería tener dicha máquina si siguiera el formato seguido en el Laboratorio (redx.redes.dis.ulpgc.es), que se pone comentada porque dico formato no ha sido usado. // // named.conf for Red Hat caching-nameserver // options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; //permitimos descargar solo a nuestros servidores secundarios allow-transfer { ; ; //permitimos resolución recursiva sólo a aquipos de nuestra red. //para el resto, la resolución será iterativa allow-recursion { ; ; ; /* * If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source 9
11 * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default. */ // query-source address * port 53; // // a caching only nameserver config // controls { inet allow { localhost; } keys { rndckey; zone "." IN { type hint; file "named.ca"; zone "localdomain" IN { type master; file "localdomain.zone"; allow-update { none; zone "localhost" IN { type master; file "localhost.zone"; allow-update { none; zone " in-addr.arpa" IN { type master; file "named.local"; allow-update { none; zone "redes6.redes.dis.ulpgc.es" IN { 10
12 type master; file "db.redes6"; // DNS primario zone " in-addr.arpa" IN { type master; // DNS inverso primario file "db "; zone " in-addr.arpa" IN { type master; // DNS inverso primario file "db "; /*zone "redes2.redes.dis.ulpgc.es" IN { type slave; // DNS secundario externo file "db.redes2"; masters{ ; zone " in-addr.arpa" IN { type slave; // DNS inverso secundario externo file "db "; masters{ ; */ zone "pasarela12.redes.dis.ulpgc.es" IN { type slave; // DNS secundario externo file "slaves/db.ey"; masters{ ; zone " in-addr.arpa" IN { type slave; // DNS inverso secundario externo file "slaves/db "; masters{ ; 11
13 /*zone " ip6.arpa" IN { type master; file "named.ip6.local"; allow-update { none; zone "255.in-addr.arpa" IN { type master; file "named.broadcast"; allow-update { none; zone "0.in-addr.arpa" IN { type master; file "named.zero"; allow-update { none; */ include "/etc/rndc.key"; son: Antes de la declaración de zonas nos encontramos con las opciones del demonionamed, que options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; //permitimos descargar solo a nuestros servidores secundarios allow-transfer { ; ; //permitimos resolución recursiva sólo a aquipos de nuestra red. //para el resto, la resolución será iterativa allow-recursion { ; ; ; /* * If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source 12
14 * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default. */ // query-source address * port 53; En ellas se indica el directorio en que está instalado named y desde donde colgarán los ficheros de declaración de las zonas, que es: /var/named. Adicionalmente se definen los ficheros de volcado (cache_dump.db) y de estadísticas (named_stats.txt). Seguidamente, sólo permitimos la descarga (sólo los equipos indicados podrán descargar las bases de datos o ficheros de nuestro DNS, para actuar como secundarios del nuetro, que será el primario) a nuestros servidores secundarios, que en nuestro caso son dos: el de la red interna ( ) y el externo ( ). Como se ve en la línea: allow-transfer { ; ; Por otro lado, en cuanto a las respuestas recursivas, sólo la permitimos a equipos de nuestra red, mientras que al resto de equipos se les responderá de forma iterativa. Lo hacemos declarando las direcciones IP de nuestro equipos, en realidad, la de todas sus interfaces de red que estén en la red interna. allow-recursion { ; ; ; En cuanto al puerto usado, permitimos que sea cualquiera, si bien el protocolo DNS suele usar el puerto 53. query-source address * port 53; Finalmente, se declaran las zonas: 1. Servidores raíz. Siempre existirán en cualquier DNS, para resolver iterativamente, preguntando directamente a alguno de los 13 servidores DNS raíz, que existen hoy día (a parte de las réplicas). Dicha zona ya se tiene declarada en el fichero named.ca, al instalar el bind. zone "." IN { 13
15 type hint; file "named.ca"; 2. Dominio local (la propia máquina). Se suelen usar dos zonas, la de localdomain y la de localhost, que permiten declarar a la propia máquina, lo que se conoce como el loopback. Se tendrán creadas también de forma automática, en los ficheros localdomain.zone y localhost.zone. zone "localdomain" IN { type master; file "localdomain.zone"; allow-update { none; zone "localhost" IN { type master; file "localhost.zone"; allow-update { none; 3. Resolución inversa del dominio local (la propia máquina). La IP de lap propia máquina siempre suele ser la , dentro del dominio , de forma que para la resolución inversa también se ha cread automáticamente el fichero named.local. zone " in-addr.arpa" IN { type master; file "named.local"; allow-update { none; 4. DNS primario. El DNS primario, que configuraremos en nuestra máquina se corresponderá con la zona redes6.redesdis.ulpgc.es y se tendrá en el fichero db.redes6. zone "redes6.redes.dis.ulpgc.es" IN { type master; // DNS primario file "db.redes6"; 5. Resolución inversa del DNS primario. Para la resolución inversa del dominio dispondremos de la zona de resolución 14
16 inversa in-addr.arpa (como se observa, la IP del dominio se debe poner con los bytes que la forman en orden inverso). El fichero db se dispondrá de las declaraciones de la resolución inversa para la red zone " in-addr.arpa" IN { type master; // DNS inverso primario file "db "; Adicionalmente, para la resolución inversa, se incluye la del dominio , para que resuelva dentro de dicho dominio, que es el del Laboratorio; se tendrá en el fichero db zone " in-addr.arpa" IN { type master; // DNS inverso primario file "db "; 6. DNS secundario externo. El DNS secundario externo del que haremos uso es el de la IP Para ello se declara la zona pasarela12.redes.dis.ulpgc.es, que se contendrá en el fichero slaves/db.ey. Se trata de que actuemos de servidor secundario de ellos o como esclavo (type slave) y por ello dichos ficheros se descargarán del servidor DNS primario de la IP , que tiene el nombre el nombre de dominio pasarela12.redes.dis.ulpgc.es, y contiene el fichero de declaraiones DNS llamado db.ey. zone "pasarela12.redes.dis.ulpgc.es" IN { type slave; // DNS secundario externo file "slaves/db.ey"; masters{ ; Como se observa, con la opción masters se indica que el servidor DNS primario para el que actúa de secundario, es el de la IP Resolución inversa del DNS secundario externo. Para la resolución inversa del DNS secundario se tendrá la zona in-addr.arpa, y el fichero slaves/db Actuarems con secundario o esclavo (type slave) y se indica que el primario es el con la opción masters. zone " in-addr.arpa" IN { type slave; // DNS inverso secundario externo file "slaves/db "; 15
17 masters{ ; Para que es haga uso del servidor DNS que hemos creado deberemos indicarlo en el fichero /etc/resolv.conf. search redes6.redes.dis.ulpgc.es #nameserver nameserver #nameserver #nameserver La opción nameserver activada es la de la IP , que es la de nuestro DNS. Con la opción search se indica que se use redes6.redes.dis.ulpgc.es cuando no se indiquen nombres de dominio absolutos, sino relativos (que no terminan en punto:.), de forma que se les añade este valor, entre otros. En el caso de los ficheros de declaración de zonas se usa por defecto $ORIGIN, que de no indicarse toma el nombre de la zona. Este valor se añadirá como sufijo a los nombres de dominio relativos declarados en los ficheros de cada zona. En la carpeta var/named/chroot/var/named es donde se almacenan los ficheros de las distintas zonas, así como la carpeta slaves para los ficheros copiados del servidor DNS primario para el que actuamos como DNS secundario externo. En primer lugar, tenemos las zonas del dominio local, de la propia máquina, que se tiene en los ficheros de resolución directa siguientes: localdomain.zone: $TTL IN SOA localhost root ( 42 ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum IN NS localhost localhost IN A
18 Y en localhost.zone: $TTL IN root ( 42 ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum IN IN A IN AAAA ::1 En cuanto a la resolución inversa se tiene en named.local: $TTL IN SOA localhost. root.localhost. ( ; Serial ; Refresh ; Retry ; Expire ) ; Minimum IN NS localhost. 1 IN PTR localhost. Los ficheros son tal y como se crearon automáticamente al instalar el bind, a excepción de la variable $TTL que se le da un valor para que use el mismo, que en nuestro caso fijamos a Esto también se usará en las zonas de nuestro dominio. Para la zona redes6.redes.dis.ulpgc.es tenemos el fichero db.redes6 con el siguiente contenido: // Valor recomendado de TTL (evita un warning, pues si no se pone usa el ttl mínimo) // El warning es: no TTL specified; using SOA MINTTL instead (en la línea 1) $TTL redes6.redes.dis.ulpgc.es. IN SOA davidj.redes6.redes.dis.ulpgc.es. root.redes6.redes.dis.ulpgc.es. ( ;Serial 17
19 ) ;Refresco ;reintento ;Expira ;ttl minimo IN NS davidj.redes6.redes.dis.ulpgc.es. ;DNS primario IN NS enrique.redes6.redes.dis.ulpgc.es. ;DNS secundario IN NS rodrigo.redes2.redes.dis.ulpgc.es. ;DNS secundario externo localhost IN A davidj IN A davidj IN A enrique IN A rodrigo IN A En el registro SOA se indica: NOMBRE_DOMINIO IN SOA MÁQUINA_DNS (..), de modo que tendremos el dominio redes6.redes.dis.ulpgc.es en la máquina davidj.redes6.redes.dis.ulpgc.es, que actua como DNS, y se indica el correo Dentro del registro SOA se indica el número de serie y los tiempos de refresco, reintento, exiración y el ttl (time-to-live) mínimo. Seguidamente se indcian los nombres de los servidores DNS: primario, secundario de nuestro dominio y secundario del dominio externo: IN NS davidj.redes6.redes.dis.ulpgc.es. ;DNS primario IN NS enrique.redes6.redes.dis.ulpgc.es. ;DNS secundario IN NS rodrigo.redes2.redes.dis.ulpgc.es. ;DNS secundario externo Finalmente se indica la traducció a direcciones IP, con los registros IN A, en los que aparecerán las resoluciones de los servidores DNS y el equipo local (localhost), así como otros nombres que se deseen, de nuestro dominio o no (en este caso serían glue record). localhost IN A davidj IN A
20 davidj IN A enrique IN A rodrigo IN A En el caso de la máquina davidj se tienen dos interfaces de red, una para la red externa y otra para la interna, por lo que se indican ambas. Al usar nombres relativos, se les añadirá el sufijo redes6.redes.dis.ulpgc.es, en este caso. Para la resolución inversa, en el fichero db , se tendrá: in-addr.arpa. IN SOA davidj.redes6.redes.dis.ulpgc.es. root.redes6.redes.dis.ulpgc.es. ( ;Serial ;refresco ;reintento ;expira ;ttl minimo ) IN NS davidj.redes6.redes.dis.ulpgc.es. ;DNS primario IN NS enrique.redes6.redes.dis.ulpgc.es. ;DNS secundario IN NS rodrigo.redes2.redes.dis.ulpgc.es. ;DNS secundario externo in-addr.arpa. IN PTR davidj.redes6.redes.dis.ulpgc.es in-addr.arpa. IN PTR enrique.redes6.redes.dis.ulpgc.es. Se sigue el mismo formato que para la resolució directa, pero ahora el dominio es in-addr.arpa, escrbiendo la IP del dominio en orden inverso, dentro del registro SOA. La principal diferencia es que ahora se tiene entradas IN PTR para indicar la resolución inversa de las Ips que están en el dominio, que podrían haberse puesto de forma relativa como 1 y 2. El otro fichero de resolución inversa es db , que contiene: in-addr.arpa. IN SOA davidj.redes6.redes.dis.ulpgc.es. root.redes6.redes.dis.ulpgc.es. ( ;Serial ;refresco ;reintento ;expira 19
21 86400) ;ttl minimo IN NS davidj.redes6.redes.dis.ulpgc.es. ;DNS primario IN NS enrique.redes6.redes.dis.ulpgc.es. ;DNS secundario interno IN NS rodrigo.pasarela12.redes.dis.ulpgc.es. ;DNS secundario externo in-addr.arpa. IN PTR davidj.redes6.redes.dis.ulpgc.es in-addr.arpa. IN PTR rodrigo.pasarela12.redes.dis.ulpgc.es. Sigue el mismo formato que el anterior y permite que declaremos nuestra interfaz de red que sale a la red del Laboratorio y la IP, con su nombre, para el servidor DNS primario externo para el cual actuamos de secundario, todo ello en los registros IN PTR in-addr.arpa. IN PTR davidj.redes6.redes.dis.ulpgc.es in-addr.arpa. IN PTR rodrigo.pasarela12.redes.dis.ulpgc.es. Al actuar como servidor DNS secundario externo, tendremos los ficheros de declaración de nombres del servidor primario DNS para el que actuamos de secundario (en la carpeta slaves). Estos ficheros son el de resolución directa e inversa. Para la resolución directa tenemos el fichero slaves/db.ey, que tiene: $ORIGIN. $TTL ; 1 day pasarela12.redes.dis.ulpgc.es IN SOA rodrigo.pasarela12.redes.dis.ulpgc.es. root.redes9.redes.dis.ulpgc.es. ( ; serial ; refresh (8 hours) ; retry (4 hours) ; expire (5 weeks 6 days 16 hours) ; minimum (1 day) ) NS davidj.redes6.redes.dis.ulpgc.es. NS eliezer.pasarela12.redes.dis.ulpgc.es. NS rodrigo.pasarela12.redes.dis.ulpgc.es. $ORIGIN pasarela12.redes.dis.ulpgc.es. Deivi A eliezer A localhost A
22 rodrigo A A De este modo, también podremos resolver los nombres conocidos por dicho DNS primario, en caso de que éste deje de funcionar. Para la resolución inversa tenemos el fichero slaves/db , que tiene: $ORIGIN in-addr.arpa. $TTL ; 1 day 2.1 IN PTR rodrigo.pasarela12.redes.dis.ulpgc.es. 2 SOA rodrigo.pasarela12.redes.dis.ulpgc.es. a dis.ulpgc.es. ( ; serial ; refresh (8 hours) ; retry (4 hours) ; expire (5 weeks 6 days 16 hours) ; minimum (1 day) ) NS davidj.redes6.redes.dis.ulpgc.es. NS eliezer.pasarela12.redes.dis.ulpgc.es. NS rodrigo.pasarela12.redes.dis.ulpgc.es. $ORIGIN in-addr.arpa. 1 PTR rodrigo.pasarela12.redes.dis.ulpgc.es. 34 PTR eliezer.pasarela12.redes.dis.ulpgc.es. De este modo, también podremos resolver las Ips conocidas por dicho DNS primario, en caso de que éste deje de funcionar. Para la resolución directa e inversa, el formato de los ficheros será como el que se comentó para los de nuestro servidor DNS primario. Servidor DNS Secundario dentro del mismo dominio Para el servidro DNS secundario situado en nuestro dominio, en el equipo PC, es decir, el que está dentro de la red interna, con la IP , tendremos que tener el demonio named instalado y configurado según el siguiente fichero named.conf. // // named.conf for Red Hat caching-nameserver // 21
23 options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; allow-recursion { ; ; /* * If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default. */ // query-source address * port 53; // // a caching only nameserver config // controls { inet allow { localhost; } keys { rndckey; zone "." IN { type hint; file "named.ca"; zone "localdomain" IN { type master; file "localdomain.zone"; allow-update { none; zone "localhost" IN { type master; 22
24 file "localhost.zone"; allow-update { none; zone " in-addr.arpa" IN { type master; file "named.local"; allow-update { none; zone "redes6.redes.dis.ulpgc.es"{ type slave; file "slaves/db.redes6"; masters { ; zone " in-addr.arpa"{ type slave; file "slaves/db "; masters { ; zone " ip6.arpa" IN { type master; file "named.ip6.local"; allow-update { none; zone "255.in-addr.arpa" IN { type master; file "named.broadcast"; allow-update { none; zone "0.in-addr.arpa" IN { type master; file "named.zero"; allow-update { none; 23
25 include "/etc/rndc.key"; Las opciones que se le ponen indican que el directorio y los ficheros de volcado y estadísticas son como los del DNS primario, ya comentados en su momento. Además, el servidor DNS secundario funcionará de forma recursiva (allow-recursion { ; ;) para los equipos de la red interna. options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; allow-recursion { ; ; /* * If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default. */ // query-source address * port 53; Las zonas declaradas son las siguientes: 1. Servidores raíz. Como en el DNS primario. 2. Dominio local (la propia máquina). Como en el DNS primario. 3. Resolución inversa del dominio local (la propia máquina). Como en el DNS primario. 4. DNS secundario. El DNS secundario, que configuraremos en nuestra máquina se corresponderá con la zona redes6.redesdis.ulpgc.es y se tendrá en el fichero slaves/db.redes6. Se trata de que lo descarga del 24
26 servidor DNS primario para actuar como secundario en el caso de que sea necesario. Por este motivo se declara como type slave (secundario o esclavo) y se indica que el maestro o primario es el DNS de la IP zone "redes6.redes.dis.ulpgc.es"{ type slave; file "slaves/db.redes6"; masters { ; 5. Resolución inversa del DNS secundario. Para la resolución inversa del dominio dispondremos de la zona de resolución inversa in-addr.arpa (como se observa, la IP del dominio se debe poner con los bytes que la forman en orden inverso). El fichero slaves/db se dispondrá de las declaraciones de la resolución inversa para la red , que se descargará del servidor primario, como se indicó para el caso de la resolución directa. zone " in-addr.arpa"{ type slave; file "slaves/db "; masters { ; Existen otras zonas que se crean por defecto y de forma automática, pero que no es necesario comentar y, de hecho, el servidor DNS puede funcionar sin ellas. El fichero /etc/resolv.conf deberá indicar el servidor DNS a usar, que debe ser el primario ( ) y en caso de que éste deje de funcionar, el propio bind se encargará de que se use el secundario. Si se indica que se use el servidor DNS secundario directamente siempre se usará éste, incluso aunque el primario no se haya extropeado, lo cual puede ser útil para hacer algunas pruebas. No obstante, el contenido que debe tener resolv.conf es: ; generated by /sbin/dhclient-script #nameserver #nameserver #nameserver #nameserver # Para probar el DNS secundario sólo nameserver
27 Como es conocido, tras las configuraciones, tanto para un servidor como para el otro (primario y secundario), se deben reiniciar el servicios de red (a causa de la modificación de resolv.conf) y resolución de nombres: service network restart service named restart Para probar el funcionamiento se podrá hacer uso de la herramiento nslookup, que permite la resolución directa e inversa. A modo de ejemplo, podemos usar el comando server para ver el DNS que se está usando y luego indicar el nombre para ver como es resuelto. etc]# nslookup > server Default server: Address: #53 > Server: Address: #53 Non-authoritative answer: canonical name = canonical name = Name: Address: Name: Address: En este caso se está usando el servidor DNS , es decir, se usa para probar que por sí sólo funciona. En el siguiente apartado se muestran las pruebas realizadas para observar el correcto funcionamiento de los servidores DNS. Pruebas Realizadas A continuación se enumeran y comentan las pruebas realizadas en función del servidor DNS del que se hace uso. Servidor DNS Primario 26
28 Para hacer uso y probar el DNS primario tendremos que configurar el fichero resolv.conf para que quede indicado que se hace uso del servidor DNS primario, cuya IP podrá ser tanto la como la Esto se pondrá en la opción nameserver de dicho fichero, y luego se reiniciará el servicio de red con service network restart. A continuación iniciamos una sesión con nslookup y con la opción server vemos con el servidor DNS que usaremos es el ; al hacer resoluciones directas o inversas se puede ver el mismo hecho, pues se indica el servidor y la dirección, en la que se indica también que se usa el puerto 53 en concreto, como se ve a continuación: ~]# nslookup > Server: Address: #53... Ahora realizamos pruebas de resolución directa e inversa de direcciones de nuestro dominio y del exterior, incluyendo direcciones típicas de Internet. Los casos tratados son: 1. Resolución Directa de nombres de dominios externos (en Internet). Si intentamos resolver obtenemos: > Server: Address: #53 Non-authoritative answer: canonical name = canonical name = Name: Address: Name: Address: Vemos como se obtienen las direcciones Ips correspondientes al nombre y adicionalmente se indica, en la respuesta, que la misma es no autoritativa (Non-authoritative), lo que quiere decir que se ha obtenido porque se ha obtenido por interrogación recursiva, ya que el servidor DNS primario nos lo permite porque estamos usando el nslookup desde la máquina 27
29 (o ), y la recursividad está permitida para los equipos de su red ( ). 2. Resolución Inversa de Ips externas (en Internet). Si intentamos resolver una de las dos Ips obtenidas para el nombre obtendremos el siguiente resultado para la IP : > Server: Address: #53 ** server can't find in-addr.arpa: NXDOMAIN La respuesta es negativa, indicando que no ha sido posible encontrar la resolución de la IP, es decir, el nombre que le corresponde. Esto es consecuencia de que no se realiza la resolución inversa para zonas externas. 3. Resolución Inversa de Ips externas (red del Laboratorio ). Para Ips externas, pero que no estén en Internet, sino en la red , es decir, la del Laboratorio de prácticas, ocurre lo mismo si no se declaran en el DNS primario, obteniendo la siguiente respuesta negativa para : > Server: Address: #53 ** server can't find in-addr.arpa: NXDOMAIN Para las Ips declaradas sí se obtendrá el nombre. Así, para la IP , que es nuestro equipo Pasarela (que alberga el DNS), se tiene el nombre davidj.resdes6.redes.dis.ulpgc.es, para la IP , que es la Pasarela del DNS para el cual actuamos como secundario, se tiene rodrigo.pasarela12.redes.dis.ulpgc.es, y para otros Ips que se incluyeran, se obtiene: > Server: Address: # in-addr.arpa name = davidj.redes6.redes.dis.ulpgc.es. > Server:
30 Address: # in-addr.arpa name = rodrigo.pasarela12.redes.dis.ulpgc.es. anteriormente. Se nos devuelve el nombre canónico de las mismas, que coincide con los ya indicados 4. Resolución Directa de nombres de nuestro dominio (red ). Se trata de poner los nombres recogidos en nuestro servidor DNS primario para las distintas máquinas de la red En nuestro caso se tiene el nombre enrique para la IP y el nombre davidj para las Ips y (se tienen dos Ips porque en la Pasarela se dispone de dos interfaces de red). El resultado de las interrogaciones DNS será afirmativo, obteniéndose las Ips asociadas a cada nombre: > enrique Server: Address: #53 Name: enrique.redes6.redes.dis.ulpgc.es Address: > davidj Server: Address: #53 Name: davidj.redes6.redes.dis.ulpgc.es Address: Name: davidj.redes6.redes.dis.ulpgc.es Address: Para enrique se obtiene la única IP que tiene asociada ( ), mientras que para davidj se obtiene las dos ( y ). Además, se indican los nombres canónicos junto a Name:. Se trata de los nombres completos, a los que se les añade el $ORIGIN porque estamos en la red local. Dichos nombres canónicos son enrique.redes6.redes.dis.ulpgc.es y davidj.redes6.redes.dis.ulpgc.es para enrique y davidj, respectivamente. 5. Resolución Directa de nombres del dominio externos (red del Laboratorio ). Se trata de ver como se resuelven los nombres del dominio externo, como es la red 29
31 , del Laboratorio. De este modo, podemos resolver el nombre rodrigo, pues se declaró que estaba en la máquina con IP Igualmente, se indica su nombre canónico: rodrigo.redes6.redes.dis.ulpgc.es. > rodrigo Server: Address: #53 Name: rodrigo.redes6.redes.dis.ulpgc.es Address: Resolución Inversa de Ips del dominio externo del DNS para el que actuamos de secundario. Se trata de obtener los nombres para las Ips de la red , que es la del DNS para el que actuamos de secundario externo. Sus Ips son la a la que se asocia el nombre canónico rodrigo.pasarela12.redes.dis.ulpgc.es y la a la que se le asocia el nombre canónico eliezer.pasarela12.redes.dis.ulpgc.es. Adicionalmente se prueba la resolución de la IP , que no existe y no tiene asociado ningún registro de resolución DNS, por lo que la respuesta es negativa. > Server: Address: # in-addr.arpa name = rodrigo.pasarela12.redes.dis.ulpgc.es. > Server: Address: #53 ** server can't find in-addr.arpa: NXDOMAIN > Server: Address: # in-addr.arpa name = eliezer.pasarela12.redes.dis.ulpgc.es. Servidor DNS Secundario del mismo dominio Para hacer uso y probar el DNS secundario del mismo dominio tendremos que configurar el 30
32 fichero resolv.conf para que quede indicado que se hace uso del mismo, cuya IP será la ; se trata de probarlo por separado, pues en realidad entraría en funcionamiento cuando el DNS primario dejase de funcionar. Esto se pondrá en la opción nameserver de dicho fichero, y luego se reiniciará el servicio de red con service network restart. Ahora mostramos como puede verse con la opción server al entrar en el nslookup: > server Default server: Address: #53 Abriendo una sesión de nslookup procedemos con las siguientes pruebas: 1. Resolución Directa de nombres externos (Internet). Se usa el mismo caso del nombre obteniendo un resultado afirmativo, ya que se hace una interrogación recursiva y se recibe una respues no autoritativa: > Server: Address: #53 Non-authoritative answer: canonical name = canonical name = Name: Address: Name: Address: Resolución Directa de nombres de nuestro dominio (red ). La resolución será correcta, como en el caso del servidor DNS primario, visto con anterioridad. > enrique Server: Address: #53 Name: enrique.redes6.redes.dis.ulpgc.es Address: > davidj 31
33 Server: Address: #53 Name: davidj.redes6.redes.dis.ulpgc.es Address: Name: davidj.redes6.redes.dis.ulpgc.es Address: Resolución Directa de nombres externos (red del Laboratorio ). Como en el caso del servidor DNS primario, se resolverán perfectamente aquellos nombres que se declaren en las bases de datos del DNS primario, que el DNS secundario descargará y usará, en este caso. Por ello, para el nombre rodrigo la resolución será correcta: > rodrigo Server: Address: #53 Name: rodrigo.redes6.redes.dis.ulpgc.es Address: Resolución Directa de nombres externos de otros dominios (red ). Como estamos usando el servidor DNS secundario directamente, no podremos hacer de DNS secundario del DNS primario externo situado en la IP (o ). Por ello no será posible la resolución de nombres ni Ips de la red , a no ser que se declaren explícitamente, pero en principio la máquinas internas de dicha red están ocultas. El nombre eliezer no podrá ser resuelto como consecuencia de ello: > eliezer Server: Address: #53 ** server can't find eliezer: NXDOMAIN 5. Resolución Inversa de Ips externa (red del Laboratorio ). 32
34 En este caso, no se podrán resolver las Ips del Laboratorio, pero como consecuencia de que el servidor DNS secundario no descarga la zona de resolución inversa para la red ; si se descargara, sí resolvería correctamente dichas Ips. Por ello, la IP no es resuelta: > Server: Address: #53 ** server can't find in-addr.arpa: NXDOMAIN 6. Resolución Inversa de Ips internas (red ). Al contrario que en el caso anterior, como la zona de la resolución inversa de la red interna sí se indica para que se descargue del DNS primario, por parte del DNS secundario, la resolución será correcta. En la siguiente captura se ven las resoluciones inversas de las Ips y : > Server: Address: # in-addr.arpa name = davidj.redes6.redes.dis.ulpgc.es. > Server: Address: # in-addr.arpa name = enrique.redes6.redes.dis.ulpgc.es. 1. Resolución Inversa de Ips externas de otros dominios (red ). Al igual que la resolución directa, la inversa tampoco será factible para el dominio , por el mimos motivo que el antes comentado, y como puede verse en las siguiente capturas: > Server: Address: #53 ** server can't find in-addr.arpa: NXDOMAIN >
35 Server: Address: #53 ** server can't find in-addr.arpa: NXDOMAIN Servidor DNS Secuandario de otro dominio externo Para hacer uso y probar el DNS secundario del dominio externo tendremos que configurar el fichero resolv.conf para que quede indicado que se hace uso del mismo, cuya IP será la Esto se pondrá en la opción nameserver de dicho fichero, y luego se reiniciará el servicio de red con service network restart. Abrimos una sesión en nslookup y hacemos las siguientes pruebas: 1. Resolución Directa de nombres externos (en Internet). En este caso, al intentar resolver el nombre no se consigue, lo cual se debe simplemente a que el DNS de la máquina (o ) no lo permite. > Server: Address: #53 Non-authoritative answer: *** Can't find No answer 2. Resolución Directa de nombres del dominio redes6.redes.dis.ulpgc.es. Se trata de indicar nombres relativos, pues se les añadirá redes6.redes.dis.ulpgc.es, ya que el fichero resolv.conf de nuestra máquina (la o ) tiene la opción search redes6.redes.dis.ulpgc.es. Por ello, al poner el nombre rodrigo se resolverá, pero como el del DNS de nuestra máquina, ya que el DNS primario para el cual actuamos como DNS secundario externo también funciona como DNS secundario externo de nuestro DNS primario. En el caso del nombre enrique la resolución será del mismo tipo, si bien dicha máquina está realmente en el dominio redes6.redes.dis.ulpgc.es y no sólo es una entrada de las declaraciones de registros del DNS primario de nuestro, como en el caso del nombre rodrigo puesto de esta forma. El resultado obtenido en la captura de ambos casos es coherente con lo mencionado: > rodrigo 34
36 Server: Address: #53 Name: rodrigo.redes6.redes.dis.ulpgc.es Address: > enrique Server: Address: #53 Name: enrique.redes6.redes.dis.ulpgc.es Address: Resolución Directa de nombres del dominio pasarela12.redes.dis.ulpgc.es. Para la resolución de nombres del dominio pasarela12.redes.dis.ulpgc.es será necesario poner el nombre absoluto, pues de lo contrario ocurrirá lo mencionado en el caso anterior, es decir, si se ponen nombres relativos se supondrá que pertenecen al dominio redes6.redes.dis.ulpgc.es. Por ello, si ponemos el nombre eliezer será como si pusiéramos eliezer.redes6.redes.dis.ulpgc.es y fallará la resolución. Mientras que poniendo eliezer.pasarela12.redes.dis.ulpgc.es, la resolución sí es correcta. > eliezer Server: Address: #53 Non-authoritative answer: *** Can't find eliezer: No answer > eliezer.pasarela12.redes.dis.ulpgc.es Server: Address: #53 Name: eliezer.pasarela12.redes.dis.ulpgc.es Address: Resolución Inversa de Ips de la red
37 La resolución inversa será correcta, pues es responsabilidad del DNS de la máquina (o ), que tiene registradas las Ips de su red en los ficheros de resolución inversa del servidor DNS. > Server: Address: # in-addr.arpa name = eliezer.pasarela12.redes.dis.ulpgc.es. 5. Resolución Inversa de Ips externa (red del Laboratorio ). En cuanto a la resolución inversa de Ips de la red , del Laboratorio, funcionará también perfectamente, ya que se habrá declarado su zona de resolución inversa correspondiente, junto con su fichero, en el DNS de la máquina (o ). > Server: Address: # in-addr.arpa name = rodrigo.pasarela12.redes.dis.ulpgc.es. 36
38 Uso del servidor DNS desde un cliente Windows Para empezar tendremos que abrir una sesión en Windows y seguidamente realizar la configuración correcta de las tarjetas de red. Así, desde aquí se configura la conexión del equipo interno a la red En primer lugar conseguimos conectividad, pero no definimos ningún servidor DNS, de forma que no dispondremos de resolución de nombres, aunque si podremos acceder a distintas zonas de Internet haciendo uso directamente de las direcciones IP. 37
40 Desde el terminal del emulador de MS-DOS es posible ver que tenemos conectividad, es decir, que nuestra tarjeta de red está correctamente configurada y que la tarjeta de red del equipo pasarela es accesible. D:\Documents and Settings\prueba>ping Haciendo ping a con 32 bytes de datos: Respuesta desde : bytes=32 tiempo<1m TTL=128 Respuesta desde : bytes=32 tiempo<1m TTL=128 Estadísticas de ping para : Paquetes: enviados = 2, recibidos = 2, perdidos = 0 (0% perdidos), Tiempos aproximados de ida y vuelta en milisegundos: Mínimo = 0ms, Máximo = 0ms, Media = 0ms 39
41 Control-C ^C D:\Documents and Settings\prueba>ping Haciendo ping a con 32 bytes de datos: Respuesta desde : bytes=32 tiempo<1m TTL=64 Respuesta desde : bytes=32 tiempo<1m TTL=64 Estadísticas de ping para : Paquetes: enviados = 2, recibidos = 2, perdidos = 0 (0% perdidos), Tiempos aproximados de ida y vuelta en milisegundos: Mínimo = 0ms, Máximo = 0ms, Media = 0ms Control-C ^C Igualmente, podemos ver como direcciones IP externas a la red del Laboratorio de Redes, es decir, tenemos acceso a Internet. La dirección IP se corresponde con el host de google para dar servicio web (www). D:\Documents and Settings\prueba>ping Haciendo ping a con 32 bytes de datos: Respuesta desde : bytes=32 tiempo=132ms TTL=236 Respuesta desde : bytes=32 tiempo=134ms TTL=236 Estadísticas de ping para : Paquetes: enviados = 2, recibidos = 2, perdidos = 0 (0% perdidos), Tiempos aproximados de ida y vuelta en milisegundos: Mínimo = 132ms, Máximo = 134ms, Media = 133ms Control-C ^C D:\Documents and Settings\prueba>ping La solicitud de ping no pudo encontrar el host Compruebe el nombr 40
42 e y vuelva a intentarlo. Se ve como las direcciones IP son accesibles, pero la resolución de nombres falla. De hecho, la IP se corresponde con pero si bien es accesible el equipo con dicha IP, escribiendo el nombre, no se consigue encontrar su host. Si indicamos el servidor DNS configurado, que se encuentra en el equipo pasarela, con la IP , conseguiremos disponer de la resolución de nombres en el equipo interna de la red (con IP ). Ahora, cuando queramos ver si el host de está accesible, funcionará, pues hará uso del servidor DNS indicado ( ). D:\Documents and Settings\prueba>ping 41
43 Haciendo ping a [ ] con 32 bytes de datos: Respuesta desde : bytes=32 tiempo=131ms TTL=235 Respuesta desde : bytes=32 tiempo=130ms TTL=235 Estadísticas de ping para : Paquetes: enviados = 2, recibidos = 2, perdidos = 0 (0% perdidos), Tiempos aproximados de ida y vuelta en milisegundos: Mínimo = 130ms, Máximo = 131ms, Media = 130ms Control-C ^C 42

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 Resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 Resolución 
 Resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 Resolución 
 Resolución 
 resolución 
 resolución 
 Resolución 
 Resolución 
 Resolución 
 Resolución 
 resolución 
 resolución 
 Resolución 
 Resolución 
 resolución 
 Resolución 
 resolución 
 Resolución 
 resolución 
 Resolución 
 resolución 
 Resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 Resolución 
 Resolución 
 resolución 
 Resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución