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 continuar:

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 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. Por 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