Dnsmasq y Active Directory – Redes PYME
¡Hola amigos!. Para comprender y seguir correctamente éste artículo es imprescindible la lectura de sus antecesores:
En ellos se explican conceptos teóricos y prácticos a los que no haremos referencia en éste. Cambiaremos de distribución en el ejercicio actual hacia Debian 8.6 “Jessie” y continuaremos con los mismos parámetros que usamos en BIND y Active Directory®.
- El procedimiento descrito en éste post, también es válido para CentOS 7. El archivo de configuración /etc/dnsmasq es el mismo. Lo declaro porque considero innecesario confeccionar un artículo aparte para Dnsmasq y Active Directory® basado en CentOS. Por suerte, los directorios relativos a la documentación y configuración, son los mismos.
- El Dnsmaq es una creación de Simon Kelley <simon@thekelleys.org.uk>
Límites sobre el uso del Dnsmasq
Por su importancia repetimos los LÍMITES que soporta el Dnsmasq -ejecuten man dnsmasq– el cual refleja exactamente lo siguiente:
LÍMITES
- Los valores predeterminados para limites de recursos son generalmente conservadores, y apropiados para uso en dispositivos tipo enrutador encrustrado con procesadores lentos y poca memoria. En hardware más capáz, es posible incrementar los límites, y soportar muchos mas clientes. Lo siguiente se aplica a dnsmasq-2.37: versiones previas no escalaban tan bien.
- Dnsmasq es capaz de soportar con DNS y DHCP a por lo menos mil (1,000) clientes. Los tiempos de arriendo no deben ser muy cortos (menos de una hora). El valor de –dns-forward-max puede ser aumentado: comience con el equivalente a el número de clientes y auméntelo si parece lento el DNS. Nótese que el rendimiento DNS depende también de los servidores DNS upstream. El tamaño del caché DNS puede ser incrementado: el límite obligatorio es 10,000 nombres y el predeterminado (150) es muy bajo. El enviarle un SIGUSR1 a dnsmasq hace que bitacore información que es útil para afinar el tamaño de caché. Ver la sección NOTAS para detalles.
- El servidor TFTP incorporado es capáz de soportar varias transferencias simultáneas de archivos: el límite absoluto está relacionado con el número de file-handles permitidos a un proceso y la habilidad del sys‐tem call select() a soportar números grandes de file-handles. Si el límite es fijado demasiado alto con –tftp-max será de-escalado y el límite real será bitacoreado al inicio. Nótese que más transferencias son posibles cuando el mismo archivo es enviado qué cuando cada transferencia envía un archivo diferente. Es posible usar dnsmasq para negar publicidad Web usando una lista de servidores de banners bien conocidos, todos resolviendose a 127.0.0.1 o 0.0.0.0 en /etc/hosts o en un archivo hosts adicional. La lista puede ser muy larga. Dnsmasq ha sido probado exitósamente con un millón de nombres. Ese tamaño de archivo necesita un CPU de 1GHz y aproximadamente 60MB de RAM.
- Dnsmasq es capaz de soportar con DNS y DHCP a por lo menos mil (1,000) clientes.
Instalemos y configuremos a Jessie y al Dnsmasq
Partiremos de una instalación nueva y limpia de un servidor basado en Debian 8 “Jessie”. O sea, el sistema operativo sin interfaz gráfica ninguna u otro paquete instalado. Los parámetros de la red serán los mismos que utilizamos en el artículo BIND y Active Directory®:
Nombre de dominio mordor.fan Red LAN 10.10.10.0/24 =============================================================================== Servidores Dirección IP Propósito (Servidores con SO Windows) =============================================================================== sauron.mordor.fan. 10.10.10.3 Active Directory® 2008 SR2 mamba.mordor.fan. 10.10.10.4 Servidor de archivos Windows dns.mordor.fan 10.10.10.5 Servidor DnsMasq sobre Jessie darklord.mordor.fan. 10.10.10.6 Proxy, gateway y firewall sobre Kerios troll.mordor.fan. 10.10.10.7 Blog basado en... no recuerdo shadowftp.mordor.fan. 10.10.10.8 Servidor FTP blackelf.mordor.fan. 10.10.10.9 Servicio e-mail completo blackspider.mordor.fan. 10.10.10.10 Servicio WWW palantir.mordor.fan. 10.10.10.11 Chat en Openfire para Windows Real CNAME ============================== sauron ad-dc mamba fileserver darklord proxyweb troll blog shadowftp ftpserver blackelf mail blackspider www palantir openfire
Configuraciones iniciales del servidor dns.mordor.fan
root@dns:~# nano /etc/hostname
dns
root@dns:~# nano /etc/hosts
127.0.0.1 localhost
10.10.10.5 dns.mordor.fan dns
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
root@dns:~# nano /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 10.10.10.5
netmask 255.255.255.0
network 10.10.10.0
broadcast 10.10.10.255
gateway 10.10.10.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 127.0.0.1
dns-search mordor.fan
Instalemos el Dnsmasq y htop
root@dns:~# aptitude install dnsmasq htop
Después de instalar el paquete htop podemos comprobar los consumos de CPU y memoria del equipo. Solo estaba consumiendo unos 71 megas de RAM. Si queremos bajar aun mas el consumo, podemos instalar el paquete SSMTP -sencillo MTA– que a su vez purga el paquete Exim4 que Debian siempre instala por defecto y que realmente no necesitamos acorde al uso que daremos a éste servidor:
root@dns:~# aptitude install ssmtp root@dns:~# aptitude purge ~c root@dns:~# aptitude clean root@dns:~# aptitude autoclean root@dns:~# systemctl reboot
Después de reiniciar el equipo, el consumo es el siguiente: 
Bajo, ¿no?. Continuemos adelante.
Indiquemos que el Dnsmasq consulte -además- al Microsft® DNS
Para probar las posibles configuraciones del Dnsmasq en el equipo dns.mordor.fan, debemos incluir una declaración que indique que se consulte al Microsoft DNS del servidor sauron.mordor.fan. Lo podemos hacer incluyendo la directiva server=/mordor.fan/10.10.10.3 en el archivo dnsmasq.conf -como veremos mas adelante- o adicionando la línea nameserver 10.10.10.3 en el archivo /etc/resolv.conf. Como aun no hemos configurado al Dnsmasq acorde a nuestras necesidades, elegimos la segunda forma:
root@dns:~# nano /etc/resolv.conf
domain mordor.fan
nameserver 127.0.0.1
nameserver 10.10.10.3
Ya podemos resolver consultas DNS
Con la configuración por defecto del Dnsmasq que aporta su archivo principal /etc/dnasmq.conf, y con lo declarado en el archivo /etc/resolv.conf del propio servidor “dns“, cualquier cliente conectado a la LAN -y que tenga declarado como servidor DNS a dns.mordor.fan– podrá resolver consultas DNS a expensas del Microsoft® DNS por ahora…
- Muy importante es comprobar la velocidad de respuesta del Dnsmasq al hacer gala de su condición de Forwarder por la sola inclusión de la IP 10.10.10.3 en su archivo /etc/resolv.conf.
Desde mi estación de trabajo administrativa y soporte de toda la parafernalia mediante la cual escribo, ejecuto:
buzz@sysadmin:~$ cat /etc/resolv.conf # Generated by NetworkManager domain mordor.fan nameserver 10.10.10.5 buzz@sysadmin:~$ nslookup > dns Server: 10.10.10.5 Address: 10.10.10.5#53 Name: dns.mordor.fan Address: 10.10.10.5 > sauron Server: 10.10.10.5 Address: 10.10.10.5#53 Non-authoritative answer: Name: sauron.mordor.fan Address: 10.10.10.3 > 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan Server: 10.10.10.5 Address: 10.10.10.5#53 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan canonical name = sauron.mordor.fan. Name: sauron.mordor.fan Address: 10.10.10.3 > 10.10.10.3 Server: 127.0.0.1 Address: 127.0.0.1#53 3.10.10.10.in-addr.arpa name = sauron.mordor.fan. > 10.10.10.9 Server: 127.0.0.1 Address: 127.0.0.1#53 9.10.10.10.in-addr.arpa name = blackelf.mordor.fan. > 10.10.10.5 Server: 127.0.0.1 Address: 127.0.0.1#53 5.10.10.10.in-addr.arpa name = dns.mordor.fan. > mail Server: 10.10.10.5 Address: 10.10.10.5#53 Non-authoritative answer: mail.mordor.fan canonical name = blackelf.mordor.fan. Name: blackelf.mordor.fan Address: 10.10.10.9 > exit buzz@sysadmin:~$
Observemos en detalle los siguientes aspectos:
- dns.mordor.fan responde directamente las consultas DNS que pueda resolver de acuerdo con la configuración actual de su Dnsmasq. Sino las puede resolver funciona como Forwarder y le pregunta a la IP 10.10.10.3 si puede responder a la consulta. Cuando se le pregunta por la IP del equipo “dns“, responde él directamente. Cuando se le pregunta al Dnsmasq ¿quién es “sauron“,?, hace forwarding a la 10.10.10.3 -no puede responder directamente pues aun no lo tiene registrado- quien le devuelve una Respuesta No Autoritaria correcta.
- Cuando se le pregunta ¿quién es “03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan“?, hace forwarding nuevamente y en ésta ocasión recibe una Respuesta Autoritaria del Microsoft® DNS.
- La alta velocidad de respuesta del Dnsmasq para cualquier tipo de consulta.
Son pequeños detalles que hacen grande un amor ;-).
Diferencias fundamentales entre Dnsmasq y BIND integrados con un Active Directory®
Efectuemos un par de consultas DNS sobre los registro SOA y NS del dominio mordor.fan, a cada uno de los servidores de nombre involucrados:
buzz@sysadmin:~$ host -t SOA mordor.fan 10.10.10.3 Using domain server: Name: 10.10.10.3 Address: 10.10.10.3#53 Aliases: mordor.fan has SOA record sauron.mordor.fan. hostmaster.mordor.fan. 56 900 600 86400 3600 buzz@sysadmin:~$ host -t SOA mordor.fan 10.10.10.5 Using domain server: Name: 10.10.10.5 Address: 10.10.10.5#53 Aliases: mordor.fan has SOA record sauron.mordor.fan. hostmaster.mordor.fan. 56 900 600 86400 3600 buzz@sysadmin:~$ host -t NS mordor.fan 10.10.10.5 Using domain server: Name: 10.10.10.5 Address: 10.10.10.5#53 Aliases: mordor.fan name server sauron.mordor.fan. buzz@sysadmin:~$ host -t NS mordor.fan 10.10.10.3 Using domain server: Name: 10.10.10.3 Address: 10.10.10.3#53 Aliases: mordor.fan name server sauron.mordor.fan.
Las respuestas son idénticas -lo que es lógico- pues siempre responde sauron.mordor.fan. ante una consulta DNS sobre registros SOA o NS, aunque parezca que responde el dns.mordor.fan. Sin embargo difiere de lo visto en el artículo BIND y Active Directory® donde habíamos suprimido por completo la funcionalidad del Microsoft® DNS. En ese artículo TODAS las consultas DNS sobre el Espacio de Nombres del Domino mordor.fan las respondía el BIND, porque así lo configuramos, y porque el BIND si responde consultas SOA y NS además de que permite el esquema Master – Slave, transferencia de Zonas, etcétera, y por tanto es un servidor DNS mas completo – complejo.
Acaso esas sean las diferencias principales entre el DNS del Dnsmasq y el BIND… pero el BIND -siempre puede haber uno o mas peros- no tiene un servidor DHCP que se integra perfectamente con un servidor DNS en un solo daemond, y sin necesidad de claves TSIG, archivos de configuraciones, bases de datos de Zonas, etcétera, como hemos vistos en artículos anteriores.
- Creo que a ésta altura, los Estimados Lectores se habrán dado cuenta de que no odio al BIND ni prefiero al Dnsmasq antes que el BIND. Futuras discusiones al respecto son una total pérdida de tiempo, pues tiene que ver mucho con necesidades, exigencias, gustos, preferencias y ... cada solución tiene su encanto ;-).
- En escenarios similares, que cada cual instale y configure el software de su preferencia y que mas conozca y que todo le funcione como espera.
Ventajas de la combinación Dnsmasq + Active Directory®
Con ésta combinación tenemos el abanico completo de respuestas a consultas DNS y un eficaz medio de arrendamiento de direcciones IP para nuestra LAN PYME. Como veremos mas adelante, funciona correctamente para cualquier situación con respecto a si el equipo está unido o no al Controlador de Dominio del Microsoft® Active Directory®. Además, disponemos de un servidor DNS y DNS Forwarder por excelencia, más un servidor DHCP muy rápido. Y todo con poca demanda de recursos. ¿Desea más?.
¿Es posible Dnsmasq + BIND?
Definitivamente SI. Aunque recomiendo se instalen en equipos diferentes para que no existan choques por el tan querido puerto 53 del servicio DNS. Tal vez y veamos algo al respecto cuando lleguemos al AD-DC basado en Samba 4. ¿Quién sabe?.
Tips sobre el Dnamasq
- Los archivos imprescindibles de trabajo para que el Dnsmasq brinde los servicios DHCP y DNS en una LAN son: /etc/dnsmasq.conf, /etc/hosts, /var/lib/misc/dnsmasq.leases, y /etc/resolv.conf. El archivo dnsmasq.leases se crea cuando arrienda su primera dirección IP.
- Otro archivo de trabajo que puede utilizar es /etc/ethers. De existir ese archivo, la directiva read-ethers declarada en el archivo de configuración, le indica al Dnsmasq que lo lea. Es muy útil cuando relacionamos direcciones MAC/nombres de hosts para determinados propósitos.
- El servicio DNS se puede deshabilitar completamente mediante la directiva port=0 en el dnsmasq.conf.
- El servicio DHCP para una o más interfaces de red se puede deshabilitar mediante directivas -una por cada línea- no-dhcp-interface=eth0, no-dhcp-interface=eth1, y así sucesivamente. Muy útil cuando estemos frente a un equipo con 2 -o más- interfaces de red y queremos se brinde el servicio DHCP solo por una de ellas o por ninguna. Por supuesto que, si deshabilitamos el servicio DHCP por todas las interfaces, dejaremos solamente en funcionamiento al servicio DNS. Si deshabilitamos ambos servicios, entonces ¿para qué necesitamos al Dnsmasq?.
- Para declarar a otros Servidores de Nombre de Dominio DNS que no sean públicos o externos a la LAN -como el caso del Microsoft DNS- lo hacemos mediante la directiva server=/nombre del dominio/IP del servidor DNS en el archivo /etc/dnsmasq.conf. Ejemplo: server=/mordor.fan/10.10.10.3.
- Para indicar al Dnsmasq que las consultas sobre los dominios locales sean respondidas solamente desde el archivo /etc/hosts o mediante su DHCP, debemos agregar la directiva local=/localnet/ en el archivo principal de su configuración. Ejemplo: local=/mordor.fan/.
- Para configurar correctamente el archivo /etc/resolv.conf – resolver sugerimos la lectura de su manual mediante el comando man resolv.conf. Si instalan el Debian 8.6 “Jessie” encontrarán que está bien redactado en lengua hispana.
- El Dnsmasq no utiliza archivos de Zonas para responder a consultas directas o inversas.
- Para conocer el significado de cada campo “especial” que se utiliza en la declaración de un Registro de Recurso SRV, debe consultar BIND y Active Directory®. La sintaxis de los registros SRV en el archivo /etc/dnsmasq.conf es la siguiente:
srv-host=<Service-Name>,<Target>,<Port>,<Priority>,<Wight>
Los Lectores que deseen conocer más, por favor lean con detenimiento el archivo original /etc/dnsmasq.conf o los documentos existentes en el directorio /usr/share/doc/dnsmasq-base.
root@dns:~# ls -l /usr/share/doc/dnsmasq-base/ total 128 -rw-r--r-- 1 root root 883 may 5 2015 copyright -rw-r--r-- 1 root root 36261 may 5 2015 changelog.archive.gz -rw-r--r-- 1 root root 11297 may 5 2015 changelog.Debian.gz -rw-r--r-- 1 root root 26014 may 5 2015 changelog.gz -rw-r--r-- 1 root root 2084 may 5 2015 DBus-interface.gz -rw-r--r-- 1 root root 4297 may 5 2015 doc.html drwxr-xr-x 2 root root 4096 feb 19 17:52 examples -rw-r--r-- 1 root root 9721 may 5 2015 FAQ.gz -rw-r--r-- 1 root root 4180 may 5 2015 README.Debian -rw-r--r-- 1 root root 12019 may 5 2015 setup.html
Configuremos al Dnsmasq y al Resolver
Tomaremos como guía inicial -cambiando los nombres y demás, por supuesto- el archivo de configuración empleado en el artículo “Dnsmasq en CentOS 7.3“.
No olvidemos el siguiente paso:
[root@dns ~]# mv /etc/dnsmasq.conf /etc/dnsmasq.conf.original
Direcciones IP fijas
Las direcciones de los servidores o equipos que requieran de una IP fija -tanto IPv4 como IPv6– se declaran en el archivo /etc/hosts:
[root@dns ~]# nano /etc/hosts 127.0.0.1 localhost # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters # Servidores y equipos con IP fijas. 10.10.10.1 sysadmin.mordor.fan 10.10.10.3 sauron.mordor.fan 10.10.10.4 mamba.mordor.fan 10.10.10.5 dns.mordor.fan 10.10.10.6 darklord.mordor.fan 10.10.10.7 troll.mordor.fan 10.10.10.8 shadowftp.mordor.fan 10.10.10.9 blackelf.mordor.fan 10.10.10.10 blackspider.mordor.fan 10.10.10.11 palantir.mordor.fan
Creemos el archivo /etc/dnsmasq.conf
[root@dns ~]# nano /etc/dnsmasq.conf
# -------------------------------------------------------------------
# O P C I O N E S G E N E R A L E S
# -------------------------------------------------------------------
domain-needed # No pasar nombres sin la parte del dominio
bogus-priv # No pasar direcciones en el espacio no enrutado
expand-hosts # Adiciona automaticamente el dominio al host
interface=eth0 # Interface. OJO con la Interface
# except-interface=eth1 # NO escuchar por esta NIC
strict-order # Orden en que consulta el archivo /etc/resolv.conf
# Incluya muchas mas opciones de configuración
# mediante un archivo o ubicando los archivos
# de configuración adicionales en un directorio
# conf-file=/etc/dnsmasq.more.conf
conf-dir=/etc/dnsmasq.d
# Relativos al Nombre del Dominio
domain=mordor.fan # Nombre del dominio
# El Servidor de Tiempo es 10.10.10.1
address=/time.windows.com/10.10.10.1
# Envía una opción vacía del valor WPAD. Se requiere para que
# se comporten bien los clientes Windos 7 y posteriores. ;-)
dhcp-option=252,"\n"
# Archivo donde declararemos los HOSTS que serán "baneados"
addn-hosts=/etc/banner_add_hosts
# Consultar al servidor Microsoft® DNS "sauron" si es que
# lo dejamos en funcionamiento
server=/mordor.fan/10.10.10.3
# Las consultas sobre los dominios locales serán respondidas
# desde /etc/hosts o mediante DHCP
local=/mordor.fan/
# Las consultas sobre registros PTR o Inversas, serán respondidas
# por los servidores "dns" y "sauron" en ese orden
server=/10.10.10.in-addr.arpa/10.10.10.5
server=/10.10.10.in-addr.arpa/10.10.10.3
# -------------------------------------------------------------------
# R E G I S T R O S C N A M E M X T X T
# -------------------------------------------------------------------
# Este tipo de registro requiere de una entrada
# en el archivo /etc/hosts
# ej: 10.10.0.7 troll.mordor.fan troll
# cname=ALIAS,REAL_NAME
cname=ad-dc.mordor.fan,sauron.mordor.fan
cname=fileserver.mordor.fan,mamba.mordor.fan
cname=proxyweb.mordor.fan,darklord.mordor.fan
cname=blog.mordor.fan,troll.mordor.fan
cname=ftpserver.mordor.fan,shadowftp.mordor.fan
cname=mail.mordor.fan,blackelf.mordor.fan
cname=www.mordor.fan,blackspider.mordor.fan
cname=opendire.mordor.fan,palantir.mordor.fan
# REGISTROS MX
# Devuelve un registro MX con el nombre "mordor.fan" con destino
# al equipo blackelf.mordor.fan y prioridad de 10
mx-host=mordor.fan,mail.mordor.fan,10
# El destino por defecto para los registros MX que se creen
# utilizando la opción localmx será:
mx-target=mail.mordor.fan
# Devuelve un registro MX apuntando al mx-target para TODAS
# las máquinas locales
localmx
# Registros TXT. Podemos declarar también un registro SPF
txt-record=mordor.fan,"v=spf1 a -all"
txt-record=mordor.fan,"Wellcome to The Dark Lan of Mordor"
# -------------------------------------------------------------------
# -------------------------------------------------------------------
# R A N G O Y S U S O P C I O N E S
# -------------------------------------------------------------------
# Rango IPv4 y tiempo de arrendamiento
# De la 1 a la 29 son para los Servidores y otras necesidades
dhcp-range=10.10.10.30,10.10.10.250,8h
dhcp-lease-max=222 # Cantidad máxima de direcciones a arrendar
# por defecto son 150
# Rango IPV6
# dhcp-range=1234::, ra-only
# Opciones para el RANGO
# O P C I O N E S
dhcp-option=1,255.255.255.0 # NETMASK
dhcp-option=3,10.10.10.253 # ROUTER GATEWAY
dhcp-option=6,10.10.10.5 # DNS Servers
dhcp-option=15,mordor.fan # DNS Domain Name
dhcp-option=19,1 # option ip-forwarding ON
dhcp-option=28,10.10.10.255 # BROADCAST
dhcp-option=42,10.10.10.1 # NTP
# dhcp-option=40,MORDOR # NIS Domain Name
# dhcp-option=41,10.10.10.3 # NIS Server
# dhcp-option=44,10.10.10.3 # WINS
# dhcp-option=45,10.10.10.3 # Datagramas NetBIOS
# dhcp-option=73,10.10.10.3 # Finger Server
# dhcp-option=46,8 # Nodo NetBIOS
dhcp-authoritative # DHCP Autoritario en la subnet
# -------------------------------------------------------------------
# -------------------------------------------------------------------
# L O G G I N G tail -f /var/log/syslog o journalctl -f
# -------------------------------------------------------------------
log-queries
# -------------------------------------------------------------------
# Registros A y SRV correspondientes al Active Directory
# -------------------------------------------------------------------
# Registros A
address=/gc._msdcs.mordor.fan/10.10.10.3
address=/DomainDnsZones.mordor.fan/10.10.10.3
address=/ForestDnsZones.mordor.fan/10.10.10.3
# Registro CNAME de la Zona del Microsoft DNS _msdcs.mordor.fan
cname=03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan,sauron.mordor.fan
# Registros SRV
# srv-host=<Service-Name>,<Target>,<Port>,<Priority>,<Wight>
# Global Catalog
# Zona _msdcs.mordor.fan del Microsoft DNS
srv-host=_ldap._tcp.gc._msdcs.mordor.fan,sauron.mordor.fan,3268,0,0
srv-host=_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan,sauron.mordor.fan,3268,0,0
# Zona mordor.fan del Microsoft DNS
srv-host=_gc._tcp.mordor.fan,sauron.mordor.fan,3268,0,0
srv-host=_gc._tcp.Default-First-Site-Name._sites.mordor.fan,sauron.mordor.fan,3268,0,0
# LDAP modificado y privado de un Active Directory
# Zona _msdcs.mordor.fan del Microsoft DNS
srv-host=_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan,sauron.mordor.fan,389,0,0
srv-host=_ldap._tcp.dc._msdcs.mordor.fan,sauron.mordor.fan,389,0,0
srv-host=_ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan,sauron.mordor.fan,389,0,0
srv-host=_ldap._tcp.pdc._msdcs.mordor.fan,sauron.mordor.fan,389,0,0
# Zona mordor.fan del Microsoft DNS
srv-host=_ldap._tcp.mordor.fan,sauron.mordor.fan,389,0,0
srv-host=_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan,sauron.mordor.fan,389,0,0
srv-host=_ldap._tcp.DomainDnsZones.mordor.fan,sauron.mordor.fan,389,0,0
srv-host=_ldap._tcp.Default-First-Site-Name._sites.mordor.fan,sauron.mordor.fan,389,0,0
srv-host=_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan,sauron.mordor.fan,389,0,0
srv-host=_ldap._tcp.ForestDnsZones.mordor.fan,sauron.mordor.fan,389,0,0
#
# KERBEROS modificado y privado de un Active Directory
srv-host=_kerberos._tcp.Default-First-Site-Name._sites.mordor.fan,sauron.mordor.fan,88,0,0
srv-host=_kerberos._tcp.mordor.fan,sauron.mordor.fan,88,0,0
srv-host=_kpasswd._tcp.mordor.fan,sauron.mordor.fan,464,0,0
srv-host=_kerberos._udp.mordor.fan,sauron.mordor.fan,88,0,0
srv-host=_kpasswd._udp.mordor.fan,sauron.mordor.fan,464,0,0
# F I N del archivo /etc/dnsmasq.conf
# -------------------------------------------------------------------
Creemos el archivo /etc/banner_add_host
[root@dns ~]# nano /etc/banner_add_hosts 127.0.0.1 windowsupdate.com 127.0.0.1 ctldl.windowsupdate.com 127.0.0.1 ocsp.verisign.com 127.0.0.1 csc3-2010-crl.verisign.com 127.0.0.1 www.msftncsi.com 127.0.0.1 ipv6.msftncsi.com 127.0.0.1 teredo.ipv6.microsoft.com 127.0.0.1 ds.download.windowsupdate.com 127.0.0.1 download.microsoft.com 127.0.0.1 fe2.update.microsoft.com 127.0.0.1 crl.microsoft.com 127.0.0.1 www.download.windowsupdate.com 127.0.0.1 win8.ipv6.microsoft.com 127.0.0.1 spynet.microsoft.com 127.0.0.1 spynet1.microsoft.com 127.0.0.1 spynet2.microsoft.com 127.0.0.1 spynet3.microsoft.com 127.0.0.1 spynet4.microsoft.com 127.0.0.1 spynet5.microsoft.com 127.0.0.1 office15client.microsoft.com 127.0.0.1 addons.mozilla.org 127.0.0.1 crl.verisign.com [root@dns ~]# dnsmasq --test dnsmasq: syntax check OK. [root@dns ~]# systemctl restart dnsmasq.service [root@dns ~]# systemctl status dnsmasq.service
Modifiquemos el archivo /etc/resolv.conf – Resolver
root@dns:~# nano /etc/resolv.conf
domain mordor.fan
search mordor.fan
¿Por qué no tenemos declaradas las habituales líneas en el archivo resolv.conf?. Porque declaramos en el dnsmasq.conf las siguientes directivas:
# Consultar al servidor Microsoft® DNS "sauron" si es que # lo dejamos en funcionamiento server=/mordor.fan/10.10.10.3 # Las consultas sobre los dominios locales serán respondidas # desde /etc/hosts o mediante DHCP local=/mordor.fan/ # Las consultas sobre registros PTR o Inversas, serán respondidas # por los servidores "dns" y "sauron" en ese orden server=/10.10.10.in-addr.arpa/10.10.10.5 server=/10.10.10.in-addr.arpa/10.10.10.3
Consultas desde sysadmin.mordor.fan
El archivo /etc/resolv.conf de éste equipo es:
buzz@sysadmin:~$ cat /etc/resolv.conf # Generated by NetworkManager search mordor.fan nameserver 10.10.10.5
buzz@sysadmin:~$ host -t A spynet4.microsoft.com spynet4.microsoft.com has address 127.0.0.1 buzz@sysadmin:~$ host -t A www.download.windowsupdate.com www.download.windowsupdate.com has address 127.0.0.1 buzz@sysadmin:~$ dig dns buzz@sysadmin:~$ dig dns.mordor.fan ;; QUESTION SECTION: ;dns.mordor.fan. IN A ;; ANSWER SECTION: dns.mordor.fan. 0 IN A 10.10.10.5 buzz@sysadmin:~$ host -t SRV _ldap._tcp.gc._msdcs buzz@sysadmin:~$ host -t SRV _ldap._tcp.gc._msdcs.mordor.fan _ldap._tcp.gc._msdcs.mordor.fan has SRV record 0 0 3268 sauron.mordor.fan. buzz@sysadmin:~$ dig _ldap._tcp.gc._msdcs.mordor.fan ;; QUESTION SECTION: ;_ldap._tcp.gc._msdcs.mordor.fan. IN A ;; ANSWER SECTION: _ldap._tcp.gc._msdcs.mordor.fan. 0 IN A 10.10.10.3 buzz@sysadmin:~$ dig mordor.fan axfr buzz@sysadmin:~$ dig 10.10.10.in-addr.arpa axfr
Y de esa forma, cuantas consultas necesitemos
Dnsmasq + Active Directory® + Clientes Microsoft® Windows
Cambio de nombre de un cliente Microsoft® Windows
seven.mordor.fan arrendó la dirección IP:
root@dns:~# cat /var/lib/misc/dnsmasq.leases 1488006009 00:0c:29:d6:14:36 10.10.10.115 seven 01:00:0c:29:d6:14:36
Cambiemos el nombre del “seven” -que no está unido al Dominio del Active Directory- por “eucaliptus“. Después del cambio y el reinicio comprobamos:
root@dns:~# cat /var/lib/misc/dnsmasq.leases 1488006633 00:0c:29:d6:14:36 10.10.10.115 eucaliptus 01:00:0c:29:d6:14:36
La historia de los cambios las podemos ver desde “sysadmin”:
buzz@sysadmin:~$ host -t A seven seven.mordor.fan has address 10.10.10.115
Después del cambio de nombre
buzz@sysadmin:~$ host -t A seven seven has no A record buzz@sysadmin:~$ host -t A eucaliptus eucaliptus.mordor.fan has address 10.10.10.115
Consultas desde el cliente eucaliptus.mordor.fan
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\buzz>nslookup
Default Server: dns.mordor.fan
Address: 10.10.10.5
> sauron
Server: dns.mordor.fan
Address: 10.10.10.5
Name: sauron.mordor.fan
Address: 10.10.10.3
> mordor.fan
Server: dns.mordor.fan
Address: 10.10.10.5
Name: mordor.fan
Address: 10.10.10.3
> eucaliptus
Server: dns.mordor.fan
Address: 10.10.10.5
Name: eucaliptus.mordor.fan
Address: 10.10.10.115
> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan
Server: dns.mordor.fan
Address: 10.10.10.5
Name: sauron.mordor.fan
Address: 10.10.10.3
Aliases: 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan
> set type=SRV
> _kerberos._udp.mordor.fan
Server: dns.mordor.fan
Address: 10.10.10.5
_kerberos._udp.mordor.fan SRV service location:
priority = 0
weight = 0
port = 88
svr hostname = sauron.mordor.fan
sauron.mordor.fan internet address = 10.10.10.3
> _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan
Server: dns.mordor.fan
Address: 10.10.10.5
_ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan
SRV service location:
priority = 0
weight = 0
port = 389
svr hostname = sauron.mordor.fan
sauron.mordor.fan internet address = 10.10.10.3
> exit
C:\Users\buzz>
Registro de los clientes Windows en el Microsoft® DNS
Clientes Windows no unidos al Dominio del Active Directory®
Debemos comprobar si se registran correctamente en el Microsoft® DNS, las direcciones IP arrendadas por los diferentes clientes Windows desde el Dnsmasq. Puede influir la forma en que activemos las Actualizaciones dinámicas – Dynamic updates en las Zonas del Microsoft® DNS del Active Directory®. Partimos de la configuración por defecto del Microsoft DNS el cual permite solamente las Actualizaciones Dinámicas Seguras – Dynamic updates –> Secure only, en cada una de sus Zonas.
Observemos que el cliente con el actual FQDN eucaliptus.mordor.fan no está unido al Dominio del Active Directory (o a un Samba4 AD-DC), y constituye una excepción a la regla de Microsoft de que “sólo los clientes registrados en Mi Dominio tendrán permiso a través de Mi Mecanismo de Actualización -que Yo solo conozco- para registrarse en Mi DNS“. Menos mal que el Samba4 AD-DC nos enseña algo al respecto.
eucaliptus.mordor.fan arrendó la IP 10.10.10.115:
buzz@sysadmin:~$ host -t A eucaliptus eucaliptus.mordor.fan has address 10.10.10.115
Cambiemos su nombre por el de “caoba“, reiniciemos el Windows 7, y veamos que sucede cuando preguntamos por los nombres “eucaliptus” y “caoba” a cada uno de los DNS, primero al Microsoft DNS y después al Dnsmasq:
buzz@sysadmin:~$ host -t A eucaliptus.mordor.fan 10.10.10.3 Using domain server: Name: 10.10.10.3 Address: 10.10.10.3#53 Aliases: Host eucaliptus.mordor.fan not found: 3(NXDOMAIN) buzz@sysadmin:~$ host -t A caoba.mordor.fan 10.10.10.3 Using domain server: Name: 10.10.10.3 Address: 10.10.10.3#53 Aliases: Host caoba.mordor.fan not found: 3(NXDOMAIN) buzz@sysadmin:~$ host -t A eucaliptus.mordor.fan 10.10.10.5 Using domain server: Name: 10.10.10.5 Address: 10.10.10.5#53 Aliases: Host eucaliptus.mordor.fan not found: 3(NXDOMAIN) buzz@sysadmin:~$ host -t A caoba.mordor.fan 10.10.10.5 Using domain server: Name: 10.10.10.5 Address: 10.10.10.5#53 Aliases: caoba.mordor.fan has address 10.10.10.115
Podemos cambiar el nombre del cliente Windows 7 que no está unido al Dominio mordor.fan del Active Directory® cuantas veces queramos, que el Microsoft® DNS no se entera de esos cambios ni de que existe tal cliente. ¿Es posible que se deba solamente a que tenemos seleccionada la opción Dynamic updates –> Secure only en cada Zona del Micorosft DNS?.
Para que el Señor Microsoft® DNS se entere de los cambios, debemos seleccionar Dynamic updates –> Nonsecure and secure. Esa opción, Estimados Lectores, implica una significativa vulnerabilidad de la seguridad de cualquier Servidor de Nombres de Dominio que se respete, sea de Microsft® o UNIX®/Linux. El Microsoft® DNS advierte sobre la vulnerabilidad porque al final no es mas que un BIND modificado y privatizado para ofrecernos “Seguridad a cambio de Obscuridad“. Sino, ¿por qué recomienda guardar en su famoso Registro todas las configuraciones y registros DNS de su Microsoft® DNS cuando estamos implementando un Active Directory®?. Además de admitir las actualizaciones no seguras en el Microsoft® DNS, es necesaria la modificación siguiente en la configuración de la tarjeta de red del cliente Windows 7:
Comprobemos:
buzz@sysadmin:~$ host -t A caoba.mordor.fan 10.10.10.3 Using domain server: Name: 10.10.10.3 Address: 10.10.10.3#53 Aliases: caoba.mordor.fan has address 10.10.10.115 buzz@sysadmin:~$ host 10.10.10.115 10.10.10.3 Using domain server: Name: 10.10.10.3 Address: 10.10.10.3#53 Aliases: 115.10.10.10.in-addr.arpa domain name pointer caoba.mordor.fan. buzz@sysadmin:~$ host -t A caoba 10.10.10.5 Using domain server: Name: 10.10.10.5 Address: 10.10.10.5#53 Aliases: caoba.mordor.fan has address 10.10.10.115 buzz@sysadmin:~$ host 10.10.10.115 10.10.10.5 Using domain server: Name: 10.10.10.5 Address: 10.10.10.5#53 Aliases: 115.10.10.10.in-addr.arpa domain name pointer caoba.mordor.fan.
¡Ahora sí. Que bonito sincronismo para dos servidores DNS no sincronizados por ningun medio!, no?.
Clientes Windows unidos al Dominio del Active Directory®
Unamos el cliente caoba.mordor.fan al Dominio, no sin antes eliminar la modificación que hicimos en la configuración de su tarjeta de red, si es que en algún momento la hicimos para comprobar nada más el punto del capítulo anterior. También borremos la entrada de “caoba” en el Microsoft® DNS, y retornemos las Actualizaciones Dinámicas a su punto de origen de “Secure only“. De paso, es válido reiniciar el servicio del Microsoft® DNS.
Después de unido al Dominio, y a pesar de todos nuestros esfuerzos, el cliente “caoba” no aparece registrado en el Microsoft® DNS. Hasta declaramos en el dnsmasq.conf -de forma temporal- que el primer servidor DNS es 10.10.10.3.
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\saruman>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : CAOBA
Primary Dns Suffix . . . . . . . : mordor.fan
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : mordor.fan
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : mordor.fan
Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection
Physical Address. . . . . . . . . : 00-0C-29-D6-14-36
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::352a:b954:7eba:963e%12(Preferred)
IPv4 Address. . . . . . . . . . . : 10.10.10.115(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Saturday, February 25, 2017 8:19:05 AM
Lease Expires . . . . . . . . . . : Saturday, February 25, 2017 4:20:36 PM
Default Gateway . . . . . . . . . : 10.10.10.253
DHCP Server . . . . . . . . . . . : 10.10.10.5
DHCPv6 IAID . . . . . . . . . . . : 251661353
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-20-3B-69-81-00-0C-29-D6-14-36
DNS Servers . . . . . . . . . . . : 10.10.10.3
10.10.10.5
NetBIOS over Tcpip. . . . . . . . : Enabled
Tunnel adapter isatap.mordor.fan:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . : mordor.fan
Description . . . . . . . . . . . : Microsoft ISATAP Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Tunnel adapter Local Area Connection* 9:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft Teredo Tunneling Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
C:\Users\saruman>
buzz@sysadmin:~$ host -t A caoba.mordor.fan 10.10.10.3
Using domain server:
Name: 10.10.10.3
Address: 10.10.10.3#53
Aliases:
Host caoba.mordor.fan not found: 3(NXDOMAIN)
buzz@sysadmin:~$ host -t A caoba.mordor.fan
caoba.mordor.fan has address 10.10.10.115
- De la única forma que se registra el cliente “caoba” en el Microsft® DNS es modificando su tarjeta de red como se indicó en la imagen anterior, o sea, declarando explícitamente que: el sufijo DNS para la conexión es mordor.fan, que registre la dirección de la conexión en el DNS, y que utilice el sufijo DNS declarado al registrar la conexión.
buzz@sysadmin:~$ host -t A caoba.mordor.fan 10.10.10.3 Using domain server: Name: 10.10.10.3 Address: 10.10.10.3#53 Aliases: caoba.mordor.fan has address 10.10.10.115 buzz@sysadmin:~$ host -t A caoba.mordor.fan caoba.mordor.fan has address 10.10.10.115
Cambiemos el nombre de “caoba” a “cedro”
buzz@sysadmin:~$ host -t A caoba.mordor.fan 10.10.10.3 Using domain server: Name: 10.10.10.3 Address: 10.10.10.3#53 Aliases: Host caoba.mordor.fan not found: 3(NXDOMAIN) buzz@sysadmin:~$ host -t A cedro.mordor.fan 10.10.10.3 Using domain server: Name: 10.10.10.3 Address: 10.10.10.3#53 Aliases: cedro.mordor.fan has address 10.10.10.115 buzz@sysadmin:~$ host -t A caoba.mordor.fan 10.10.10.5 Using domain server: Name: 10.10.10.5 Address: 10.10.10.5#53 Aliases: Host caoba.mordor.fan not found: 3(NXDOMAIN) buzz@sysadmin:~$ host -t A cedro.mordor.fan 10.10.10.5 Using domain server: Name: 10.10.10.5 Address: 10.10.10.5#53 Aliases: cedro.mordor.fan has address 10.10.10.115
Y todo normal, como le agrada a los clientes Microsoft® y al Microsoft® DNS que sean las cosas.
Trabajemos con el Microsoft® DHCP y el Microsoft® DNS
Estimados Lectores, éste capítulo está fuera del contexto de un blog dedicado al Software Libre. Consulten la ayuda de Microsoft®. ¿No creen?.
Conclusiones
Existen varias formas de trabajar el Microsoft® DNS cuando hacemos que conviva en una Red PYME con el Dnsmasq. Entre ellas mencionaremos solo las siguientes:
- Detener totalmente el servicio Microsoft® DNS en el equipo donde se esté ejecutando, indicando después que el inicio del servicio está inhabilitado. Desmarcar en la configuración de la tarjeta de red de cada cliente Microsoft® la opción de que Registre la dirección de la conexión en el DNS. Eliminar del archivo /etc/dnsmasq.conf la directiva server=/mordor.fan/10.10.10.3. Notas:
- Aunque no se responda a las consultas sobre los registros SOA y NS, la red funcionará correctamente, así como la unión de los diferentes clientes -Microsoft® y Linux- al Dominio del Active Directory®.
- Tiene la ventaja de que en la LAN PYME solo existirá un Servidor de Nombres de Dominio -macho machote- y será el Dnsmasq. ;-). Por otra parte, se elimina la posibilidad de que ocurran inconsistencias entre los registros DNS almacenados en el Microsoft® DNS y los disponibles mediante el Dnsmasq.
- Dejar en funcionamiento el Microsoft® DNS para que responda solamente las consultas DNS sobre los registros SOA y NS. Notas:
- Modificar la configuración de la tarjeta de red de cada cliente Windows, desmarcando la opción de que Registre la dirección de la conexión en el DNS.
- Pensamos que esta solución es un derroche de recursos.
- Configurar los servicios como hemos visto a lo largo de todo el artículo, el cual muestra una solución más del agrado de la filosofía Microsoft® -que no FreeBSD/Linux- Ok?.
Resumen
- La propuesta del Microsoft® DNS es muy cerrada. No deja espacio alguno para otras soluciones que no estén acorde a su hermética filosofía.
- La Madre Naturaleza nos enseña que existimos en un universo diverso. Lo normal es tener una LAN mixta, en movimiento hacia el Software Libre, y rica en vida y variedad.
- Tal parece que para Microsoft®, los clientes que no se Unan a Su Filosofía son unos Marginados, y por tanto, no debe molestarse en tenerlos en consideración.
- ¡Que difícil es trabajar con Software Privado!. Prefiero pasar un poco de trabajo configurando Software Libre y ser verdaderamente Libre, ¡carajo!.
“El Mejor Criterio de la Verdad es la Práctica”.
El artículo Dnsmasq y Active Directory – Redes PYME aparece primero en Dnsmasq y Active Directory – Redes PYME.
fico
Lástima que no reflejen la cantidad de visitas que ha tenido éste artículo. Lástima que recién me entero de que todos mis artículos se repitan -junto a otros de muy buena calidad- en éste sitio, aunque reconozca que lo hacen de una forma muy respetuosa. Gracias por ello. Lástima que lo han hecho sin mi permiso personal, pues me gustaría mas que siempre me leyeran en el sitio original.