• BIND y Active Directory®

    por  • 13 febrero, 2017 • Desde Linux • 0 Comentarios

    ¡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.

    Bind

    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.

    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.3pregunta 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.
    • 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®.

    Artículo original: BIND y Active Directory®

    Deja un comentario

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *