DNS-FEDORA
Objetivos de la práctica:
Instalación y configuración de Bind (DNS) en Fedora.
Resolución de nombres de servidor-cliente y cliente-servidor.
Resolución inversa de servidor-cliente y cliente-servidor
Que Alex Castel nos haga sufrir por el uso de Fedora.
Lo primero que haremos será instalar Fedora. Una vez esté completa la instalación, agregaremos dos comandos básicos y esenciales para co ntinuar:
yum –y update Nos servirá para actualizar el sistema, muy importante siempre realizar esta orden antes de instalar nada.
yum –y install bind bind-utiles Nos instalará el bind para Fedora.
El siguiente paso será agregar una IP estática a la máquina servidor. En nuestro caso será la
192.168.1.1. Y lo mismo haremos haremos con el cliente (Windows 7) que será la 192.168.1.2. Estos procesos los haremos gráficamente desde la configuración de red en Fedora, por lo que no vale la pena enseñar capturas de pantalla.
Una vez configuradas las direcciones, el primer paso será ir a /etc/named.conf y editar el archivo principal de bind de la siguiente forma: Los puertos donde escuchará el servidor será el 53, TCP/UDP para que pueda conectarse la
petición sin problemas. Otro dato importante será agregar entre corchetes la condición any .. donde cualquier IP “
”
pueda conectarse. Si ponemos una IP fija o un rango no funcionará (al menos personalmente).
En el mismo archivo configuremos las zonas directas e inversas. Agregaremos vellido.local como el nombre de dominio y el archivo que recibirá las órdenes “
”
directas será "vellido.db . ”
Haremos el mismo proceso con la zona inversa, pero agregando inverso.db . “
”
Dato importante en la configuración inversa. El 1.168.192.in-addr.arpa es la IP (192.168.1.1) “
”
al revés, pero quitándole el último octeto de la IP (es decir, el 1 final). De esta manera podremos resolver de forma inversa la resolución de nombres, que serían las IPS.
Después de realizar la configuración del named, es hora de ir a /var/named y configurar los archivos de zona directa y zona inversa, es decir vellido.db e inversa.db:
Vellido.db Básicamente agregaremos todos los registros y le diremos que nuestro nombre de dominio será vellido.local de nuestro hostname (vellipc). “
”
El TTL es el tiempo de vida que durarán las consultas del servidor. SOA es para cuentas de correo. Agregamos la IP del servidor: 192.168.1.1 y el nombre: vellipc.vellido.local. Y hacemos lo mismo con el cliente: cliente A 192.168.1.2
Inverso.db Inversamente realizaremos la misma tarea: Cambiaremos las últimas líneas. Aquí van los registros inversos, que son los PTR y añadiremos la configuración siguiente:
*Nota: El 50 y el 1 está mal. Sería 1 y 2 respectivamente (esto es un pantallazo antiguo). ¿Por qué 1 y 2? Porque toma el último número de las IPs del servidor y el cliente.
También tocaremos el archivo resolv.conf situado en /etc para añadir nuestro nameserver. Importante este paso:
Y añadiremos al mismo grupo de trabajo a servidor y cliente. En nuestro caso será “
SUPERVELLIDO
”
Fedora:
Windows 7:
Antes de iniciar el servicio, tenemos que deshabilitar el firewall del equipo servidor, porque si no no nos dejará conectar más tarde. Con las órdenes:
systemctl stop firewalld.service systemctl disable firewalld.service Apagaremos el Firewall y no debería darnos más problemas. Después de toda la configuración realizada, reiniciaremos el BIND para que nos tome todos los cambios, con los comandos:
systemctl start named.service systemctl enable named.service Si no aparece nada más, es que el servicio se ha iniciado correctamente. Para seguir comprobando que la configuración es adecuada, haremos un nslookup a nuestro propio servidor:
Y también lo haremos inversamente:
Incluso la orden dig nos dirá si está bien o no: “
”
Después de toda la configuración en el servidor, es hora de ver si en el cliente funciona todo perfectamente. Detalles que son obvios, pero añadiremos por si un caso:
La IP del cliente debe estar en la misma red que el server, 192.168.1.2.
El nombre del equipo debe ser el agregado en las zonas (cliente.vellido.local.)
El grupo de trabajo debe ser SUPERVELLIDO.
En la configuración de Red, el DNS debe ser el del servidor (192.168.1.1).
El Firewall del cliente está desactivado.
Una vez esté todo eso configurado, es el turno de probar los nslookup del cliente. Desde el cliente, haremos un nslookup al servidor (vellido.local.) y nos responderá. Lo mismo desde zona inversa (192.168.1.1):
Incluso lo podemos comprobar realizándose un nslookup a si mismo (cliente.vellido.local.) e inversamente 192.168.1.2. También al subdominio www.vellido.local. “
”
Una vez acabados los nslookup, iremos al Wireshark para ver el envío de paquetes después de hacer la orden: Podemos ver los paquetes DNS, como desde el origen del nslookup (192.168.1.2) los envía a su destino (el servidor) 192.168.1.1 y como toma los registros AAAA (configuados en el vellido.db) y puede hacer conexión con el vellido.local, que es nuestro servidor.
La respuesta es devuelta por 192.168.1.1 (server) al 192.168.1.2 (cliente) para mostrarle la todos los datos que pedía el nslookup. Servidor, nombre e IP.
De forma inversa también recibimos paquetes Whireshark. Po r ejemplo, podemos ver como los registros PTR son enviados (PTR vellido.local). Estos se realizan cuando la resolución de nombres es inversa. Es el caso de nslookup 192.168.1.1 que hemos realizado un poco más arriba.
Y hasta aquí la instalación, configuración y realización de DNS -Fedora con un Cliente de Windows. En este mismo documento inserto el vídeo explicando un poco más de lo mismo: http://www.youtube.com/watch?v=nBOJ3iDBCzg&feature=youtu.be
Josep Mª Vellido ASIX2M – SERXAR Alex Castel – 13/14
