Software de Comunicaciones. Práctica 3 - Domain Name System (DNS)

Transcripción

1 Software de Comunicaciones Práctica 3 - Domain Name System (DNS) Juan Díez-Yanguas Barber Software de Comunicaciones Ingeniería Informática - 5º Curso Jdyb - Marzo 2013

2 Juan Díez- Yanguas Barber Práctica 3 Índice 1. Uso de NSLOOKUP y DIG Realizar peticiones DNS con NSLOOKUP Realizar peticiones DNS con DIG Proceso de búsqueda iterativo con DIG 6 2. Instalación del servidor BIND Configuración del servidor BIND Comprobar el funcionamiento de la caché Creación de zonas primarias Mantenimiento de las zonas primarias Sincronización primaria-secundarias Delegación de un subdominio Partes opcionales Configuración de vistas Usar TSIG para la autenticación de los servidores en transferencia de zonas Resumen de RNDC Configuración con Webmin 45 Jdyb - Marzo

3 Juan Díez- Yanguas Barber Práctica 3 1. Uso de NSLOOKUP y DIG 1.1. Realizar peticiones DNS con NSLOOKUP En primer lugar realizaremos peticiones con nslookup a un servidor local. En nuestro caso el servidor local será el interno del CEU, con dirección , podremos preguntar por ejemplo por jerusalen.eps.uspceu.es. Las opciones sobre nslookup se hacen sobre el modo interactivo que tiene el mismo. Entraremos en el modo interactivo y seleccionaremos como servidor el DNS de la escuela. Ahora realizaremos la resolución inversa para el mismo dominio con la herramienta nslookup (no se ha encontrado la entrada de resolución inversa). La IP que se ha probado ha sido la dirección de la web eps.uspceu.es pero vista desde dentro de la escuela. Pasaremos ahora a realizar las consultas sobre un servidor DNS externo y veremos que no encontrará la dirección porque se trata de una máquina interna de la escuela que no está anunciada al exterior. Esto se puede realizar mediante el uso de vistas, este concepto será visto en esta práctica. Jdyb - Marzo

4 Juan Díez- Yanguas Barber Práctica 3 Haremos por último la resolución inversa con el servidor DNS de google, esta vez lo haremos con la dirección IP de elmundo.es 1.2. Realizar peticiones DNS con DIG Realizaremos las mismas acciones con dig, para usar servidores DNS diferentes a los que haya establecidos en la máquina por la configuración de red (normalmente por DHCP) usaremos la dirección del servidor precedida de una Como podemos ver en las respuestas de dig vemos que están mejor organizadas con los apartados bien separados de las mismas. En primer lugar el apartado con la pregunta realizada, en segundo lugar veremos la respuesta (en caso de que exista) y en algunos casos veremos dos secciones más, en primer lugar la sección en la que se indica la autoridad de la zona y en segundo lugar información adicional que puede servidor DNS para evitar peticiones adicionales posteriores. Como por ejemplo cuando el servidor DNS no responde con respuesta sino con indicación de la autoridad de la zona en la sección adicional suele dar las resoluciones de los servidores con autoridad de la zona para que no haya que volver a lanzar peticiones preguntando por la IP de los servidores que se han indicado como que tienen autoridad sobre la zona. Jdyb - Marzo

5 Juan Díez- Yanguas Barber Práctica 3 Ahora realizaremos una resolución inversa también usando dig, para ello habrá que hacerlo con la opción -x. Podemos hacer la misma consulta a un servidor DNS externo como pueden ser los de google. Jdyb - Marzo

6 Juan Díez- Yanguas Barber Práctica 3 Usaremos de nuevo dig para hacer una resolución inversa a la dirección de la web uspceu.es con un servidor DNS externo Proceso de búsqueda iterativo con DIG Normalmente cuando realizamos peticiones a servidores DNS configurados en nuestros equipos estos responden de manera recursiva, lo que quiere decir que nos devuelven la respuesta a la pregunta que planteamos, ellos mismos se encargan de hacer el proceso iterativo de búsqueda para posteriormente devolvernos la respuesta a la petición. Sin embargo este no es el comportamiento de todos los servidores DNS, los servidores raíz de Internet no responden de esta manera debido a la carga que esto supondría, los servidores raíz simplemente nos responden diciéndonos los servidores DNS que tienen autoridad sobre la zona por la que hemos preguntado de manera que Jdyb - Marzo

7 Juan Díez- Yanguas Barber Práctica 3 tendremos que preguntar a uno de los servidores DNS con autoridad sobre la zona requerida. Petición Tipo A uspceu.es Pregunta a.es 2 Root DNS Petición Tipo A uspceu.es Dir IP 1 Petición Tipo A uspceu.es 3.es DNS Server Sucesivamente hasta obtener respuesta Servidor DNS Comportamiento Recursivo En este apartado realizaremos manualmente el proceso iterativo de búsqueda desde los servidores raíz de Internet. Petición Tipo NS. Servidores DNS Raiz Petición Tipo A uspceu.es "no se, pregunta a responsable.es 5 6 Petición Tipo A uspceu.es "no se, pregunta a responsable uspceu.es.es DNS1 Root DNS1 Root DNS2 Root DNS3.es DNS Equipo usuario 7 8 Pregunta Tipo A uspceu.es IP uspceu.es uspceu.es DNS1 uspceu.es DNS2 Comportamiento Iterativo Una vez mostrado el esquema mostraremos los pasos seguidos mediante el terminal usando dig. Jdyb - Marzo

8 Juan Díez- Yanguas Barber Práctica 3 Jdyb - Marzo

12 Juan Díez- Yanguas Barber Práctica 3 Ahora veremos que el proceso que hemos seguido se puede seguir igualmente usando la opción +trace de dig y se realizará el proceso iterativo automáticamente mostrándolo por pantalla y obtendremos al final la IP de uno de los servidores responsables de la zona uspceu.es. Jdyb - Marzo

13 Juan Díez- Yanguas Barber Práctica 3 2. Instalación del servidor BIND Para la instalación del servidor en nuestra máquina virtual lo podremos llevar a cabo mediante un paquete RPM con el uso de los comandos para la instalación de este tipo de paquetes. A la finalización de la instalación el paquete habrá sido instalado y los ficheros estarán situados en los directorios correspondientes. El servicio no estará arranca ni configurado para arrancar al inicio de la máquina. El servicio se encontrará bajo el nombre de named y será el nombre del script que usaremos para arrancar el servicio y si se quisiera configurar para arrancar automáticamente también debería de usarse ese nombre con chkconfig. Jdyb - Marzo

14 Juan Díez- Yanguas Barber Práctica 3 3. Configuración del servidor BIND En este apartado se estudiará la configuración del servidor mediante sus ficheros de configuración. Las configuraciones las realizaremos mediante línea de comandos editando los ficheros. Es posible realizar estos pasos usando Webmin, el proceso será mediante una interfaz más amigable y evitando posible erratas en la configuración, no obstante como he dicho el proceso se hará manualmente. Para configurar el servidor BIND tendremos varios ficheros de configuración, en primer lugar el propio del servidor donde se definirán las zonas y opciones generales (/etc/ named.conf), y en segundo lugar el fichero de configuración de cada zona (/var/named/). En primer lugar lo que haremos será modificar la configuración del servidor DNS local para que las peticiones se resuelvan a través del servidor que vamos a configurar que estará en la dirección local. Lo haremos en el fichero /etc/resolv.conf, la configuración hecha en este fichero no es permanente, ya que este fichero es autogenerado cuando las interfaces arrancan, si quisiéramos hacer permanente la configuración habría que anotar los servidores DNS en los fichero de configuración de la interfaz correspondiente (/etc/ sysconfig/network-scripts/). Para arrancar el servidor DNS lo haremos con el comando service Comprobar el funcionamiento de la caché La manera que tenemos de comprobar el funcionamiento de la caché de las peticiones realizadas al servidor DNS lo que podemos hacer es usar un comando rndc para vaciar la misma hacer una petición al servidor, fijarnos en el TTL de la respuesta y hacer posteriormente otra y comprobar que ha disminuido, lo que significará que la respuesta la está dando de la caché. Jdyb - Marzo

15 Juan Díez- Yanguas Barber Práctica 3 También se puede apreciar que en la segunda respuesta (la que está cacheada) el tiempo de consulta Query time ha disminuido drásticamente de 183 ms a 1 ms gracias al uso de la caché que está en local, ya no se ha tenido que salir a buscar la información. Jdyb - Marzo

