DNS dinámico


Es muy cómodo utilizar DHCP en una red local, pero tiene un inconveniente: no sabemos qué dirección tiene en cada momento un equipo. Una solución para esto es sincronizar el servidor DHCP con el DNS, creando lo que se denomina un servidor DNS dinámico (DDNS). Esta configuración permite que cada vez que se modifique una dirección IP, se registre el cambio en los ficheros que controlan la zona local y, de esta manera, poder acceder a un equipo a través de su nombre.

Características del montaje

Vamos a utilizar un equipo que va a actuar como servidor DHCP y DNS, por lo que la comunicación entre estos dos servicios será a través de localhost. Configuraremos incialmente DNS con RNDC, para la sincronización entre los dos servicios a través del puerto 953/tcp.

Utilizaremos el dominio de pruebas “dominio.biz” y el segmento 10.0.0.0/24 para la red local de direcciones privadas.

Software utilizado

  • Distribución: Debian GNU/Linux (lenny)
  • Servidor DNS: Bind 9.5.0
  • Servidor DHCP: Dhcp3-server 3.1.1

Aunque los mismos pasos se han seguido también en un equipo con Debian etch sin haber encontrado ninguna diferencia relevante.

Instalar el servidor DNS (Bind9)

aptitude install bind9



El directorio /etc/bind/ contiene los siguientes ficheros:

-rw-r--r-- 1 root root  237 oct  7 23:47 db.0
-rw-r--r-- 1 root root  271 oct  7 23:47 db.127
-rw-r--r-- 1 root root  237 oct  7 23:47 db.255
-rw-r--r-- 1 root root  353 oct  7 23:47 db.empty
-rw-r--r-- 1 root root  270 oct  7 23:47 db.local
-rw-r--r-- 1 root root 2878 oct  7 23:47 db.root
-rw-r--r-- 1 root bind  907 oct  7 23:47 named.conf
-rw-r--r-- 1 root bind  165 oct  7 23:47 named.conf.local
-rw-r--r-- 1 root bind  572 oct  7 23:47 named.conf.options
-rw-r----- 1 bind bind   77 nov 13 13:57 rndc.key
-rw-r--r-- 1 root root 1317 oct  7 23:47 zones.rfc1918

Los ficheros named.conf.* eran originalmente sólo uno, ahora se modifican principalmente named.conf.options y named.conf.local, para incluir respectivamente las opciones de bind y la definición de las zonas locales.

El fichero rndc.key contiene una clave para el rndc, que será muy importante en la sincronización con el servidor DHCP:

key "rndc-key" {
algorithm hmac-md5;
secret "S9QTPFn8zklrPHQ7z6XcOA==";
};

Obviamente la clave cambiará en cada equipo y esta se muestra porque se está ejecutando en una máquina virtual de pruebas. Esta clave se genera de forma automática al instalar bind9, pero es posible generar una nueva clave mediante la instrucción rndc-confgen.

El resto de ficheros del directorio /etc/bind/ no deben modificarse y nos garantizan el buen funcionamiento del servidor Bind.

Otro aspecto a considerar es el usuario que ejecuta el demonio de bind (denominado named), que como podemos ver en el fichero /etc/default/bind y se llama precisamente bind; este usuario deberá tener los permisos pertinentes para actualizar los registros del DNS.

Para que bind utilice rndc, hay que incluir la siguiente entrada en named.conf:

include "/etc/bind/rndc.key";

controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};

de esta manera se permiten actualizaciones de las entradas DNS, pero sólo a quien facilite la clave y sólo desde localhost.

El fichero named.conf.options

La única directiva relevante de este fichero es:

directory "/var/cache/bind";

que nos indica el directorio de trabajo del servidor. Este directorio de trabajo tiene los siguientes propietarios:

drwxrwxr-x  2 root   bind     4096 nov 13 18:07 bind

Es decir, podrán escribir en él tanto root como los usuarios que pertenezcan al grupo bind, inicialmente sólo el usuario bind.

Creando las zonas locales

Supongamos que queremos resolver las direcciones de nuestra red local, y que pertenecen al dominio dominio.biz. Para ello editamos el fichero named.conf.local que inicialmente sólo tiene algunas líneas comentadas e incluimos las siguientes entradas:

zone "dominio.biz" {
type master;
file "db.dominio";
allow-update { key "rndc-key"; };
notify yes;
};

zone "0.0.10.in-addr.arpa" {
type master;
file "db.10.0.0";
allow-update { key "rndc-key"; };
notify yes;
};

Es decir, crearemos dos ficheros que incluirán las entradas para la resolución directa (db.dominio) e inversa (db.10.0.0), además se incluye la directiva “allow-update” para que puedan actualizarse las entradas DNS a través de rndc y se indica el nombre de la clave.

