Dnsmasq y Active Directory – Redes PYME

10
1599

Índice general de la serie: Redes de Computadoras para las PYMES: Introducción

¡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: Dnsmasq y Active Directory

 

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.confresolver 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”.

COMPARTIR
Artículo anteriorUber desde la consola con Uber CLI
Artículo siguienteLux un estupendo tema para Plasma 5
fico

Ingeniero Termo Energético de profesión. Administrador de Redes desde hace ya varios años. Programador en Visual FoxPro. Debianero de Corazón, y “OldFashion Man”.
Contacto: federicotoujague@gmail.com / +53 5 5005735

10 COMENTARIOS

  1. No creo haber visto en el internet (en lenguaje español) una guía más completa y detallada para sysadmin, el trabajo que estás haciendo en Redes para Pymes es para enmarcar.

    Si bien el trabajo es ardúo y llegar a ese nivel de detalle es cuestión de muchas horas, creo que estás creando un punto de referencia que será utilizado en la medida que se vaya conociendo por una gran cantidad de SysAdmin que tienen en tus artículos la llave maestra para muchas de las actividades a la que se enfrenta a diaios.

    En cuando a dnsmasq y active directory, creo no haber tenido la oportunidad nunca de trabajar con ambos, pero en mi laboratorio a falta de algún cliente windows, todo parece haber quedado bien, y no es para menos con este excelente paso a paso.

    Rescatar tu frase “¡Que difícil es trabajar con Software Privado!. Prefiero pasar un poco de trabajo configurando Software Libre y ser verdaderamente Libre, ¡carajo!.”… Vamos que de apoco eso de pasar un poco de trabajo configurando software libre se va saltando en tiempo, más que todo por documentación como la tuya y de mucha otra gente, cómo también con la constante humanización del software libre.

    Enhorabuena FIco… Seguimos adelante.

  2. Zodiac: Tus palabras son aliciente para seguir escribiendo. No lo dudes, muchas buenas horas – nalgas son necesarias para escribir un modesto artículo como éste.

    Julio León: Saludos para ti también, estimado Julio. Ojalá y continúes con nosotros en el sendero de conocer un poco mas sobre Software Libre.

    Lagarto: Los días y horas dedicados bien valen la pena cuando leo comentarios como los de éste post. Son la mejor recompensa por nuestro trabajo. Al propio Simon Kelley le pasé el enlace del artículo y tuvo la gran amabilidad de responderme.

    Quiero aprovechar éste espacio para decir que en el tema DNS y DHCP empezamos -por estrategia- de lo complejo a lo fácil. El Dnsmasq es una muy válida solución para las Redes PYME, y es mucho más fácil de implementar que la dupla BIND + Isc-Dhcp-Server. Puede que a muchos lectores le parezca un poco técnico el tema. Con el tiempo y el práctica se percatarán de que no es así. Bien vale la pena estudiar los Principios de un Servidor de Infraestructura, título que abarcaría a los 6 artículos escritos sobre los servicios DNS y DHCP, sin olvidar al NTP.

    Enhorabuena a todos… ¡Seguimos adelante!

  3. Gracias Federico por otro gran articulo con tremendo detalle y amplia teoría sobre Dnsmasq, herramienta que ya vemos que es sumamente útil para los sysadmins.

    GENIAL todo lo relacionado con la inserción en su archivo de configuración /etc/dnsmasq.conf de la Zona “_msdcs.mordor.fan” del Microsoft DNS por medio de sus registros SRV que emplean los servicios: _gc, _ldap, _kerberos y _kpasswd con el objetivo de utilizar el Microsoft DNS ( instrucción “server=/mordor.fan/10.10.10.3” ) además del Dnsmasq (instrucción “local=/mordor.fan/” ) para resolver consultas DNS.

    BUENÍSIMO también el ejemplo desarrollado de que para que el Microsoft DNS registre los clientes Windows con cambios de IP en la LAN, hay que seleccionar en la configuración del DNS, las “Dynamic updates” como “Nonsecure and secure” y lo que eso implica en la vulnerabilidad de la seguridad de cualquier Servidor de Nombres de Dominio que se respete, sea de Microsoft o UNIX/Linux. Además de ser necesaria la modificación en la configuración de la tarjeta de red del cliente Windows.
    !Nada que con cada nuevo post subes la parada! Esperando ansiosamente los sgtes artículos!

    • Gracias mil por tu evaluación y comentario, IWO. En cada artículo que publico, siempre espero tu opinión, pues está avalada por tu ocupación, conocimientos y práctica. Enhorabuena IWO. Nos veremos en el próximo artículo

Dejar una respuesta