16 Juan Díez- Yanguas Barber Práctica Creación de zonas primarias En este apartado como propone el enunciado se creará un dominio ficticio que será efirel.com y deberemos configurar las dos zonas primarias, la de resolución directa y la inversa. El dominio administrará las direcciones del rango /24. Lo que hemos de hacer es crear las dos zonas en el fichero de configuración principal del que ya hemos hablado. Lo primero que haremos en este apartado es mostrar el inicio del fichero de configuración en el que podemos ver parámetros generales de configuración como los puertos en los que tendrá que escuchar las peticiones el servidor, directorio de mantenimiento de las zonas, y ficheros de log. Aunque los parámetros del puerto de escucha estén comentados son los que toma por defecto, habría que descomentar las líneas si se quisieran usar unos diferentes. Una vez vista esta configuración general nos iremos al final del fichero en el que hemos añadido ambas zonas para la administración de efirel.com. Para cada una de las zonas tendremos que especificar el nombre de la misma, el tipo (en este caso serán maestras ambas), el fichero de mantenimiento de la zona y si se permiten actualizaciones de la zona y de quien, en este caso nadie podrá mandar actualizaciones de las zonas. Este parámetro lo usaremos en apartados posteriores. La primera de las zonas añadidas será la de resolución directa y la segunda de ellas será la de resolución inversa con entradas PTR. Jdyb - Marzo

17 Juan Díez- Yanguas Barber Práctica Mantenimiento de las zonas primarias Una vez que en el apartado anterior hemos configurado las zonas maestras para la configuración que se ha pedido en el enunciado lo que hemos de hacer es ir al directorio / var/named y en el mismo crear los ficheros de las zonas a los que se hace referencia en el fichero de configuración del apartado anterior. Dentro de los ficheros de configuración lo primero que nos vamos a encontrar es el nombre absoluto del dominio (hay que poner el punto al final) y posteriormente nos encontraremos la entrada SOA de la zona que da información de autoridad sobre la misma. En esta entrada la arroba de la dirección del administrador se indica con un punto. Posteriormente lo que nos encontraremos serán una serie de números que serán necesarios, a continuación indicamos el significado de cada uno de ellos por orden. 1. Número de serie: Valor numérico que incrementa en cada actualización, esto servirá para que se detecten los cambios en una zona cuando hay servidores secundarios 2. Tiempo de refresco (seg): Frecuencia con que los servidores secundarios comprueban si se ha actualizado el primario 3. Tiempo de reintento (seg): Frecuencia con que un servidor secundario reintenta una conexión al servidor primario después de un fallo 4. Tiempo de vencimiento (seg): Tiempo que un servidor secundario sigue dando respuestas a las peticiones sobre una zona sin que se haya podido contrastar con el primario Jdyb - Marzo

18 Juan Díez- Yanguas Barber Práctica 3 5. Tiempo de vencimiento de caché (seg): Tiempo máximo de vida de los registros de la zona en los servidores caché. Posteriormente lo que encontraremos en el fichero de configuración serán cada una de las entradas, habrá una por línea y los parámetros en el orden en el que aparecen serán los siguientes. 1. Petición: Nombre de dominio absoluto o relativo al nombre de dominio de la zona 2. Tipo de entrada 3. Respuesta: Nombre de dominio absoluto o relativo al nombre de dominio de la zona Entre todas las entradas es necesario que siempre aparezca al menos una entrada NS que será el servidor DNS responsable de la zona. Si no existe una entrada NS la zona no arrancará y dependiendo del servidor DNS el servidor arrancará sin arrancar esa zona o directamente no levantará si tiene error en una zona. A continuación mostramos el archivo de configuración de la zona en el que se detallan todas las entradas especificadas por el enunciado. El fichero de configuración mostrado será el correspondiente para la resolución directa. Después de realizar este fichero de configuración reiniciaremos el servidor y haremos algunas comprobaciones, en el comando dig no especificaremos el servidor DNS al que consultamos porque recordemos que hemos puesto la dirección de localhost como servidor DNS por defecto de la máquina en el fichero /etc/resolv.conf. Jdyb - Marzo

20 Juan Díez- Yanguas Barber Práctica 3 Ahora que hemos comprobado el funcionamiento correcto del DNS para la zona de resolución directa de efirel.com lo que haremos será pasar a la configuración de la zona de resolución inversa. No se ha incluido la dirección.4 debido a que se especifica en el enunciado que la máquina zape no ha de aparecer en la resolución inversa. Jdyb - Marzo

