BIND i Active Directory® - Xarxes PIME

Índex general de la sèrie: Xarxes de Ordinadors per a les PIMES: Introducció

Hola amics !. L'objectiu principal d'aquest article és mostrar com podem integrar el servei DNS basat en el bind9 en una xarxa Microsoft, molt comuna en moltes PIMES.

Sorgeix de la sol·licitud oficial d'un amic que viu a La Terra de l'Foc -el Fueguino- especialitzat en Xarxes Microsoft -Certificats inclosos- de guiar-lo en aquesta part de la migració dels seus servidors a Linux. Els Costos de l' Suport Tècnic que paguen a Microsoft ja són insuportables per la Companyia en què treballa i de la qual és la seva Accionista Principal.

El meu amic el Fueguino té un gran sentit de l'humor, i des que va veure la sèrie de tres pel·lícules «El Senyor dels Anells»Quedar enamorat de molts dels noms dels seus personatges ombrívols. Així que, amic Lector, no s'estranyi dels noms del seu domini i dels seus servidors.

Als nouvinguts a el tema i abans de continuar la lectura li recomanem llegeixin i estudiïn els tres articles anteriors sobre les Xarxes PIMES:

• DNS i DHCP a openSUSE 13.2 «Harlequin»
• DNS i DHCP a CentOS juliol
• DNS i DHCP a Debian 8 «Jessie»

És com veure tres de les quatre parts de «Underworld»Publicades fins avui, i que aquesta sigui la quarta.

paràmetres generals

Després de diversos intercanvis via e-mail, A la fi vaig quedar clar dels paràmetres principals de la seva xarxa actual, els quals són:

Nom de domini mordor.fan Xarxa LAN 10.10.10.0/24 ===================================== ========================================== Servidors Adreça IP Propòsit (servidors amb SO Windows) ================================================ =============================== sauron.mordor.fan. 10.10.10.3 Active Directory® 2008 SR2 mamba.mordor.fan. 10.10.10.4 Servidor d'arxius Windows darklord.mordor.fan. 10.10.10.6 Proxy, passarel·la i tallafocs sobre Kerios troll.mordor.fan. 10.10.10.7 Bloc basat en ... no recordo shadowftp.mordor.fan. 10.10.10.8 Servidor FTP blackelf.mordor.fan. 10.10.10.9 Servei e-mail complet blackspider.mordor.fan. 10.10.10.10 Servei WWW palantir.mordor.fan. 10.10.10.11 Xat en Openfire per a Windows

Li vaig demanar permís a el Fueguino per establir tants Alias ​​com fossin necessaris per aclarir la meva ment i em va donar el seu autoritzo:

Reial CNAME ============================== sauron ad-dc mamba fileserver Darklord proxyweb troll bloc shadowftp ftpserver blackelf mail blackspider www palantir Openfire

Tots els registres DNS importants els vaig declarar en el meu instal·lació d'un Active Directory Windows 2008 que em vaig veure obligat a implementar per guiar-me en la confecció d'aquest post.

Sobre els registres SRV de DNS d'un Active Directory

els registres SRV o Localitzadors de Serveis -molt emprats en els Active Directory de Microsoft- es defineixen en la Request for Comments RFC 2782. Permeten la localització d'un servei basat en el protocol TCP / IP mitjançant un consulta DNS. Per exemple, un client en una xarxa Microsoft pot localitzar la ubicació dels controladors de domini - Controladors de domini que brinden el servei LDAP sobre el protocol TCP pel port 389 mitjançant una sola consulta DNS.

És normal que en els Boscos - Boscos, I Arbres - Arbres d'una gran Xarxa Microsoft hi hagi diversos controladors de domini. Mitjançant l'ús dels registres SRV en les diferents Zones que conformen L'Espai de Noms de Domini d'aquesta Xarxa, podem mantenir una Llista dels servidors que brinden similars serveis ben coneguts, ordenats per preferència d'acord amb el protocol de transport i el port de cada un dels servidors.

En la Request for Comments RFC 1700 es defineixen els Noms Simbòlics Universals per als Serveis Bé Coneguts - Well-Known Service, I es reserven noms com «_telnet","_smtp»Per als serveis telnet y SMTP. Si no està definit un nom simbòlic per a un Servei Bé Conegut, es pot utilitzar un nom local o un altre nom d'acord a les preferències de l'usuari.

El propòsit de cada camp «especial»Que s'utilitza en la declaració d'un Registre de Recurs SRV és el següent:

