BIND és Active Directory® - kkv-hálózatok

A sorozat általános mutatója: Számítógépes hálózatok kkv-k számára: Bevezetés

Hello barátok!. A cikk fő célja annak bemutatása, hogy miként integrálhatjuk a BIND9-en alapuló DNS-szolgáltatást egy Microsoft hálózatba, amely sok kkv-ban nagyon elterjedt.

Egy La Tierra del Fuegóban élő barát hivatalos kérelméből adódik -A Fuegian- szakosodott a Microsoft® Networks -hez - Tanúsítványok tartoznak -, hogy eligazítsák Önt a szerverek Linuxra történő áttérésének ezen részében. A költségek támogatás A Microsoft®-nak fizetõ technikusok már Kibírhatatlan a Társaság számára, amelyben dolgozik, és amelynek fő részvényese.

A barátom A Fuegian remek humorérzéke van, és mivel három film sorozatát látta «A Gyűrűk Ura»Sötét szereplőinek sok neve magával ragadta. Szóval, Olvasó barátom, ne lepődj meg a domained és a szervereid nevén.

A téma újoncai számára és az olvasás folytatása előtt javasoljuk, hogy olvassa el és tanulmányozza a kkv-hálózatokról szóló három korábbi cikket:

• DNS és DHCP az openSUSE 13.2 "Harlequin" programban
• DNS és DHCP a CentOS 7-en
• DNS és DHCP a Debian 8 "Jessie" -ben

Olyan, mintha megnézném a négy részből három «Alvilág»A mai napig jelent meg, és hogy ez a negyedik.

Általános paraméterek

Többszöri csere után E-mail, végre tisztában voltam a jelenlegi hálózatának fő paramétereivel, amelyek a következők:

Domain név mordor.fan LAN hálózat 10.10.10.0/24 ======================================= ============================================ Szerverek IP-címe (operációs rendszerrel rendelkező kiszolgálók) Windows) ================================================== =============================== sauron.mordor.fan. 10.10.10.3 Active Directory® 2008 SR2 mamba.mordor.fan. 10.10.10.4 Windows fájlkiszolgáló darklord.mordor.fan. 10.10.10.6 Proxy, átjáró és tűzfal a Kerios troll.mordor.fan oldalon. 10.10.10.7 A ... alapú blog nem emlékszem a shadowftp.mordor.fan fájlra. 10.10.10.8 FTP-kiszolgáló blackelf.mordor.fan. 10.10.10.9 Teljes e-mail szolgáltatás blackspider.mordor.fan. 10.10.10.10 WWW szolgáltatás palantir.mordor.fan. 10.10.10.11 Chat on Openfire for Windows

Engedélyt kértem A Fuegian annyi álnevet állítson be, amennyi szükséges az elmém tisztításához, és megadta az engedélyét:

Valódi CNAME ============================== sauron ad-dc mamba fájlszerver darklord proxyweb troll blog shadowftp ftpserver blackelf mail blackspider www palantir openfire

Az Active Directory Windows 2008 telepítésekor deklaráltam az összes fontos DNS-rekordot, amelyet kénytelen voltam végrehajtani, hogy útmutatást nyújtsak ennek a bejegyzésnek a készítésében.

Az Active Directory DNS-jének SRV-rekordjairól

A regiszterek SRV o A Microsoft Active Directoryban széles körben használt szolgáltatás-lokátorokat a Megjegyzések kérése RFC 2782. DNS-lekérdezéssel engedélyezik a szolgáltatás helyét a TCP / IP protokoll alapján. Például egy Microsoft-hálózaton lévő ügyfél megtalálja a tartományvezérlők helyét - Tartományvezérlők amelyek egyetlen DNS-lekérdezéssel nyújtják az LDAP szolgáltatást a 389-es port TCP protokollján keresztül.

Normális, hogy az erdőkben - Az erdők, és a fák - Fák egy nagy Microsoft hálózatból számos tartományvezérlő létezik. Az SRV rekordok használatával a hálózat tartománynévterületét alkotó különböző zónákban fenntarthatunk egy listát olyan szerverekről, amelyek hasonló, jól ismert szolgáltatásokat nyújtanak, preferencia szerint megrendelve az egyes közlekedési protokollok és portok szerint. az egyik szerver.

Az Megjegyzések kérése RFC 1700 Univerzális szimbolikus nevek meghatározása a jól ismert szolgáltatások számára - Jól ismert szolgáltatás, és olyan nevek, mint «_telnet""_SMTP»Szolgáltatásokra telnet y SMTP. Ha egy jól ismert szolgáltatáshoz nincs meghatározva egy szimbolikus név, akkor a felhasználó preferenciáinak megfelelően helyi vagy más név is használható.

Az egyes mezők célja «speciális»Az SRV erőforrásrekord deklarációjában a következőket használják:

• Domén: "Pdc._msdcs.mordor.fan.«. A szolgáltatás DNS-neve, amelyre az SRV rekord vonatkozik. A DNS-név a példában többet vagy kevesebbet jelent Elsődleges tartományvezérlő a terület _msdcs.mordor.fan.
• szolgáltatás: "_Ldap". A nyújtott szolgáltatás szimbolikus neve, a Megjegyzések kérése RFC 1700.
• Protokoll: "_Tcp". A szállítási protokoll típusát jelzi. Általában az értékeket veheti fel _tcp o _udp, bár - és valójában - bármilyen típusú szállítási protokoll, amelyet a Megjegyzések kérése RFC 1700. Például egy szolgáltatáshoz csevegés protokoll alapú XMPP, ennek a mezőnek értéke lenne _xmpp.
• Prioritás"0«. Nyilvánítsa az elsőbbséget vagy preferenciát Ezt a szolgáltatást kínáló host hogy később meglátjuk. Az SRV rekord által meghatározott szolgáltatással kapcsolatos ügyfelek DNS-lekérdezései a megfelelő válasz kézhezvételekor megpróbálják felvenni a kapcsolatot az első elérhető mezővel, amelynek a mezőben a legalacsonyabb a száma. Prioritás. Az értéktartomány, amelyet ez a mező vehet igénybe, az 0 a 65535.
• Súly"100«. Használható együtt Prioritás terheléselosztó mechanizmus biztosítására, ha több kiszolgáló nyújtja ugyanazt a szolgáltatást. A Zone fájl minden kiszolgálójához hasonló SRV rekordnak kell lennie, a nevét a mezőben deklarálva Ezt a szolgáltatást kínáló host. A mezőben azonos értékű kiszolgálók előtt Prioritás, a mező értéke Súly további preferenciaszintként használható a szerver pontos kiválasztásához a terheléselosztáshoz. Az értéktartomány, amelyet ez a mező vehet igénybe, az 0 a 65535. Ha nincs szükség terheléselosztásra, például egyetlen kiszolgáló esetén, akkor ajánlott az érték hozzárendelése 0 hogy az SRV rekord könnyebben olvasható legyen.
• Port szám - Port"389«. Port száma itt Ezt a szolgáltatást kínáló host amely a mezőben feltüntetett szolgáltatást nyújtja szolgáltatás. A jól ismert szolgáltatás minden típusához ajánlott portszámot a Megjegyzések kérése RFC 1700, bár érték lehet közöttük 0 és 65535.
• Ezt a szolgáltatást kínáló host - Target"sauron.mordor.ventilátor.«. Megadja a FQDN hogy egyértelműen azonosítja a vendéglátó amely az SRV rekord által jelzett szolgáltatást nyújtja. Rekordtípus «A»A domain névtérben mindegyikhez FQDN a szerverről vagy vendéglátó amely a szolgáltatást nyújtja. Egyszerűbb, egy típusú rekord A a közvetlen zónában (zónákban).
  • Megjegyzés:
    Annak hiteles jelzésére, hogy az SRV rekord által meghatározott szolgáltatást nem ezen a gazdagépen nyújtják, egyetlen (.) pont.

Csak azt szeretnénk megismételni, hogy egy hálózat vagy egy Active Directory® helyes működése nagymértékben támaszkodik a Domain Name Service helyes működésére.

Az Active Directory DNS-rekordjai

Ahhoz, hogy az új DNS-kiszolgáló zónái a BIND alapján készüljenek, meg kell szereznünk az összes DNS-rekordot az Active Directory®-tól. Az élet megkönnyítése érdekében a csapatba megyünk sauron.mordor.ventilátor -Active Directory® 2008 SR2- és a DNS-adminisztrációs konzolban aktiváljuk a Zone Transfer -direct és reverse-t az ilyen típusú szolgáltatásban deklarált fő zónákhoz, amelyek:

• _msdcs.mordor.fan
• mordor.ventilátor
• 10.10.10.in-addr.harp

Miután az előző lépést végrehajtottuk, lehetőleg olyan Linux számítógépről, amelynek IP címe a Windows hálózat által használt alhálózat tartományán belül van, végrehajtjuk:

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

• Felidézzük a korábbi cikkekből, hogy az eszköz IP-címe sysadmin.desdelinux.ventilátor es 10.10.10.1 vagy 192.168.10.1.

A három korábbi parancsban kiküszöbölhetjük az opciót 10.10.10.3 -kérdezze meg az ezzel a címmel rendelkező DNS-szervert- ha az aktában kijelentjük / Etc / resolv.conf a szerver IP-jére sauron.mordor.ventilátor:

buzz@sysadmin:~$ cat /etc/resolv.conf # A NetworkManager keresés által generált desdelinux.fan nameserver 192.168.10.5 nameserver 10.10.10.3

Rendkívül körültekintően, a BIND zónafájljainak megfelelő szerkesztés után a következő adatokat kapjuk meg:

Az RRs rekordok az eredeti _msdcs.mordor.fan zónából

buzz @ sysadmin: ~ $ cat temp / rrs._msdcs.mordor.fan 
; A SOA és az NS _msdcs.mordor.fan fájlokkal kapcsolatban. 3600 SOA-ban sauron.mordor.fan. hostmaster.mordor.fan. 12 900 600 86400 3600 _msdcs.mordor.fan. 3600 IN NS sauron.mordor.fan. ; ; GLOBÁLIS KATALÓGUS gc._msdcs.mordor.fan. 600 IN A 10.10.10.3; ; Álnevek - az Active Directory módosított és privát LDAP-adatbázisában - a SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan fájlban. 600 CNAME-ben sauron.mordor.fan. ; ; Az Active Directory módosított és privát LDAP-ja: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. ; ; KERBEROS módosítva és privátként az Active Directory _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan fájlból. 600 IN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan.

RRs rekordok az eredeti zónából mordor.fan

buzz @ sysadmin: ~ $ macska temp / rrs.mordor.fan 
; A SOA, NS, MX és az általa feltérképezett A rekordok vonatkozásában; a domain név a SAURON IP-jéhez; Dolgok az Active Directory mordor.fan oldaláról. 3600 SOA-ban sauron.mordor.fan. hostmaster.mordor.fan. 48 900 600 86400 3600 mordor.fan. 600 IN A 10.10.10.3 mordor.fan. 3600 IN NS sauron.mordor.fan. mordor.ventilátor. 3600 IN MX 10 blackelf.mordor.fan. _msdcs.mordor.fan. 3600 IN NS sauron.mordor.fan. ; ; Szintén fontos A rögzíti a DomainDnsZones.mordor.fan fájlt. 600 IN A 10.10.10.3 ForestDnsZones.mordor.fan. 600 IN A 10.10.10.3; ; GLOBÁLIS KATALÓGUS _gc._tcp.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _gc._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. ; ; Az Active Directory _ldap._tcp.mordor.fan módosított és privát LDAP-ja. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. ; ; Az Active Directory módosított és privát KERBEROS-ja _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 600 IN SRV 0 100 464 sauron.mordor.fan. _kerberos._udp.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 600 IN SRV 0 100 464 sauron.mordor.fan. ; ; A rögzített IP-kkel rendelkező rekordok -> Blackelf.mordor.fan szerverek. 3600 IN A 10.10.10.9 blackspider.mordor.fan. 3600 IN A 10.10.10.10 darklord.mordor.fan. 3600 IN A 10.10.10.6 mamba.mordor.fan. 3600 IN A 10.10.10.4 palantir.mordor.fan. 3600 IN A 10.10.10.11 sauron.mordor.fan. 3600 IN A 10.10.10.3 shadowftp.mordor.fan. 3600 IN A 10.10.10.8 troll.mordor.fan. 3600 IN A 10.10.10.7; ; A CNAME rögzíti az ad-dc.mordor.fan fájlt. 3600 CNAME-ben sauron.mordor.fan. blog.mordor.fan. 3600 CNAME-ben troll.mordor.fan. fájlkiszolgáló.mordor.fan. 3600 CNAME-ben mamba.mordor.fan. ftpserver.mordor.fan. 3600 CNAME-ben shadowftp.mordor.fan. mail.mordor.fan. 3600 CNAME-ben balckelf.mordor.fan. openfire.mordor.fan. 3600 CNAME-ben palantir.mordor.fan. proxy.mordor.fan. 3600 CNAME-ben darklord.mordor.fan. www.mordor.fan. 3600 CNAME-ben blackspider.mordor.fan.

RRs rekordok az eredeti zónából 10.10.10.in-addr.arpa

buzz @ sysadmin: ~ $ cat temp / rrs.10.10.10.in-addr.arpa 
; A SOA-hoz és az NS-hez kapcsolódó 10.10.10.in-addr.arpa. 3600 SOA-ban sauron.mordor.fan. hostmaster.mordor.fan. 21 900 600 86400 3600 10.10.10.in-addr.arpa. 3600 IN NS sauron.mordor.fan. ; ; PTR rekordok 10.10.10.10.in-addr.arpa. 3600 IN PTR blackspider.mordor.fan. 11.10.10.10.in-addr.arpa. 3600 IN PTR palantir.mordor.fan. 3.10.10.10.in-addr.arpa. 3600 IN PTR sauron.mordor.fan. 4.10.10.10.in-addr.arpa. 3600 IN PTR mamba.mordor.fan. 5.10.10.10.in-addr.arpa. 3600 IN PTR dnslinux.mordor.fan. 6.10.10.10.in-addr.arpa. 3600 IN PTR darklord.mordor.fan. 7.10.10.10.in-addr.arpa. 3600 IN PTR troll.mordor.fan. 8.10.10.10.in-addr.arpa. 3600 IN PTR shadowftp.mordor.fan. 9.10.10.10.in-addr.arpa. 3600 IN PTR blackelf.mordor.fan.

Eddig a pontig azt gondolhatjuk, hogy rendelkezünk a szükséges adatokkal a kalandunk folytatásához, anélkül, hogy először megfigyelnénk a TTL-ek és egyéb adatok, amelyek nagyon tömör módon a Microsft® Active Directory® 2008 SR2 64 bitek kimenetét és közvetlen megfigyelését nyújtják számunkra.

A DNS-kezelő képei a SAURON-ban

Dnslinux.mordor.fan csapat.

Ha jól megnézzük, az IP-címre 10.10.10.5 nem rendeltek hozzá nevet pontosan azért, hogy azt az új DNS neve foglalja el dnslinux.mordor.fan. A DNS és DHCP pár telepítéséhez a cikkek vezethetnek DNS és DHCP a Debian 8 "Jessie" -ben y DNS és DHCP a CentOS 7-en.

Alap operációs rendszer

A barátom A FuegianAmellett, hogy igazi szakember a Microsoft® Windows rendszerben - van néhány tanúsítványa, amelyeket az adott cég adott ki -, elolvasott és a gyakorlatba is átült néhány, az asztali számítógépekről szóló cikket. DesdeLinux., és azt mondta nekem, hogy kifejezetten egy Debian-alapú megoldást szeretett volna. 😉

Hogy örömet szerezzünk neked, a kiszolgáló friss és tiszta telepítésével kezdjük Debian 8 "Jessie". Amit azonban legközelebb írunk, azokra a CentOS és az openSUSE disztribúciókra érvényes, amelyek cikkeit korábban említettük. A BIND és a DHCP minden disztrón megegyezik. Enyhe variációkat vezetnek be a csomag fenntartói az egyes disztribúciókban.

A telepítést az alábbiak szerint végezzük DNS és DHCP a Debian 8 "Jessie" -ben, ügyelve az IP használatára 10.10.10.5 és a hálózat 10.10.10.0/24., még a BIND konfigurálása előtt.

A BIND-t a Debian stílusban konfiguráljuk

/etc/bind/named.conf

A fájl /etc/bind/named.conf a telepítéskor hagyjuk.

/etc/bind/named.conf.options

A fájl /etc/bind/named.conf.options a következő tartalommal kell maradnia:

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

root @ dnslinux: ~ # nano /etc/bind/named.conf.options
opciók {könyvtár "/ var / cache / bind"; // Ha tűzfal van közted és a névkiszolgálók között, akikkel // beszélni szeretnél, akkor lehet, hogy meg kell javítanod a tűzfalat, hogy több // port is beszélhessen. Lásd: http://www.kb.cert.org/vuls/id/800113 // Ha az internetszolgáltatója egy vagy több IP-címet adott a stabil // névszerverekhez, akkor valószínűleg továbbítóként szeretné használni őket. // Kommentálja a következő blokkot, és illessze be a címeket az // összes-0 helyőrzőjére. // szállítmányozók {// 0.0.0.0; //}; // ================================================= ===================== $ // Ha a BIND naplózza a root kulcs lejártával kapcsolatos hibaüzeneteket, // akkor frissítenie kell a kulcsokat. Lásd: https://www.isc.org/bind-keys // ================================= =================================== $

    // Nem akarunk DNSSEC-t
        dnssec-enable nem;
        //dnssec-érvényesítés automatikus;

        auth-nxdomain nem; # megfelel az RFC1035 szabványnak

 // Nem kell hallgatnunk az IPv6-címeket
        // listen-on-v6 {any; };
    listen-on-v6 {nincs; };

 // A localhost és a sysadmin ellenőrzéséhez
    // keresztül // dig mordor.fan axfr // dig 10.10.10.in-addr.arpa axfr // dig _msdcs.mordor.fan axfr // Nincs Slave DNS ... eddig
 allow-transfer {localhost; 10.10.10.1; };
};

// BIND naplózása
naplózás {

        csatornakérdezések {
        a "/var/log/named/queries.log" fájl 3-as verziója 1m;
        súlyossági információk;
        nyomtatási idő igen;
        nyomtatás-súlyosság igen;
        nyomtatási kategória igen;
        };

        csatorna lekérdezés-hiba {
        a "/var/log/named/query-error.log" fájl 3-as verziója 1m;
        súlyossági információk;
        nyomtatási idő igen;
        nyomtatás-súlyosság igen;
        nyomtatási kategória igen;
        };

                                
kategória lekérdezések {
         lekérdezések;
         };

kategória lekérdezési hibák {
         lekérdezés-hiba;
         };

};

• BIND naplók befogását mutatjuk be a-ként NEW megjelenés a témáról szóló cikksorozatban. Létrehozzuk lmappa és fájlok, amelyek szükségesek a Fakitermelés a 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

Ellenőrizzük a konfigurált fájlok szintaxisát

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

/etc/bind/named.conf.local

Mi hozzuk létre a fájlt /etc/bind/zones.rfcFreeBSD alatt feltüntetett tartalommal DNS és DHCP a Debian 8 "Jessie" -ben.

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

A fájl /etc/bind/named.conf.local a következő tartalommal kell maradnia:

// // Itt végezhet bármilyen helyi konfigurációt // // Fontolja meg az 1918-as zónák ide történő hozzáadását, ha azokat nem használja a // szervezete
tartalmazza: "/etc/bind/zones.rfc1918"; tartalmazza az "/etc/bind/zones.rfcFreeBSD" szót;

zóna "mordor.fan" {type master; fájl "/var/lib/bind/db.mordor.fan"; }; zóna "10.10.10.in-addr.arpa" {típusú mester; fájl "/var/lib/bind/db.10.10.10.in-addr.arpa"; };

zóna "_msdcs.mordor.fan" {type master;
 az ellenőrző nevek figyelmen kívül hagyják; fájl "/etc/bind/db._msdcs.mordor.fan"; }; root @ dnslinux: ~ # named-checkconf
root @ dnslinux: ~ #

Zóna Archívum mordor.fan

root @ dnslinux: ~ # nano /var/lib/bind/db.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; soros 1D; frissítse 1H-t; próbálkozzon újra 1W-vel; 3H-ig jár le); minimum vagy; Negatív gyorsítótárazás az élésre;
; Legyen NAGYON ÓVATOS A KÖVETKEZŐ JEGYZÉKEKKEL
@ IN NS dnslinux.mordor.fan.
@ IN A 10.10.10.5
@ IN MX 10 blackelf.mordor.fan. @ IN TXT "Üdvözlet a Mordor sötét sávjában";
_msdcs.mordor.fan. IN NS dnslinux.mordor.fan.
;
dnslinux.mordor.fan. IN A 10.10.10.5
; A KÖVETKEZŐ NYILVÁNTARTÁSSAL NAGYON GONDOSAN VÉGE
DomainDnsZones.mordor.fan. IN A 10.10.10.3 ForestDnsZones.mordor.fan. IN A 10.10.10.3; ; GLOBÁLIS KATALÓGUS _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. ; ; Az Active Directory _ldap._tcp.mordor.fan módosított és privát LDAP-ja. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. ; ; Az Active Directory módosított és privát KERBEROS-ja _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 0 88 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 600 IN SRV 0 0 88 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 600 IN SRV 0 0 464 sauron.mordor.fan. _kerberos._udp.mordor.fan. 600 IN SRV 0 0 88 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 600 IN SRV 0 0 464 sauron.mordor.fan. ; ; A rögzített IP-kkel rendelkező rekordok -> Blackelf.mordor.fan szerverek. IN A 10.10.10.9 blackspider.mordor.fan. IN A 10.10.10.10 darklord.mordor.fan. IN A 10.10.10.6 mamba.mordor.fan. IN A 10.10.10.4 palantir.mordor.fan. IN A 10.10.10.11
sauron.mordor.ventilátor. IN A 10.10.10.3
shadowftp.mordor.fan. IN A 10.10.10.8 troll.mordor.fan. IN A 10.10.10.7; ; A CNAME rögzíti az ad-dc.mordor.fan fájlt. CNAME-ben sauron.mordor.fan. blog.mordor.fan. CNAME-ben troll.mordor.fan. fájlkiszolgáló.mordor.fan. CNAME-ben mamba.mordor.fan. ftpserver.mordor.fan. A CNAME-ben shadowftp.mordor.fan. mail.mordor.fan. CNAME-ben balckelf.mordor.fan. openfire.mordor.fan. CNAME-ben palantir.mordor.fan. proxy.mordor.fan. CNAME-ben darklord.mordor.fan. www.mordor.fan. CNAME-ben blackspider.mordor.fan.

root @ dnslinux: ~ # named-checkzone mordor.fan /var/lib/bind/db.mordor.fan 
zóna mordor.fan/IN: betöltött 1. sor OK

Az idők 600 TTL az összes SRV regiszter közül megtartjuk őket arra az esetre, ha a Slave BIND-t időnként telepítjük. Ezek a rekordok az Active Directory® szolgáltatásokat reprezentálják, amelyek többnyire az LDAP adatbázisból olvasnak adatokat. Mivel az adatbázis gyakran változik, a szinkronizálási időket rövidnek kell tartani, a Master - Slave DNS sémában. Az Active Directory 2000 és 2008 között megfigyelt Microsoft filozófia szerint a 600 értéke megmarad az ilyen típusú SRV rekordoknál.

sok TTL-ek a fix IP-vel rendelkező kiszolgálók közül 3 órán belül vannak a deklarált idő alatt az SOA-ban.

Zónafájl 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; soros 1D; frissítse 1H-t; próbálkozzon újra 1W-vel; 3H-ig jár le); minimum vagy; Negatív gyorsítótárazás az élésre; @ 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 PTR-ben 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 
zóna 10.10.10.in-addr.arpa/IN: betöltött 1. sor OK

Zónafájl _msdcs.mordor.fan

Vegyük figyelembe a fájlban ajánlottakat /usr/share/doc/bind9/readme.debian.gz A fő zónák fájljainak helyéről, amelyeket a DHCP nem frissített dinamikusan.

root @ dnslinux: ~ # nano /etc/bind/db._msdcs.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; soros 1D; frissítse 1H-t; próbálkozzon újra 1W-vel; 3H-ig jár le); minimum vagy; Negatív gyorsítótárazás az élésre; @ IN NS dnslinux.mordor.fan. ; ; ; GLOBÁLIS KATALÓGUS gc._msdcs.mordor.fan. 600 IN A 10.10.10.3; ; Álnevek - az Active Directory módosított és privát LDAP-adatbázisában - a SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan fájlban. 600 CNAME-ben sauron.mordor.fan. ; ; Az Active Directory módosított és privát LDAP-ja: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. ; ; KERBEROS módosítva és privátként az Active Directory _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan fájlból. 600 IN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan.

Ellenőrizzük a szintaxist, és figyelmen kívül hagyhatjuk a visszatérő hibát, mivel ennek a Zónának a konfigurációjában található a fájl /etc/bind/named.conf.local belefoglaljuk az állítást az ellenőrző nevek figyelmen kívül hagyják;. A zónát a BIND megfelelően tölti be.

root @ dnslinux: ~ # named-checkzone _msdcs.mordor.fan /etc/bind/db._msdcs.mordor.fan 
/etc/bind/db._msdcs.mordor.fan:14: gc._msdcs.mordor.fan: rossz tulajdonos neve (check-names) zóna _msdcs.mordor.fan/IN: betöltött soros 1 OK

root @ dnslinux: ~ # systemctl indítsa újra a bind9.service szolgáltatást 
root @ dnslinux: ~ # systemctl állapot bind9.service 
● bind9.service - BIND tartománynév-kiszolgáló betöltve: betöltve (/lib/systemd/system/bind9.service; engedélyezve) Drop-In: /run/systemd/generator/bind9.service.d └─50-insserv.conf- $ named.conf Active: aktív (futó) vasárnap óta 2017-02-12 08:48:38 EST; 2 másodperccel ezelőtt Dokumentumok: man: named (8) Folyamat: 859 ExecStop = / usr / sbin / rndc stop (kód = kilépett, status = 0 / SIKER) Fő PID: 864 (megnevezve) CGroup: /system.slice/bind9.service └─864 / usr / sbin / named -f -u bind február 12 08:48:38 dnslinux nevű [864]: zóna 3.efip6.arpa/IN: betöltött soros február 1 12:08:48 dnslinux [38 néven ]: zóna befip864.arpa/IN: betöltött sorozat 6. február 1. 12:08:48 dnslinux nevű [38]: zóna 864.efip0.arpa/IN: betöltött soros 6. február 1. 12:08:48 dnslinux néven [38]: zóna 864.efip7.arpa/IN: betöltött sorozat 6. február 1. 12:08:48 dnslinux nevű [38]: zóna mordor.fan/IN: betöltött soros 864. február 1. 12:08:48 dnslinux néven [38]: zóna példa .org / IN: betöltött soros február 864, 1:12:08 dnslinux [48] néven: zone _msdcs.mordor.fan/IN: betöltött soros február 38, 864:1:12 [08] nevű dnslinux: érvénytelen zóna / IN : betöltött sorozat 48. február 38. 864:1:12 dnslinux [08] néven: minden zóna betöltve
Február 12. 08:48:38 dnslinux [864] néven: futás

Konzultálunk a BIND-vel

előtt A DHCP telepítése után egy sor ellenőrzést kell végrehajtanunk, amely magában foglalja akár a Windows 7 kliens csatlakozását is a tartományhoz mordor.ventilátor a számítógépre telepített Active Directory képviseli sauron.mordor.ventilátor.

Az első dolog a számítógép DNS-szolgáltatásának leállítása sauron.mordor.ventilátor, és a hálózati felületén jelentse be, hogy mostantól a DNS-kiszolgáló lesz a 10.10.10.5 dnslinux.mordor.fan.

Magának a kiszolgálónak a konzoljában sauron.mordor.ventilátor végrehajtjuk:

Microsoft Windows [verziószám 6.1.7600]
Szerzői jog (c) 2009 Microsoft Corporation. Minden jog fenntartva.

C: \ Users \ Administrator> nslookup
Alapértelmezett kiszolgáló: dnslinux.mordor.fan Cím: 10.10.10.5

> gc._msdcs
Szerver: dnslinux.mordor.fan Cím: 10.10.10.5 Név: gc._msdcs.mordor.fan Cím: 10.10.10.3

> mordor.fan
Szerver: dnslinux.mordor.fan Cím: 10.10.10.5 Név: mordor.fan Cím: 10.10.10.3

> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs
Szerver: dnslinux.mordor.fan Cím: 10.10.10.5 Név: sauron.mordor.fan Cím: 10.10.10.3 Álnevek: 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan

> set type = SRV
> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
Szerver: dnslinux.mordor.fan Cím: 10.10.10.5 _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan SRV szerver jég helye: prioritás = 0 súly = 100 port = 88 svr hosztnév = sauron.mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan internetcím = 10.10.10.3 dnslinux.mordor.fan internetcím = 10.10.10.5
> _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs
Szerver: dnslinux.mordor.fan Cím: 10.10.10.5 _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan SRV szolgáltatás helye: prioritás = 0 súly = 100 port = 389 svr hosztnév = sauron .mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan internetcím = 10.10.10.3 dnslinux.mordor.fan internetcím = 10.10.10.5
> kilépés

C: \ Felhasználók \ Rendszergazda>

DNS-lekérdezések készült sauron.mordor.ventilátor kielégítőek.

A következő lépés egy újabb virtuális gép létrehozása lesz, telepítve a Windows 7 rendszert. Mivel még mindig nincs telepítve a DHCP szolgáltatás, megadjuk a számítógép nevét «win7»Az IP-cím 10.10.10.251. Kijelentjük továbbá, hogy a DNS-kiszolgáló lesz a 10.10.10.5 dnslinux.mordor.fan, és hogy a keresési domain az lesz mordor.ventilátor. Ezt a számítógépet nem regisztráljuk a DNS-be, mert a telepítés után a DHCP szolgáltatás tesztelésére is felhasználjuk.

Ezután kinyitunk egy konzolt CMD és ebben végrehajtjuk:

Microsoft Windows [verziószám 6.1.7601]
Szerzői jog (c) 2009 Microsoft Corporation. Minden jog fenntartva.

C: \ Users \ buzz> nslookup
Alapértelmezett kiszolgáló: dnslinux.mordor.fan Cím: 10.10.10.5

> mordor.fan
Szerver: dnslinux.mordor.fan Cím: 10.10.10.5 Név: mordor.fan Cím: 10.10.10.3

> set type = SRV
> _ldap._tcp.DomainDnsZones
Szerver: dnslinux.mordor.fan Cím: 10.10.10.5 _ldap._tcp.DomainDnsZones.mordor.fan SRV szolgáltatás helye: prioritás = 0 súly = 0 port = 389 svr hosztnév = sauron.mordor.fan mordor.fan névkiszolgáló = dnslinux.mordor .fan sauron.mordor.fan internetcím = 10.10.10.3 dnslinux.mordor.fan internetcím = 10.10.10.5
> _kpasswd._udp
Szerver: dnslinux.mordor.fan Cím: 10.10.10.5 _kpasswd._udp.mordor.fan SRV szolgáltatás helye: prioritás = 0 súly = 0 port = 464 svr hosztnév = sauron.mordor.fan mordor.fan névkiszolgáló = dnslinux.mordor.fan sauron.mordor.fan internetcím = 10.10.10.3 dnslinux.mordor.fan internetcím = 10.10.10.5
> _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones
Szerver: dnslinux.mordor.fan Cím: 10.10.10.5 _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan SRV kiszolgáló jég helye: prioritás = 0 súly = 0 port = 389 svr hosztnév = sauron. mordor.fan mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan internetcím = 10.10.10.3 dnslinux.mordor.fan internetcím = 10.10.10.5
> kijárat

C: \ Felhasználók \ buzz>

DNS-lekérdezések az ügyféltől «win7»Kielégítőek is voltak.

Az Active Directory-ban létrehozzuk a felhasználót «szarkán«, Azzal a céllal, hogy a klienshez való csatlakozáskor használja win7 a domainhez mordor.ventilátor., a «Hálózati azonosító«, Felhasználónevek használata saruman@mordor.fan y admin@mordor.fan. A csatlakozás sikeres volt, és ezt a következő képernyőkép bizonyítja:

A Microsoft® DNS és a BIND dinamikus frissítéseiről

Mivel a DNS-szolgáltatás leállt az Active Directory®-ban, az ügyfél nem volt képes «win7»Regisztrálja nevét és IP-címét a DNS-be. Sokkal kevésbé dnslinux.mordor.fan mivel nem nyilatkoztunk engedélyezés-frissítés az érintett területek bármelyikéhez.

És itt alakult ki a jó harc a barátommal A Fuegian. Az ezzel kapcsolatos első e-mailemben megjegyzést fűztem:

• A Microsoft a BIND és az Active Directory® használatáról szóló cikkei azt javasolják, hogy engedélyezzék különösen a Direct Zone frissítését -behatolt- közvetlenül Windows kliensek, amelyek már csatlakoztak az Active Directory tartományhoz.
• Éppen ezért alapértelmezés szerint az Active Directory® DNS zónáiban engedélyezettek a biztonságos dinamikus frissítések a Windows kliensek már csatlakoztak az Active Directory tartományhoz. Ha nem egyesülnek, tartózkodnak a következményektől.
• Az Active Directory DNS-je támogatja a "Csak biztonságos", "Nem biztonságos és biztonságos" vagy "Nincs" dinamikus frissítéseket, ami megegyezik azzal, hogy NO frissítéseket vagy Nincs.
• Igen valóban A Microsoft Philosophy nem ért egyet azzal, hogy ügyfelei NEM frissítik az adataikat a DNS-ekben, nem hagyja nyitva a DNS-ek dinamikus frissítésének letiltásának lehetőségét, hacsak ez az opció rejtettebb célokra marad.
• A Microsoft a "Sötétségért" cserébe kínálja a "Biztonságot", ahogy a Microsft® Certificates tanfolyamokon átesett kollégám és barátom elmondta. Igaz. Ezen kívül El Fueguino megerősítette nekem.
• Az a kliens, amely például egy UNIX® / Linux gépre telepített DHCP-n keresztül szerez IP-címet, nem tudja feloldani a saját nevének IP-címét. amíg nem csatlakozik az Active Directory tartományhoz, mindaddig, amíg a Microsoft®-t vagy a BIND-t DNS-ként használják dinamikus frissítések nélkül a DHCP által.
• Ha magába az Active Directory®-ba telepítem a DHCP-t, akkor nyilatkoznom kell arról, hogy a zónákat a Microsoft® DHCP frissíti.
• Ha a BIND-t fogjuk használni a Windows hálózat DNS-ként, akkor logikus, és ajánlott a BIND-DHCP duó telepítése, utóbbi dinamikusan frissíti a BIND-t és az ügy lezárult.
• Az UNIX® / Linux rendszerű LAN-hálózatok világában, amióta a BIND-re feltalálták a dinamikus frissítéseket, csak Mr. DHCP engedélyezett «behatol»Mrs. BIND-nek frissítéseivel. Kérjük, a rendezéssel járó kikapcsolódást.
• Amikor kijelentem a zónában mordor.ventilátor például: allow-update {10.10.10.0/24; };, Maga a BIND arról tájékoztat, amikor elindítom vagy újraindítom, hogy:

  • A 'mordor.fan' zóna IP-cím alapján engedélyezi a frissítéseket, ami nem biztonságos

• A szentséges UNIX® / Linux világban az ilyen hozzáértés a DNS-sel egyszerűen megengedhetetlen.

El tudja képzelni a barátommal folytatott többi beszélgetést A Fuegian mediante e-mailek, Távirat Chat, az általa fizetett telefonhívások (persze ember, nincs ehhez kilóm), sőt a postagalambokon keresztüli üzenetek a XXI.

Még azzal is megfenyegette, hogy nem küld nekem fia a házi kedvencének, az iguánának «Petra»Hogy megígérte nekem a fizetés részeként. Ott nagyon féltem. Szóval újrakezdtem, de egy másik oldalról.

• A "majdnem" Active Directory, amelyet a Samba 4 segítségével lehet elérni, mesteri módon oldja meg ezt a szempontot, akkor is, ha a belső DNS-jét használjuk, vagy a BIND-t, amelyet a DLZ zónák támogatására fordítottunk - Dinamyc terhelt zónák, vagy dinamikusan betöltött zónák.
• Továbbra is ugyanazoktól szenved: amikor egy kliens egy IP-címet szerez be egy DHCP-re, amely telepítve van más UNIX® / Linux gépen nem tudja megoldani a saját nevének IP-címét amíg nem csatlakozik a Samba 4 AD-DC tartományához.
• Integrálja a BIND-DLZ és DHCP duót ugyanazon a gépen, ahová a AD-DC Samba 4 ez egy igazi szakember munkája.

A Fuegian Fejezetbe hívott, és rám kiabált: NEM beszélünk AD-DC Samba 4, de a Microsoft® Active Directory®! -ból. És alázatosan azt válaszoltam, hogy örülök a következő cikkek egy részének, amelyet írni fogok.

Ekkor mondtam el neki, hogy a hálózatán lévő kliens számítógépek dinamikus frissítéséről a végső döntést az ő szabad akaratára bízták. Hogy csak neki adnám a típus korábban írták kb allow-update {10.10.10.0/24; };, és még semmi. Hogy nem vagyok felelős azért, ami abból az eredetiségből fakad, hogy minden Windows-ügyfél - vagy Linux - a hálózatukban «behatol»Büntetlenül a BIND-hez.

Ha tudná, Olvasó barátom, hogy ez a verekedés végpontja, nem hinné el. A barátom A Fuegian elfogadta a megoldást - és elküldi nekem az iguánát «Pete«- hogy most megosztom veled.

Telepítjük és konfiguráljuk a DHCP-t

További részletekért olvassa el DNS és DHCP a Debian 8 "Jessie" -ben.

root @ dnslinux: ~ # aptitude telepítse az isc-dhcp-szervert

root @ dnslinux: ~ # nano / etc / default / isc-dhcp-server .... # Milyen felületeken kell a DHCP-kiszolgálónak (dhcpd) kiszolgálni a DHCP-kéréseket? # Különítsen el több interfészt szóközökkel, pl. "Eth0 eth1". INTERFACES = "eth0" root @ dnslinux: ~ # dnssec-keygen -a HMAC-MD5 -b 128 -r / dev / urandom -n FELHASZNÁLÓ dhcp-kulcs
Kdhcp-kulcs. + 157 + 29836

root @ dnslinux: ~ # cat Kdhcp-kulcs. +157 + 29836. magán
Privát kulcs-formátum: v1.3 algoritmus: 157 (HMAC_MD5) Kulcs: 3HT / bg / 6YwezUShKYofj5g == Bitek: AAA = Létrehozva: 20170212205030 Közzététel: 20170212205030 Aktiválás: 20170212205030

root @ dnslinux: ~ # nano dhcp.key
kulcs dhcp-kulcs {hmac-md5 algoritmus; titkos "3HT / bg / 6YwezUShKYofj5g =="; };

root @ dnslinux: ~ # install -o root -g root -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
// // Itt végezhet bármilyen helyi konfigurációt // // Fontolja meg az 1918-as zónák ide történő hozzáadását, ha azokat nem használja a // szervezete, az "/etc/bind/zones.rfc1918"; tartalmazza az "/etc/bind/zones.rfcFreeBSD" szót;
// ne felejtsd el ... elfelejtettem és hibákkal fizettem. ;-)
tartalmazza az "/etc/bind/dhcp.key" szót;


zóna "mordor.fan" {type master;
        allow-update {10.10.10.3; kulcs dhcp-kulcs; };
        fájl "/var/lib/bind/db.mordor.fan"; }; zóna "10.10.10.in-addr.arpa" {típusú mester;
        allow-update {10.10.10.3; kulcs dhcp-kulcs; };
        fájl "/var/lib/bind/db.10.10.10.in-addr.arpa"; }; zóna "_msdcs.mordor.fan" {type master; az ellenőrző nevek figyelmen kívül hagyják; fájl "/etc/bind/db._msdcs.mordor.fan"; };

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

root @ dnslinux: ~ # nano /etc/dhcp/dhcpd.conf
ddns-update-style interim; ddns-frissítések be; ddns-domainname "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; figyelmen kívül hagyja az ügyfélfrissítéseket; irányadó; opció ip-továbbítás ki; opció tartománynév "mordor.fan"; tartalmazza az "/etc/dhcp/dhcp.key" szót; zóna mordor.ventilátor. {elsődleges 127.0.0.1; kulcs dhcp-kulcs; } zóna 10.10.10.in-addr.arpa. {elsődleges 127.0.0.1; kulcs dhcp-kulcs; } megosztott hálózati redlocal {alhálózat 10.10.10.0 netmask 255.255.255.0 {opció útválasztók 10.10.10.1; opció alhálózati maszk 255.255.255.0; opció sugárzási cím: 10.10.10.255; domain tartománynév-kiszolgálók opció 10.10.10.5; opció netbios-name-server 10.10.10.5; tartomány 10.10.10.30 10.10.10.250; }} # VÉGE dhcpd.conf

root @ dnslinux: ~ # dhcpd -t
Internet Systems Consortium DHCP Server 4.3.1 Copyright 2004-2014 Internet Systems Consortium. Minden jog fenntartva. További információ: https://www.isc.org/software/dhcp/ Config fájl: /etc/dhcp/dhcpd.conf Adatbázis fájl: /var/lib/dhcp/dhcpd.leases PID fájl: / var / run /dhcpd.pid

root @ dnslinux: ~ # systemctl indítsa újra a bind9.service szolgáltatást 
root @ dnslinux: ~ # systemctl állapot bind9.service 

root @ dnslinux: ~ # systemctl start isc-dhcp-server.service
root @ dnslinux: ~ # systemctl állapot isc-dhcp-server.service

Mi kapcsolódik Ellenőrzések az ügyfelekkelés a A zóna fájlok kézi módosítása, meghagyjuk neked, olvasó barátom, hogy közvetlenül olvassa el DNS és DHCP a Debian 8 "Jessie" -ben, és alkalmazza a tényleges körülményeire. Elvégeztük az összes szükséges ellenőrzést és kielégítő eredményeket értünk el. Természetesen mindegyikük másolatát elküldjük a címre A Fuegian. Nem lesz több!

tippek

általános

• Kezdete előtt kapjon sok türelmet.
  
• Először telepítse és konfigurálja a BIND-t. Ellenőrizzen mindent, és tekintse meg az összes olyan rekordot, amelyet a három vagy több zóna minden fájljában deklarált, mind az Active Directory, mind pedig a Linux DNS-kiszolgálójától. Ha lehetséges, a tartományhoz nem csatlakozó Linux gépről végezze el a szükséges DNS-lekérdezéseket a BIND-hez.
  
• Csatlakozzon egy fix IP-címmel rendelkező Windows klienshez a meglévő tartományhoz, és ellenőrizze újra a BIND összes beállítását a Windows kliensből.
• Miután kétségtelenül biztos abban, hogy vadonatúj BIND-jének konfigurációja teljesen helytálló, vállalkozzon a DHCP-szolgáltatás telepítésére, konfigurálására és indítására.
• Hibák esetén ismételje meg a teljes eljárást 0-tól.
• Vigyázzon a másolással és beillesztéssel! és a megmaradt szóközök a named.conf.xxxx fájlok minden sorában
  
• Utána nem panaszkodott - még kevésbé Fuegian barátomnak -, hogy nem tanácsolták megfelelően.

Egyéb tippek

• Oszd meg és uralkodj.
• Egy kkv-hálózatban biztonságosabb és előnyösebb olyan hiteles BIND-t telepíteni a belső LAN zónákra, amely nem fordul elő egyetlen gyökérkiszolgálón sem: rekurzió nem;.
• Internetkapcsolat-szolgáltatónál található kkv-hálózatban - ISP, talán a szolgáltatások meghatalmazott y SMTP meg kell oldaniuk a domain neveket az interneten. Ő Tintahal lehetősége van arra, hogy deklarálja a DNS-ét külsőnek vagy sem, míg a levelezőszerveren alapul utáni javítás o Mdaemon® Kijelenthetjük azokat a DNS-kiszolgálókat is, amelyeket az adott szolgáltatásban használni fogunk. Ilyen esetekben, vagyis olyan esetekben, amelyek nem nyújtanak szolgáltatást az Internet számára, és amelyek a Internet szolgáltató, telepíthet egy BIND fájlt a Szállítmányozók rámutatva a ISP, és nyilvánítsa másodlagos DNS-ként azokon a kiszolgálókon, amelyeknek meg kell oldaniuk a LAN-ra vonatkozó külső kérdéseket, különben lehetőség van a saját konfigurációs fájljaikon keresztüli deklarálásra.
• Ha Ön teljes felelősségére delegált zónával rendelkezikAztán még egy kakasvarjú:
  • Telepítse a DNS-kiszolgálót a következők alapján: NBI, amely definíció szerint hiteles DNS-kiszolgáló, amely válaszol az interneten lévő számítógépekről érkező kérdésekre. Néhány információ alkalmassági show nsd. 😉 Kérjük, nagyon jól védje meg annyi tűzfallal, amennyi csak szükséges. Hardver és szoftver egyaránt. DNS lesz az internet számára, és ez «Cár»Nem szabad alacsony nadrággal adni. 😉
  • Mivel még soha nem láttam magam ilyen esetben, vagyis teljes felelősséggel tartozom egy delegált zónáért, nagyon jól át kellene gondolnom, mit ajánljak a LAN-on kívüli domainnevek feloldására azoknak a szolgáltatásoknak, amelyekre szükségük van. A kkv hálózati ügyfeleknek nem igazán van rá szükségük. Konzultáljon szakirodalommal, vagy szakemberrel ezekben a tantárgyakban, mivel messze nem tartozom közéjük. Komolyan.
  • Rekurzió nem létezik az autoriter szervereken. Oké?. Abban az esetben, ha valaki véletlenül BIND-del csinálja.
• Bár kifejezetten meghatározzuk a fájlban /etc/dhcp/dhcpd.conf a nyilatkozatot figyelmen kívül hagyja az ügyfélfrissítéseket;, ha számítógépes konzolon futunk dnslinux.mordor.fan a megrendelés Journalctl -f, ezt látni fogjuk az ügyfél indításakor win7.mordor.fan a következő hibaüzeneteket kapjuk:

  • Február 12. 16:55:41 [900] nevű dnslinux: kliens 10.10.10.30 # 58762: a „mordor.fan/IN” frissítés megtagadva
    Február 12. 16:55:42 [900] nevű dnslinux: kliens 10.10.10.30 # 49763: a „mordor.fan/IN” frissítés megtagadva
    Február 12. 16:56:23 [900] nevű dnslinux: kliens 10.10.10.30 # 63161: a „mordor.fan/IN” frissítés megtagadva
    

  • Ezeknek az üzeneteknek a kiküszöbölése érdekében át kell mennünk a hálózati kártya konfigurációjának speciális lehetőségeire, és törölnünk kell a jelölést «Regisztrálja a kapcsolat címét a DNS-ben«. Ez megakadályozza az ügyfelet abban, hogy örökre megpróbálja magát regisztrálni a Linux DNS-be, és ezzel vége a problémának. Sajnálom, de a Windows 7 spanyol nyelvű példánya nincs. 😉
• Ha meg szeretné tudni a Windows 7 kliens összes komoly és őrült kérdését, nézze meg a napló lekérdezések.log hogy valamire a BIND konfigurációban deklaráljuk. A sorrend a következő lenne:

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

• Ha nem engedélyezi az ügyfélszámítógépek közvetlen kapcsolódását az internethez, akkor miért van szüksége root DNS-kiszolgálókra? Ez jelentősen csökkenti a parancs kimenetét Journalctl -f és az előzőtől, ha a belső zónák autoriter DNS-kiszolgálója nem kapcsolódik közvetlenül az internethez, ami biztonsági szempontból nagyon ajánlott.

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

• Ha nincs szüksége a gyökérkiszolgálók deklarációjára, akkor miért kell a Rekurzió - Rekurzió?

  root @ dnslinux: ~ # nano /etc/bind/named.conf.options
  lehetőségek {
   ....
   rekurzió nem;
   ....
  };

Konkrét tanácsok, amelyekben még mindig nem vagyok egyértelmű

El ember dhcpd.conf sok más dolog közül a következőket mondja el nekünk:

        A frissítés-optimalizálás utasítás

            frissítés-optimalizálás jelző;

            Ha a frissítés-optimalizálási paraméter hamis egy adott ügyfél számára, akkor a kiszolgáló megpróbálja az adott ügyfél DNS-frissítését minden egyes alkalommal, amikor az ügyfél megújítja bérletét, és nem csak akkor próbál meg frissíteni, amikor szükségesnek tűnik. Ez lehetővé teszi a DNS számára, hogy könnyebben meggyógyuljon az adatbázis inkonzisztenciáitól, de ennek költsége az, hogy a DHCP-kiszolgálónak sokkal több DNS-frissítést kell végrehajtania. Javasoljuk, hogy olvassa el ezt az opciót engedélyezve, amely az alapértelmezett. Ez a beállítás csak az ideiglenes DNS-frissítési séma viselkedését befolyásolja, és nincs hatással az eseti DNS-frissítési sémára. Ha ez a paraméter nincs megadva, vagy igaz, akkor a DHCP-kiszolgáló csak akkor frissül, ha az ügyfélinformációk megváltoznak, az ügyfél más bérleti szerződést kap, vagy ha az ügyfél bérleti ideje lejár.

A többé-kevésbé pontos fordítás vagy értelmezés rád maradt, kedves olvasó.

Személy szerint velem történt - és ez a cikk írása során is megtörtént -, hogy amikor egy BIND-t összekapcsolok egy Active Directory®-val, akkor az a Microsft®-ből vagy a Samba 4-ből származik, ha megváltoztatom az Active Directory® tartományban regisztrált kliens számítógép nevét. vagy AD–DC a Samba 4-ből, régi nevét és IP-címét a Közvetlen Zónában tartja, és nem fordítva, amelyet helyesen frissítenek az új névvel. Más szavakkal, a régi és az új nevek ugyanarra az IP-címre vannak feltérképezve a Direct Zone-ban, míg fordítva csak az új név jelenik meg. Ahhoz, hogy jól megértsen, magának is ki kell próbálnia.

Azt hiszem, ez egyfajta bosszú a felé A Fuegian -nem nekem kérem-, hogy megpróbáltam átállítani a szolgáltatásait Linuxra.

Természetesen a régi név eltűnik, amikor 3600 TTL, vagy az az idő, amelyet a DHCP konfigurációban deklaráltunk. De azt akarjuk, hogy azonnal eltűnjön, ahogy egy BIND + DHCP-ben történik Active Directory nélkül keresztül.

A helyzet megoldását a nyilatkozat beszúrásával találtam meg frissítés-optimalizálás hamis; a fájl tetejének végén /etc/dhcp/dhcpd.conf:

ddns-update-style interim; ddns-frissítések be; ddns-domainname "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; figyelmen kívül hagyja az ügyfélfrissítéseket;
frissítés-optimalizálás hamis;

Ha bármelyik Olvasó többet tud róla, kérem, világosítson fel. Sokat fogom értékelni.

Összegzés

Nagyon jól szórakoztunk a témában, igaz? Nem szenved, mert van egy BIND, amely DNS-kiszolgálóként működik a Microsoft® hálózaton, és felajánlja az összes SRV rekordot, és megfelelően reagál a hozzájuk intézett DNS-lekérdezésekre. Másrészt van egy DHCP szerverünk, amely megadja az IP-címeket és dinamikusan frissíti a BIND zónákat.

De nem kérhetjük ... egyelőre.

Remélem a barátom A Fuegian légy elégedett és elégedett a Linuxra való áttérés első lépésével, hogy elviselhetővé tegye a Microsft® technikai támogatás elviselhetetlen költségeit.

Fontos megjegyzés

Karakter "A Fuegian»Teljesen kitalált és képzeletem terméke. Bármilyen hasonlóság vagy egybeesés a valódi emberekkel ugyanaz: tiszta önkéntelen egybeesés részemről. Csak azért hoztam létre, hogy egy kicsit élvezetessé tegyem a cikk írását és olvasását. Most, ha elmondja, hogy a DNS probléma sötét, 😉