Los ficheros db.dominio y db.10.0.0 se deben crear en el directorio de trabajo, que en este caso es /var/cache/bind, aunque hay gente que prefiere modificar este directorio por /etc/bind. Los propietarios y permisos de estos ficheros deben ser:

-rw-rw-r-- 1 bind bind 313 nov 14 16:25 db.10.0.0
-rw-rw-r-- 1 bind bind 440 nov 14 16:25 db.dominio

Y su contenido podría ser (incluyendo sólo el propio servidor DNS de forma estática, ya que estará fuera del rango de direcciones IP que reparte el servidor DHCP):

db.dominio

$ORIGIN dominio.biz.
$TTL 86400 ; 1 day
@       IN      SOA     talut   postmaster (
        200811132 ; serial
        21600 ; refresh (6 hours)
        3600 ; retry (1 hour)
        604800 ; expire (1 week)
        21600 ; minimum (6 hours)
)
        NS      talut
talut   A       10.0.0.128

db.10.0.0

$ORIGIN 0.0.10.in-addr.arpa.
$TTL 86400 ; 1 day
@       IN      SOA     talut   postmaster (
        200811131 ; serial
        21600 ; refresh (6 hours)
        3600 ; retry (1 hour)
        604800 ; expire (1 week)
        21600 ; minimum (6 hours)
)
        NS      talut.domionio.biz.
128     PTR     talut.dominio.biz.

Prueba de funcionamiento del servidor DNS

Utilizando algún cliente DNS (preferentemente dig), haremos consultas al servidor DNS local y comprobaremos si responde correctamente, por ejemplo:

dig @127.0.0.1 talut.dominio.biz

; <> DiG 9.5.0-P2 <> @127.0.0.1 talut.dominio.biz
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29030
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;talut.dominio.biz.	      IN	A

;; ANSWER SECTION:
talut.dominio.biz. 86400 IN	A	10.0.0.128

;; AUTHORITY SECTION:
dominio.biz. 86400	IN	NS	talut.dominio.biz.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Nov 14 17:27:49 2008
;; MSG SIZE  rcvd: 77

Instalar el servidor DHCP (dhcp3-server)

aptitude install dhcp3-server



No se inicia y nos indica que busquemos el motivo en syslog, editamos el fichero /var/log/syslog y encontramos la línea:

dhcpd: Not configured to listen on any interfaces!

Editamos el fichero /etc/default/dhcp3-server y suponiendo que este equipo debe ofrecer las direcciones IP a la red a la que está conectado por la interfaz eth0, ponemos:

INTERFACES="eth0"

Además editamos el fichero /etc/dhcp3/dhcpd.conf y definimos un rango de direcciones para el servidor DHCP, por ejemplo:

#################################################
# Líneas para la actualización del servidor DNS:

server-identifier       talut;
ddns-updates            on;
ddns-update-style       interim;
ddns-domainname         "dominio.biz.";
ddns-rev-domainname     "in-addr.arpa.";
deny                    client-updates;     

include                 "/etc/bind/rndc.key";

zone dominio.biz. {
primary 127.0.0.1;
key rndc-key;
}

zone 0.0.10.in-addr.arpa. {
primary 127.0.0.1;
key rndc-key;
}

#################################################
# Configuración general del servidor DHCP

default-lease-time 3600;
max-lease-time 86400;
authoritative;

#################################################
# Se reparten las direcciones 10.0.0.1-10.0.0.127
# entre los clientes:

subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.1 10.0.0.127;
option routers 10.0.0.128;
option domain-name "dominio.biz.";
option domain-name-servers 10.0.0.128;
option broadcast-address 10.0.0.255;
}

Puesta en marcha

Lo primero que haremos será parar ambos servidores y vaciar los ficheros de peticiones dhcp que se pudiesen haber generado:

/etc/init.d/bind9 stop
/etc/init.d/dhcp3-server stop
echo "" > /var/lib/dhcp3/dhcpd.leases
echo "" > /var/lib/dhcp3/dhcpd.leases~


Ponemos en marcha de nuevo los dos servidores y realizamos una petición DHCP desde un cliente de la red, abrimos el fichero /var/log/syslog y si todo va bien nos aparecerán líneas como:

