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:
Desde lo alto del Cerro 
Excelente, estaba buscando algo asi justamente.
Saludos
Me gustaMe gusta
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 gustaMe gusta
[…] https://albertomolina.wordpress.com/2008/11/14/dns-dinamico/ page_revision: 0, last_edited: 1232366215|%e %b %Y, %H:%M %Z (%O ago) edittags history files […]
Me gustaMe gusta
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 gustaMe gusta
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 gustaMe gusta
¿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 gustaMe gusta
#Raul, para dyndns tienes ddclient
Me gustaMe gusta
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 gustaMe gusta
[…] pudes encontrar en internet: DNS dinámico con Bind9, de Mario Carrión (antiguo alumno del ciclo), DNS dinámico “Desde lo alto del Cerro” de mi compañero Alberto Molina o este manual que elaboramos […]
Me gustaMe gusta
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 gustaMe gusta
Hola Alberto.
En primer lugar, agradecerte la calidad de este material, que facilita tanto el trabajo diario a los que nos dedicamos a ésto.
En segundo lugar, me gustaría plantearte una cuestión para conocer tu opinión al respecto. ¿Cómo montarías un servidor web en una red local sobre un equipo con IP dinámica, donde el servidor DHCP puede ser un isc-dhcp3-server y el DNS puede ser un BIND9?. ¿Cómo crearías los ALIAS en el DDNS de BIND9, porque está claro que con los registros CNAME no sería, no?, o al menos yo he sido incapaz.
Gracias por todo.
Me gustaMe gusta
Que tal? con este tutorial puedo convertir a mi red en una especie de no-ip? gracias.
Me gustaMe gusta