Source: http://foro.bitsdelocos.es/index.php?topic=3412.0
Timestamp: 2019-11-11 20:21:04+00:00

Document:
Autor Tema: Actualizar DNS con DHCP (Leído 609 veces)
« en: Abril 29, 2017, 11:00:47 am »
En la entrada anterior vimos como montar un servidor bind y un server dhcp en linux para bloquear la resolución de algunas webs en nuestra red de área local. (Suplantando nuestros dns en la red local). Ya que tenemos el laboratorio montado en casa, podemos mejorar sus funcionalidades haciendo que todos los dispositivos que reciban una dirección DHCP de nuestro servidor queden registrados en el DNS con una entrada dinámica. Hacerlo a mano sería bastante laborioso y en breves tendríamos la zona dns desactualizada.
Para ello me he creado una zona a la que llamaré “canostra.local”, esta zona engloba mi red local. Siguiendo con el ejemplo anterior, tendremos 3 dispositivos en la red:
192.168.22.1  --> Gateway
192.168.22.2  --> Equipo Windows con reserva de DHCP
192.168.22.11 --> DNS + DHCP.
Para poder crear el dynamic dns, el primer paso es editar el archivo para crear las nuevas zonas:
Se van a crear 2 zonas, la primera de resolución directa (cuando haces un nslookup de un dominio para que te devuelva la ip) y la segunda zona de resolución inversa (al hacer un nslookup de una ip el dns puede devolverte el dominio asociado). Además de estas zonas, debemos decir que solo se permita actualizar dinámicamente una zona desde el servidor dhcp, en este caso la misma raspberry pi (127.0.0.1), además de especificar la clave que se debe usar para realizar el update.
### dynamic zones (updated by DDNS) #########
zone "canostra.local" {
file "/etc/bind/db.canostra.local";
zone "22.168.192.in-addr.arpa" {
file "/etc/bind/db.192.168.22";
Si os fijáis en la segunda zona tiene un nombre un poco extraño, esto es una zona “legacy” de los principios de Internet. El formato del nombre de la zona viene especificado por la red a la que va a resolver con sus octetos en orden inverso.
Los siguiente que neceistamos hacer es crear los archivos
/etc/bind/db.canostra.local
/etc/bind/db.192.168.22
En estos archivos especificaremos la zona y sus propiedades:
$TTL 86400      ; 1 day
canostra.local            IN SOA  ns.canostra.local. root.localhost. (
3          ; serial
604800     ; refresh (1 week)
86400      ; retry (1 day)
2419200    ; expire (4 weeks)
604800     ; minimum (1 week)
NS      ns.canostra.local.
A       192.168.22.1
$ORIGIN canostra.local.
mi-pc                   A       192.168.22.2
ns                      NS      192.168.22.11
Fijaos bien en la notación de “canostra.local IN SOA ns.canostra.local. root.localhost. ” y los puntos al final del ns, si no los ponemos no funcionará y dará un error de carga. El otro punto importante es que el “email” debe existir, en nuestro caso root.localhost existe por defecto. Con esta configuración conseguiremos que al registrarse nuevas máquinas en la red, vayan apareciendo entradas del tipo A en esta zona.
$TTL 907200     ; 1 week 3 days 12 hours
22.168.192.in-addr.arpa IN SOA  ns.canostra.local. root.localhost. (
28800      ; refresh (8 hours)
604800     ; retry (1 week)
$ORIGIN 22.168.192.in-addr.arpa.
$TTL 3600       ; 1 hour
1                        PTR     canostra.local.
6                        PTR     mi-pc.canostra.local
Igual que antes tened cuidado con los puntos al final de los dominios. Con esta configuración se ha conseguido crear la zona inversa de resolución para el dominio canostra.local.
Para comprobar que todo funciona se debe reiniciar el servicio de dns:
Si todo va bien, podemos probar la resolución directa y la resolución inversa:
$nslookup mi-pc.canostra.local
Server:         127.0.0.1
Address:        127.0.0.1#53
Name:   mi-pc.canostra.local
Address: 192.168.22.6
$ nslookup 192.168.22.6
6.22.168.192.in-addr.arpa       name = mi-pc.canostra.local.22.168.192.in-addr.arpa.
$ nslookup 192.168.22.1
1.22.168.192.in-addr.arpa       name = canostra.local.
Si el DNS ha conseguido resolver estas direcciones es que lo hemos creado correctamente. Como siempre es recomendable ir revisando el syslog ya que da pistas sobre los errores que podemos tener en la configuración.
Si en el syslog vemos que aparecen errores del tipo
zone canostra.local/IN: MI_PC.canostra.local/A: bad owner name
Es debido a que la barra baja no está permitida por defecto, para habilitarla deberemos editar el archivo:
Y añadir las entradas:
Si vemos errores de que hay problemas de integridad con dnssec, será necesario añadir las siguientes opciones al mismo archivo:
Para que DHCP pueda actualizar las entradas DNS será necesario un último paso, dar permisos de escritura al usuario bind a la carpeta donde están las zonas:
chown -R bind:bind /etc/bind/
En este punto del manual, ya podemos pasar a editar la configuración de DHCP:
sudo cat /etc/dhcp/dhcpd.conf
En este archivo debemos comentar la línea:
Y añadir las siguientes justo abajo:
#Configuracion para integrar con dns#
zone canostra.local. {
ddns-domainname "canostra.local";
Con estas líneas especificamos que zona se debe utilizar para actualizar el dns, y con que clave. Además en la configuración del rango de DHCP debemos volverlo a especificar (además de especificar la zona inversa):
range 192.168.22.15 192.168.22.250;
#integracion ddns
# DNS zones to update
zone 22.168.192.in-addr.arpa. {
primary 192.168.22.11;
Ya solo queda reiniciar el servidor dhcp y revisar que se añaden entradas en el dns, para ello basta con observar el archvio de syslog. En este punto he conectado mi teléfono a la red local:
tail -200f /var/log/syslog
Apr 29 09:35:03 raspberrypi named[3036]: client 192.168.22.11#42676/key rndc-key: updating zone 'canostra.local/IN': adding an RR at 'MI-TELEFONO.canostra.local' A
Apr 29 09:35:03 raspberrypi dhcpd: Added new forward map from MI-TELEFONO.canostra.local to 192.168.22.200
Apr 29 09:35:03 raspberrypi named[3036]: client 192.168.22.11#42676/key rndc-key: signer "rndc-key" approved
Apr 29 09:35:03 raspberrypi named[3036]: client 192.168.22.11#42676/key rndc-key: updating zone '22.168.192.in-addr.arpa/IN': deleting rrset at '200.22.168.192.in-addr.arpa' PTR
Apr 29 09:35:03 raspberrypi named[3036]: client 192.168.22.11#42676/key rndc-key: updating zone '22.168.192.in-addr.arpa/IN': adding an RR at '200.22.168.192.in-addr.arpa' PTR
Apr 29 09:35:03 raspberrypi dhcpd: Added reverse map from 200.22.168.192.in-addr.arpa. to MI-TELEFONO.canostra.local
Si hicieras un ping a MI-TELEFONO.canostra.local debería contestarte:
ping MI-TELEFONO.canostra.local
PING MI-TELEFONO.canostra.local (192.168.22.200) 56(84) bytes of data.
64 bytes from MI-TELEFONO.canostra.local (192.168.22.200): icmp_seq=1 ttl=64 time=279 ms
64 bytes from MI-TELEFONO.canostra.local (192.168.22.200): icmp_seq=2 ttl=64 time=220 ms
64 bytes from MI-TELEFONO.canostra.local (192.168.22.200): icmp_seq=3 ttl=64 time=156 ms
Si quisiéramos poder resolver los nombres de hosts sin tener que especificar el dominio, deberíamos añadir la siguiente linea en el archivo de configuración de dhcp:
option domain-search "canostra.local";
Pues con esto la entrada de hoy, espero que os haya gustado.
« Respuesta #1 en: Abril 30, 2017, 10:48:45 pm »
¿No sería preferible usar el dominio canostra.local? Así si alguien compra el dominio público canostra.com no sería accesible desde vuestra red
« Respuesta #2 en: Mayo 01, 2017, 08:34:34 am »
Preferiblemente sí, pero como todos los manuales que aparecen en esta web son orientativos no son datos reales los que aparecen. PD: ahora lo corrijo.

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución