BIND y Active Directory®
¡Hola amigos!. El objetivo principal de este artículo es mostrar cómo podemos integrar el servicio DNS basado en el BIND9 en una red Microsoft, muy común en muchas PYMES.
Surge de la solicitud oficial de un amigo que vive en La Tierra del Fuego –El Fueguino– especializado en Redes Microsoft® -Certificados incluidos- de guiarlo en ésta parte de la migración de sus servidores a Linux. Los Costes del Soporte Técnico que pagan a Microsoft® ya son Insoportables para la Compañía en que trabaja y de la que es su Accionista Principal.
Mi amigo El Fueguino tiene un gran sentido del humor, y desde que vio la serie de tres películas “El Señor de los Anillos” quedó prendado de muchos de los nombres de sus personajes sombríos. Así que, amigo Lector, no se extrañe de los nombres de su dominio y de sus servidores.
A los recién llegados al tema y antes de continuar la lectura le recomendamos lean y estudien los tres artículos anteriores sobre las Redes PYMES:
Es como ver tres de las cuatro partes de “UnderWorld” publicadas hasta hoy, y que ésta sea la cuarta.
Parámetros generales
Después de varios intercambios vía e-mail, al fin quedé claro de los parámetros principales de su red actual, los cuales son:
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 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
Le pedí permiso a El Fueguino para establecer tantos Alias como fueran necesarios para aclarar mi mente y me dio su autorizo:
Real CNAME ============================== sauron ad-dc mamba fileserver darklord proxyweb troll blog shadowftp ftpserver blackelf mail blackspider www palantir openfire
Todos los registros DNS importantes los declaré en mi instalación de un Active Directory Windows 2008 que me vi obligado a implementar para guiarme en la confección de éste post.
Sobre los registros SRV del DNS de un Active Directory
Los Registros SRV o Localizadores de Servicios -muy empleados en los Active Directory de Microsoft- se definen en la Request for Comments RFC 2782. Permiten la localización de un servicio basado en el protocolo TCP/IP mediante un consulta DNS. Por ejemplo, un cliente en una red Microsoft puede localizar la ubicación de los Controladores de Dominio – Domain Controllers que brindan el servicio LDAP sobre el protocolo TCP por el puerto 389 mediante una sola consulta DNS.
Es normal que en los Bosques – Forests, y Árboles – Trees de una gran Red Microsoft existan varios Controladores de Dominio. Mediante el uso de los registros SRV en las diferentes Zonas que conforman El Espacio de Nombres de Dominio de esa Red, podemos mantener una Lista de los Servidores que brindan similares servicios bien conocidos, ordenados por preferencia acorde al protocolo de transporte y el puerto de cada uno de los servidores.
En la Request for Comments RFC 1700 se definen los Nombres Simbólicos Universales para los Servicios Bien Conocidos – Well-Known Service, y se reservan nombres como “_telnet“, “_smtp” para los servicios telnet y SMTP. Si no está definido un nombre simbólico para un Servicio Bien Conocido, se puede utilizar un nombre local u otro nombre acorde a las preferencias del usuario.
El propósito de cada campo “especial” que se utiliza en la declaración de un Registro de Recurso SRV es el siguiente:
- Domain: “pdc._msdcs.mordor.fan.“. Nombre DNS del servicio al cual se refiere el registro SRV. El nombre DNS del ejemplo significa -mas o menos- Primary Domain Controller de la zona _msdcs.mordor.fan.
- Service: “_ldap”. Nombre Simbólico del servicio que se brinda definido según la Request for Comments RFC 1700.
- Protocol: “_tcp”. Indica el tipo de protocolo de transporte. Típicamente puede tomar los valores _tcp o _udp, aunque -y de hecho- se puede utilizar cualquier tipo de protocolo de transporte indicado en la Request for Comments RFC 1700. Por ejemplo, para un servicio chat basado en el protocolo XMPP, este campo tendría el valor de _xmpp.
- Priority: “0“. Declara la prioridad o preferencia para el Host offering this service que veremos mas adelante. Las consultas DNS de los clientes sobre el servicio definido por este registro SRV, al recibir la respuesta adecuada, intentarán contactar con el primer host disponible con el número mas bajo listado en el campo Priority. El rango de valores que puede tomar este campo es de 0 a 65535.
- Weight: “100“. Se puede utilizar en combinación con Priority para proveer un mecanismo de balance de carga cuando existan varios servidores que prestan el mismo servicio. Deberá existir un registro similar SRV para cada servidor en el archivo de Zona, con su nombre declarado en el campo Host offering this service. Ante servidores con iguales valores en el campo Priority, el valor del campo Weight se puede usar como un nivel adicional de preferencia y así obtener una exacta selección de servidor para balancear la carga. El rango de valores que puede tomar este campo es de 0 a 65535. Si no se necesita el balance de carga, por ejemplo como en el caso de un solo servidor, se recomienda asignar el valor 0 para facilitar la lectura del registro SRV.
- Port number – Port: “389“. Número del puerto en el Host offering this service que brinda el servicio indicado en el campo Service. El número del puerto que se recomienda para cada tipo de Servicio Bien Conocido está indicado en la Request for Comments RFC 1700, aunque pueda tomar un valor entre 0 y 65535.
- Host offering this service – Target: “sauron.mordor.fan.“. Especifica el FQDN que identifica inequívocamente al host que provee el servicio indicado por el registro SRV. Se requiere un registro tipo “A” en el espacio de nombres del dominio para cada FQDN del servidor o host que brinde el servicio. Mas simple, un registro tipo A en la(s) zona(s) directa(s).
- Nota:
Para indicar de forma autoritaria que el servicio especificado por el registro SRV no se presta en éste host, se utiliza un solo (.) punto.
- Nota:
Solo queremos repetir que el correcto funcionamiento de una red o de un Active Directory® descansa enormemente en el correcto funcionamiento del Servicio de Nombres de Dominio.
Registros DNS del Active Directory
Para confeccionar las Zonas del nuevo Servidor DNS basado en BIND, debemos obtener todos los registros DNS del Active Directory®. Para facilitarnos la vida, vamos al equipo sauron.mordor.fan -Active Directory® 2008 SR2- y en la Consola de Administración del DNS activamos la Transferencia de Zona -directas e inversa- para las principales zonas declaradas en éste tipo de servicio que son:
- _msdcs.mordor.fan
- mordor.fan
- 10.10.10.in-addr.arpa
Una vez efectuado el paso anterior y preferentemente desde un equipo con Linux cuya dirección IP esté dentro del rango de la subred empleada por la Red Windows, ejecutamos:
buzz@sysadmin:~$ dig @10.10.10.3 _msdcs.mordor.fan axfr > temp/rrs._msdcs.mordor.fan buzz@sysadmin:~$ dig @10.10.10.3 mordor.fan axfr > temp/rrs.mordor.fan buzz@sysadmin:~$ dig @10.10.10.3 10.10.10.in-addr.arpa axfr > temp/rrs.10.10.10.in-addr.arpa
- Recordemos de artículos anteriores que la dirección IP del equipo sysadmin.desdelinux.fan es 10.10.10.1 o la 192.168.10.1.
En los tres comandos anteriores podemos eliminar la opción @10.10.10.3 –pregunta al servidor DNS con esa dirección– si declaramos en el archivo /etc/resolv.conf a la IP del servidor sauron.mordor.fan:
buzz@sysadmin:~$ cat /etc/resolv.conf # Generated by NetworkManager search desdelinux.fan nameserver 192.168.10.5 nameserver 10.10.10.3
Después de editar con extremo cuidado, como corresponde a cualquier archivo de zona de un BIND, obtendremos los datos siguientes:
Registros RRs de la zona original _msdcs.mordor.fan
buzz@sysadmin:~$ cat temp/rrs._msdcs.mordor.fan ; Relativos al SOA y NS _msdcs.mordor.fan. 3600 IN SOA sauron.mordor.fan. hostmaster.mordor.fan. 12 900 600 86400 3600 _msdcs.mordor.fan. 3600 IN NS sauron.mordor.fan. ; ; GLOBAL CATALOG gc._msdcs.mordor.fan. 600 IN A 10.10.10.3 ; ; Alias -en la base de datos del LDAP modificado y privado de un Active Directory- de SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 IN CNAME sauron.mordor.fan. ; ; LDAP modificado y privado de un Active Directory _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. ; ; KERBEROS modificado y privado de un Active Directory _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan.
Registros RRs de la zona original mordor.fan
buzz@sysadmin:~$ cat temp/rrs.mordor.fan ; Relativos al SOA, NS, MX y al registro A que mapea ; el Nombre del Dominio a la IP de SAURON ; Cosas de un Active Directory mordor.fan. 3600 IN SOA sauron.mordor.fan. hostmaster.mordor.fan. 48 900 600 86400 3600 mordor.fan. 600 IN A 10.10.10.3 mordor.fan. 3600 IN NS sauron.mordor.fan. mordor.fan. 3600 IN MX 10 blackelf.mordor.fan. _msdcs.mordor.fan. 3600 IN NS sauron.mordor.fan. ; ; Registros A tambien importantes DomainDnsZones.mordor.fan. 600 IN A 10.10.10.3 ForestDnsZones.mordor.fan. 600 IN A 10.10.10.3 ; ; GLOBAL CATALOG _gc._tcp.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _gc._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. ; ; LDAP modificado y privado de un Active Directory _ldap._tcp.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. ; ; KERBEROS modificado y privado de un Active Directory _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 600 IN SRV 0 100 464 sauron.mordor.fan. _kerberos._udp.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 600 IN SRV 0 100 464 sauron.mordor.fan. ; ; Registros A con IP fijas -> Servidores blackelf.mordor.fan. 3600 IN A 10.10.10.9 blackspider.mordor.fan. 3600 IN A 10.10.10.10 darklord.mordor.fan. 3600 IN A 10.10.10.6 mamba.mordor.fan. 3600 IN A 10.10.10.4 palantir.mordor.fan. 3600 IN A 10.10.10.11 sauron.mordor.fan. 3600 IN A 10.10.10.3 shadowftp.mordor.fan. 3600 IN A 10.10.10.8 troll.mordor.fan. 3600 IN A 10.10.10.7 ; ; Registros CNAME ad-dc.mordor.fan. 3600 IN CNAME sauron.mordor.fan. blog.mordor.fan. 3600 IN CNAME troll.mordor.fan. fileserver.mordor.fan. 3600 IN CNAME mamba.mordor.fan. ftpserver.mordor.fan. 3600 IN CNAME shadowftp.mordor.fan. mail.mordor.fan. 3600 IN CNAME balckelf.mordor.fan. openfire.mordor.fan. 3600 IN CNAME palantir.mordor.fan. proxy.mordor.fan. 3600 IN CNAME darklord.mordor.fan. www.mordor.fan. 3600 IN CNAME blackspider.mordor.fan.
Registros RRs de la zona original 10.10.10.in-addr.arpa
buzz@sysadmin:~$ cat temp/rrs.10.10.10.in-addr.arpa ; Relativos al SOA y al NS 10.10.10.in-addr.arpa. 3600 IN SOA sauron.mordor.fan. hostmaster.mordor.fan. 21 900 600 86400 3600 10.10.10.in-addr.arpa. 3600 IN NS sauron.mordor.fan. ; ; Registros PTR 10.10.10.10.in-addr.arpa. 3600 IN PTR blackspider.mordor.fan. 11.10.10.10.in-addr.arpa. 3600 IN PTR palantir.mordor.fan. 3.10.10.10.in-addr.arpa. 3600 IN PTR sauron.mordor.fan. 4.10.10.10.in-addr.arpa. 3600 IN PTR mamba.mordor.fan. 5.10.10.10.in-addr.arpa. 3600 IN PTR dnslinux.mordor.fan. 6.10.10.10.in-addr.arpa. 3600 IN PTR darklord.mordor.fan. 7.10.10.10.in-addr.arpa. 3600 IN PTR troll.mordor.fan. 8.10.10.10.in-addr.arpa. 3600 IN PTR shadowftp.mordor.fan. 9.10.10.10.in-addr.arpa. 3600 IN PTR blackelf.mordor.fan.
Hasta este punto podemos pensar que tenemos los datos necesarios para continuar en nuestra aventura, no sin antes observar los TTLs y demás datos que de forma muy concisa nos brinda la salida y observación directa del DNS de un Active Directory® 2008 SR2 de 64 bits de Microsft®.
Imágenes del DNS Manager en SAURON
Equipo dnslinux.mordor.fan.
Si observamos bien, a la dirección IP 10.10.10.5 no se le asignó nombre alguno para que precisamente quedara ocupada por el nombre del nuevo DNS dnslinux.mordor.fan. Para instalar la pareja DNS y DHCP nos podemos guiar por los artículos DNS y DHCP en Debian 8 “Jessie” y DNS y DHCP en CentOS 7.
Sistema operativo base
Mi amigo El Fueguino, además de ser un verdadero especialista en Microsoft® Windows -posee un par de Certificados expedidos por esa compañía- ha leído y puesto en práctica algunos de los artículos sobre escritorios publicados en DesdeLinux., y me comentó que expresamente quería una solución basada en Debian. 
Para complacerlo, partiremos de una instalación nueva y limpia de un servidor basado en Debian 8 “Jessie”. No obstante, lo que escribiremos a continuación es válido para las distribuciones CentOS y openSUSE cuyos artículos mencionamos antes. El BIND y el DHCP son los mismos en cualquier distro. Las ligeras variaciones las introducen los mantenedores de los paquetes en cada distribución.
La instalación la haremos según lo indicado en DNS y DHCP en Debian 8 “Jessie”, poniendo cuidado en utilizar la IP 10.10.10.5 y la red 10.10.10.0/24., hasta antes de configurar el BIND.
Configuramos el BIND al estilo Debian
/etc/bind/named.conf
El archivo /etc/bind/named.conf lo dejamos tal cual se instala.
/etc/bind/named.conf.options
El archivo /etc/bind/named.conf.options debe quedar con el contenido siguiente:
root@dnslinux:~# cp /etc/bind/named.conf.options /etc/bind/named.conf.options.original
root@dnslinux:~# nano /etc/bind/named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
//=====================================================================$
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//=====================================================================$
// No queremos DNSSEC
dnssec-enable no;
//dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
// No necesitamos escuchar por direcciones IPv6
// listen-on-v6 { any; };
listen-on-v6 { none; };
// Para comprobaciones desde el localhost y sysadmin
// mediante
// dig mordor.fan axfr
// dig 10.10.10.in-addr.arpa axfr
// dig _msdcs.mordor.fan axfr
// No tenemos DNS Esclavos... hasta ahora
allow-transfer { localhost; 10.10.10.1; };
};
// Logging BIND
logging {
channel queries {
file "/var/log/named/queries.log" versions 3 size 1m;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel query-error {
file "/var/log/named/query-error.log" versions 3 size 1m;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
category queries {
queries;
};
category query-errors {
query-error;
};
};
- Introducimos la captura de los logs del BIND como un NUEVO aspecto en la serie de artículos sobre el tema. Creamos la carpeta y archivos necesarios para el Logging del BIND:
root@dnslinux:~# mkdir /var/log/named root@dnslinux:~# touch /var/log/named/queries.log root@dnslinux:~# touch /var/log/named/query-error.log root@dnslinux:~# chown -R bind:bind /var/log/named
Comprobamos la sintaxis de los archivos configurados
root@dnslinux:~# named-checkconf root@dnslinux:~#
/etc/bind/named.conf.local
Creamos el archivo /etc/bind/zones.rfcFreeBSD con igual contenido que lo indicado en DNS y DHCP en Debian 8 “Jessie”.
root@dnslinux:~# nano /etc/bind/zones.rfcFreeBSD
El archivo /etc/bind/named.conf.local deberá quedar con el siguiente contenido:
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
include "/etc/bind/zones.rfc1918";
include "/etc/bind/zones.rfcFreeBSD";
zone "mordor.fan" {
type master;
file "/var/lib/bind/db.mordor.fan";
};
zone "10.10.10.in-addr.arpa" {
type master;
file "/var/lib/bind/db.10.10.10.in-addr.arpa";
};
zone "_msdcs.mordor.fan" {
type master;
check-names ignore;
file "/etc/bind/db._msdcs.mordor.fan";
};
root@dnslinux:~# named-checkconf
root@dnslinux:~#
Archivo de la Zona mordor.fan
root@dnslinux:~# nano /var/lib/bind/db.mordor.fan
$TTL 3H
@ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (
1 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum or
; Negative caching time to live
;
; MUCHO CUIDADO CON LOS SIGUIENTES REGISTROS
@ IN NS dnslinux.mordor.fan.
@ IN A 10.10.10.3
@ IN MX 10 blackelf.mordor.fan.
@ IN TXT "Wellcome to The Dark Lan of Mordor"
;
_msdcs.mordor.fan. IN NS dnslinux.mordor.fan.
;
dnslinux.mordor.fan. IN A 10.10.10.5
; FIN DE MUCHO CUIDADO CON LOS SIGUIENTES REGISTROS
;
DomainDnsZones.mordor.fan. IN A 10.10.10.3
ForestDnsZones.mordor.fan. IN A 10.10.10.3
;
; GLOBAL CATALOG
_gc._tcp.mordor.fan. 600 IN SRV 0 0 3268 sauron.mordor.fan.
_gc._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 0 3268 sauron.mordor.fan.
;
; LDAP modificado y privado de un Active Directory
_ldap._tcp.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan.
_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan.
_ldap._tcp.DomainDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan.
_ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan.
_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan.
_ldap._tcp.ForestDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan.
;
; KERBEROS modificado y privado de un Active Directory
_kerberos._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 0 88 sauron.mordor.fan.
_kerberos._tcp.mordor.fan. 600 IN SRV 0 0 88 sauron.mordor.fan.
_kpasswd._tcp.mordor.fan. 600 IN SRV 0 0 464 sauron.mordor.fan.
_kerberos._udp.mordor.fan. 600 IN SRV 0 0 88 sauron.mordor.fan.
_kpasswd._udp.mordor.fan. 600 IN SRV 0 0 464 sauron.mordor.fan.
;
; Registros A con IP fijas -> Servidores
blackelf.mordor.fan. IN A 10.10.10.9
blackspider.mordor.fan. IN A 10.10.10.10
darklord.mordor.fan. IN A 10.10.10.6
mamba.mordor.fan. IN A 10.10.10.4
palantir.mordor.fan. IN A 10.10.10.11
sauron.mordor.fan. IN A 10.10.10.3
shadowftp.mordor.fan. IN A 10.10.10.8
troll.mordor.fan. IN A 10.10.10.7
;
; Registros CNAME
ad-dc.mordor.fan. IN CNAME sauron.mordor.fan.
blog.mordor.fan. IN CNAME troll.mordor.fan.
fileserver.mordor.fan. IN CNAME mamba.mordor.fan.
ftpserver.mordor.fan. IN CNAME shadowftp.mordor.fan.
mail.mordor.fan. IN CNAME balckelf.mordor.fan.
openfire.mordor.fan. IN CNAME palantir.mordor.fan.
proxy.mordor.fan. IN CNAME darklord.mordor.fan.
www.mordor.fan. IN CNAME blackspider.mordor.fan.
root@dnslinux:~# named-checkzone mordor.fan /var/lib/bind/db.mordor.fan
zone mordor.fan/IN: loaded serial 1
OK
Los tiempos TTL 600 de todos los registros SRV los mantendremos por si instalamos un BIND Esclavo en tiempos por vanir. Esos registros representan servicios del Active Directory® que mayormente leen datos de su base de datos del LDAP. Como esa base de datos cambia con frecuencia, se deben mantener cortos los tiempos de sincronismo, en un esquema DNS Maestro – Esclavo. Según la filosofía Microsoft observada desde el Active Directory 2000 hasta el 2008, se mantiene el valor de 600 para éstos tipos de registros SRV.
Los TTLs de los servidores con IP fijas, quedan bajo el tiempo declarado en el SOA de 3 horas.
Archivo de la Zona 10.10.10.in-addr.arpa
root@dnslinux:~# nano /var/lib/bind/db.10.10.10.in-addr.arpa
$TTL 3H
@ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (
1 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum or
; Negative caching time to live
;
@ IN NS dnslinux.mordor.fan.
;
10 IN PTR blackspider.mordor.fan.
11 IN PTR palantir.mordor.fan.
3 IN PTR sauron.mordor.fan.
4 IN PTR mamba.mordor.fan.
5 IN PTR dnslinux.mordor.fan.
6 IN PTR darklord.mordor.fan.
7 IN PTR troll.mordor.fan.
8 IN PTR shadowftp.mordor.fan.
9 IN PTR blackelf.mordor.fan.
root@dnslinux:~# named-checkzone 10.10.10.in-addr.arpa /var/lib/bind/db.10.10.10.in-addr.arpa
zone 10.10.10.in-addr.arpa/IN: loaded serial 1
OK
Archivo de la Zona _msdcs.mordor.fan
Tengamos en cuenta lo recomendado en el archivo /usr/share/doc/bind9/README.Debian.gz dobre la ubicación de los archivos de las Zonas Maestras no sometidas a actualizaciones dinámicas por el DHCP.
root@dnslinux:~# nano /etc/bind/db._msdcs.mordor.fan
$TTL 3H
@ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (
1 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum or
; Negative caching time to live
;
@ IN NS dnslinux.mordor.fan.
;
;
; GLOBAL CATALOG
gc._msdcs.mordor.fan. 600 IN A 10.10.10.3
;
; Alias -en la base de datos del LDAP modificado y privado de un Active Directory- de SAURON
03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 IN CNAME sauron.mordor.fan.
;
; LDAP modificado y privado de un Active Directory
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan.
_ldap._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan.
_ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan.
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan.
_ldap._tcp.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan.
_ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan.
;
; KERBEROS modificado y privado de un Active Directory
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan.
_kerberos._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan.
Comprobamos la sintaxis y podemmos ignorar el error que devuelve, ya que en la configuración de ésta Zona en el archivo /etc/bind/named.conf.local incluimos la declaración check-names ignore;. La zona será correctamente cargada por el BIND.
root@dnslinux:~# named-checkzone _msdcs.mordor.fan /etc/bind/db._msdcs.mordor.fan
/etc/bind/db._msdcs.mordor.fan:14: gc._msdcs.mordor.fan: bad owner name (check-names)
zone _msdcs.mordor.fan/IN: loaded serial 1
OK
root@dnslinux:~# systemctl restart bind9.service
root@dnslinux:~# systemctl status bind9.service
● bind9.service - BIND Domain Name Server
Loaded: loaded (/lib/systemd/system/bind9.service; enabled)
Drop-In: /run/systemd/generator/bind9.service.d
└─50-insserv.conf-$named.conf
Active: active (running) since dom 2017-02-12 08:48:38 EST; 2s ago
Docs: man:named(8)
Process: 859 ExecStop=/usr/sbin/rndc stop (code=exited, status=0/SUCCESS)
Main PID: 864 (named)
CGroup: /system.slice/bind9.service
└─864 /usr/sbin/named -f -u bind
feb 12 08:48:38 dnslinux named[864]: zone 3.e.f.ip6.arpa/IN: loaded serial 1
feb 12 08:48:38 dnslinux named[864]: zone b.e.f.ip6.arpa/IN: loaded serial 1
feb 12 08:48:38 dnslinux named[864]: zone 0.e.f.ip6.arpa/IN: loaded serial 1
feb 12 08:48:38 dnslinux named[864]: zone 7.e.f.ip6.arpa/IN: loaded serial 1
feb 12 08:48:38 dnslinux named[864]: zone mordor.fan/IN: loaded serial 1
feb 12 08:48:38 dnslinux named[864]: zone example.org/IN: loaded serial 1
feb 12 08:48:38 dnslinux named[864]: zone _msdcs.mordor.fan/IN: loaded serial 1
feb 12 08:48:38 dnslinux named[864]: zone invalid/IN: loaded serial 1
feb 12 08:48:38 dnslinux named[864]: all zones loaded
feb 12 08:48:38 dnslinux named[864]: running
Consultamos el BIND
Antes de instalar el DHCP, debemos efectuar toda una serie de comprobaciones que incluye hasta la unión de un cliente Windows 7 al dominio mordor.fan representado por el Active Directory instalado en el equipo sauron.mordor.fan.
Lo primero que debemos hacer es detener el servicio DNS en el equipo sauron.mordor.fan, y declarar en su interfaz de red que en lo adelante su servidor DNS será el 10.10.10.5 dnslinux.mordor.fan.
En una consola del propio servidor sauron.mordor.fan ejecutamos:
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Administrator>nslookup
Default Server: dnslinux.mordor.fan
Address: 10.10.10.5
> gc._msdcs
Server: dnslinux.mordor.fan
Address: 10.10.10.5
Name: gc._msdcs.mordor.fan
Address: 10.10.10.3
> mordor.fan
Server: dnslinux.mordor.fan
Address: 10.10.10.5
Name: mordor.fan
Address: 10.10.10.3
> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs
Server: dnslinux.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._tcp.Default-First-Site-Name._sites.dc._msdcs
Server: dnslinux.mordor.fan
Address: 10.10.10.5
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan SRV serv
ice location:
priority = 0
weight = 100
port = 88
svr hostname = sauron.mordor.fan
_msdcs.mordor.fan nameserver = dnslinux.mordor.fan
sauron.mordor.fan internet address = 10.10.10.3
dnslinux.mordor.fan internet address = 10.10.10.5
> _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs
Server: dnslinux.mordor.fan
Address: 10.10.10.5
_ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan
SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = sauron.mordor.fan
_msdcs.mordor.fan nameserver = dnslinux.mordor.fan
sauron.mordor.fan internet address = 10.10.10.3
dnslinux.mordor.fan internet address = 10.10.10.5
> exit
C:\Users\Administrator>
Las consultas DNS realizadas desde sauron.mordor.fan son satisfactorias.
El próximo paso será la creación de otra máquina virtual con Windows 7 instalado. Como aun no tenemos instalado el servicio DHCP, le daremos al equipo con nombre “win7” la dirección IP 10.10.10.251. También le declaramos que su servidor DNS será el 10.10.10.5 dnslinux.mordor.fan, y que el dominio de búsqueda será mordor.fan. No registraremos ese equipo en el DNS porque lo usaremos también para probar el servicio DHCP después que lo instalemos.
A continuación abrimos una consola CMD y en ella ejecutamos:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\buzz>nslookup
Default Server: dnslinux.mordor.fan
Address: 10.10.10.5
> mordor.fan
Server: dnslinux.mordor.fan
Address: 10.10.10.5
Name: mordor.fan
Address: 10.10.10.3
> set type=SRV
> _ldap._tcp.DomainDnsZones
Server: dnslinux.mordor.fan
Address: 10.10.10.5
_ldap._tcp.DomainDnsZones.mordor.fan SRV service location:
priority = 0
weight = 0
port = 389
svr hostname = sauron.mordor.fan
mordor.fan nameserver = dnslinux.mordor.fan
sauron.mordor.fan internet address = 10.10.10.3
dnslinux.mordor.fan internet address = 10.10.10.5
> _kpasswd._udp
Server: dnslinux.mordor.fan
Address: 10.10.10.5
_kpasswd._udp.mordor.fan SRV service location:
priority = 0
weight = 0
port = 464
svr hostname = sauron.mordor.fan
mordor.fan nameserver = dnslinux.mordor.fan
sauron.mordor.fan internet address = 10.10.10.3
dnslinux.mordor.fan internet address = 10.10.10.5
> _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones
Server: dnslinux.mordor.fan
Address: 10.10.10.5
_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan SRV serv
ice location:
priority = 0
weight = 0
port = 389
svr hostname = sauron.mordor.fan
mordor.fan nameserver = dnslinux.mordor.fan
sauron.mordor.fan internet address = 10.10.10.3
dnslinux.mordor.fan internet address = 10.10.10.5
> exit
C:\Users\buzz>
Las consultas DNS efectuadas desde el cliente “win7” también fueron satisfactorias.
En el Active Directory creamos el usuario “saruman“, con el objetivo de utilizarlo al unir el cliente win7 al dominio mordor.fan., mediante el método “Network ID“, usando los nombres de usuarios saruman@mordor.fan y administrator@mordor.fan. La unión se efectuó correctamente y lo prueba la siguiente captura de pantalla:
Sobre las Actualizaciones Dinámicas en el Microsoft® DNS y en el BIND
Como tenemos el servicio DNS detenido en el Active Directory® no le fue posible al cliente “win7” registrar su nombre y dirección IP en ese DNS. Mucho menos en dnslinux.mordor.fan ya que no hicimos ninguna declaración allow-update para cualquiera de las zonas involucradas.
Y aquí fue donde se formó la buena trifulca con mi amigo El Fueguino. En mi primer correo sobre éste aspecto le comenté:
- En los artículos de Microsoft sobre el uso del BIND y el Active Directory® recomiendan que, sobre todo a la Zona Directa, se permita ser actualizada –penetrada– directamente por los clientes Windows que ya están unidos al dominio del Active Directory.
- Por eso es que, por defecto, en las zonas del DNS de un Active Directory® se permiten las Actualizaciones Dinámicas Seguras por parte de los clientes Windows que ya estén unidos al dominio del Active Directory. Sino están unidos, que se abstengan a las consecuencias.
- El DNS de un Active Directory admite las actualizaciones dinámicas “Secure only”, “Nonsecure and secure”, o “None” que es lo mismo que decir SIN Actualizaciones o Ninguna.
- Si de verdad la Filosofía Microsoft no estuviera de acuerdo con que sus clientes NO actualizaran sus datos en su(s) DNS(s), no dejaría abierta la posibilidad de inhabilitar las actualizaciones dinámicas en su(s) DNS(s), a menos que esa opción se dejara para propósitos mas ocultos.
- Microsoft ofrece “Seguridad” a cambio de Obscuridad, como me afirmó un colega y amigo que pasó cursos de Certificados Microsft®. Cierto. Además, me lo confirmó El Fueguino.
- Un cliente que adquiera una dirección IP por medio de un DHCP instalado en una máquina con UNIX®/Linux por ejemplo, no podrá resolver la dirección IP de su propio nombre hasta que no esté unido al dominio del Active Directory, siempre que se utilice como DNS el de Microsoft® o un BIND sin actualizaciones dinámicas por parte de un DHCP.
- Si instalo el DHCP en el propio Active Directory®, entonces debo declarar que las Zonas sean actualizadas por el DHCP de Microsoft®.
- Si vamos a utilizar el BIND como el DNS para la red Windows, lo lógico y recomendado sea que instalemos la dupla BIND-DHCP, con éste último actualizando de forma dinámica al BIND y asunto concluido.
- En el mundo de las redes LAN en UNIX®/Linux, desde que se inventaron las actualizaciones dinámicas sobre el BIND, solo se le permite al Señor DHCP “penetrar” a la Señora BIND con sus actualizaciones. El relajo que sea con orden, por favor.
- Cuando declaro en la zona mordor.fan por ejemplo: allow-update { 10.10.10.0/24; };, el propio BIND me informa al iniciarlo o reiniciarlo que:
-
zone 'mordor.fan' allows updates by IP address, which is insecure
-
- En el sacrosanto mundo UNIX®/Linux ese desparpajo con el DNS es sencillamente inadmisible.
Se podrán imaginar el resto del intercambio con mi amigo El Fueguino mediante e-mails, Telegram Chat, llamadas telefónicas pagadas por él (por supuesto hombre, que no tengo un kilo para eso), y hasta ¡mensajes por medio de palomas mensajeras en pleno siglo XXI!.
Hasta me amenazó con no mandarme un hijo de su mascota, su Iguana “Petra” que me había prometido como parte del pago. Ahí si que me asusté de verdad. Entonces empecé de nuevo, pero desde otro ángulo.
- El “casi” Active Directory que se puede lograr con Samba 4, resuelve ese aspecto de forma magistral, tanto cuando utilizamos su DNS Interno, o el BIND compilado para que soporte zonas DLZ – Dinamyc Loaded Zones, o Zonas Cargadas Dinámicamente.
- Sigue padeciendo de lo mismo: cuando un cliente adquiere una dirección IP por medio de un DHCP instalado en otra máquina con UNIX®/Linux, no podrá resolver la dirección IP de su propio nombre hasta que no esté unido al dominio del AD-DC de Samba 4.
- Integrar la dupla BIND-DLZ y DHCP en la misma máquina donde esté instalado el AD-DC Samba 4 es tarea para un especialista de verdad.
El Fueguino me llamó a capítulo y me gritó: ¡NO estamos hablando del AD-DC Samba 4, sino del Microsoft® Active Directory®!. Y humildemente le respondí que me embullé con parte de los siguientes artículos que yo iba a escribir.
Entonces fue cuando le dije que, la decisión final sobre las actualizaciones dinámicas de los equipos clientes en su red quedaba a su libre albedrío. Que solamente le daría el tip escrito antes sobre allow-update { 10.10.10.0/24; };, y más nada. Que yo no me hacía responsable de lo que resultara de esa promiscuidad de que cada cliente Windows -o Linux- en su red “penetrara” impunemente al BIND.
Si Usted supiera amigo Lector que ese fue el Punto Final a la trifulca no me lo creería. Mi amigo El Fueguino aceptó la solución -y me enviará a la iguana “Petrica“- que ahora comparto con Usted.
Instalamos y configuramos el DHCP
Para mas detalles lea DNS y DHCP en Debian 8 “Jessie”.
root@dnslinux:~# aptitude install isc-dhcp-server
root@dnslinux:~# nano /etc/default/isc-dhcp-server
....
# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
# Separate multiple interfaces with spaces, e.g. "eth0 eth1".
INTERFACES="eth0"
root@dnslinux:~# dnssec-keygen -a HMAC-MD5 -b 128 -r /dev/urandom -n USER dhcp-key
Kdhcp-key.+157+29836
root@dnslinux:~# cat Kdhcp-key.+157+29836.private
Private-key-format: v1.3
Algorithm: 157 (HMAC_MD5)
Key: 3HT/bg/6YwezUShKYofj5g==
Bits: AAA=
Created: 20170212205030
Publish: 20170212205030
Activate: 20170212205030
root@dnslinux:~# nano dhcp.key
key dhcp-key {
algorithm hmac-md5;
secret "3HT/bg/6YwezUShKYofj5g==";
};
root@dnslinux:~# install -o root -g bind -m 0640 dhcp.key /etc/bind/dhcp.key
root@dnslinux:~# install -o root -g root -m 0640 dhcp.key /etc/dhcp/dhcp.key
root@dnslinux:~# nano /etc/bind/named.conf.local
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
include "/etc/bind/zones.rfc1918";
include "/etc/bind/zones.rfcFreeBSD";
// No olvidar... me olvidé y pagué con errores. ;-)
include "/etc/bind/dhcp.key";
zone "mordor.fan" {
type master;
allow-update { 10.10.10.3; key dhcp-key; };
file "/var/lib/bind/db.mordor.fan";
};
zone "10.10.10.in-addr.arpa" {
type master;
allow-update { 10.10.10.3; key dhcp-key; };
file "/var/lib/bind/db.10.10.10.in-addr.arpa";
};
zone "_msdcs.mordor.fan" {
type master;
check-names ignore;
file "/etc/bind/db._msdcs.mordor.fan";
};
root@dnslinux:~# named-checkconf
root@dnslinux:~#
root@dnslinux:~# nano /etc/dhcp/dhcpd.conf
ddns-update-style interim;
ddns-updates on;
ddns-domainname "mordor.fan.";
ddns-rev-domainname "in-addr.arpa.";
ignore client-updates;
authoritative;
option ip-forwarding off;
option domain-name "mordor.fan";
include "/etc/dhcp/dhcp.key";
zone mordor.fan. {
primary 127.0.0.1;
key dhcp-key;
}
zone 10.10.10.in-addr.arpa. {
primary 127.0.0.1;
key dhcp-key;
}
shared-network redlocal {
subnet 10.10.10.0 netmask 255.255.255.0 {
option routers 10.10.10.1;
option subnet-mask 255.255.255.0;
option broadcast-address 10.10.10.255;
option domain-name-servers 10.10.10.5;
option netbios-name-servers 10.10.10.5;
range 10.10.10.30 10.10.10.250;
}
}
# FIN dhcpd.conf
root@dnslinux:~# dhcpd -t
Internet Systems Consortium DHCP Server 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Config file: /etc/dhcp/dhcpd.conf
Database file: /var/lib/dhcp/dhcpd.leases
PID file: /var/run/dhcpd.pid
root@dnslinux:~# systemctl restart bind9.service
root@dnslinux:~# systemctl status bind9.service
root@dnslinux:~# systemctl start isc-dhcp-server.service
root@dnslinux:~# systemctl status isc-dhcp-server.service
Lo relacionado con las Comprobaciones con clientes, y la Modificación manual de los archivos de Zonas, lo dejamos para que Usted, amigo lector, lo lea directamente de DNS y DHCP en Debian 8 “Jessie”, y lo aplique a sus condiciones reales. Nosotros si efectuamos todas las comprobaciones necesarias y obtuvimos resultados satisfactorios. Por supuesto que enviamos copia de todas ellas a El Fueguino. ¡No faltara más!.
Consejos
Generales
- Adquiera una buena cantidad de paciencia antes de empezar.
- Primero instale y configure el BIND. Compruebe todo y consulte todos los registros que declaró en cada archivo de las tres -o más- zonas, tanto desde el Active Directory como desde el propio servidor DNS en Linux. Si es posible, desde una máquina Linux que no esté unida al dominio, haga las necesarias consultas DNS al BIND.
- Una al dominio existente un cliente Windows con una dirección IP fija, y vuelva a comprobar toda la configuración del BIND desde el cliente Windows.
- Después que Usted esté indudablemente seguro de que la configuración de su nuevo y flamante BIND es totalmente correcta, aventúrese a instalar, configurar, e iniciar el servicio DHCP.
- Ante errores, repita todo el procedimiento desde cero 0.
- ¡Cuidado con el copy & paste! y los espacios sobrantes en cada línea de los archivos named.conf.xxxx
- Después no se queje -mucho menos con mi amigo el Fueguino- de que no lo aconsejaron debidamente.
Otros consejos
- Divide y vencerás.
- En una Red PYME es mas seguro y beneficioso instalar un BIND Autoritario para las Zonas de la LAN interna que no haga recursividad a ningún servidor raíz: recursion no;.
- En una Red PYME ubicada bajo un Proveedor de Acceso a Internet – ISP, acaso los servicios Proxy y SMTP necesitan resolver nombres de dominio en la Internet. El Squid tiene la opción de declarar sus DNS sean externos o no, mientras que en un servidor de correo basado en Postfix o MDaemon® también podemos declarar los servidores DNS que utilizaremos en ese servicio. En casos como éste, o sea, casos que no brinden servicios a la Internet y que estén debajo de un Internet Service Provider, se puede instalar un BIND con Forwarders apuntando a los DNS del ISP, y declararlo como DNS secundario en los servidores que necesiten resolver consultas externas a la LAN, sino es posible declararlos mediante sus propios archivos de configuración.
- Si Usted tiene una Zona Delegada bajo su entera responsabilidad, entonces canta otro gallo:
- Instale un servidor DNS basado en NSD, el cual es un servidor DNS Autoritario por definición, que responda a las consultas provenientes de equipos en la Internet. Para alguna información aptitude show nsd. Favor de protegerlo muy bien mediante tantos muros cortafuegos como sean necesarios. Tanto por hardware como por software. Será un DNS cara a Internet, y esa “cara” no la debemos dar con los pantalones bajos.
- Como nunca me he visto en un caso como el éste, o sea, responsable total de una Zona Delegada, tendría que pensar muy bien que recomendar para la resolución de nombres de dominio externos a nuestra LAN para los servicios que lo necesiten. Los Clientes de la Red PYME no lo necesitan realmente. Consulte literatura especializada, o a un especialista en éstos temas, pues estoy muy lejos de ser uno de ellos. En serio.
- En los servidores Autoritarios no existe la Recursividad. ¿Ok?. Por si a alguien se le ocurre hacerlo con un BIND.
- Instale un servidor DNS basado en NSD, el cual es un servidor DNS Autoritario por definición, que responda a las consultas provenientes de equipos en la Internet. Para alguna información aptitude show nsd.
- A pesar que especificamos explícitamente en el archivo /etc/dhcp/dhcpd.conf la declaración ignore client-updates;, si ejecutamos en una consola del equipo dnslinux.mordor.fan la orden journalctl -f, veremos que al iniciar el cliente win7.mordor.fan obtenemos los siguientes mensajes de error:
-
feb 12 16:55:41 dnslinux named[900]: client 10.10.10.30#58762: update 'mordor.fan/IN' denied feb 12 16:55:42 dnslinux named[900]: client 10.10.10.30#49763: update 'mordor.fan/IN' denied feb 12 16:56:23 dnslinux named[900]: client 10.10.10.30#63161: update 'mordor.fan/IN' denied - Para eliminar esos mensajes, debemos ir a las opciones avanzadas de la configuración de la tarjeta de red y desmarcar la opción “Register this connection’s addresses in DNS“. Eso evitará para siempre que el cliente intente auto registrase en el DNS Linux y fin del problema. Lo siento, pero no tengo una copia de Windows 7 en español.
-
- Para enterarse de todas las consultas serias -y locas- que hace un cliente Windows 7, consulte el log queries.log que para algo lo declaramos en la configuración del BIND. La orden sería:
-
root@dnslinux:~# tail -f /var/log/named/queries.log
-
- Si Usted no permite que sus equipos clientes se conecten directamente a Internet, entonces ¿para que le hacen falta los Servidores DNS Raíces?. Ésto disminuirá considerablemente la salida del comando journalctl -f y del anterior, si su servidor DNS Autoritario para las Zonas Internas no se conecta directamente con Internet, lo cual es muy recomendado desde el punto de vista de la seguridad.
root@dnslinux:~# cp /etc/bind/db.root /etc/bind/db.root.original root@dnslinux:~# cp /dev/null /etc/bind/db.root
- Sino necesita la declaración de los servidores raíces, entonces ¿para que le hace falta la Recursividad – Recursion?
root@dnslinux:~# nano /etc/bind/named.conf.options options { .... recursion no; .... };
Consejo específico del cual aun no estoy muy claro
El man dhcpd.conf nos dice lo siguiente entre muchas -muchísimas- cosa mas:
The update-optimization statement
update-optimization flag;
If the update-optimization parameter is false for a given client,
the server will attempt a DNS update for that client each time the
client renews its lease, rather than only attempting an update
when it appears to be necessary. This will allow the DNS to heal
from database inconsistencies more easily, but the cost is that
the DHCP server must do many more DNS updates. We recommend leav‐
ing this option enabled, which is the default. This option only
affects the behavior of the interim DNS update scheme, and has no
effect on the ad-hoc DNS update scheme. If this parameter is not
specified, or is true, the DHCP server will only update when the
client information changes, the client gets a different lease, or
the client's lease expires.
La traducción o interpretación mas o menos exacta se la dejamos a Usted, caro lector.
Personalmente me ha sucedido -y sucedió durante la confección de éste artículo- que cuando enlazo un BIND a un Active Directory® sea de Microsft® o de Samba 4, si le cambio el nombre a un equipo cliente registrado en el dominio del Active Directory® o del AD-DC de Samba 4, mantiene su nombre antiguo y dirección IP en la Zona Directa, y no así en la inversa que se actualiza correctamente con el nombre nuevo. O sea, se mapean el nombre antiguo y el nuevo a la misma dirección IP en la Zona Directa, mientras que en la inversa solo aparece el nombre nuevo. Para entenderme bien lo deben probar Ustedes mismos.
Pienso sea una especie de venganza hacia El Fueguino -que no hacia mi, por favor- por tratar de migrar sus servicios a Linux.
Por supuesto que el nombre antiguo desaparecerá cuando expire su TTL 3600, o el tiempo que hayamos declarado en la configuración del DHCP. Pero queremos que desaparezca de inmediato como sucede en un BIND + DHCP sin un Active Directory por medio.
La solución a esa situación la encontré insertando la declaración update-optimization false; al final de la parte superior del archivo /etc/dhcp/dhcpd.conf:
ddns-update-style interim; ddns-updates on; ddns-domainname "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; ignore client-updates; update-optimization false;
Si algún Lector conoce mas al respecto, por favor de Iluminarme. Se lo agradeceré y mucho.
Resumen
Nos hemos divertido un montón con el tema, no?. Nada de sufrimientos pues tenemos un BIND funcionando como servidor DNS en una red Microsoft®, ofreciendo todos los registros SRV y respondiendo adecuadamente a las consultas DNS que se les haga. Por otra parte tenemos a un servidor DHCP otorgando direcciones IP y actualizando correctamente de forma dinámica a las Zonas del BIND.
Mas no podemos pedir… por el momento.
Espero que mi amigo El Fueguino esté contento y satisfecho del primer paso en su migración a Linux para hacer soportable los insoportables costos del Soporte Técnico de Microsft®.
Nota importante
El personaje “El Fueguino” es completamente ficticio y producto de mi imaginación. Cualquier parecido o coincidencia con personas reales es eso mismo: Pura Coincidencia Involuntaria de mi parte. Solo lo creé para hacer un poco amena la redacción y lectura de éste artículo. Ahora si que me pueden decir que el tema DNS es obscuro.
El artículo BIND y Active Directory® aparece primero en BIND y Active Directory®.