21 Juan Díez- Yanguas Barber Práctica 3 Se puede pensar que con este fichero de configuración es suficiente, pero lo cierto es que, si nos queremos regir exactamente a lo que dice el enunciado también deberíamos ser capaces de hacer la resolución inversa del propio servidor DNS que estamos usando (nuestra máquina virtual) y con la configuración actual eso no va a ser posible. Deberíamos de añadir una nueva zona de resolución inversa para la zona de la dirección IP en que este nuestra máquina. Jdyb - Marzo

22 Juan Díez- Yanguas Barber Práctica 3 Una vez que hemos realizado estas configuraciones podemos realizar algunas pruebas con el comando dig con la opción -x para resolución inversa de manera que podamos comprobar que las configuraciones han surtido los efectos deseados. Jdyb - Marzo

25 Juan Díez- Yanguas Barber Práctica Sincronización primaria-secundarias En este apartado se va a realizar la configuración de una nueva zona pero con nombre de dominio diferente como por ejemplo miempresa.com y se va tratar de configurar un servidor secundario para esta zona de manera que se sincronice con el primario. En primer lugar describiremos nuestro escenario mediante un gráfico. VMWare Red: /24 miempresa.com miempresa.com Notificación Transferencia DNS Primario DNS Secundario Como se puede observar en el gráfico vamos a tener dos máquinas virtuales y en cada una de ellas un servidor DNS, se tratará de que cuando haya cambios en el servidor primario el servidor secundario sea notificado mediante una notificación explícita para que éste pida una actualización al primario y actualice sus entradas de la configuración de la zona. Empecemos con la configuración del servidor primario. Lo que hemos de hacer en primer lugar es crear la zona de miempresa.com, pero esta vez añadiremos más parámetros en la configuración. Habrá que permitir la notificación explícita y a quién hay que notificar los cambios y por otra parte también se deberán permitir transferencias de zona hacia el servidor DNS secundario. Jdyb - Marzo

26 Juan Díez- Yanguas Barber Práctica 3 Una vez que hemos realizado esta configuración creamos el fichero de la zona que va a ser el mismo que para efirel pero cambiando el dominio por miempresa.com y cambiando la IP que en este caso va a ser /24. Ahora comprobaremos que se responden correctamente a las peticiones después de reiniciar el servidor. Jdyb - Marzo

27 Juan Díez- Yanguas Barber Práctica 3 Pasaremos ahora a la configuración del servidor DNS secundario. Lo que tendremos que hacer es configurar la zona de una manera similar a como lo hemos hecho en el servidor primario. Habrá que configurar la zona en el fichero de configuración del servidor DNS secundario configurando la zona como secundaria o esclava y también habrá que indicar que se permiten las notificaciones desde la IP del servidor DNS primario. Ahora reiniciaremos el servidor DNS, en el servidor primario aumentaremos el número de serie y reiniciaremos el servidor y miraremos haber que es lo que pasa. Podemos ver lo sucedido en /var/named/data/named.run. Como se puede ver el proceso de transferencia de zona ha fallado porque no se tienen permisos en ese directorio para el usuario named. Jdyb - Marzo

28 Juan Díez- Yanguas Barber Práctica 3 Sin embargo como podemos ver en el directorio slaves si que tiene permisos el usuario named. Si ponemos ahí en fichero de miempresa.com debería de funcionar. Veremos que el directorio slaves está vacío. Cambiamos la configuración de la zona en el servidor secundario, reiniciamos el servidor, volvemos a aumentar el número de serie en el servidor primario y comprobamos que ahora si funcionará. Jdyb - Marzo

29 Juan Díez- Yanguas Barber Práctica 3 Ahora añadiremos un nuevo servidor de nombres en la zona que será ns2 y tendrá la IP del servidor secundario. Actualizaremos también el número de serie y comprobaremos que se ha extendido el cambio al DNS secundario. Jdyb - Marzo

31 Juan Díez- Yanguas Barber Práctica Delegación de un subdominio En este apartado vamos a tratar de delegar la autoridad de un subdominio concreto, por ejemplo ventas.miempresa.com en otro servidor DNS. Será necesario crear una entrada de tipo NS en la zona de miempresa.com que apunte al nuevo servidor creado. Ahora nos dirigimos al nuevo servidor DNS y configuramos una nueva zona maestra que administre ventas.miempresa.com. A la nueva zona creada le hemos puesto un TTL diferente para que sea un punto más de diferenciación a la hora de hacer la petición con dig. Jdyb - Marzo

32 Juan Díez- Yanguas Barber Práctica 3 Reiniciaremos ambos servidores y comprobaremos que se resuelven correctamente las peticiones. Si quitamos la recursividad al servidor que mantiene el dominio principal deberíamos ver un comportamiento parecido a lo que se estuvo viendo en el primer apartado de la práctica. El servidor en vez de dar una respuesta nos debería de decir que la autoridad de la zona ventas.miempresa.com no la tiene él y por lo tanto vayamos a preguntar al servidor DNS que tiene autoridad sobre dicha zona. Jdyb - Marzo

34 Juan Díez- Yanguas Barber Práctica 3 4. Partes opcionales 4.1. Configuración de vistas En este apartado se va a estudiar la configuración de vistas para el servidor DNS, las vistas nos serán de utilidad si queremos dar una imagen diferente de nuestra zona dependiendo desde donde sea vista. Por poner un ejemplo podríamos poner el de la propia escuela. Si consultamos al DNS desde dentro de la red de la escuela podemos ver que responde con IPs de la red privada y responde también a peticiones realizadas a los servidores de docencia como son jerusalen, jerico, etc... Sin embargo, si realizamos peticiones al mismo desde el exterior nos responde con las IPs públicas de los servidores y además no da una respuesta si se realizan peticiones a los servidores de docencia. En conclusión, los recursos de la red no se ven de la misma manera si estoy dentro o fuera de la EPS. Para nuestro caso nos plantearemos un escenario sencillo con dos zonas, una interna y otra externa. En la zona interna daremos a conocer los recursos con direcciones de la red de VMWARE a partir de la 201 y en la zona externa usaremos direcciones públicas. Por otra parta habrá un recurso de base de datos que no será mostrado al exterior. La zona interna estará definida por la dirección mientras que la zona externa estará definida por la dirección y el resto. Se podrían dar direcciones de red perfectamente para las ACL pero por simplicidad se hará de esta manera. La dirección.130 corresponde a la máquina virtual que se usó como servidor DNS secundario y la dirección.1 corresponde a la dirección de la máquina anfitriona dentro de la red de VMWARE. Otro punto interesante es que podríamos poner en la vista externa la recursión apagada, eso podría servir por ejemplo para que nadie usara nuestro servidor DNS para resolver peticiones salvo las que fueran de zonas de nuestra autoridad. Un apunte importante a la hora de configurarlo es que no puede quedar ninguna zona de DNS fuera de las vistas. Jdyb - Marzo

35 Juan Díez- Yanguas Barber Práctica 3 Ahora lo que hemos de hacer es comprobar el funcionamiento de las mismas. Para ello nos pondremos primero desde la zona interna en la dirección a lanzar consultas. Jdyb - Marzo

37 Juan Díez- Yanguas Barber Práctica 3 Ahora pasaremos a mostrar las consultas hechas desde el exterior (máquina anfitriona y veremos como cambian y veremos que tampoco podemos lanzar consultas recursivas. Jdyb - Marzo

39 Juan Díez- Yanguas Barber Práctica Usar TSIG para la autenticación de los servidores en transferencia de zonas TSIG tiene como fin asegurar los mensajes que se transfieren entre los servidores DNS en los procesos de transferencia de zonas. Usaremos este manual: Lo primero que vamos a tener que hacer para configurarlo será generar las claves pública y privada, lo haremos con md5 con una longitud de clave de 128 bits. Una vez que hemos generado las claves lo que hemos de hacer es generarnos un fichero TSIG para poder usarlo dentro de la configuración del BIND. Hay que fijarse que lo que estamos haciendo es darle al servidor primario la clave del secundario, la IP que hemos puesto es la del servidor secundario. Posteriormente el fichero creado lo tendremos que incluir en el fichero de configuración de bind. Ahora lo que haremos es copiar las claves al servidor secundario, en mi caso lo he hecho mediante SFTP con un cliente gráfico desde la máquina anfitriona. Jdyb - Marzo

40 Juan Díez- Yanguas Barber Práctica 3 Editamos el fichero TSIG con la IP del servidor primario, aquí es donde se ve que le estamos dando al servidor secundario la clave del servidor primario. Y de nuevo incluimos este fichero en el fichero de configuración de bind. Ahora vamos a editar la configuración del servidor maestro para que solo haga transferencia de zonas a aquellos servidores que tengan la clave TRANSFER. Ahora lo que haremos es actualizar el número de serie en la zona maestra para comprobar que se producen las transferencias. Mirando los ficheros de log nos damos cuenta de que no funciona porque los dos servidores tienen que estar sincronizados en hora. Para sincronizar la hora en las dos máquinas virtuales nos disponemos a instalar el servicio ntp con el comando yum install ntp, y dando a las dos máquinas virtuales un mismo servidor de hora (ntpdate 0.es.pool.ntp.org). Comprobamos de nuevo el comportamiento cambiando el número de serie de la zona maestra (siempre de manera creciente). Comprobamos que no se ha producido ningún error en el log, que como ya se ha comentado anteriormente lo podemos encontrar en /var/named/data/named.run. Jdyb - Marzo

42 Juan Díez- Yanguas Barber Práctica Resumen de RNDC Esta utilidad permite la administración de línea de comandos del demonio named desde el host remoto o desde un host local. Para prevenir el acceso no autorizado al demonio named, BIND utiliza un método de autenticación de llave secreta compartida para otorgar privilegios a hosts. Esto significa que una llave idéntica debe estar presente en los archivos de configuración /etc/ named.conf y en el rndc, /etc/rndc.conf. Funcionaría de manera similar a lo que se ha realizado en el apartado anterior para la transferencia de zonas. En primer lugar hay que hacer el fichero de configuración de RNDC en la máquina que se vaya a conectar, esto lo podemos hacer con esta herramienta /usr/sbin/rndcconfgen. Situaremos el fichero de configuración en /etc/rndc.conf. Mostramos el contenido del fichero indicado en el include que como se puede ver hemos usado la misma clave que en el apartado anterior. En el fichero de configuración de BIND del servidor DNS hay que añadir una nueva sección para indicar que escuche en cualquier dirección si se quiere que una dirección arbitraria lo pueda administrar vía rndc y por otra parte hay que especificar las claves que son admitidas. En este fichero la clave TRANSFER ya la teníamos con el include del apartado anterior. Jdyb - Marzo

43 Juan Díez- Yanguas Barber Práctica 3 Una vez que se ha aplicado esta configuración reiniciando el servidor y en ambos sitios (servidor y cliente rndc) como ya se ha comentado, ya estamos en disposición de ejecutar los comandos rndc sobre el servidor desde cualquier IP como bien se indica en la directiva de controls. Podemos por ejemplo comprobar si los comandos se ejecutan correctamente desde el cliente ejecutando algunos de ellos. Podemos por ejemplo parar el servidor a distancia. Veamos como se encuentra el servidor antes de ejecutar el comando a distancia, se puede ver que está escuchando en los puertos propios del servicio DNS y con el nombre de proceso named. Ejecutaremos el comando para parar el servidor a distancia y comprobaremos que el servidor deja de escuchar en los puertos que se han mostrado. Por otra parte se puede hacer un resumen de los comandos que admite rndc. halt: Detiene por completo el servicio named querylog: Registra todas las peticiones realizadas al servidor de nombres refresh: Refresca la base de datos del servidor de nombres reload: Recarga los archivos de zona pero mantiene todas las respuestas precedentes situadas en caché. Esto le permite realizar cambios en los Jdyb - Marzo

44 Juan Díez- Yanguas Barber Práctica 3 archivos de zona sin perder todas las resoluciones de nombres almacenadas stats: Descarga las estadísticas actuales de named al archivo /var/named/ named.stats stop: Detiene al servidor salvando todas las actualizaciones dinámicas y los datos de las Transferencias de zona incremental (IXFR) antes de salir Jdyb - Marzo

45 Juan Díez- Yanguas Barber Práctica 3 5. Configuración con Webmin Como se comentó al principio de la práctica también hubiera sido posible realizar las configuraciones mediante el uso de Webmin, el cual provee una interfaz más agradable a la vez que ayuda a evitar pequeños fallos de escritura en los ficheros de configuración. El objetivo de este apartado será simplemente mostrar que Webmin posee interfaz para realizar las configuraciones sobre los ficheros del bind. De hecho a continuación en las capturas presentadas comprobaremos como se encuentran presentes las configuraciones que hemos ido llevando a cabo en la práctica. Jdyb - Marzo