• domini: «Pdc._msdcs.mordor.fan.«. Nom DNS de el servei a el qual es refereix el registre SRV. El nom DNS de l'exemple vol dir -mes o menys- Controlador de domini principal de la zona _msdcs.mordor.fan.
• servei: «_Ldap». Nom Simbòlic de el servei que es brinda definit segons la Request for Comments RFC 1700.
• Protocol: «_Tcp». Indica el tipus de protocol de transport. Típicament pot prendre els valors _tcp o _udp, Tot i que -i de fet- es pot utilitzar qualsevol tipus de protocol de transport indicat en la Request for Comments RFC 1700. Per exemple, per a un servei xat basat en el protocol XMPP, Aquest camp tindria el valor de _xmpp.
• Prioritat'0«. Declara la prioritat o preferència per al Host offering this service que veurem més endavant. Les consultes DNS dels clients sobre el servei definit per aquest registre SRV, a l'rebre la resposta adequada, intentaran contactar amb el primer host disponible amb el nombre més baix llistat en el camp Prioritat. El rang de valors que pot prendre aquest camp és de 0 a 65535.
• pes'100«. Es pot utilitzar en combinació amb Prioritat per proveir un mecanisme de balanç de càrrega quan hi hagi diversos servidors que presten el mateix servei. Hi ha d'haver un registre similar SRV per a cada servidor a l'arxiu de la zona, amb el seu nom declarat en el camp Host offering this service. Davant servidors amb iguals valors en el camp Prioritat, El valor de camp pes es pot usar com un nivell addicional de preferència i així obtenir una exacta selecció de servidor per balancejar la càrrega. El rang de valors que pot prendre aquest camp és de 0 a 65535. Si no necessita el balanç de càrrega, per exemple com en el cas d'un sol servidor, es recomana assignar el valor 0 per facilitar la lectura de l'registre SRV.
• Port number - Port'389«. Nombre de el port al Host offering this service que brinda el servei indicat en el camp servei. El nombre de port que es recomana per a cada tipus de servei Bé Conegut està indicat en la Request for Comments RFC 1700, Encara que pugui prendre un valor entre 0 i 65535.
• Host offering this service - Target'sauron.mordor.fan.«. especifica el FQDN que identifica inequívocament a l' host que proveeix el servei indicat pel registre SRV. Es requereix un registre tipus «A»En l'espai de noms de domini per a cada FQDN de servidor o host que brindi el servei. Mas simple, un registre tipus A a la (es) zona (s) directa (s).
  • Nota:
    Per indicar de forma autoritària que el servei especificat pel registre SRV no es presta a aquest host, s'utilitza un sol (.) punt.

Només volem repetir que el correcte funcionament d'una xarxa o d'un Active Directory® descansa enormement en el correcte funcionament de el Servei de Noms de Domini.

Registres DNS de l'Active Directory

Per confeccionar les Zones de el nou Servidor DNS basat en BIND, hem d'obtenir tots els registres DNS de l'Active Directory®. Per facilitar-nos la vida, anem a l'equip sauron.mordor.fan -Active Directory® 2008 SR2- i en la Consola d'administració de l'DNS activem la Transferència de la zona -directes i inversament per a les principals zones declarades en aquest tipus de servei que són:

• _msdcs.mordor.fan
• mordor.fan
• 10.10.10.in-addr.arpa

Un cop efectuat el pas anterior i preferentment des d'un equip amb Linux l'adreça IP estigui dins el rang de la subxarxa emprada per la Xarxa Windows, executem:

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

• Recordem d'articles anteriors que l'adreça IP de l'equip sysadmin.desdelinux.fan és 10.10.10.1 o la 192.168.10.1.

En els tres ordres anteriors podem eliminar l'opció 10.10.10.3 -pregunta a l'servidor DNS amb aquesta direcció- si declarem a l'arxiu /etc/resolv.conf a la IP de 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

Després d'editar amb molta cura, com correspon a qualsevol arxiu de zona d'un BIND, obtindrem les dades següents:

Registres RRS de la zona original _msdcs.mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs._msdcs.mordor.fan 
; Relatius a l'SOA i NS _msdcs.mordor.fan. 3600 IN SOA sauron.mordor.fan. hostmaster.mordor.fan. 12 900 600 _msdcs.mordor.fan. 86400 IN NS sauron.mordor.fan. ; ; GLOBAL CATALOG gc._msdcs.mordor.fan. 3600 IN A 3600; ; Alias ​​-a la base de dades de l'LDAP modificat i privat d'un Active Directory- de Sàuron 600-10.10.10.3a03296249-82aa-a1f49-4f0d28900b._msdcs.mordor.fan. 5 IN CNAME sauron.mordor.fan. ; ; LDAP modificat i privat d'un Active Directory _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 256 IN SRV 600 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. _ldap._tcp.100d389d-600fdb-0cf-a100-d389c18b3360d8.domains._msdcs.mordor.fan. 40 IN SRV 678 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 7 IN SRV 420 6 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 775 IN SRV 600 0 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 100 IN SRV 389 sauron.mordor.fan. ; ; Kerberos modificat i privat d'un Active Directory _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 3268 IN SRV 600 0 sauron.mordor.fan.

Registres RRS de la zona original mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs.mordor.fan 
; Relatius a l'SOA, NS, MX i a l'registre A que mapeja; el Nom de l'Domini a la IP de Sàuron; Coses d'un Active Directory mordor.fan. 3600 IN SOA sauron.mordor.fan. hostmaster.mordor.fan. 48 900 600 mordor.fan. 86400 IN A 3600 mordor.fan. 600 IN NS sauron.mordor.fan. mordor.fan. 10.10.10.3 IN MX 3600 blackelf.mordor.fan. _msdcs.mordor.fan. 3600 IN NS sauron.mordor.fan. ; ; Registres A també importants DomainDnsZones.mordor.fan. 10 IN A 3600 ForestDnsZones.mordor.fan. 600 IN A 10.10.10.3; ; GLOBAL CATALOG _gc._tcp.mordor.fan. 600 IN SRV 10.10.10.3 600 sauron.mordor.fan. _gc._tcp.Default-First-Site-Name._sites.mordor.fan. 0 IN SRV 100 3268 sauron.mordor.fan. ; ; LDAP modificat i privat d'un Active Directory _ldap._tcp.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 100 IN SRV 3268 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 100 IN SRV 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 100 IN SRV 389 sauron.mordor.fan. ; ; Kerberos modificat i privat d'un Active Directory _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 389 IN SRV 600 0 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 100 IN SRV 389 sauron.mordor.fan. _kerberos._udp.mordor.fan. 600 IN SRV 0 100 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 389 IN SRV 600 sauron.mordor.fan. ; ; Registres A amb IP fixes -> Servidors blackelf.mordor.fan. 0 IN A 100 blackspider.mordor.fan. 389 IN A 600 darklord.mordor.fan. 0 IN A 100 mamba.mordor.fan. 88 IN A 600 palantir.mordor.fan. 0 IN A 100 sauron.mordor.fan. 88 IN A 600 shadowftp.mordor.fan. 0 IN A 100 troll.mordor.fan. 464 IN A 600; ; Registres CNAME ad-dc.mordor.fan. 0 IN CNAME sauron.mordor.fan. blog.mordor.fan. 100 IN CNAME troll.mordor.fan. fileserver.mordor.fan. 88 IN CNAME mamba.mordor.fan. ftpserver.mordor.fan. 600 IN CNAME shadowftp.mordor.fan. mail.mordor.fan. 0 IN CNAME balckelf.mordor.fan. openfire.mordor.fan. 100 IN CNAME palantir.mordor.fan. proxy.mordor.fan. 464 IN CNAME darklord.mordor.fan. www.mordor.fan. 3600 IN CNAME blackspider.mordor.fan.

Registres RRS de la zona original 10.10.10.in-addr.arpa

buzz @ sysadmin: ~ $ cat temp / rrs.10.10.10.in-addr.arpa 
; Relatius a l'SOA i a l'NS 10.10.10.in-addr.arpa. 3600 IN SOA sauron.mordor.fan. hostmaster.mordor.fan. 21 900 600 86400.in-addr.arpa. 3600 IN NS sauron.mordor.fan. ; ; Registres PTR 10.10.10.in-addr.arpa. 3600 IN PTR blackspider.mordor.fan. 10.10.10.10.in-addr.arpa. 3600 IN PTR palantir.mordor.fan. 11.10.10.10.in-addr.arpa. 3600 IN PTR sauron.mordor.fan. 3.10.10.10.in-addr.arpa. 3600 IN PTR mamba.mordor.fan. 4.10.10.10.in-addr.arpa. 3600 IN PTR dnslinux.mordor.fan. 5.10.10.10.in-addr.arpa. 3600 IN PTR darklord.mordor.fan. 6.10.10.10.in-addr.arpa. 3600 IN PTR troll.mordor.fan. 7.10.10.10.in-addr.arpa. 3600 IN PTR shadowftp.mordor.fan. 8.10.10.10.in-addr.arpa. 3600 IN PTR blackelf.mordor.fan.

Fins a aquest punt podem pensar que tenim les dades necessàries per a continuar en la nostra aventura, no sense abans observar els TTLS i altres dades que de forma molt concisa ens brinda la sortida i observació directa de l'DNS d'un Active Directory® 2008 SR2 de 64 bits de Microsft®.

Imatges de l'DNS Manager a Sàuron

Equip dnslinux.mordor.fan.

Si observem bé, a l'adreça IP 10.10.10.5 no se li va assignar nom algun perquè precisament quedés ocupada pel nom de el nou DNS dnslinux.mordor.fan. Per instal·lar la parella DNS i DHCP ens podem guiar pels articles DNS i DHCP a Debian 8 «Jessie» y DNS i DHCP a CentOS juliol.

Sistema operatiu base

El meu amic el Fueguino, A més de ser un veritable especialista en Microsoft Windows -posseeix un parell de Certificats expedits per aquesta companyia- ha llegit i posat en pràctica alguns dels articles sobre escriptoris publicats en DesdeLinux., I em va comentar que expressament volia una solució basada en Debian. 😉

Per complaure-ho, partirem d'una instal·lació nova i neta d'un servidor basat en Debian 8 «Jessie». Això no obstant, el que escriurem a continuació és vàlid per a les distribucions CentOS i openSUSE els articles esmentem abans. El BIND i el DHCP són els mateixos en qualsevol distro. Les lleugeres variacions les introdueixen els mantenidors dels paquets en cada distribució.

La instal·lació la farem segons el que indica DNS i DHCP a Debian 8 «Jessie», Posant cura en utilitzar la IP 10.10.10.5 i la xarxa 10.10.10.0/24., Fins abans de configurar l'BIND.

Configurem el BIND a l'estil Debian

/etc/bind/named.conf

l'arxiu /etc/bind/named.conf ho deixem tal qual s'instal·la.

/etc/bind/named.conf.options

l'arxiu /etc/bind/named.conf.options ha de quedar amb el contingut següent:

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 tallafocs between you and nameservers you want // to talk to, you may need to fix the tallafocs to allow múltiple // ports to talk. Veure 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. Veure https://www.isc.org/bind-keys // ================================== =================================== $

    // No volem DNSSEC
        DNSSEC-enable no;
        //DNSSEC-validation acte;

        auth-NXDOMAIN no; # Conform to RFC1035

 // No necessitem escoltar per adreces IPv6
        // listen-on-v6 {any; };
    listen-on-v6 {none; };

 // Per comprovacions des del localhost i sysadmin
    // mitjançant // dig mordor.fan AXFR // dig 10.10.10.in-addr.arpa AXFR // dig _msdcs.mordor.fan AXFR // No tenim DNS Esclaus ... fins ara
 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 {
         volies;
         };

category query-errors {
         query-error;
         };

};

• Introduïm la captura dels logs d'el BIND com un NOU aspecte en la sèrie d'articles sobre el tema. creem la carpeta i arxius necessaris per al Inici de sessió de l'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

Vam comprovar la sintaxi dels arxius configurats

root @ dnslinux: ~ # named-checkconf 
root @ dnslinux: ~ #

/etc/bind/named.conf.local

Creem l'arxiu /etc/bind/zones.rfcFreeBSD amb igual contingut que el que indica DNS i DHCP a Debian 8 «Jessie».

root @ dnslinux: ~ # nano /etc/bind/zones.rfcFreeBSD

l'arxiu /etc/bind/named.conf.local haurà de quedar amb el següent contingut:

// // Do any local configuration here // // Consider adding the 1918 zones here, if they are not used in your // organització
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 ignori; file "/etc/bind/db._msdcs.mordor.fan"; }; root @ dnslinux: ~ # named-checkconf
root @ dnslinux: ~ #

Arxiu 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; expiri 3H); minimum or; Negative caching time to live;
; MOLT DE COMPTE AMB ELS SEGÜENTS REGISTRES
@ IN NS dnslinux.mordor.fan.
@ IN A 10.10.10.5
@ 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
; CAP DE MOLT DE COMPTE AMB ELS SEGÜENTS REGISTRES;
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 modificat i privat d'un Active Directory _ldap._tcp.mordor.fan. 600 IN SRV 0 0 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 389 IN SRV 600 0 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 0 IN SRV 389 600 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 0 IN SRV 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 IN SRV 0 0 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 389 IN SRV 600 0 sauron.mordor.fan. ; ; Kerberos modificat i privat d'un Active Directory _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan. 0 IN SRV 389 600 0 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 0 IN SRV 389 600 0 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 0 IN SRV 88 600 sauron.mordor.fan. _kerberos._udp.mordor.fan. 0 IN SRV 0 88 600 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 0 IN SRV 0 464 sauron.mordor.fan. ; ; Registres A amb IP fixes -> Servidors blackelf.mordor.fan. IN A 600 blackspider.mordor.fan. IN A 0 darklord.mordor.fan. IN A 0 mamba.mordor.fan. IN A 88 palantir.mordor.fan. IN A 600
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; ; Registres 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

els temps TTL 600 de tots els registres SRV els mantindrem per si instal·lem un BIND Esclau en temps per vanir. Aquests registres representen serveis de l'Active Directory® que majorment llegeixen dades de la base de dades de l'LDAP. Com aquesta base de dades canvia amb freqüència, s'han de mantenir curts els temps de sincronisme, en un esquema DNS Mestre - Esclau. Segons la filosofia Microsoft observada des de l'Active Directory 2000 fins al 2008, es manté el valor de 600 per a aquests tipus de registres SRV.

Els TTLS dels servidors amb IP fixes, queden sota el temps declarat al SOA de 3 hores.

Arxiu 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; expiri 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

Arxiu de la Zona _msdcs.mordor.fan

Tinguem en compte el recomanat a l'arxiu /usr/share/doc/bind9/README.Debian.gz dobre la ubicació dels arxius de les Zones Mestres no sotmeses a actualitzacions dinàmiques pel 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; expiri 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 ​​-a la base de dades de l'LDAP modificat i privat d'un Active Directory- de Sàuron 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 IN CNAME sauron.mordor.fan. ; ; LDAP modificat i privat d'un Active Directory _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 100 IN SRV 389 sauron.mordor.fan. _ldap._tcp.600d0d-100fdb-389cf-a18-d3360c8b40d678.domains._msdcs.mordor.fan. 7 IN SRV 420 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 6 IN SRV 775 600 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 0 IN SRV 100 389 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. ; ; Kerberos modificat i privat d'un Active Directory _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 100 IN SRV 3268 600 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 0 IN SRV 100 3268 sauron.mordor.fan.

Comprovem la sintaxi i podemmos ignorar l'error que retorna, ja que en la configuració d'aquesta zona a l'arxiu /etc/bind/named.conf.local incloem la declaració check-names ignori;. La zona serà correctament carregada pel 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 estatus bind9.service 
● bind9.service - BIND nom de camp Server Loaded: loaded (/lib/systemd/system/bind9.service; enabled) Drop-In: /run/systemd/generator/bind9.service.d └─50-insserv.conf- $ named.conf Active: activi (running) since dg 2017 02:12:08 EST; 48s ago Docs: man: named (38) Process: 2 ExecStop = / usr / sbin / rndc stop (code = exited, status = 8 / SUCCESS) Main PID: 859 (named) CGroup: /system.slice/bind0.service └─864 / usr / sbin / named -f -o bind febrer 9 864:12:08 dnslinux named [48]: zone 38.efip864.arpa/IN: loaded serial 3 febrer 6 1:12:08 dnslinux named [48 ]: zone befip38.arpa/IN: loaded serial 864 febrer 6 1:12:08 dnslinux named [48]: zone 38.efip864.arpa/IN: loaded serial 0 febrer 6 1:12:08 dnslinux named [48]: zone 38.efip864.arpa/IN: loaded serial 7 febrer 6 1:12:08 dnslinux named [48]: zone mordor.fan/IN: loaded serial 38 febrer 864 1:12:08 dnslinux named [48]: zone example .org / IN: loaded serial 38 febrer 864 1:12:08 dnslinux named [48]: zone _msdcs.mordor.fan/IN: loaded serial 38 febrer 864 1:12:08 dnslinux named [48]: zone invalid / IN : loaded serial 38 febrer 864 1:12:08 dnslinux named [48]: all zones loaded
febrer 12 08:48:38 dnslinux named [864]: funcionament

Vam consultar el BIND

Abans d'instal·lar el DHCP, hem d'efectuar tot un seguit de comprovacions que inclou fins a la unió d'un client Windows 7 a l'domini mordor.fan representat pel Active Directory instal·lat en l'equip sauron.mordor.fan.

El primer que hem de fer és aturar el servei DNS en l'equip sauron.mordor.fan, I declarar en la seva interfície de xarxa que d'ara endavant el seu servidor DNS serà el 10.10.10.5 dnslinux.mordor.fan.

En una consola de el propi servidor sauron.mordor.fan executem:

Microsoft Windows [versió 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 Àlies: 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
> sortir

C: \ Users \ Administrator>

Les consultes DNS realitzades des sauron.mordor.fan són satisfactòries.

El proper pas serà la creació d'una altra màquina virtual amb Windows 7 instal·lat. Com encara no tenim instal·lat el servei DHCP, li donarem a l'equip amb nom «win7»L'adreça IP 10.10.10.251. També li vam declarar que el seu servidor DNS serà el 10.10.10.5 dnslinux.mordor.fan, I que el domini de cerca serà mordor.fan. No registrarem aquest equip al DNS perquè el farem servir també per provar el servei DHCP després que el instal·lem.

A continuació obrim una consola CMD i en ella executem:

Microsoft Windows [versió 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
> sortir de

C: \ Users \ buzz>

Les consultes DNS efectuades des del client «win7»També van ser satisfactòries.

En l'Active Directory vam crear l'usuari «saruman«, Amb l'objectiu d'utilitzar-a l'unir el client win7 a el domini mordor.fan., Mitjançant el mètode «Identificador de xarxa«, Usant els noms d'usuaris saruman@mordor.fan y administrator@mordor.fan. La unió es va efectuar correctament i ho prova la següent captura de pantalla:

Sobre les Actualitzacions Dinàmiques al Microsoft DNS i en el BIND

Com tenim el servei DNS detingut a l'Active Directory® no li va ser possible a el client «win7»Registrar el seu nom i adreça IP en aquest DNS. Molt menys en dnslinux.mordor.fan ja que no vam fer cap declaració allow-update per qualsevol de les zones involucrades.

I aquí va ser on es va formar la bona baralla amb el meu amic el Fueguino. En el meu primer correu sobre aquest aspecte li vaig comentar:

• En els articles de Microsoft sobre l'ús de l'BIND i l'Active Directory® recomanen que, sobretot a la Zona Directa, es permeti ser actualitzada -penetrada- directament pels clients Windows que ja estan units a el domini de l'Active Directory.
• Per això és que, per defecte, a les zones de l'DNS d'un Active Directory® es permeten les Actualitzacions Dinàmiques Segures per part dels clients Windows que ja estiguin units a el domini de l'Active Directory. Sinó estan units, que s'abstinguin a les conseqüències.
• El DNS d'un Active Directory admet actualitzacions dinàmiques «Secure only», «Nonsecure and secure», o «None» que és el mateix que dir SENSE Actualitzacions o Cap.
• Si de veritat la Filosofia Microsoft no estigués d'acord amb que els seus clients NO s'actualitzaran les seves dades en el seu (s) DNS (s), no deixaria oberta la possibilitat d'inhabilitar les actualitzacions dinàmiques en el seu (s) DNS (s), llevat que aquesta opció es deixés per a propòsits més ocults.
• Microsoft ofereix «Seguretat» a canvi de Obscuridad, com em va afirmar un col·lega i amic que va passar cursos de Certificats Microsft®. Cert. A més, m'ho va confirmar El Fueguino.
• Un client que adquireixi una adreça IP per mitjà d'un DHCP instal·lat en una màquina amb UNIX® / Linux per exemple, no podrà resoldre l'adreça IP del seu propi nom fins que no estigui unit a el domini de l'Active Directory, Sempre que s'utilitzi com DNS el de Microsoft o BIND sense actualitzacions dinàmiques per part d'un DHCP.
• Si instal·lo el DHCP en el propi Active Directory®, llavors he de declarar que les Zones siguin actualitzades pel DHCP de Microsoft.
• Si anem a utilitzar el BIND com el DNS per a la xarxa Windows, el lògic i recomanat sigui que instal·lem la dupla BIND-DHCP, amb aquest últim actualitzant de forma dinàmica a l'BIND i assumpte conclòs.
• En el món de les xarxes LAN en UNIX® / Linux, des que es van inventar les actualitzacions dinàmiques sobre el BIND, només se li permet el Senyor DHCP «penetrar»A la Senyora BIND amb les seves actualitzacions. El relaxo que sigui amb ordre, si us plau.
• Quan declaro a la zona mordor.fan per exemple: allow-update {10.10.10.0/24; };, El mateix BIND m'informa a l'iniciar-lo o reiniciar-que:

  • zone 'mordor.fan' Allows updates by IP address, which is insecure

• En el sacrosant món UNIX® / Linux aquest desimboltura amb el DNS és senzillament inadmissible.

Es podran imaginar la resta de l'intercanvi amb el meu amic el Fueguino mitjançant missatges de correu electrònic, Telegram Xat, Trucades telefòniques pagades per ell (per descomptat home, que no tinc un quilo per això), i fins ¡missatges per mitjà de coloms missatgers en ple segle XXI !.

Fins i tot em va amenaçar de no enviar-me un fill de la seva mascota, el seu Iguana «Petra»Que m'havia promès com a part de l'pagament. Aquí si que em vaig espantar de veritat. Llavors vaig començar de nou, però des d'un altre angle.

• El «gairebé» Active Directory que es pot aconseguir amb Samba 4, resol aquest aspecte de forma magistral, tant quan fem servir la seva DNS Intern, o el BIND compilat perquè suporti zones DLZ - Dinamyc Loaded Zones, O Zones carregades Dinàmicament.
• Segueix patint del mateix: quan un client adquireix una adreça IP per mitjà d'un DHCP instal·lat a altra màquina amb UNIX® / Linux, no podrà resoldre l'adreça IP del seu propi nom fins que no estigui unit a el domini de l'AD-DC de Samba 4.
• Integrar la dupla BIND-DLZ i DHCP a la mateixa màquina on estigui instal·lat el AD-DC Samba 4 és tasca per a un especialista de veritat.

el Fueguino em va cridar a capítol i em va cridar: NO estem parlant de l' AD-DC Samba 4, Sinó de l'Microsoft® Active Directory® !. I humilment li vaig respondre que em embullé amb part dels següents articles que jo anava a escriure.

Llavors va ser quan li vaig dir que, la decisió final sobre les actualitzacions dinàmiques dels equips clients a la seva xarxa quedava al seu lliure albir. Que només li donaria el punta escrit abans sobre allow-update {10.10.10.0/24; };, I més res. Que jo no em feia responsable del que resultés d'aquesta promiscuïtat que cada client Windows -o Linux- a la seva xarxa «penetrés»Impunement el BIND.

Si vostè sabés amic Lector que aquest va ser el Punt Final a la batussa no m'ho creuria. El meu amic el Fueguino acceptar la solució -i em enviarà a la iguana «Petrica«- que ara comparteixo amb vostè.

Instal·lem i configurem el DHCP

Per a més detalls llegiu DNS i DHCP a Debian 8 «Jessie».

root @ dnslinux: ~ # aptitude install isc-dhcp-server

root @ dnslinux: ~ # nano / etc / default / isc-dhcp-server .... # On what interfícies should the DHCP server (dhcpd) serve DHCP requests? # Separate múltiple interfícies with spaces, ig "eth0 eth1". INTERFÍCIES = "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 // organització include "/etc/bind/zones.rfc1918"; include "/etc/bind/zones.rfcFreeBSD";
// No oblidar ... em vaig oblidar i vaig pagar amb errors. ;-)
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 ignori; 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."; ignori 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; }} # FI 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 estatus bind9.service 

root @ dnslinux: ~ # systemctl start isc-dhcp-server.service
root @ dnslinux: ~ # systemctl per a l'estat isc-dhcp-server.service

El relacionat amb les Comprovacions amb clients, I la Modificació manual dels arxius de Zones, El deixem perquè vostè, amic lector, el llegeixi directament de DNS i DHCP a Debian 8 «Jessie», I l'apliqui a les seves condicions reals. Nosaltres si efectuem totes les comprovacions necessàries i vam obtenir resultats satisfactoris. Per descomptat que enviem còpia de totes elles a el Fueguino. No faltés més !.

Consells

Generals

• Adquireixi una bona quantitat de paciència abans de començar.
  
• Primer instal·lat i configurat el BIND. Comproveu tot i consulti tots els registres que va declarar en cada arxiu de les tres -o més- zones, tant des del Active Directory com des del propi servidor DNS en Linux. Si és possible, des d'una màquina Linux que no estigui unida a l'domini, feu les necessàries consultes DNS a l'BIND.
  
• Una a l'domini existent un client Windows amb una adreça IP fixa, i torneu a comprovar tota la configuració de l'BIND des del client Windows.
• Després que vostè estigui indubtablement segur que la configuració del seu nou i flamant BIND és totalment correcta, aventúrese a instal·lar, configurar, i iniciar el servei DHCP.
• Davant errors, repeteixi tot el procediment des de zero 0.
• Compte amb el copy & paste! i els espais sobrants en cada línia dels arxius named.conf.xxxx
  
• Després no es queixi -molt menys amb el meu amic el Fueguino- que no ho van aconsellar degudament.

altres consells

• Divideix i venceràs.
• En una Xarxa PIME és més segur i beneficiós instal·lar un BIND Autoritari per a les Zones de la LAN interna que no faci recursivitat a cap servidor arrel: recurs no;.
• En una Xarxa PIME situada sota un Proveïdor d'Accés a Internet - ISP, Per ventura els serveis Apoderat y SMTP necessiten resoldre noms de domini a Internet. el Calamar té l'opció de declarar els seus DNS siguin externs o no, mentre que a un servidor de correu basat en Postfix o MDaemon® també podem declarar els servidors DNS que utilitzarem en aquest servei. En casos com aquest, és a dir, casos que no ofereixin serveis a Internet i que estiguin sota d'un Internet Service Provider, Es pot instal·lar un BIND amb Transitaris apuntant als DNS de l' ISP, I declarar-ho com DNS secundari en els servidors que necessitin resoldre consultes externes a la LAN, sinó és possible declarar-los mitjançant els seus propis arxius de configuració.
• Si vostè té una zona delegada sota la seva total responsabilitat, Llavors canta un altre gall:
  • Instal un servidor DNS basat en NSD, El qual és un servidor DNS Autoritari per definició, que respongui a les consultes provinents d'equips a Internet. Per alguna informació aptitude show nsd. 😉 Favor de protegir-molt bé mitjançant tants murs tallafocs com siguin necessaris. Tant per maquinari com per programari. Serà un DNS cara a Internet, i aquesta «Zar»No l'hem de trobar els pantalons baixos. 😉
  • Com mai m'he vist en un cas com el aquest, o sigui, responsable total d'una zona Delegada, hauria de pensar molt bé de recomanar per a la resolució de noms de domini externs a la nostra LAN per als serveis que ho necessitin. Els Clients de la Xarxa PIME no ho necessiten realment. Consulteu literatura especialitzada, oa un especialista en aquests temes, ja que estic molt lluny de ser un d'ells. De debò.
  • En els servidors Autoritaris no existeix la Recursivitat. ¿Ok ?. Per si a algú se li ocorre fer-ho amb un BIND.
• Malgrat que especifiquem explícitament en el fitxer /etc/dhcp/dhcpd.conf la declaració ignori client-updates;, Si executem en una consola de l'equip dnslinux.mordor.fan l'ordre journalctl -f, Veurem que a l'engegar el client win7.mordor.fan obtenim els següents missatges d'error:

  • febrer 12 16:55:41 dnslinux named [900]: client 10.10.10.30 # 58762: update 'mordor.fan/IN' denied
    febrer 12 16:55:42 dnslinux named [900]: client 10.10.10.30 # 49763: update 'mordor.fan/IN' denied
    febrer 12 16:56:23 dnslinux named [900]: client 10.10.10.30 # 63161: update 'mordor.fan/IN' denied
    

  • Per eliminar aquests missatges, hem d'anar a les opcions avançades de la configuració de la targeta de xarxa i desmarcar l'opció «Register this connection 's addresses in DNS«. Això evitarà per sempre que el client intenti acte registrés al DNS Linux i cap de el problema. Ho sento, però no tinc una còpia de Windows 7 en espanyol. 😉
• Per assabentar-se de totes les consultes serioses -i boges- que fa un client Windows 7, consulteu el log queries.log que per alguna cosa el declarem en la configuració de l'BIND. L'ordre seria:

  • root @ dnslinux: ~ # tail -f /var/log/named/queries.log

• Si No permet que els seus equips clients es connectin directament a Internet, llavors perquè li fan falta els servidors DNS Arrels ?. Això disminuirà considerablement la sortida de la comanda journalctl -f i de l'anterior, si el seu servidor DNS Autoritari per a les Zones Internes no es connecta directament amb Internet, la qual cosa és molt recomanat des del punt de vista de la seguretat.

  root @ dnslinux: ~ # cp /etc/bind/db.root /etc/bind/db.root.original
  root @ dnslinux: ~ # cp / dev / null /etc/bind/db.root

• Sinó necessita la declaració dels servidors arrels, llavors perquè li cal la Recursivitat - La recursivitat?

  root @ dnslinux: ~ # nano /etc/bind/named.conf.options
  opcions {
   ....
   recurs no;
   ....
  };

Consell específic de el qual encara no estic molt clar

El man dhcpd.conf ens diu el següent entre moltes -muchísimas- cosa mes:

        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ó o interpretació més o menys exacta es la deixem vostra, car lector.

Personalment m'ha passat -i va succeir durant la confecció d'aquest article- que quan enllaço 4 BIND a un Active Directory® sigui de Microsft® o de Samba XNUMX, si li canvio el nom a un equip client registrat en el domini de l'Active Directory® o de l' AD-DC de Samba 4, manté el seu nom antic i adreça IP a la Zona Directa, i no així en la inversa que s'actualitza correctament amb el nom nou. O sigui, es mapegen el nom antic i el nou a la mateixa adreça IP a la Zona Directa, mentre que a la inversa només apareix el nom nou. Per entendre-bé ho han de provar Vostès mateixos.

Penso sigui una mena de venjança cap a el Fueguino -que no cap a mi, per favor- per tractar de migrar els seus serveis a Linux.

Per descomptat que el nom antic desapareixerà quan expiri el seu TTL 3600, O el temps que hàgim declarat en la configuració de l'DHCP. Però volem que desaparegui immediatament com succeeix en un BIND + DHCP sense un Active Directory per mitjà.

La solució a aquesta situació la vaig trobar inserint la declaració update-optimization false; a la fi de la part superior de l'arxiu /etc/dhcp/dhcpd.conf:

DDNS-update-style interim; DDNS-updates on; DDNS-domainname "mordor.fan."; DDNS-rev-domainname "in-addr.arpa."; ignori client-updates;
update-optimization false;

Si algun lector coneix mes a l'respecte, si us plau de il·luminar-. L'hi agrairé i molt.

Resum

Ens hem divertit un munt amb el tema, no ?. Res de sofriments doncs tenim un BIND funcionant com a servidor DNS en una xarxa Microsoft, oferint tots els registres SRV i responent adequadament a les consultes DNS que se'ls faci. D'altra banda tenim a un servidor DHCP atorgant adreces IP i actualitzant correctament de forma dinàmica a les Zones de l'BIND.

Mas no podem demanar ... de moment.

Espero que el meu amic el Fueguino estigui content i satisfet de el primer pas en la seva migració a Linux per fer suportable els insuportables costos de el Suport Tècnic de Microsft®.

Nota important

El personatge «el Fueguino»És completament fictici i producte de la meva imaginació. Qualsevol semblança o coincidència amb persones reals és això mateix: Pura Coincidència Involuntària de la meva part. Només el vaig crear per fer una mica amena la redacció i lectura d'aquest article. Ara si que em poden dir que el tema DNS és obscur,