talut dhcpd: DHCPDISCOVER from 00:11:09:60:c6:ec via eth2
talut dhcpd: DHCPOFFER on 192.168.0.2 to 00:11:09:60:c6:ec (jondalar) via eth2
talut named[4596]: client 127.0.0.1#51880: signer "rndc-key" approved
talut named[4596]: client 127.0.0.1#51880: updating zone 'dominio.biz/IN': adding an RR at jondalar.dominio.biz' A
talut named[4596]: client 127.0.0.1#51880: updating zone 'dominio.biz/IN': adding an RR at 'jondalar.dominio.biz' TXT
talut named[4596]: journal file db.dominio.jnl does not exist, creating it
talut dhcpd: Added new forward map from jondalar.dominio.biz. to 10.0.0.2
talut named[4596]: client 127.0.0.1#39603: signer "rndc-key" approved
talut named[4596]: client 127.0.0.1#39603: updating zone '0.0.10.in-addr.arpa/IN': deleting rrset at '2.0.0.10.in-addr.arpa' PTR
talut named[4596]: client 127.0.0.1#39603: updating zone '0.0.10.in-addr.arpa/IN': adding an RR at '2.0.0.10.in-addr.arpa' PTR
talut named[4596]: journal file db.10.0.0.jnl does not exist, creating it
talut named[4596]: zone 0.0.10.in-addr.arpa/IN: sending notifies (serial 200811133)
talut dhcpd: added reverse map from 2.0.0.10.in-addr.arpa. to jondalar.dominio.biz.
talut dhcpd: DHCPREQUEST for 192.168.0.2 (127.0.1.1) from 00:11:09:60:c6:ec (jondalar) via eth2
talut dhcpd: DHCPACK on 192.168.0.2 to 00:1d:09:60:c6:ec (jondalar) via eth2

También podemos comprobar que se han creado dos nuevos ficheros en el directorio de trabajo de bind:

-rw-r--r-- 1 bind bind 844 nov 14 18:08 db.10.0.0.jnl
-rw-r--r-- 1 bind bind 911 nov 14 18:08 db.dominio.jnl

Es evidente que se generan gran cantidad de registros en el fichero /var/log/syslog, es posible sacar estos registros a un fichero propio como se explica en crear un registro (log) propio para una aplicación.

Configuración de los clientes DHCP

El principal requisito que debe cumplir un cliente DHCP para funcionar en este entorno es que debe enviar el nombre del host (hostname) en la petición inicial. El cliente más habitual en las distribuciones linux es dhcp3-client, que no viene configurado inicialmente para enviar el hostname. Para solucionar esto editamos el fichero /etc/dhcp3/dhclient.conf e incluimos la línea:

send host-name jondalar;

donde hay que sustituir jondalar por el nombre correspondiente. No he encontrado na solución general, seguiré buscando …

Referencias

He cogido bastantes ideas de los siguientes enlaces:

, , , , ,

  1. #1 por Mstaaravin el 15-11-08 - 4:19 am

    Excelente, estaba buscando algo asi justamente.
    Saludos

    Me gusta

  2. #2 por albertomolina el 15-11-08 - 6:53 pm

    Me alegro de que te venga bien Mstaaravin, si encuentras alguna solución más elegante para la configuración de los clientes, te lo agradezco ;)

    Me gusta

  3. #3 por Raul el 5-12-09 - 6:24 am

    ¿Como puedo poner un servidor DDNS pero no para mi LAN, si que se pueda usar desde internet, es decir, algo asi como dyndns.org o bien, no-ip.com, ETC.??

    Me gusta

  4. #5 por Freddy Taborda el 16-01-10 - 1:01 am

    Alberto Molina, excelente material, con tu permiso lo estoy copiando para mi sitio y le hare unas modificaciones para adaptarlo a mis necesidades.

    Saludos

    Me gusta

  5. #6 por Leonard el 8-01-14 - 10:19 pm

    Hola alberto es un buen articulo!!
    Te felicito por ello.

    Me surge la siguiente duda, es posible configurar un servidor con (ip publica, accesible por internet)
    utilizando este metodo de dns, para identificar hosts en una red LAN ??

    Me gusta

  6. #7 por javier el 15-10-09 - 1:38 pm

    Hola Alberto! en primer lugar felicitarte por el manual es genial y todo muy bien explicado…pero tengo un problema que tal vez puedas ayudarme a solucionar…

    Despues de hacer todos los pasos y configuraciones cuando activo el dhcp me da error diciendome que no puede abrir el fichero rndc.key: permiso denegado…

    Lo curioso esque ya le he cambiado el permiso a otros para que pueda leerlo…y el usuario esta creado y agregado al grupo para mas incredulidad…

    Sabrias decirme que puede estar pasando??

    Mil gracias!

    Me gusta

  7. #8 por albertomolina el 15-10-09 - 5:39 pm

    Hoja Javier,

    Parece que debe estar relacionado con los permisos del usuario bind, deberás comprobar la configuración de forma detallada. La primera vez que lo hice cambié el propietario de named a root (modificando el fichero /etc/default/bind9) y después cuando ya estaba funcionando volví a poner a bind como usuario que ejecuta named y encontré el problema de permisos que comento.

    Suerte!

    Me gusta

  1. jpcozar-public: DNS dinámico y DHCP en ubuntu
  2. Problemas con DNS dinámico en Debian Squeeze - PLEDIN 2.0

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: