BIND kaj Active Directory® - SME-Retoj

Ĝenerala indekso de la serio: Komputilaj Retoj por SMEoj: Enkonduko

Saluton, amikoj!. La ĉefa celo de ĉi tiu artikolo estas montri, kiel ni povas integri la DNS-servon bazitan sur la BIND9 en reto de Microsoft, tre ofta en multaj PYME.

Ĝi ekestiĝas de la oficiala peto de amiko, kiu loĝas en La Fajrolando -La Fuegian- specialiĝis pri Retoj de Microsoft® - Atestiloj inkluzivitaj - por gvidi vin en ĉi tiu parto de la migrado de viaj serviloj al Linukso. La kostoj de Subteno Teknikisto, kiu pagas Microsoft®, jam estas Neeltenebla por la Kompanio, en kiu li laboras kaj de kiu li estas lia Ĉefa Akciulo.

Mi amiko La Fuegian li havas bonegan humursenton, kaj de kiam li vidis la serion de tri filmoj «La Sinjoro de la Ringoj»Lin allogis multaj el la nomoj de liaj malhelaj roluloj. Do, Leganto amiko, ne miru pri la nomoj de via domajno kaj viaj serviloj.

Por novuloj al la temo, kaj antaŭ ol legi, ni rekomendas, ke vi legu kaj studu la tri antaŭajn artikolojn pri retoj de pymes:

Estas kiel spekti tri el la kvar partoj de «Submondo»Eldonita ĝis hodiaŭ, kaj ke ĉi tiu estas la kvara.

Ĝeneralaj parametroj

Post pluraj interŝanĝoj per retpoŝto, finfine mi klaris pri la ĉefaj parametroj de via nuna reto, kiuj estas:

Domajna nomo mordor.fan LAN Reto 10.10.10.0/24 ====================================== =========================================== Serviloj IP-Adreso Celo (Serviloj kun OS Vindozo) ================================================== =============================== sauron.mordor.fan. 10.10.10.3 Active Directory® 2008 SR2 mamba.mordor.fan. 10.10.10.4 Vindozo dosierservilo darklord.mordor.fan. 10.10.10.6 prokurilo, enirejo kaj fajroŝirmilo ĉe Kerios troll.mordor.fan. 10.10.10.7 Blogo bazita sur ... ne memoras shadowftp.mordor.fan. 10.10.10.8 FTP-servilo blackelf.mordor.fan. 10.10.10.9 Plena retpoŝta servo blackspider.mordor.fan. 10.10.10.10 WWW-servo palantir.mordor.fan. 10.10.10.11 Babilejo pri Openfire por Vindozo

Mi petis permeson La Fuegian agordi tiom da kaŝnomoj kiom necesas por liberigi mian menson kaj donis al mi lian permeson:

Reala CNAME ============================== sauron ad-dc mamba dosierservilo darklord proxyweb troll blogo shadowftp ftpserver nigra poŝto blackspider www palantir openfire

Mi deklaris ĉiujn gravajn DNS-rekordojn en mia instalado de Aktiva Adresaro Vindozo 2008, kiun mi estis devigita efektivigi por gvidi min en la kreo de ĉi tiu afiŝo.

Pri Active Directory DNS-SRV-registroj

La registroj SRV Servaj Lokaliziloj - vaste uzataj en Microsoft Active Directory - estas difinitaj en la Peto pri Komentoj RFC 2782. Ili permesas la lokon de servo bazita sur la protokolo TCP / IP per DNS-konsulto. Ekzemple, kliento en reto de Mikrosofto povas trovi la lokon de Domajnaj Regiloj - Regilaj Regiloj kiuj provizas la LDAP-servon super la TCP-protokolo ĉe la haveno 389 per ununura DNS-konsulto.

Estas normale, ke en la Arbaroj - Arbaroj, kaj Arboj - arboj de granda Mikrosofta Reto ekzistas pluraj Domajnaj Regiloj. Uzante la SRV-registrojn en la malsamaj Zonoj, kiuj konsistas el la Domajna Spaco de tiu Reto, ni povas konservi Liston de Serviloj, kiuj provizas similajn konatajn servojn, ordigitaj laŭ prefero laŭ la transporta protokolo kaj haveno de ĉiu unu el la serviloj.

En la Peto pri Komentoj RFC 1700 Difini Universalajn Simbolajn Nomojn por Konataj Servoj - Konata Servo, kaj nomoj kiel «_telnet","_smtp»Por servoj telnet y SMTP. Se simbola nomo ne estas difinita por Konata Servo, loka nomo aŭ alia nomo povas esti uzataj laŭ la preferoj de la uzanto.

Ligi

La celo de ĉiu kampo «speciala»Uzata en la deklaro de SRV-Rimeda Rekordo estas la jena:

  • havaĵo: "Pdc._msdcs.mordor.fan.«. DNS-nomo de la servo, al kiu rilatas la SRV-rekordo. La DNS-nomo en la ekzemplo signifas -pli aŭ malpli- Ĉefregiona Regilo de la areo _msdcs.mordor.fan.
  • servo: "_Lap". Simbola nomo de la servo provizita difinita laŭ Peto pri Komentoj RFC 1700.
  • protokolon: "_Tcp". Indikas la specon de transporta protokolo. Tipe ĝi povas preni la valorojn _tcp o _udp, kvankam -kaj efektive- ajna speco de transporta protokolo indikita en la Peto pri Komentoj RFC 1700. Ekzemple, por servo babilejo protokol-bazita XMPP, ĉi tiu kampo havus la valoron de _xmpp.
  • prioritato: «0«. Deklaru la prioritaton aŭ preferon por la Gastiganto ofertanta ĉi tiun servon tion ni vidos poste. La DNS-demandoj de la klientoj pri la servo difinita de ĉi tiu SRV-dosiero, ricevinte la taŭgan respondon, provos kontakti la unuan disponeblan gastiganton kun la plej malalta nombro listigita en la kampo. prioritato. La gamo de valoroj, kiujn ĉi tiu kampo povas preni, estas 0 a 65535.
  • Pezo: «100«. Uzebla kune kun prioritato provizi ŝarĝan ekvilibran mekanismon kiam ekzistas pluraj serviloj, kiuj provizas la saman servon. Devus esti simila SRV-registro por ĉiu servilo en la Zona dosiero, kun ĝia nomo deklarita sur la kampo Gastiganto ofertanta ĉi tiun servon. Antaŭ serviloj kun egalaj valoroj sur la kampo prioritato, la kampa valoro Pezo ĝi povas esti uzata kiel aldona prefernivelo por akiri ĝustan servilan elekton por ŝarĝa ekvilibro. La gamo de valoroj, kiujn ĉi tiu kampo povas preni, estas 0 a 65535. Se ŝarĝa ekvilibro ne necesas, ekzemple kiel ĉe unu servilo, oni rekomendas atribui la valoron 0 por faciligi la legadon de la SRV-disko.
  • Havena numero - Haveno: «389«. Havena numero en Gastiganto ofertanta ĉi tiun servon kiu provizas la servon indikitan en la kampo servo. La rekomendita havennumero por ĉiu tipo de Konata Servo estas indikita sur la Peto pri Komentoj RFC 1700, kvankam ĝi povas preni valoron inter 0 kaj 65535.
  • Gastiganto ofertanta ĉi tiun servon - Celon: «sauron.mordor.fan.«. Specifas la FQDN tio sendube identigas la gastiganto tio provizas la servon indikitan per la SRV-rekordo. Rekorda tipo «A»En la domajna nomspaco por ĉiu FQDN de la servilo aŭ gastiganto tio provizas la servon. Pli simpla, tipo-rekordo A en la rekta (j) zono (j).
    • Noto:
      Aŭtoritate indiki, ke la servo specifita de la SRV-dosiero ne estas provizita ĉe ĉi tiu gastiganto, unu (
      .) punkto.

Ni nur volas ripeti, ke la ĝusta funkciado de reto aŭ Active Directory® multe dependas de la ĝusta funkciado de la Domajna Servo..

Rekordoj DNS de Aktiva Adresaro

Por krei la Zonojn de la nova DNS-Servilo surbaze de BIND, ni devas akiri ĉiujn DNS-registrojn de Active Directory®. Por plifaciligi la vivon, ni iras al la teamo sauron.mordor.fan -Active Directory® 2008 SR2- kaj en la Administra Konzolo DNS ni aktivigas la Zonan Transdonon -rektan kaj inversan- por la ĉefaj zonoj deklaritaj en ĉi tiu tipo de servo, kiuj estas:

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

Post kiam la antaŭa paŝo estis plenumita kaj prefere de Linukso-komputilo kies IP-adreso estas ene de la intervalo de la subreto uzita de la Vindoza Reto, ni ekzekutas:

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
  • Memoru de antaŭaj artikoloj, ke la IP-adreso de la aparato sysadmin.fromlinux.fan estas 10.10.10.1 aŭ 192.168.10.1.

En la tri antaŭaj komandoj ni povas forigi la opcion @10.10.10.3 -demandu la DNS-servilon kun tiu adreso- se ni deklaras en la dosiero /etc/resolv.conf al servila IP sauron.mordor.fan:

buzz @ sysadmin: ~ $ cat /etc/resolv.conf # Generita de NetworkManager-serĉo de linux.fan nomservilo 192.168.10.5 nomservilo 10.10.10.3

Post redaktado kun ekstrema zorgo, kiel respondas al iu ajn zona dosiero en BIND, ni akiros la jenajn datumojn:

RR-registroj de la originala zono _msdcs.mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs._msdcs.mordor.fan 
; Rilate al SOA kaj NS _msdcs.mordor.fan. 3600 EN SOA sauron.mordor.fan. gastiganto.mordor.fan. 12 900 600 86400 3600 _msdcs.mordor.fan. 3600 EN NS sauron.mordor.fan. ; ; TUTA KATALOGO gc._msdcs.mordor.fan. 600 EN A 10.10.10.3; ; Kaŝnomoj -en la modifita kaj privata LDAP-datumbazo de Aktiva Adresaro- de SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 EN CNAME sauron.mordor.fan. ; ; Modifita kaj privata LDAP de Aktiva Adresaro _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 EN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 600 EN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan. 600 EN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 600 EN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 600 EN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 EN SRV 0 100 389 sauron.mordor.fan. ; ; KERBEROS modifita kaj privata de Aktiva Adresaro _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 EN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 600 EN SRV 0 100 88 sauron.mordor.fan.

RR-registroj de la originala zono mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs.mordor.fan 
; Rilate al SOA, NS, MX kaj la A-rekordo, kiun ĝi mapas; la Domajna Nomo al la IP de SAURON; Aĵoj de Aktiva Adresaro mordor.fan. 3600 EN SOA sauron.mordor.fan. gastiganto.mordor.fan. 48 900 600 86400 3600 mordor.fan. 600 IN A 10.10.10.3 mordor.fan. 3600 EN NS sauron.mordor.fan. mordor.fan. 3600 IN MX 10 blackelf.mordor.fan. _msdcs.mordor.fan. 3600 EN NS sauron.mordor.fan. ; ; Ankaŭ grava A registras DomainDnsZones.mordor.fan. 600 IN A 10.10.10.3 ForestDnsZones.mordor.fan. 600 EN A 10.10.10.3; ; TUTA KATALOGO _gc._tcp.mordor.fan. 600 EN SRV 0 100 3268 sauron.mordor.fan. _gc._tcp.Default-First-Site-Name._sites.mordor.fan. 600 EN SRV 0 100 3268 sauron.mordor.fan. ; ; Modifita kaj privata LDAP de Aktiva Adresaro _ldap._tcp.mordor.fan. 600 EN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 600 EN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 600 EN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 600 EN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 EN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 600 EN SRV 0 100 389 sauron.mordor.fan. ; ; KERBEROS modifita kaj privata de Aktiva Adresaro _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan. 600 EN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 600 EN SRV 0 100 88 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 600 EN SRV 0 100 464 sauron.mordor.fan. _kerberos._udp.mordor.fan. 600 EN SRV 0 100 88 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 600 EN SRV 0 100 464 sauron.mordor.fan. ; ; Registras A kun fiksa IP -> Serviloj blackelf.mordor.fan. 3600 IN A 10.10.10.9 nigra araneo.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 EN A 10.10.10.7; ; CNAME registras ad-dc.mordor.fan. 3600 EN CNAME sauron.mordor.fan. blogo.mordor.fan. 3600 EN CNAME troll.mordor.fan. fileserver.mordor.fan. 3600 EN CNAME mamba.mordor.fan. ftpserver.mordor.fan. 3600 EN CNAME shadowftp.mordor.fan. poŝto.mordor.fan. 3600 EN CNAME balckelf.mordor.fan. openfire.mordor.fan. 3600 EN CNAME palantir.mordor.fan. prokurilo.mordor.fan. 3600 EN CNAME darklord.mordor.fan. www.mordor.fan. 3600 EN CNAME blackspider.mordor.fan.

RR-registroj de originala zono 10.10.10.in-addr.arpa

buzz @ sysadmin: ~ $ cat temp / rrs.10.10.10.in-addr.arpa 
; Rilate al SOA kaj NS 10.10.10.in-addr.arpa. 3600 EN SOA sauron.mordor.fan. gastiganto.mordor.fan. 21 900 600 86400 3600 10.10.10.in-addr.arpa. 3600 EN NS sauron.mordor.fan. ; ; PTR registras 10.10.10.10.in-addr.arpa. 3600 EN 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 EN 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 EN PTR dnslinux.mordor.fan. 6.10.10.10.in-addr.arpa. 3600 EN PTR darklord.mordor.fan. 7.10.10.10.in-addr.arpa. 3600 EN PTR troll.mordor.fan. 8.10.10.10.in-addr.arpa. 3600 EN PTR shadowftp.mordor.fan. 9.10.10.10.in-addr.arpa. 3600 IN PTR blackelf.mordor.fan.

Ĝis ĉi tiu punkto ni povas pensi, ke ni havas la necesajn datumojn por daŭrigi nian aventuron, ne sen antaŭe observi la TTLoj kaj aliaj datumoj, kiuj tre koncize donas al ni la eliron kaj rektan observadon de la DNS de Microsft® Active Directory® 2008 SR2 64 bitoj.

Bildoj de la DNS-administrilo en SAURON

Dnslinux.mordor.fan-teamo.

Se ni atente rigardas, al la IP-adreso 10.10.10.5 neniu nomo estis atribuita al ĝi ĝuste por ke ĝi estu okupita per la nomo de la nova DNS dnslinux.mordor.fan. Por instali la paron DNS kaj DHCP ni povas esti gvidataj de la artikoloj DNS kaj DHCP en Debian 8 "Jessie" y DNS kaj DHCP ĉe CentOS 7.

Baza operaciumo

Mi amiko La FuegianKrom esti vera specialisto pri Microsoft® Windows - li havas kelkajn Atestilojn eldonitajn de tiu kompanio - li legis kaj praktikis iujn artikolojn pri labortabloj publikigitaj en De Linukso., kaj li diris al mi, ke li esprimas deziron de Debiana solvo. 😉

Por plaĉi al vi, ni komencos per nova, pura instalado de servilo bazita sur Debian 8 "Jessie". Tamen tio, kion ni skribos poste, validas por la distribuoj de CentOS kaj openSUSE, kies artikolojn ni menciis antaŭe. BIND kaj DHCP samas en iu ajn distro. Iomete varioj estas enkondukitaj de la pakaj prizorgantoj en ĉiu distribuo.

Ni faros la instaladon kiel indikite en DNS kaj DHCP en Debian 8 "Jessie", zorgante uzi la IP 10.10.10.5 kaj la reto 10.10.10.0 / 24., eĉ antaŭ agordi la BIND.

Ni agordas la BIND laŭ la Debiana stilo

/etc/bind/named.conf

La arkivo /etc/bind/named.conf ni lasas ĝin kiel ĝi estas instalita.

/etc/bind/named.conf.options

La arkivo /etc/bind/named.conf.options restu kun la jena enhavo:

root @ dnslinux: ~ # cp /etc/bind/named.conf.options /etc/bind/named.conf.options.original

root @ dnslinux: ~ # nano /etc/bind/named.conf.options
opcioj {dosierujo "/ var / cache / bind"; // Se estas fajroŝirmilo inter vi kaj nomserviloj, kun kiuj vi volas // paroli, vi eble devos ripari la fajromuron por permesi al pluraj // havenoj paroli. Vidu http://www.kb.cert.org/vuls/id/800113 // Se via ISP provizis unu aŭ plurajn IP-adresojn por stabilaj // nomserviloj, vi probable volas uzi ilin kiel plusendilojn. // Malkomentigu la sekvan blokon, kaj enmetu la adresojn anstataŭigante // la anstataŭilon de ĉiuj 0. // plusendantoj {// 0.0.0.0; //}; // ================================================= ===================== $ // Se BIND registras erarmesaĝojn pri la radika ŝlosilo eksvalidiĝanta, // vi devos ĝisdatigi viajn ŝlosilojn. Vidu https://www.isc.org/bind-keys // ================================== =================================== $

    // Ni ne volas DNSSEC
        dnssec-enable ne;
        //dnssec-validado aŭtomata;

        auth-nxdomain ne; # konformas al RFC1035

 // Ni ne bezonas aŭskulti IPv6-adresojn
        // aŭskultu-v6 {iu ajn; };
    aŭskultu-ĉe-v6 {neniu; };

 // Por ĉekoj de localhost kaj sysadmin
    // tra // dig mordor.fan axfr // dig 10.10.10.in-addr.arpa axfr // dig _msdcs.mordor.fan axfr // Ni ne havas Sklavan DNS ... ĝis nun
 permesi-translokigi {localhost; 10.10.10.1; };
};

// Registrado BIND
ensalutado {

        demandoj pri kanalo {
        dosiero "/var/log/named/queries.log" versioj 3 grandeco 1m;
        informoj pri severeco;
        presita tempo jes;
        print-severity jes;
        preskategorio jes;
        };

        kanala demando-eraro {
        dosiero "/var/log/named/query-error.log" versioj 3 grandeco 1m;
        informoj pri severeco;
        presita tempo jes;
        print-severity jes;
        preskategorio jes;
        };

                                
demandoj pri kategorio {
         demandoj;
         };

kategoriaj demandaj eraroj {
         demando-eraro;
         };

};
  • Ni enkondukas la kapton de la BIND-protokoloj kiel NUEVO apero en la serio de artikoloj pri la temo. Ni kreas ldosierujo kaj dosieroj necesaj por la tala de la LIGA:
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

Ni kontrolas la sintakson de la agorditaj dosieroj

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

/etc/bind/named.conf.local

Ni kreas la dosieron /etc/bind/zones.rfcFreeBSD kun la sama enhavo kiel indikita en DNS kaj DHCP en Debian 8 "Jessie".

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

La arkivo /etc/bind/named.conf.local restu kun la jena enhavo:

// // Faru iun ajn lokan agordon ĉi tie // // Konsideru aldoni la 1918 zonojn ĉi tie, se ili ne estas uzataj en via // organizo
inkluzivi "/etc/bind/zones.rfc1918"; inkluzivi "/etc/bind/zones.rfcFreeBSD";

zono "mordor.fan" {tipo majstro; dosiero "/var/lib/bind/db.mordor.fan"; }; zono "10.10.10.in-addr.arpa" {tipo majstro; dosiero "/var/lib/bind/db.10.10.10.in-addr.arpa"; };

zono "_msdcs.mordor.fan" {tipo majstro;
 ĉekonomoj ignoras; dosiero "/etc/bind/db._msdcs.mordor.fan"; }; root @ dnslinux: ~ # named-checkconf
root @ dnslinux: ~ #

Zona Dosiero mordor.fan

root @ dnslinux: ~ # nano /var/lib/bind/db.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; seria 1D; refreŝigi 1H; reprovi 1W; eksvalidiĝi 3H); minimuma aŭ; Negativa konservado de tempo;
; ESTU TRE ATENTA KUN LA SEGANTAJ REKORDOJ
@ IN NS dnslinux.mordor.fan.
@ EN A 10.10.10.5
@ IN MX 10 blackelf.mordor.fan. @ IN TXT "Bonvenon al La Malluma Lan de Mordor";
_msdcs.mordor.fan. EN NS dnslinux.mordor.fan.
;
dnslinux.mordor.fan. EN A 10.10.10.5
; FINU TRE ATENTE PER LA JENAJ REKORDOJ;
DomainDnsZones.mordor.fan. EN A 10.10.10.3 ForestDnsZones.mordor.fan. EN A 10.10.10.3; ; TUTA KATALOGO _gc._tcp.mordor.fan. 600 EN SRV 0 0 3268 sauron.mordor.fan. _gc._tcp.Default-First-Site-Name._sites.mordor.fan. 600 EN SRV 0 0 3268 sauron.mordor.fan. ; ; Modifita kaj privata LDAP de Aktiva Adresaro _ldap._tcp.mordor.fan. 600 EN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 600 EN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 600 EN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 600 EN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 EN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 600 EN SRV 0 0 389 sauron.mordor.fan. ; ; Modifita kaj privata KERBEROS de Active Directory _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan. 600 EN SRV 0 0 88 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 600 EN SRV 0 0 88 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 600 EN SRV 0 0 464 sauron.mordor.fan. _kerberos._udp.mordor.fan. 600 EN SRV 0 0 88 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 600 EN SRV 0 0 464 sauron.mordor.fan. ; ; Registras A kun fiksa IP -> Serviloj blackelf.mordor.fan. EN A 10.10.10.9 nigra araneo.mordor.fan. EN 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. EN A 10.10.10.11
sauron.mordor.fan. EN A 10.10.10.3
shadowftp.mordor.fan. EN A 10.10.10.8 troll.mordor.fan. EN A 10.10.10.7; ; CNAME registras ad-dc.mordor.fan. EN CNAME sauron.mordor.fan. blogo.mordor.fan. EN CNAME troll.mordor.fan. fileserver.mordor.fan. EN CNAME mamba.mordor.fan. ftpserver.mordor.fan. EN CNAME shadowftp.mordor.fan. poŝto.mordor.fan. EN CNAME balckelf.mordor.fan. openfire.mordor.fan. EN CNAME palantir.mordor.fan. prokurilo.mordor.fan. EN CNAME darklord.mordor.fan. www.mordor.fan. EN CNAME blackspider.mordor.fan.

root @ dnslinux: ~ # named-checkzone mordor.fan /var/lib/bind/db.mordor.fan 
zono mordor.fan/IN: ŝarĝita seria 1 OK

La tempoj TTL 600 el ĉiuj SRV-registroj ni konservos ilin, se ni instalos Sklavon BIND baldaŭ. Tiuj registroj reprezentas Active Directory®-servojn, kiuj plejparte legas datumojn de via LDAP-datumbazo. Ĉar tiu datumbazo ofte ŝanĝiĝas, la sinkronigaj tempoj devas esti mallongaj, en mastro-sklava DNS-skemo. Laŭ la Microsoft-filozofio observita de Active Directory 2000 ĝis 2008, la valoro de 600 estas konservita por ĉi tiuj specoj de SRV-registroj.

la TTLoj de la serviloj kun fiksa IP, ili estas sub la deklarita tempo en la SOA de 3 horoj.

Zona Dosiero 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; seria 1D; refreŝigu 1H; reprovu 1W; eksvalidiĝu 3H); minimuma aŭ; Negativa konservado de tempo; @ IN NS dnslinux.mordor.fan. ; 10 EN PTR blackspider.mordor.fan. 11 EN PTR palantir.mordor.fan. 3 EN PTR sauron.mordor.fan. 4 EN PTR mamba.mordor.fan. 5 EN PTR dnslinux.mordor.fan. 6 EN PTR darklord.mordor.fan. 7 EN PTR troll.mordor.fan. 8 EN PTR shadowftp.mordor.fan. 9 EN PTR blackelf.mordor.fan.

root @ dnslinux: ~ # named-checkzone 10.10.10.in-addr.arpa /var/lib/bind/db.10.10.10.in-addr.arpa 
zono 10.10.10.in-addr.arpa/IN: ŝarĝita seria 1 OK

Zona Dosiero _msdcs.mordor.fan

Ni konsideru tion, kio rekomendas en la dosiero /usr/share/doc/bind9/README.Debian.gz Pri la loko de la dosieroj de la Majstraj Zonoj ne submetitaj al dinamikaj ĝisdatigoj de DHCP.

root @ dnslinux: ~ # nano /etc/bind/db._msdcs.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; seria 1D; refreŝigi 1H; reprovi 1W; eksvalidiĝi 3H); minimuma aŭ; Negativa konservado de tempo; @ IN NS dnslinux.mordor.fan. ; ; ; TUTA KATALOGO gc._msdcs.mordor.fan. 600 EN A 10.10.10.3; ; Kaŝnomoj -en la modifita kaj privata LDAP-datumbazo de Aktiva Adresaro- de SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 EN CNAME sauron.mordor.fan. ; ; Modifita kaj privata LDAP de Aktiva Adresaro _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 EN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 600 EN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan. 600 EN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 600 EN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 600 EN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 EN SRV 0 100 389 sauron.mordor.fan. ; ; KERBEROS modifita kaj privata de Aktiva Adresaro _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 EN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 600 EN SRV 0 100 88 sauron.mordor.fan.

Ni kontrolas la sintakson kaj ni povas ignori la eraron, kiun ĝi redonas, ĉar en la agordo de ĉi tiu Zono en la dosiero /etc/bind/named.conf.local ni inkluzivas la aserton ĉekonomoj ignoras;. La zono estos ĝuste ŝarĝita de la 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: malbona posedanto nomo (markonomoj) zono _msdcs.mordor.fan/IN: ŝarĝita serio 1 OK

root @ dnslinux: ~ # systemctl restart bind9.service 
root @ dnslinux: ~ # systemctl status bind9.service 
● bind9.service - BIND Domajna Servilo Ŝarĝita: ŝarĝita (/lib/systemd/system/bind9.service; ebligita) Eniro: /run/systemd/generator/bind9.service.d └─50-insserv.conf- $ named.conf Aktiva: aktiva (kuranta) ekde Suno 2017-02-12 08:48:38 EST; Antaŭ 2s Dokumentoj: man: named (8) Procezo: 859 ExecStop = / usr / sbin / rndc stop (kodo = eliris, stato = 0 / SUKCESO) Ĉefa PID: 864 (nomita) CGroup: /system.slice/bind9.service └─864 / usr / sbin / named -f -u bind Feb 12 08:48:38 dnslinux nomita [864]: zono 3.efip6.arpa/IN: ŝarĝita seria 1 Feb 12 08:48:38 dnslinux nomita [864 ]: zone befip6.arpa/IN: ŝarĝita seria 1 Feb 12 08:48:38 dnslinux nomita [864]: zono 0.efip6.arpa/IN: ŝarĝita seria 1 Feb 12 08:48:38 dnslinux nomita [864]: zono 7.efip6.arpa/IN: ŝarĝita seria 1 Feb 12 08:48:38 dnslinux nomita [864]: zono mordor.fan/IN: ŝarĝita seria 1 Feb 12 08:48:38 dnslinux nomita [864]: zona ekzemplo .org / IN: ŝarĝita serio 1 Feb 12 08:48:38 dnslinux nomata [864]: zone _msdcs.mordor.fan/IN: ŝarĝita seria 1 Feb 12 08:48:38 dnslinux nomita [864]: zono nevalida / IN : ŝarĝita seria 1 Feb 12 08:48:38 dnslinux nomita [864]: ĉiuj zonoj ŝarĝitaj
Feb 12 08:48:38 dnslinux nomata [864]: kurado

Ni konsultas la BIND

Antaŭe Post instalado de DHCP, ni devas plenumi serion de kontroloj, kiuj inkluzivas eĉ kunigi Windows 7-klienton al la regado mordor.fan reprezentita de la Aktiva Adresaro instalita en la komputilo sauron.mordor.fan.

La unua afero, kiun ni faru, estas haltigi la DNS-servon en la komputilo sauron.mordor.fan, kaj deklaru en via retinterfaco, ke de nun via DNS-servilo estos la 10.10.10.5 dnslinux.mordor.fan.

En konzolo de la servilo mem sauron.mordor.fan ni ekzekutas:

Vindozo [Versio 6.1.7600]
Kopirajto (c) 2009 Microsoft Corporation. Ĉiuj rajtoj rezervitaj.

C: \ Uzantoj \ Administranto> nslookup
Defaŭlta Servilo: dnslinux.mordor.fan Adreso: 10.10.10.5

> gc._msdcs
Servilo: dnslinux.mordor.fan Adreso: 10.10.10.5 Nomo: gc._msdcs.mordor.fan Adreso: 10.10.10.3

> mordor.fan
Servilo: dnslinux.mordor.fan Adreso: 10.10.10.5 Nomo: mordor.fan Adreso: 10.10.10.3

> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs
Servilo: dnslinux.mordor.fan Adreso: 10.10.10.5 Nomo: sauron.mordor.fan Adreso: 10.10.10.3 Kaŝnomoj: 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan

> aro tipo = SRV
> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
Servilo: dnslinux.mordor.fan Adreso: 10.10.10.5 _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan SRV-servloko: prioritato = 0 pezo = 100 haveno = 88 svr gastnomo = sauron.mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan interreta adreso = 10.10.10.3 dnslinux.mordor.fan interreta adreso = 10.10.10.5
> _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs
Servilo: dnslinux.mordor.fan Adreso: 10.10.10.5 _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan SRV-servoloko: prioritato = 0 pezo = 100 haveno = 389 svr gastnomo = sauron .mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan interreta adreso = 10.10.10.3 dnslinux.mordor.fan interreta adreso = 10.10.10.5
> eliri

C: \ Uzantoj \ Administranto>

DNS-demandoj faritaj de sauron.mordor.fan estas kontentigaj.

La sekva paŝo estos krei alian virtualan maŝinon kun instalita Vindozo 7. Ĉar ni ankoraŭ ne havas la DHCP-servon instalitan, ni donos al la komputilo kun la nomo «win7»La IP-adreso 10.10.10.251. Ni ankaŭ deklaras, ke via DNS-servilo estos la 10.10.10.5 dnslinux.mordor.fan, kaj ke la serĉregiono estos mordor.fan. Ni ne registros tiun komputilon en DNS ĉar ni ankaŭ uzos ĝin por testi la DHCP-servon post kiam ni instalos ĝin.

Poste ni malfermas konzolon CMD kaj en ĝi ni ekzekutas:

Vindozo [Versio 6.1.7601]
Kopirajto (c) 2009 Microsoft Corporation. Ĉiuj rajtoj rezervitaj.

C: \ Uzantoj \ buzz> nslookup
Defaŭlta Servilo: dnslinux.mordor.fan Adreso: 10.10.10.5

> mordor.fan
Servilo: dnslinux.mordor.fan Adreso: 10.10.10.5 Nomo: mordor.fan Adreso: 10.10.10.3

> aro tipo = SRV
> _ldap._tcp.DomainDnsZones
Servilo: dnslinux.mordor.fan Adreso: 10.10.10.5 _ldap._tcp.DomainDnsZones.mordor.fan SRV-servo loko: prioritato = 0 pezo = 0 haveno = 389 svr gastnomo = sauron.mordor.fan mordor.fan nameserver = dnslinux.mordor .fan sauron.mordor.fan interreta adreso = 10.10.10.3 dnslinux.mordor.fan interreta adreso = 10.10.10.5
> _kpasswd._udp
Servilo: dnslinux.mordor.fan Adreso: 10.10.10.5 _kpasswd._udp.mordor.fan SRV-servo loko: prioritato = 0 pezo = 0 haveno = 464 svr gastnomo = sauron.mordor.fan mordor.fan nameserver = dnslinux.mordor.fan retadreso sauron.mordor.fan = 10.10.10.3 dnslinux.mordor.fan retadreso = 10.10.10.5
> _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones
Servilo: dnslinux.mordor.fan Adreso: 10.10.10.5 _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan SRV-serva loko: prioritato = 0 pezo = 0 haveno = 389 svr gastnomo = sauron. mordor.fan mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan interreta adreso = 10.10.10.3 dnslinux.mordor.fan interreta adreso = 10.10.10.5
> eliro

C: \ Uzantoj \ buzz>

DNS-demandoj faritaj de la kliento «win7»Ankaŭ estis kontentigaj.

En Active Directory ni kreas la uzanton «saruman«, Kun la celo uzi ĝin kiam vi aliĝas al la kliento win7 al la domajno mordor.fan., uzante la metodon «Reta identigilo«, Uzante uzantnomojn saruman@mordor.fan y administranto@mordor.fan. La aliĝo sukcesis kaj estas pruvita per la sekva ekrankopio:

Pri Dinamikaj Ĝisdatigoj en Microsoft® DNS kaj BIND

Ĉar ni havas la DNS-servon haltigita en Active Directory®, ne eblis al la kliento «win7»Registri vian nomon kaj IP-adreson en tiu DNS. Multe malpli en dnslinux.mordor.fan ĉar ni faris neniun aserton permesi-ĝisdatigi por iuj ajn koncernataj areoj.

Kaj ĉi tie formiĝis la bona batalo kun mia amiko La Fuegian. En mia unua retpoŝto pri ĉi tiu aspekto mi komentis:

  • La artikoloj de Microsoft pri la uzo de BIND kaj Active Directory® rekomendas, ke, precipe la Rekta Zono, estu permesata ĝisdatigi -penetris- rekte de Vindozaj klientoj, kiuj jam aliĝis al la domajno Active Directory.
  • Tial defaŭlte en la DNS-zonoj de Aktiva Katalogo® Sekuraj Dinamikaj Ĝisdatigoj estas permesitaj. de Vindozaj klientoj jam aliĝis al la domajno Active Directory. Se ili ne unuiĝas, ili sin detenas de la konsekvencoj.
  • La DNS de Aktiva Adresaro subtenas dinamikajn ĝisdatigojn "Nur sekura", "Nesekura kaj sekura" aŭ "Neniu", kio estas la sama kiel diri NO Ĝisdatigoj aŭ Neniu.
  • Jes, vere La Mikrosofta Filozofio ne konsentas, ke ĝiaj klientoj NE ĝisdatigos siajn datumojn en siaj DNS-oj, ĝi ne lasus malfermita la eblon malŝalti dinamikajn ĝisdatigojn en iliaj DNS-oj, krom se tiu opcio restos por pli kaŝitaj celoj.
  • Microsoft ofertas "Sekurecon" kontraŭ Mallumo, kiel diris al mi kolego kaj amiko, kiu pasigis kursojn de Microsft®-Atestiloj. Vere. Krome, El Fueguino konfirmis ĝin al mi.
  • Kliento, kiu akiras IP-adreson per DHCP instalita sur UNIX® / Linukso-maŝino ekzemple, ne povos solvi la IP-adreson de sia propra nomo ĝis vi aliĝos al la domajno Active Directory, kondiĉe ke Microsoft® aŭ BIND estas uzataj kiel DNS sen dinamikaj ĝisdatigoj de DHCP.
  • Se mi instalas DHCP en la Active Directory® mem, tiam mi devas deklari, ke la Zonoj estas ĝisdatigitaj de Microsoft® DHCP.
  • Se ni uzos BIND kiel la DNS por la Vindoza reto, estas logike kaj rekomendinde instali la duopon BIND-DHCP, kun ĉi-lasta dinamike ĝisdatigante la BIND kaj la afero finita.
  • En la mondo de LAN-retoj ĉe UNIX® / Linukso, ĉar dinamikaj ĝisdatigoj estis inventitaj sur BIND, nur sinjoro DHCP rajtas «penetri»Al sinjorino BIND kun ŝiaj ĝisdatigoj. La malstreĉiĝo kun ordo, mi petas.
  • Kiam mi deklaras en la zono mordor.fan ekzemple: permesi-ĝisdatigi {10.10.10.0/24; };, BIND mem informas min komencante aŭ rekomencante ĝin, ke:
    • zono 'mordor.fan' permesas ĝisdatigojn per IP-adreso, kiu estas nesekura
  • En la sankta UNIX® / Linukso-mondo, tia sensencaĵo kun DNS estas simple neakceptebla.

Vi povas imagi la reston de la interŝanĝo kun mia amiko La Fuegian mediante retmesaĝoj, Telegram-Babilejo, telefonvokoj pagitaj de li (kompreneble homo, mi ne havas kilogramon por tio), kaj eĉ mesaĝojn per portkolomboj en la XNUMXa jarcento!

Li eĉ minacis ne sendi al mi filon de sia dorlotbesto, sian igvanon «Petra»Ke li promesis al mi kadre de la pago. Tie mi vere ektimis. Do mi rekomencis, sed de alia angulo.

  • La "preskaŭ" Aktiva Adresaro atingebla per Samba 4 solvas ĉi tiun aspekton majstre, ambaŭ kiam ni uzas ĝian Internan DNS aŭ la BIND kompilitan por subteni DLZ-zonojn - Dinamyc Ŝarĝitaj Zonoj, aŭ Dinamike Ŝarĝitaj Zonoj.
  • Ĝi daŭre suferas la samon: kiam kliento akiras IP-adreson per DHCP instalita en alia UNIX® / Linukso-maŝino, vi ne povos solvi la IP-adreson de via propra nomo ĝis ĝi kuniĝos al la regado de la Samba 4 AD-DC.
  • Integri la duopon BIND-DLZ kaj DHCP sur la sama maŝino kie la AD-DC Sambo 4 ĝi estas laboro por vera specialisto.

La Fuegian Li vokis min al ĉapitro kaj alkriis min: Ni NE parolas AD-DC Sambo 4, sed de Microsoft® Active Directory®!. Kaj mi humile respondis, ke mi ĝojas pri parto de la sekvaj artikoloj, kiujn mi verkos.

Tiam mi diris al li, ke la fina decido pri dinamikaj ĝisdatigoj de klientaj komputiloj en lia reto estis lasita al lia libera volo. Ke mi donus al li nur la pinto verkita antaŭ ĉirkaŭ permesi-ĝisdatigi {10.10.10.0/24; };, kaj pli nenio. Ke mi ne respondecis pri tio, kio rezultis de tiu malĉasteco, kiun ĉiu Windows-kliento -aŭ Linukso- en sia reto «penetros»Senpune al LIGANTO.

Se vi scius, mia amiko, Leganto, ke tio estas la fina punkto de la interbatiĝo, vi ne kredus ĝin. Mia amiko La Fuegian li akceptis la solvon - kaj li sendos al mi la igvanon «petrika«- ke nun mi dividas kun vi.

Ni instalas kaj agordas DHCP

Por pliaj detaloj legu DNS kaj DHCP en Debian 8 "Jessie".

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

root @ dnslinux: ~ # nano / etc / default / isc-dhcp-server .... # Sur kiuj interfacoj la DHCP-servilo (dhcpd) devas servi DHCP-petojn? # Apartigu plurajn interfacojn kun spacoj, ekz. "Eth0 eth1". INTERFACES = "eth0" root @ dnslinux: ~ # dnssec-keygen -a HMAC-MD5 -b 128 -r / dev / urandom -n USER dhcp-key
Kdhcp-ŝlosilo. + 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
ŝlosilo dhcp-ŝlosilo {algoritmo hmac-md5; sekreta "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
// // Faru iun ajn lokan agordon ĉi tie // // Konsideru aldoni la 1918-zonojn ĉi tie, se ili ne estas uzataj en via // organizo inkluzivas "/etc/bind/zones.rfc1918"; inkluzivi "/etc/bind/zones.rfcFreeBSD";
// Ne forgesu ... Mi forgesis kaj pagis per eraroj. ;-)
inkluzivi "/etc/bind/dhcp.key";


zono "mordor.fan" {tipo majstro;
        permesi-ĝisdatigi {10.10.10.3; ŝlosilo dhcp-ŝlosilo; };
        dosiero "/var/lib/bind/db.mordor.fan"; }; zono "10.10.10.in-addr.arpa" {tipo majstro;
        permesi-ĝisdatigi {10.10.10.3; ŝlosilo dhcp-ŝlosilo; };
        dosiero "/var/lib/bind/db.10.10.10.in-addr.arpa"; }; zono "_msdcs.mordor.fan" {tipo majstro; ĉekonomoj ignoras; dosiero "/etc/bind/db._msdcs.mordor.fan"; };

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

root @ dnslinux: ~ # nano /etc/dhcp/dhcpd.conf
ddns-ĝisdatigi-stilan provizoran; ddns-ĝisdatigoj pri; ddns-domajna nomo "mordor.fan."; ddns-rev-domajna nomo "in-addr.arpa."; ignori klientajn ĝisdatigojn; aŭtoritata; opcio ip-plusendado; opcio domajna nomo "mordor.fan"; inkluzivi "/etc/dhcp/dhcp.key"; zone mordor.fan. {ĉefa 127.0.0.1; ŝlosilo dhcp-ŝlosilo; } zono 10.10.10.in-addr.arpa. {ĉefa 127.0.0.1; ŝlosilo dhcp-ŝlosilo; } dividita-retloka {subreto 10.10.10.0 retmasko 255.255.255.0 {opcio-enkursigiloj 10.10.10.1; opcio subreto-masko 255.255.255.0; opcio elsendadreso 10.10.10.255; opcio domajna-serviloj 10.10.10.5; opcio netbios-name-servers 10.10.10.5; gamo 10.10.10.30 10.10.10.250; }} # END dhcpd.conf

root @ dnslinux: ~ # dhcpd -t
Interreta Sistemo-Konsorcio DHCP-Servilo 4.3.1 Kopirajto 2004-2014 Interreta Sistemo-Konsorcio. Ĉiuj rajtoj rezervitaj. Por informoj, bonvolu viziti https://www.isc.org/software/dhcp/ Agordan dosieron: /etc/dhcp/dhcpd.conf Datumbaza dosiero: /var/lib/dhcp/dhcpd.leases PID-dosiero: / 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

Al kio rilatas Kontroloj kun klientojkaj la Mana modifo de Zonaj dosieroj, ni lasas ĝin al vi, leganto-amiko, legi ĝin rekte de DNS kaj DHCP en Debian 8 "Jessie", kaj apliku ĝin al viaj realaj kondiĉoj. Ni ja faris ĉiujn necesajn kontrolojn kaj akiris kontentigajn rezultojn. Kompreneble ni sendas kopion de ĉiuj al La Fuegian. Ne plu ekzistos!

Konsiletoj

Ĝenerala

  • Akiru multan paciencon antaŭ ol komenci.
  • Unue instalu kaj agordu la BIND. Kontrolu ĉion kaj vidu ĉiujn registrojn, kiujn vi deklaris en ĉiu dosiero de la tri -aŭ pli- zonoj, kaj de la Aktiva Adresaro kaj de la DNS-servilo mem en Linukso. Se eble, de Linuksa maŝino ne ligita al la domajno, faru la necesajn DNS-demandojn al BIND.
  • Aliĝu al Vindozo-kliento kun fiksa IP-adreso al la ekzistanta domajno, kaj rekontrolu ĉiujn BIND-agordojn de la Vindoza kliento.
  • Post kiam vi sendube certas, ke la agordo de via tute nova BIND estas tute ĝusta, kuraĝu instali, agordi kaj komenci la DHCP-servon.
  • En kazo de eraroj, ripetu la tutan procedon de nulo 0.
  • Atentu pri la kopio kaj algluado! kaj la ceteraj spacoj en ĉiu linio de la named.conf.xxxx-dosieroj
  • Poste li ne plendis - des malpli al mia amiko la Fuegian - ke li ne estis konvene konsilita.

Aliaj konsiletoj

  • Dividu kaj venku.
  • En SME-Reto estas pli sekure kaj pli utile instali Aŭtoritatan BIND por la Interna LAN-Zonoj, kiu ne ripetiĝas al iu radika servilo: rekursio ne;.
  • En SME-Reto situanta sub Interreta Alira Provizanto - ISP, eble la servoj prokurilo y SMTP ili bezonas solvi domajnajn nomojn en la interreto. Li Ĉemizo vi havas la eblon deklari vian DNS eksteran aŭ ne, dum en poŝta servilo bazita sur Postfikso o MDaemon® Ni ankaŭ povas deklari la DNS-servilojn, kiujn ni uzos en tiu servo. En tiaj kazoj, tio estas kazoj, kiuj ne provizas servojn al la interreto kaj estas sub a Provizanto de Interreta Servo, vi povas instali BIND kun Transludantoj montrante al la DNS de la ISP, kaj deklaras ĝin kiel duaranga DNS en la serviloj, kiuj bezonas solvi eksterajn demandojn al la LAN, alie eblas deklari ilin per siaj propraj agordaj dosieroj.
  • Se vi havas Delegitan Zonon sub via tuta respondecoTiam alia koko krias:
    • Instalu DNS-servilon bazitan sur NSD, kiu estas Aŭtoritata DNS-servilo laŭdifine, kiu respondas al demandoj de komputiloj en la interreto. Por iuj informoj taŭga spektaklo nsd. 😉 Bonvolu protekti ĝin tre bone kun tiom da fajraj muroj kiom necesas. Kaj aparataro kaj programaro. Ĝi estos DNS por la interreto, kaj tio «ulon»Ni ne devas doni ĝin per malalta pantalono. 😉
    • Kiel mi neniam vidis min en tia kazo, do tute respondeca pri Delegita Zono, mi devus tre bone pensi, kion rekomendi por la rezolucio de domajnaj nomoj ekster nia LAN por la servoj, kiuj bezonas ĝin. Klientoj pri retaj klientoj ne vere bezonas ĝin. Konsultu fakan literaturon aŭ specialiston pri ĉi tiuj temoj, ĉar mi estas malproksima de esti unu el ili. Serioze.
    • Rekursio ne ekzistas sur Aŭtoritataj serviloj. Bone ?. Se iu pensas fari ĝin per BIND.
  • Kvankam ni eksplicite specifas en la dosiero /etc/dhcp/dhcpd.conf la deklaro ignori klientajn ĝisdatigojn;, se ni funkcias per komputila konzolo dnslinux.mordor.fan la ordono journalctl -f, ni vidos tion komencante la klienton win7.mordor.fan ni ricevas jenajn erarmesaĝojn:
    • Feb 12 16:55:41 dnslinux nomata [900]: kliento 10.10.10.30 # 58762: ĝisdatigo 'mordor.fan/IN' rifuzita
      Feb 12 16:55:42 dnslinux nomata [900]: kliento 10.10.10.30 # 49763: ĝisdatigo 'mordor.fan/IN' rifuzita
      Feb 12 16:56:23 dnslinux nomata [900]: kliento 10.10.10.30 # 63161: ĝisdatigo 'mordor.fan/IN' rifuzita
      
    • Por forigi ĉi tiujn mesaĝojn, ni devas iri al la altnivelaj elektoj de la agordo de retkarto kaj malmarku la opcion «Registri la adresojn de ĉi tiu konekto en DNS«. Tio malhelpos la klienton provi memregistriĝi en la Linuksa DNS por ĉiam kaj la fino de la problemo. Pardonu, sed mi ne havas kopion de Windows 7 en la hispana. 😉
  • Por ekscii pri ĉiuj seriozaj - kaj frenezaj - demandoj, kiujn kliento de Windows 7 faras, rigardu la log demandoj.log ke por io ni deklaras ĝin en la agordo BIND. La ordo estus:
    • root @ dnslinux: ~ # tail -f /var/log/named/queries.log
  • Se vi ne permesas al viaj klientaj komputiloj ligi rekte al la interreto, kial vi bezonas la Radikajn DNS-Servilojn? Ĉi tio signife malpliigos la eliron de la komando journalctl -f kaj de la antaŭa, se via Aŭtoritata DNS-servilo por la Internaj Zonoj ne konektas rekte al la Interreto, kio estas tre rekomendinda laŭ sekureca vidpunkto.
    root @ dnslinux: ~ # cp /etc/bind/db.root /etc/bind/db.root.original
    root @ dnslinux: ~ # cp / dev / null /etc/bind/db.root
  • Se vi ne bezonas la deklaron de la radikaj serviloj, tiam kial vi bezonas Rekursion - rikuro?
    root @ dnslinux: ~ # nano /etc/bind/named.conf.options
    opcioj {
     ....
     rekursio ne;
     ....
    };

Specifaj konsiloj, pri kiuj mi ankoraŭ ne estas tre klaraj

El viro dhcpd.conf diras al ni la jenon inter multaj-multaj- aliaj aferoj:

        La deklaro pri ĝisdatigo-optimumigo

            flago de ĝisdatigo-optimumigo;

            Se la ĝisdatiga-optimumiga parametro estas falsa por donita kliento, la servilo provos DNS-ĝisdatigon por tiu kliento ĉiufoje kiam la kliento renovigos sian lizkontrakton, anstataŭ nur provi ĝisdatigon kiam ĝi ŝajnas esti necesa. Ĉi tio permesos al la DNS resaniĝi el datumbazaj nekonsekvencoj pli facile, sed la kosto estas, ke la DHCP-servilo devas fari multajn pliajn DNS-ĝisdatigojn. Ni rekomendas legi ĉi tiun opcion ebligita, kiu estas la apriora. Ĉi tiu opcio nur influas la konduton de la provizora DNS-ĝisdatiga skemo, kaj ne efikas sur la ad-hoc DNS-ĝisdatiga skemo. Se ĉi tiu parametro ne estas specifita, aŭ estas vera, la DHCP-servilo nur ĝisdatiĝos kiam la klientaj informoj ŝanĝiĝos, la kliento ricevos malsaman lizkontrakton aŭ la lizkontrakto de la kliento eksvalidiĝos.

La pli-malpli ĝusta traduko aŭ interpreto restas al vi, kara leganto.

Persone okazis al mi - kaj okazis dum la kreo de ĉi tiu artikolo - ke kiam mi ligas BIND al Active Directory®, ĝi estas de Microsft® aŭ Samba 4, se mi ŝanĝas la nomon de klienta komputilo registrita en la Active Directory®-domajno. aŭ de AD-DC de Samba 4, ĝi konservas sian malnovan nomon kaj IP-adreson en la Rekta Zono, kaj ne male, kiu estas ĝuste ĝisdatigita kun la nova nomo. Alivorte, la malnova kaj nova nomoj estas mapitaj al la sama IP-adreso en la Rekta Zono, dum inverse nur la nova nomo aperas. Por bone kompreni min, vi devas provi ĝin mem.

Mi pensas, ke ĝi estas ia venĝo al La Fuegian -ne al mi, mi petas- ĉar mi provis migri viajn servojn al Linukso.

Kompreneble la malnova nomo malaperos kiam ĝia TTL 3600, aŭ la tempon, kiun ni deklaris en la DHCP-agordo. Sed ni volas, ke ĝi malaperu tuj, kiel ĝi okazas en BIND + DHCP sen Active Directory tra.

La solvon al tiu situacio mi trovis ĝin enmetante la deklaron ĝisdatigo-optimumigo falsa; ĉe la fino de la supro de la dosiero /etc/dhcp/dhcpd.conf:

ddns-ĝisdatigi-stilan provizoran; ddns-ĝisdatigoj pri; ddns-domajna nomo "mordor.fan."; ddns-rev-domajna nomo "in-addr.arpa."; ignori klientajn ĝisdatigojn;
ĝisdatigo-optimumigo falsa;

Se iu Leganto scias pli pri ĝi, bonvolu klerigi min. Mi multe dankos ĝin.

Resumo

Ni multe amuziĝis kun la temo, ĉu ne? Neniu sufero ĉar ni havas BIND funkcianta kiel DNS-servilo en reto Microsoft®, ofertante ĉiujn SRV-registrojn kaj respondante taŭge al la DNS-demandoj faritaj al ili. Aliflanke ni havas DHCP-servilon donantan IP-adresojn kaj dinamike ĝisdatigante la BIND-Zonojn ĝuste.

Sed ni ne povas demandi ... por la momento.

Mi esperas, ke mia amiko La Fuegian estu feliĉa kaj kontenta pri la unua paŝo en via migrado al Linukso por fari la neelteneblajn kostojn de Microsft® Technical Support elteneblaj.

Grava noto

Karaktero "La Fuegian»Estas tute fikcia kaj produkto de mia imago. Ĉiu simileco aŭ koincido kun realaj homoj estas la sama: Pura Senintenca Koincido miaflanke. Mi kreis ĝin nur por iomete ĝui la verkadon kaj legadon de ĉi tiu artikolo. Nun se vi povas diri al mi, ke la DNS-problemo estas malluma. 😉


La enhavo de la artikolo aliĝas al niaj principoj de redakcia etiko. Por raporti eraron alklaku Ĉi tie.

13 komentoj, lasu la viajn

Lasu vian komenton

Via retpoŝta adreso ne estos eldonita. Postulita kampojn estas markita per *

*

*

  1. Respondeculo pri la datumoj: Miguel Ángel Gatón
  2. Celo de la datumoj: Kontrola SPAM, administrado de komentoj.
  3. Legitimado: Via konsento
  4. Komunikado de la datumoj: La datumoj ne estos komunikitaj al triaj krom per laŭleĝa devo.
  5. Stokado de datumoj: Datumbazo gastigita de Occentus Networks (EU)
  6. Rajtoj: Iam ajn vi povas limigi, retrovi kaj forigi viajn informojn.

  1.   krespo88 diris

    Tre forta, neniu komento. Ĉar la DNS de Mikrosofto ne necesas. Atentu, ke oni ne procesu vin, hahahaha. Dankon pro la livero Fico.

  2.   federika diris

    Ĉu demandi min? Ke ili vidas ilin kun EL Fueguino. 😉
    Dankon, amiko!!!

  3.   Hanibala Fabo diris

    Ĉu ne estis pli facile instali zentyal, por ĉi tiu tuta parto de la aktiva dosierujo?

  4.   ĉasisto diris

    Haha, bonega artiko por munti la potencan ligilon kaj mi vidas, ke Zentyal estis rekomendita al vi en la supra komento, mi foriras antaŭ ol ekpafos.

    PS: La domajno bazita sur Vindozo estas Mordor sed se ni muntus puran Sambon, ĝi estus Gondor aŭ Rohan ĉu ne? 😉

  5.   federika diris

    Mi rekomendas la uzon de Zentyal al neniu. Uzu Vindozon ĉar ĝia uzo estas realaĵo en multaj PYME. Pri la stabileco de la Zentyal, demandu mian amikon kaj kolegon Dhunter. 😉

  6.   federika diris

    Certe, dhunter amiko. Kun Samba 4 ĝi nomiĝos tierramedia.fan. 😉

  7.   federika diris

    Por tiuj, kiuj jam elŝutis la artikolon, tre zorgu pri la jenaj:
    Kie diras
    ; ESTU TRE ATENTA KUN LA SEGANTAJ REKORDOJ
    @ IN NS dnslinux.mordor.fan.
    @ EN A 10.10.10.3

    Devas diri ĝuste

    ; ESTU TRE ATENTA KUN LA SEGANTAJ REKORDOJ
    @ IN NS dnslinux.mordor.fan.
    @ EN A 10.10.10.5

    La kolego Eduardo Noel estis tiu, kiu rimarkis mian nevolan eraron.

  8.   federika diris

    Por tiuj, kiuj jam elŝutis la artikolon, tre zorgu pri la jenaj:
    Kie diras
    ; ESTU TRE ATENTA KUN LA SEGANTAJ REKORDOJ
    @ IN NS dnslinux.mordor.fan.
    @ EN A 10.10.10.3

    Devas diri ĝuste

    ; ESTU TRE ATENTA KUN LA SEGANTAJ REKORDOJ
    @ IN NS dnslinux.mordor.fan.
    @ EN A 10.10.10.5

    La kolego Eduardo Noel estis tiu, kiu rimarkis mian nevolan eraron.

  9.   ĉasisto diris

    Por tiuj, kiuj planas uzi Zentyal por io serioza, mi avertas vin esti tre singarda, mi uzas du Zentyal 4.2-ŝoforojn (je 14.04), ĝisdatigis ĉion kaj zorgu ĝis maksimumo, tre maloftaj cimoj (kaj pli maloftaj estas la respondoj en la projekto bugzilla, vi Ili sentigas vin stulta pro uzado de io, kion vi tiel malmulte dankas), ili estis sen terura reago dum kelka tempo, ke mi pensis, ke ili malaperis kaj subite ili liberigas 5.0 sen ebla migrado de 4.2 ... belega ....

    Raporti cimojn al la komunuma versio ne havas sencon krom se vi kuras kune kun la programistoj ĉiam uzante la plej novan, kontrolu ĉi tion: https://tracker.zentyal.org/issues/5080#comment:14

    Finfine oni devas morti kun relative stabila versio kaj bati ĝin ĝis ĝi daŭras, rigardu la aferojn, kiujn mia zentyal havas en la cron:

    0 7 * * 1-6 /sbin/shutdown -r now

    Kiel mi diris ... aminda!

    PS: Supozeble mi elspezas ĉi tiun tutan laboron por uzi la senpagan version, supozeble la pagita versio estas serioza, sed mi pensas, ke ĝi ne estas la plej bona strategio por gajni uzantojn, alia produkto kun simila komerca modelo estas Proxmox kaj mi komparis ĝian pagitan version por tia por doni monon al la projekto kaj ne ĉar la senpaga versio mankas, Proxmox estas juvelo.

  10.   Ismael Alvarez Wong diris

    Saluton Federico:
    Kun ĉiu nova artikolo vi haltigas, iru kvazaŭ ĝi ne sufiĉus kun ĉio pritraktita en la 3 antaŭaj afiŝoj pri la duopo BIND + DHCP, nun vi publikigas ĉi tiun "kofron" (pardonu min la eksplodaĵo) de artikolo pri kiel migri la DNS de Microsoft al la BIND, kiel ĝisdatigi ĝin de DHCP en Linukso kaj supre ĉio supre kunekzistas kun Microsoft Active Directory.
    . Bonege ĉio rilate al la SRV-registroj de la DNS de Aktiva Adresaro, ĝia rekta zono "_msdcs.dominio", kiel kapti el Linukso la registrojn de la zonoj -aŭ pli- de la DNS de la Microsoft AD por krei la Datumbazojn de diris Zonoj en LIGADO.
    . Estas tre utile ebligi la Registrojn de la demandoj en la agordo BIND.
    . TRE VALORA la konsilo, ke: Kliento, kiu akiras IP-adreson per DHCP instalita en Linukso, ne povos solvi la IP-adreson de sia propra nomo, ĝis li aliĝos al la aktiva dosierujo. En la ekzemplo de la Laboratorio de la artikolo, unue al la komputilo "win7" estas asignita la IP-adreso 10.10.10.251 por fari DNS-kontrolojn de la domajno "mordor.fan", tiam ĝi kuniĝas de tiu fiksa IP al la Microsoft AD tiel ke fine kiam Se DHCP estas instalita en Linukso, ĉi tiu estas tiu, kiu atribuas sian IP kaj samtempe ĝisdatigas "penetras" la BIND por skribi la ekipaĵan registron en la Antaŭaj kaj Inversaj Zonoj. IRO PLI DETALA, VI NE TROVOS!
    . Tre bone ĉiuj konsideroj pri la Dinamikaj Ĝisdatigoj en la Microsoft® DNS kaj en la BIND; same kiel ĉiuj konsiloj klarigitaj en la fina sekcio kaj specife la tuta evoluo kaj la proponita solvo al la "Specifa Konsilio, pri kiu mi ankoraŭ ne estas tre klara."
    ! 5 STELOJ POR LA A ATORO! kaj mi sekvas la Serion PYMES kun kreskanta intereso!

  11.   federika diris

    Dhunter: Verkis la Voĉon de Sperto. "Praktiko estas la plej bona kriterio de vero."

    Wong: Mi jam maltrafis vian komenton - artikolan komplementon. Mi esperas, ke unu pri dnsmasq aperos baldaŭ.

    Dankon al vi ambaŭ pro viaj komentoj.

  12.   krespo88 diris

    Vi ne parolis + pri la partnero nomata «El Fueguino», nek pri lia decido komenci la migradon de liaj serviloj. Vi ŝtelis alian de Microsoft, hahaha !!!! ????

  13.   federika diris

    hahahaha amiko crespo88. Mi vidas, ke vi ŝatis la ondon de la fikcia rolulo. Se aliaj havas pli da opinioj kiel vi, ĝi povus pli amuzigi artikolojn pri densaj temoj. Ni atendu aliajn komentojn pri ĝi.