BIND a Active Directory® - sítě malých a středních podniků

Obecný index série: Počítačové sítě pro malé a střední podniky: Úvod

Dobrý den, přátelé!. Hlavním cílem tohoto článku je ukázat, jak můžeme integrovat službu DNS založenou na BIND9 v síti Microsoft, což je velmi běžné v mnoha malých a středních podnicích.

Vyplývá to z oficiální žádosti přítele, který žije v La Tierra del Fuego -Fuegian- specializující se na Microsoft® Networks - Zahrnuty certifikáty - které vás provedou touto částí migrace vašich serverů na Linux. Náklady na podpora Technici, kteří platí společnosti Microsoft®, již jsou Nesnesitelný pro společnost, ve které pracuje a jejíž je hlavním akcionářem.

Můj přítel Fuegian má velký smysl pro humor, a protože viděl sérii tří filmů «Pán prstenů»Byl uchvácen mnoha jmény svých temných postav. Takže, příteli čtenáři, nenechte se překvapit názvy vaší domény a vašich serverů.

Pro nováčky v tomto tématu a před pokračováním ve čtení doporučujeme přečíst si a prostudovat tři předchozí články o sítích SME:

• DNS a DHCP v openSUSE 13.2 „Harlekýn“
• DNS a DHCP na CentOS 7
• DNS a DHCP v Debianu 8 „Jessie“

Je to jako sledovat tři ze čtyř částí «Podsvětí»Zveřejněno dodnes a toto je čtvrté.

Obecné parametry

Po několika výměnách prostřednictvím e-mail, konečně jsem měl jasno o hlavních parametrech vaší aktuální sítě, kterými jsou:

Název domény mordor.fan LAN Network 10.10.10.0/24 ==================================== ========================================== Účel IP adresy serverů (servery s OS Windows) ================================================ =============================== sauron.mordor.fan. 10.10.10.3 Active Directory® 2008 SR2 mamba.mordor.fan. 10.10.10.4 Souborový server Windows darklord.mordor.fan. 10.10.10.6 Proxy, brána a firewall na Kerios troll.mordor.fan. 10.10.10.7 Blog založený na ... si nepamatuji shadowftp.mordor.fan. 10.10.10.8 FTP server blackelf.mordor.fan. 10.10.10.9 Plná e-mailová služba blackspider.mordor.fan. 10.10.10.10 WWW služba palantir.mordor.fan. 10.10.10.11 Chat na Openfire pro Windows

Požádal jsem o povolení Fuegian nastavit tolik aliasů, kolik je třeba, aby mi vyčistil mysl a dal mi svolení:

Skutečný CNAME ============================== sauron ad-dc mamba fileserver darklord proxyweb troll blog shadowftp ftpserver blackelf mail blackspider www palantir openfire

Deklaroval jsem všechny důležité záznamy DNS v instalaci systému Windows 2008 Active Directory, které jsem byl nucen implementovat, aby mě vedl při vytváření tohoto příspěvku.

O záznamech DNS SRV služby Active Directory

Rejstříky SRV o Vyhledávače služeb - široce používané v Microsoft Active Directory - jsou definovány v Žádost o připomínky RFC 2782. Umožňují umístění služby založené na protokolu TCP / IP prostřednictvím dotazu DNS. Například zákazník v síti Microsoft může vyhledat umístění řadičů domény - Řadiče domény které poskytují službu LDAP přes protokol TCP na portu 389 prostřednictvím jediného dotazu DNS.

Je normální, že v lesích - Lesya stromy - Stromy velké sítě Microsoft existuje několik řadičů domény. Pomocí záznamů SRV v různých zónách, které tvoří prostor doménových jmen dané sítě, můžeme udržovat seznam serverů, které poskytují podobné známé služby, seřazené podle preferencí podle přepravního protokolu a portu každé z servery.

V Žádost o připomínky RFC 1700 Jsou definovány univerzální symbolické názvy pro dobře známé služby - Známá službaa jména jako «_telnet","_smtp»Pro služby telnet y SMTP. Pokud pro dobře známou službu není definován symbolický název, lze použít místní název nebo jiný název podle preferencí uživatele.

Účel každého pole «zvláštní»Při deklaraci záznamu o zdroji SRV se používá následující:

• Doména: "Pdc._msdcs.mordor.fan.«. Název DNS služby, na kterou se záznam SRV vztahuje. Název DNS v příkladu znamená - více či méně - Primární řadič domény oblasti _msdcs.mordor.fan.
• Servis: „_Ldap“. Symbolický název poskytované služby definovaný podle Žádost o připomínky RFC 1700.
• Protokol: „_Tcp“. Označuje typ přepravního protokolu. Obvykle může nabývat hodnot _tcp o _udp, i když - a ve skutečnosti - jakýkoli typ přepravního protokolu uvedeného v Žádost o připomínky RFC 1700. Například pro službu povídání na základě protokolu XMPP, toto pole bude mít hodnotu _xmpp.
• Priorita"0«. Deklarovat prioritu nebo preference pro Hostitel nabízející tuto službu které uvidíme později. Dotazy DNS klientů na službu definovanou tímto záznamem SRV se po obdržení příslušné odpovědi pokusí kontaktovat prvního dostupného hostitele s nejnižším počtem uvedeným v poli. Priorita. Rozsah hodnot, které toto pole může nabývat, je 0 65535.
• Hmotnost"100«. Lze použít v kombinaci s Priorita poskytnout mechanismus vyrovnávání zatížení, když existuje několik serverů, které poskytují stejnou službu. Pro každý server v souboru zóny by měl existovat podobný záznam SRV s názvem deklarovaným v poli Hostitel nabízející tuto službu. Před servery se stejnými hodnotami v poli Priorita, hodnota pole Hmotnost lze jej použít jako další úroveň preference k získání přesného výběru serveru pro vyvažování zátěže. Rozsah hodnot, které toto pole může nabývat, je 0 65535. Pokud není vyžadováno vyvážení zátěže, například jako v případě jednoho serveru, doporučuje se přiřadit hodnotu 0 aby se záznam SRV snáze četl.
• Číslo portu - Port"389«. Číslo portu v Hostitel nabízející tuto službu který poskytuje službu uvedenou v poli Servis. Číslo portu doporučené pro každý typ dobře známé služby je uvedeno v Žádost o připomínky RFC 1700, i když to může mít hodnotu mezi 0 a 65535.
• Hostitel nabízející tuto službu - Target"sauron.mordor.fan.«. Určuje FQDN který jednoznačně identifikuje hostitel která poskytuje službu označenou záznamem SRV. Typ záznamu «A»V oboru názvů domén pro každého FQDN ze serveru nebo hostitel který poskytuje službu. Jednodušší, typový záznam A v přímé zóně (zónách).
  • Nota:
    Chcete-li autoritativně označit, že služba určená záznamem SRV není na tomto hostiteli poskytována, použijte jeden (.) směřovat.

Chtěli bychom jen zopakovat, že správný provoz sítě nebo služby Active Directory® do značné míry závisí na správném fungování služby Domain Name Service..

Záznamy DNS služby Active Directory

Abychom vytvořili zóny nového serveru DNS na základě BIND, musíme získat všechny záznamy DNS ze služby Active Directory®. Abychom usnadnili život, jdeme do týmu sauron.mordor.fan -Active Directory® 2008 SR2- a v administrační konzole DNS aktivujeme zónový přenos - přímý a inverzní - pro hlavní zóny deklarované v tomto typu služby, které jsou:

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

Po provedení předchozího kroku a nejlépe z počítače s Linuxem, jehož IP adresa je v rozsahu podsítě používané sítí Windows, provedeme:

buzz @ sysadmin: ~ $ dig @ 10.10.10.3 _msdcs.mordor.fan axfr> teplota /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

• Připomeňme si z předchozích článků, že IP adresa zařízení správce systému.desdelinux.fanoušek es 10.10.10.1 nebo 192.168.10.1.

Ve třech předchozích příkazech můžeme tuto možnost vyloučit 10.10.10.3 -zeptejte se serveru DNS s touto adresou- pokud prohlásíme v souboru / Etc / resolv.conf na adresu IP serveru sauron.mordor.fan:

buzz@sysadmin:~$ cat /etc/resolv.conf # Vygenerováno vyhledáváním NetworkManager desdelinux.názvový server fanoušků 192.168.10.5 jmenný server 10.10.10.3

Po úpravě s maximální opatrností, která odpovídá jakémukoli souboru zóny v BIND, získáme následující data:

Záznamy RR z původní zóny _msdcs.mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs._msdcs.mordor.fan 
; Vztahující se k SOA a NS _msdcs.mordor.fan. 3600 V SOA sauron.mordor.fan. hostmaster.mordor.fan. 12 900 600 86400 3600 _msdcs.mordor.fan. 3600 IN NS sauron.mordor.fan. ; ; GLOBÁLNÍ KATALOG gc._msdcs.mordor.fan. 600 IN A 10.10.10.3; ; Aliasy - v upravené a soukromé databázi LDAP služby Active Directory - SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 V CNAME sauron.mordor.fan. ; ; Upravený a soukromý LDAP Active Directory _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 100 IN SRV 389 sauron.mordor.fan. _ldap._tcp.600d0d-100fdb-389cf-a18-d3360c8b40d678.domains._msdcs.mordor.fan. 7 IN SRV 420 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 6 IN SRV 775 600 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 0 IN SRV 100 389 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. ; ; Modifikovaný a soukromý KERBEROS Active Directory _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 100 V SRV 3268 600 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 0 V SRV 100 3268 sauron.mordor.fan.

Záznamy RR z původní zóny mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs.mordor.fan 
; Pokud jde o záznamy SOA, NS, MX a A, které mapuje; Doménové jméno do IP SAURON; Věci ze služby Active Directory mordor.fan. 3600 V SOA sauron.mordor.fan. hostmaster.mordor.fan. 48 900 600 86400 3600 mordor.fan. 600 IN A 10.10.10.3 mordor.fan. 3600 IN NS sauron.mordor.fan. mordor.fan. 3600 IN MX 10 blackelf.mordor.fan. _msdcs.mordor.fan. 3600 IN NS sauron.mordor.fan. ; ; Také důležité A zaznamenává DomainDnsZones.mordor.fan. 600 IN A 10.10.10.3 ForestDnsZones.mordor.fan. 600 IN A 10.10.10.3; ; GLOBÁLNÍ KATALOG _gc._tcp.mordor.fan. 600 IN SRV 0 100 sauron.mordor.fan. _gc._tcp.Default-First-Site-Name._sites.mordor.fan. 3268 IN SRV 600 0 sauron.mordor.fan. ; ; Upravený a soukromý LDAP služby Active Directory _ldap._tcp.mordor.fan. 100 V SRV 3268 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 600 V SRV 0 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 100 V SRV 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 600 V SRV 0 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 100 V SRV 389 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 600 V SRV 0 sauron.mordor.fan. ; ; Upravený a soukromý KERBEROS služby Active Directory _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan. 100 V SRV 389 600 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 0 V SRV 100 389 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. _kerberos._udp.mordor.fan. 100 V SRV 389 600 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 0 IN SRV 100 sauron.mordor.fan. ; ; Záznamy A s pevnou IP -> Servery blackelf.mordor.fan. 389 IN A 600 blackspider.mordor.fan. 0 IN A 100 darklord.mordor.fan. 88 IN A 600 mamba.mordor.fan. 0 IN A 100 palantir.mordor.fan. 88 IN A 600 sauron.mordor.fan. 0 IN A 100 shadowftp.mordor.fan. 464 IN A 600 troll.mordor.fan. 0 IN A 100; ; CNAME zaznamenává ad-dc.mordor.fan. 88 V CNAME sauron.mordor.fan. blog.mordor.fan. 600 V CNAME troll.mordor.fan. fileserver.mordor.fan. 0 V CNAME mamba.mordor.fan. ftpserver.mordor.fan. 100 V CNAME shadowftp.mordor.fan. mail.mordor.fan. 464 V CNAME balckelf.mordor.fan. openfire.mordor.fan. 3600 V CNAME palantir.mordor.fan. proxy.mordor.fan. 10.10.10.9 V CNAME darklord.mordor.fan. www.mordor.fan. 3600 V CNAME blackspider.mordor.fan.

Záznamy RR z původní zóny 10.10.10.in-addr.arpa

buzz @ sysadmin: ~ $ cat temp / rrs.10.10.10.in-addr.arpa 
; Pokud jde o SOA a NS 10.10.10.in-addr.arpa. 3600 V SOA sauron.mordor.fan. hostmaster.mordor.fan. 21 900 600 86400 3600 10.10.10.in-addr.arpa. 3600 IN NS sauron.mordor.fan. ; ; Záznamy PTR 10.10.10.10.in-addr.arpa. 3600 IN PTR blackspider.mordor.fan. 11.10.10.10.in-addr.arpa. 3600 IN PTR palantir.mordor.fan. 3.10.10.10.in-addr.arpa. 3600 V PTR sauron.mordor.fan. 4.10.10.10.in-addr.arpa. 3600 V PTR mamba.mordor.fan. 5.10.10.10.in-addr.arpa. 3600 V 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 V 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.

Až do tohoto okamžiku si můžeme myslet, že máme data potřebná k pokračování našeho dobrodružství, ale ne dříve, než pozorujeme TTL a další data, která nám velmi stručně poskytují výstup a přímé pozorování DNS Microsft® Active Directory® 2008 SR2 64 bitů.

Obrázky správce DNS v programu SAURON

Tým Dnslinux.mordor.fan.

Pokud se podíváme pozorně, na IP adresu 10.10.10.5 nebylo mu přiděleno žádné jméno přesně, aby bylo obsazeno jménem nového DNS dnslinux.mordor.fan. K instalaci páru DNS a DHCP se můžeme řídit články DNS a DHCP v Debianu 8 „Jessie“ y DNS a DHCP na CentOS 7.

Základní operační systém

Můj přítel FuegianKromě toho, že je skutečným specialistou na Microsoft® Windows - má několik certifikátů vydaných touto společností - přečetl si a uvedl do praxe některé články o počítačích publikované v DesdeLinux… a řekl mi, že výslovně chce řešení založené na Debianu. 😉

Abychom vás potěšili, začneme s čerstvou a čistou instalací serveru založeného na Debian 8 „Jessie“. To, co napíšeme dále, však platí pro distribuce CentOS a openSUSE, jejichž články jsme zmínili dříve. BIND a DHCP jsou stejné u všech distribucí. Mírné variace zavádějí správci balíků v každé distribuci.

Provedeme instalaci, jak je uvedeno v DNS a DHCP v Debianu 8 „Jessie“, dbejte na používání IP 10.10.10.5 a síť 10.10.10.0/24., ještě před konfigurací BIND.

Nakonfigurujeme BIND ve stylu Debianu

/etc/bind/named.conf

Soubor /etc/bind/named.conf necháme to tak, jak je nainstalováno.

/etc/bind/named.conf.options

Soubor /etc/bind/named.conf.options by měl zůstat s následujícím obsahem:

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

root @ dnslinux: ~ # nano /etc/bind/named.conf.options
volby {adresář "/ var / cache / bind"; // Pokud mezi vámi a jmennými servery, se kterými chcete // mluvit, je brána firewall, bude pravděpodobně nutné bránu firewall opravit, aby bylo možné hovořit více // portů. Viz http://www.kb.cert.org/vuls/id/800113 // Pokud váš ISP poskytl jednu nebo více IP adres pro stabilní // jmenné servery, pravděpodobně je budete chtít použít jako forwardery. // Odkomentujte následující blok a vložte adresy, které nahradí // zástupný symbol všech 0. // vyvážecí vozy {// 0.0.0.0; //}; // ================================================ ====================== $ // Pokud BIND zaznamená chybové zprávy o vypršení platnosti kořenového klíče, // budete muset aktualizovat své klíče. Viz https://www.isc.org/bind-keys // ================================== ==================================== $

    // Nechceme DNSSEC
        dnssec-povolit ne;
        //dnssec-validation auto;

        auth-nxdomain no; # odpovídá RFC1035

 // Nepotřebujeme poslouchat adresy IPv6
        // listen-on-v6 {any; };
    listen-on-v6 {none; };

 // Pro kontroly od localhost a sysadmin
    // přes // dig mordor.fan axfr // dig 10.10.10.in-addr.arpa axfr // dig _msdcs.mordor.fan axfr // Nemáme Slave DNS ... až dosud
 allow-transfer {localhost; 10.10.10.1; };
};

// Protokolování BIND
protokolování {

        dotazy kanálu {
        soubor "/var/log/named/queries.log" verze 3 velikost 1m;
        informace o závažnosti;
        doba tisku ano;
        závažnost tisku ano;
        print-category ano;
        };

        chyba dotazu kanálu {
        soubor "/var/log/named/query-error.log" verze 3 velikost 1m;
        informace o závažnosti;
        doba tisku ano;
        závažnost tisku ano;
        print-category ano;
        };

                                
dotazy kategorie {
         dotazy;
         };

kategorie dotaz-chyby {
         chyba dotazu;
         };

};

• Zachycení protokolů BIND zavedeme jako a NEW vystoupení v sérii článků na toto téma. Vytvoříme lsložku a soubory potřebné pro Přihlášení BIND:

root @ dnslinux: ~ # mkdir / var / log / pojmenovaný
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

Zkontrolujeme syntaxi nakonfigurovaných souborů

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

/etc/bind/named.conf.local

Vytvoříme soubor /etc/bind/zones.rfcFreeBSD se stejným obsahem, jaký je uveden v DNS a DHCP v Debianu 8 „Jessie“.

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

Soubor /etc/bind/named.conf.local by měl zůstat s následujícím obsahem:

// // Zde proveďte libovolnou místní konfiguraci // // // Zvažte, zda sem přidat zóny 1918, pokud se ve vaší // organizaci nepoužívají
zahrnout "/etc/bind/zones.rfc1918"; zahrnout "/etc/bind/zones.rfcFreeBSD";

zóna "mordor.fan" {typ pán; soubor "/var/lib/bind/db.mordor.fan"; }; zóna "10.10.10.in-addr.arpa" {typ master; soubor "/var/lib/bind/db.10.10.10.in-addr.arpa"; };

zóna "_msdcs.mordor.fan" {typ master;
 kontrolní jména ignorovat; soubor "/etc/bind/db._msdcs.mordor.fan"; }; root @ dnslinux: ~ # named-checkconf
root @ dnslinux: ~ #

Soubor zóny mordor.fan

root @ dnslinux: ~ # nano /var/lib/bind/db.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; sériové 1D; aktualizace 1H; opakování 1W; platnost 3H); minimální nebo; Negativní doba ukládání do mezipaměti;
; BUĎTE VELMI OPATRNÍ S NÁSLEDUJÍCÍMI ZÁZNAMY
@ IN NS dnslinux.mordor.fan.
@ IN A 10.10.10.5
@ IN MX 10 blackelf.mordor.fan. @ IN TXT „Vítejte v The Dark Lan of Mordor“;
_msdcs.mordor.fan. V NS dnslinux.mordor.fan.
;
dnslinux.mordor.fan. V 10.10.10.5
; KONEC VELMI POZORNĚ S NÁSLEDUJÍCÍMI ZÁZNAMY;
DomainDnsZones.mordor.fan. V 10.10.10.3 ForestDnsZones.mordor.fan. V A 10.10.10.3; ; GLOBÁLNÍ KATALOG _gc._tcp.mordor.fan. 600 V SRV 0 0 3268 sauron.mordor.fan. _gc._tcp.Default-First-Site-Name._sites.mordor.fan. 600 V SRV 0 0 3268 sauron.mordor.fan. ; ; Upravený a soukromý LDAP Active Directory _ldap._tcp.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. ; ; Upravený a soukromý KERBEROS z Active Directory _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan. 600 V SRV 0 0 88 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 600 V SRV 0 0 88 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 600 V SRV 0 0 sauron.mordor.fan. _kerberos._udp.mordor.fan. 464 V SRV 600 0 0 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 88 V SRV 600 0 sauron.mordor.fan. ; ; Záznamy s pevnými adresami IP -> servery Blackelf.mordor.fan. V 0 blackspider.mordor.fan. V 464 darklord.mordor.fan. V 10.10.10.9 mamba.mordor.fan. V 10.10.10.10 palantir.mordor.fan. V 10.10.10.6
sauron.mordor.fan. V 10.10.10.3
shadowftp.mordor.fan. V 10.10.10.8 troll.mordor.fan. V A 10.10.10.7; ; CNAME zaznamenává ad-dc.mordor.fan. V CNAME sauron.mordor.fan. blog.mordor.fan. V CNAME troll.mordor.fan. fileserver.mordor.fan. V CNAME mamba.mordor.fan. ftpserver.mordor.fan. V CNAME shadowftp.mordor.fan. mail.mordor.fan. V CNAME balckelf.mordor.fan. openfire.mordor.fan. V CNAME palantir.mordor.fan. proxy.mordor.fan. V CNAME darklord.mordor.fan. www.mordor.fan. V CNAME blackspider.mordor.fan.

root @ dnslinux: ~ # named-checkzone mordor.fan /var/lib/bind/db.mordor.fan 
zóna mordor.fan/IN: načten sériový 1 OK

Časy 600 TTL ze všech registrů SRV je uchováme pro případ, že v nejbližší době nainstalujeme Slave BIND. Tyto záznamy představují služby Active Directory®, které většinou čtou data z vaší databáze LDAP. Protože se tato databáze často mění, musí být časy synchronizace udržovány krátké, ve schématu DNS typu Master - Slave. Podle filozofie společnosti Microsoft pozorované od služby Active Directory 2000 až 2008 je pro tyto typy záznamů SRV zachována hodnota 600.

L TTL serverů s pevnou IP, jsou pod deklarovaným časem v SOA 3 hodiny.

Soubor zóny 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; sériové 1D; aktualizace 1H; opakování 1W; platnost 3H); minimální nebo; Negativní doba ukládání do mezipaměti; @ IN NS dnslinux.mordor.fan. ; 10 V PTR blackspider.mordor.fan. 11 IN PTR palantir.mordor.fan. 3 V PTR sauron.mordor.fan. 4 V PTR mamba.mordor.fan. 5 IN PTR dnslinux.mordor.fan. 6 IN PTR darklord.mordor.fan. 7 IN PTR troll.mordor.fan. 8 IN PTR shadowftp.mordor.fan. 9 IN PTR blackelf.mordor.fan.

root @ dnslinux: ~ # named-checkzone 10.10.10.in-addr.arpa /var/lib/bind/db.10.10.10.in-addr.arpa 
zóna 10.10.10.in-addr.arpa/IN: načten sériový 1 OK

Soubor zóny _msdcs.mordor.fan

Vezměme v úvahu, co se v souboru doporučuje /usr/share/doc/bind9/README.Debian.gz O umístění souborů hlavních zón nepodléhajících dynamickým aktualizacím pomocí DHCP.

root @ dnslinux: ~ # nano /etc/bind/db._msdcs.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; sériové 1D; obnovení 1H; opakování 1W; platnost 3H); minimální nebo; Negativní doba ukládání do mezipaměti; @ IN NS dnslinux.mordor.fan. ; ; ; GLOBÁLNÍ KATALOG gc._msdcs.mordor.fan. 600 IN A 10.10.10.3; ; Aliasy - v upravené a soukromé databázi LDAP služby Active Directory - SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 V CNAME sauron.mordor.fan. ; ; Upravený a soukromý LDAP Active Directory _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 100 IN SRV 389 sauron.mordor.fan. _ldap._tcp.600d0d-100fdb-389cf-a18-d3360c8b40d678.domains._msdcs.mordor.fan. 7 IN SRV 420 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 6 IN SRV 775 600 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 0 IN SRV 100 389 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. ; ; Modifikovaný a soukromý KERBEROS Active Directory _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 100 V SRV 3268 600 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 0 V SRV 100 3268 sauron.mordor.fan.

Zkontrolujeme syntaxi a můžeme ignorovat chybu, kterou vrací, protože v konfiguraci této zóny v souboru /etc/bind/named.conf.local zahrneme prohlášení kontrolní jména ignorovat;. Zóna bude BINDem správně načtena.

root @ dnslinux: ~ # named-checkzone _msdcs.mordor.fan /etc/bind/db._msdcs.mordor.fan 
/etc/bind/db._msdcs.mordor.fan:14: gc._msdcs.mordor.fan: špatné jméno vlastníka (kontrolní jména) zóna _msdcs.mordor.fan/IN: načten sériový 1 OK

root @ dnslinux: ~ # systemctl restart bind9.service 
root @ dnslinux: ~ # systemctl status bind9.service 
● bind9.service - BIND Domain Name Server načten: načten (/lib/systemd/system/bind9.service; povoleno) Drop-In: /run/systemd/generator/bind9.service.d └─50-insserv.conf- $ named.conf Aktivní: aktivní (běží) od ne 2017-02-12 08:48:38 EST; Před 2 s Docs: man: named (8) Process: 859 ExecStop = / usr / sbin / rndc stop (code = exited, status = 0 / SUCCESS) Main PID: 864 (named) CGroup: /system.slice/bind9.service └─864 / usr / sbin / named -f -u bind 12. února 08:48:38 dnslinux pojmenovaný [864]: zóna 3.efip6.arpa/IN: načtený seriál 1. února 12 08:48:38 dnslinux pojmenovaný [864 ]: zóna befip6.arpa/IN: načteno sériově 1 února 12 08:48:38 dnslinux pojmenováno [864]: zóna 0.efip6.arpa/IN: načteno sériově 1 února 12 08:48:38 dnslinux pojmenováno [864]: zóna 7.efip6.arpa/IN: načteno sériově 1 února 12 08:48:38 dnslinux pojmenováno [864]: zóna mordor.fan/IN: načteno sériově 1 února 12 08:48:38 dnslinux pojmenováno [864]: příklad zóny .org / IN: načtený seriál 1. února 12 08:48:38 dnslinux s názvem [864]: zóna _msdcs.mordor.fan/IN: načtený seriál 1. února 12 08:48:38 dnslinux s názvem [864]: zóna neplatná / IN : načten seriál 1. února 12 08:48:38 dnslinux s názvem [864]: všechny zóny načteny
12. února 08:48:38 dnslinux pojmenovaný [864]: běh

Konzultujeme BIND

Před Po instalaci DHCP musíme provést řadu kontrol, které zahrnují i ​​připojení klienta Windows 7 k doméně mordor.fan představovaná službou Active Directory nainstalovanou v počítači sauron.mordor.fan.

První věcí, kterou musíme udělat, je zastavit službu DNS v počítači sauron.mordor.fana ve svém síťovém rozhraní deklarujte, že od nynějška bude váš server DNS 10.10.10.5 dnslinux.mordor.fan.

V konzole samotného serveru sauron.mordor.fan provádíme:

Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. Všechna práva vyhrazena.

C: \ Users \ Administrator> nslookup
Výchozí server: dnslinux.mordor.fan Adresa: 10.10.10.5

> gc._msdcs
Server: dnslinux.mordor.fan Adresa: 10.10.10.5 Název: gc._msdcs.mordor.fan Adresa: 10.10.10.3

> mordor.fan
Server: dnslinux.mordor.fan Adresa: 10.10.10.5 Název: mordor.fan Adresa: 10.10.10.3

> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs
Server: dnslinux.mordor.fan Adresa: 10.10.10.5 Název: sauron.mordor.fan Adresa: 10.10.10.3 Aliasy: 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan

> typ sady = SRV
> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
Server: dnslinux.mordor.fan Adresa: 10.10.10.5 _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan Umístění služby SRV: priorita = 0 váha = 100 port = 88 svr název hostitele = sauron.mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan internetová adresa sauron.mordor.fan = 10.10.10.3 dnslinux.mordor.fan internetová adresa = 10.10.10.5
> _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs
Server: dnslinux.mordor.fan Adresa: 10.10.10.5 _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan Umístění služby SRV: priorita = 0 hmotnost = 100 port = 389 název hostitele svr = sauron .mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan internetová adresa = 10.10.10.3 dnslinux.mordor.fan internetová adresa = 10.10.10.5
> výstup

C: \ Users \ Administrator>

DNS dotazy z sauron.mordor.fan jsou uspokojivé.

Dalším krokem bude vytvoření dalšího virtuálního počítače s nainstalovaným Windows 7. Protože stále nemáme nainstalovanou službu DHCP, dáme počítači s názvem «win7»IP adresa 10.10.10.251. Rovněž prohlašujeme, že váš server DNS bude 10.10.10.5 dnslinux.mordor.fan, a že vyhledávací doména bude mordor.fan. Tento počítač nebudeme registrovat v DNS, protože jej po instalaci také použijeme k otestování služby DHCP.

Dále otevřeme konzolu CMD a v něm provedeme:

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Všechna práva vyhrazena.

C: \ Users \ buzz> nslookup
Výchozí server: dnslinux.mordor.fan Adresa: 10.10.10.5

> mordor.fan
Server: dnslinux.mordor.fan Adresa: 10.10.10.5 Název: mordor.fan Adresa: 10.10.10.3

> typ sady = SRV
> _ldap._tcp.DomainDnsZones
Server: dnslinux.mordor.fan Adresa: 10.10.10.5 _ldap._tcp.DomainDnsZones.mordor.fan Umístění služby SRV: priorita = 0 váha = 0 port = 389 svr název hostitele = sauron.mordor.fan mordor.fan nameserver = dnslinux.mordor internetová adresa .fan sauron.mordor.fan = 10.10.10.3 internetová adresa dnslinux.mordor.fan = 10.10.10.5
> _kpasswd._udp
Server: dnslinux.mordor.fan Adresa: 10.10.10.5 _kpasswd._udp.mordor.fan Umístění služby SRV: priorita = 0 váha = 0 port = 464 název hostitele svr = sauron.mordor.fan mordor.fan nameserver = dnslinux.mordor.fan internetová adresa sauron.mordor.fan = 10.10.10.3 internetová adresa dnslinux.mordor.fan = 10.10.10.5
> _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones
Server: dnslinux.mordor.fan Adresa: 10.10.10.5 _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan Umístění služby SRV: priorita = 0 hmotnost = 0 port = 389 svr název hostitele = sauron. mordor.fan mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan internetová adresa = 10.10.10.3 dnslinux.mordor.fan internetová adresa = 10.10.10.5
> výstup

C: \ Users \ buzz>

DNS dotazy od klienta «win7»Byly také uspokojivé.

Ve službě Active Directory vytvoříme uživatele «saruman«, S cílem použít jej při připojení ke klientovi win7 do domény mordor.fan., pomocí metody «ID sítě«, Používání uživatelských jmen saruman@mordor.fan y správce@mordor.fan. Spojení bylo úspěšné a dokazuje to následující snímek obrazovky:

O dynamických aktualizacích v Microsoft® DNS a BIND

Protože máme službu DNS zastavenou ve službě Active Directory®, nebylo možné pro klienta «win7»Zaregistrujte své jméno a IP adresu v daném DNS. Mnohem méně v dnslinux.mordor.fan protože jsme neudělali žádné prohlášení povolit aktualizaci pro kteroukoli ze zúčastněných oblastí.

A právě zde vznikl dobrý boj s mým přítelem Fuegian. Ve svém prvním e-mailu o tomto aspektu jsem komentoval:

• Články společnosti Microsoft o používání BIND a Active Directory® doporučují, aby bylo možné aktualizovat, zejména Direct Zone -pronikl- přímo klienty Windows, kteří jsou již připojeni k doméně Active Directory.
• Proto jsou ve výchozím nastavení povoleny zóny DNS služby Active Directory® Secure Dynamic Updates. klienty Windows, kteří jsou již připojeni k doméně služby Active Directory. Pokud nejsou jednotní, zdržují se následků.
• DNS služby Active Directory podporuje dynamické aktualizace „Pouze zabezpečené“, „Nezabezpečené a zabezpečené“ nebo „Žádné“, což je stejné, jako když říkáte „Žádné aktualizace“ nebo „Žádné“.
• Ano, skutečně Microsoft Philosophy nesouhlasí s tím, že její zákazníci NENÍ aktualizují svá data ve svých DNS, nenechali by otevřenou možnost deaktivace dynamických aktualizací ve svých DNS, pokud tato možnost nebude bude ponecháno pro skrytější účely.
• Microsoft nabízí „Zabezpečení“ výměnou za Darkness, jak mi řekl kolega a přítel, který prošel kurzy certifikátů Microsft®. Skutečný. El Fueguino mi to navíc potvrdilo.
• Klient, který získá adresu IP například prostřednictvím protokolu DHCP nainstalovaného na počítači se systémem UNIX® / Linux, nebude schopen zjistit adresu IP svého vlastního jména dokud nejste připojeni k doméně služby Active Directory, pokud je Microsoft® nebo BIND používán jako DNS bez dynamických aktualizací pomocí DHCP.
• Pokud nainstaluji DHCP do samotné služby Active Directory®, musím prohlásit, že zóny jsou aktualizovány pomocí Microsoft® DHCP.
• Pokud budeme používat BIND jako DNS pro síť Windows, je logické a doporučujeme, abychom si nainstalovali duo BIND-DHCP, které dynamicky aktualizuje BIND a věc je uzavřena.
• Ve světě sítí LAN v systému UNIX® / Linux, protože byly vyvinuty dynamické aktualizace pro BIND, je povolen pouze pan DHCP «proniknout»Paní BIND s jejími aktualizacemi. Relaxace, která je s objednávkou, prosím.
• Když prohlásím v zóně mordor.fan např. allow-update {10.10.10.0/24; };, Sám BIND mě při spuštění nebo restartu informuje, že:

  • zóna „mordor.fan“ umožňuje aktualizace podle IP adresy, která je nezabezpečená

• V posvátném světě UNIX® / Linux je taková drzost s DNS jednoduše nepřípustná.

Dokážete si představit zbytek výměny s mým přítelem Fuegian skrz e-maily, Telegramový chat, telefonní hovory hrazené jím (samozřejmě, člověče, nemám na to kilo), a dokonce i zprávy prostřednictvím poštovních holubů ve XXI století!

Dokonce se vyhrožoval, že mi neposílá syna svého mazlíčka, jeho leguána «Petra»Že mi slíbil jako součást platby. Tam jsem se opravdu bál. Začal jsem tedy znovu, ale z jiného úhlu.

• „Téměř“ Active Directory, kterého lze dosáhnout pomocí Samba 4, řeší tento aspekt mistrovským způsobem, ať už používáme jeho interní DNS, nebo BIND kompilovaný pro podporu DLZ zón - Načtené zóny Dinamycnebo dynamicky načítané zóny.
• Stále trpí tím samým: když klient získá adresu IP prostřednictvím nainstalovaného serveru DHCP další V systému UNIX® / Linux nebudete moci zjistit IP adresu svého vlastního jména dokud se nepřipojí k doméně Samba 4 AD-DC.
• Integrujte duo BIND-DLZ a DHCP na stejný stroj, kde je AD-DC Samba 4 je to práce pro skutečného specialistu.

Fuegian Zavolal mě na kapitolu a křičel na mě: NEMÁME o AD-DC Samba 4, ale z Microsoft® Active Directory®!. A pokorně jsem odpověděl, že mě potěšila část následujících článků, které jsem chtěl napsat.

Tehdy jsem mu řekl, že konečné rozhodnutí o dynamických aktualizacích pro klientské počítače v jeho síti bylo ponecháno na jeho vlastní svobodné vůli. Že bych mu dal jen typ napsáno dříve o allow-update {10.10.10.0/24; };a ještě nic. Že jsem nebyl zodpovědný za to, co vyplynulo z té promiskuity, že každý klient Windows - nebo Linux - ve své síti «pronikne»Beztrestně pro BIND.

Kdybys věděl, příteli, čtenáři, že to byl konečný bod rvačky, nevěřil bys tomu. Můj přítel Fuegian přijal řešení - a pošle mi leguána «Pete«- to teď s vámi sdílím.

Instalujeme a konfigurujeme DHCP

Pro více informací si přečtěte DNS a DHCP v Debianu 8 „Jessie“.

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

root @ dnslinux: ~ # nano / etc / default / isc-dhcp-server .... # Na jakých rozhraních by měl server DHCP (dhcpd) sloužit požadavkům DHCP? # Oddělte více rozhraní mezerami, např. „Eth0 eth1“. ROZHRANÍ = "eth0" root @ dnslinux: ~ # dnssec-keygen -a HMAC-MD5 -b 128 -r / dev / urandom -n UŽIVATEL dhcp klíč
Klíč Kdhcp. + 157 + 29836

root @ dnslinux: ~ # cat Kdhcp-key. +157 + 29836.private
Formát soukromého klíče: v1.3 Algoritmus: 157 (HMAC_MD5) Klíč: 3HT / bg / 6YwezUShKYofj5g == Bity: AAA = Vytvořeno: 20170212205030 Publikovat: 20170212205030 Aktivovat: 20170212205030

root @ dnslinux: ~ # nano dhcp.key
key dhcp-key {algoritmus hmac-md5; tajemství "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
// // Proveďte zde jakoukoli místní konfiguraci // // Zvažte přidání zón z roku 1918, pokud se ve vaší // organizaci nepoužívají, zahrňte "/etc/bind/zones.rfc1918"; zahrnout "/etc/bind/zones.rfcFreeBSD";
// Nezapomeňte ... zapomněl jsem a zaplatil s chybami. ;-)
zahrnout "/etc/bind/dhcp.key";


zóna "mordor.fan" {typ pán;
        povolit aktualizaci {10.10.10.3; klíč dhcp-key; };
        soubor "/var/lib/bind/db.mordor.fan"; }; zóna "10.10.10.in-addr.arpa" {typ master;
        povolit aktualizaci {10.10.10.3; klíč dhcp-key; };
        soubor "/var/lib/bind/db.10.10.10.in-addr.arpa"; }; zóna "_msdcs.mordor.fan" {typ master; kontrolní jména ignorovat; soubor "/etc/bind/db._msdcs.mordor.fan"; };

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

root @ dnslinux: ~ # nano /etc/dhcp/dhcpd.conf
ddns-update-style prozatímní; ddns-aktualizace na; ddns-domainname "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; ignorovat aktualizace klienta; autoritativní; možnost přesměrování IP vypnuto; volba název domény "mordor.fan"; zahrnout "/etc/dhcp/dhcp.key"; zóna mordor.fan. {primární 127.0.0.1; klíč dhcp-key; } zóna 10.10.10.in-addr.arpa. {primární 127.0.0.1; klíč dhcp-key; } redlocal sdílené sítě {podsíť 10.10.10.0 síťová maska ​​255.255.255.0 {volitelné směrovače 10.10.10.1; volitelná maska ​​podsítě 255.255.255.0; možnost broadcast-address 10.10.10.255; volba domain-name-servery 10.10.10.5; volba netbios-name-servery 10.10.10.5; rozsah 10.10.10.30 10.10.10.250; }} # END dhcpd.conf

root @ dnslinux: ~ # dhcpd -t
Konsorcium internetových systémů DHCP Server 4.3.1 Copyright 2004-2014 Konsorcium internetových systémů. Všechna práva vyhrazena. Informace najdete na https://www.isc.org/software/dhcp/ konfigurační soubor: /etc/dhcp/dhcpd.conf databázový soubor: /var/lib/dhcp/dhcpd.leases PID soubor: / 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

S čím souvisí Kontroly s klienty, A Ruční úprava souborů zóny, necháme to na vás, příteli čtenáři, abyste si je mohli přečíst přímo z DNS a DHCP v Debianu 8 „Jessie“, a použít jej na vaše skutečné podmínky. Provedli jsme všechny nezbytné kontroly a získali uspokojivé výsledky. Samozřejmě jim pošleme kopii všech Fuegian. Už nebudou!

Tipy

Obecný

• Než začnete, získejte hodně trpělivosti.
  
• Nejprve nainstalujte a nakonfigurujte BIND. Zkontrolujte vše a podívejte se na všechny záznamy, které jste deklarovali v každém souboru tří nebo více zón, a to jak ze služby Active Directory, tak ze samotného serveru DNS v systému Linux. Pokud je to možné, ze stroje se systémem Linux, který není připojen k doméně, proveďte potřebné dotazy DNS na BIND.
  
• Připojte se ke klientovi Windows s pevnou IP adresou k existující doméně a znovu zkontrolujte všechna nastavení BIND z klienta Windows.
• Poté, co jste si nepochybně jisti, že konfigurace vašeho zcela nového BINDu je zcela správná, odvážte se nainstalovat, nakonfigurovat a spustit službu DHCP.
• V případě chyb opakujte celý postup od nuly 0.
• Při kopírování a vkládání buďte opatrní! a zbývající mezery v každém řádku souborů named.conf.xxxx
  
• Poté si nestěžoval - natož mému příteli Fuegianovi -, že mu nebylo řádně doporučeno.

Další tipy

• Rozděl a panuj.
• V síti SME je bezpečnější a výhodnější nainstalovat autoritativní BIND pro interní zóny LAN, který se neopakuje na žádném kořenovém serveru: rekurze ne;.
• V síti SME umístěné pod poskytovatelem přístupu k internetu - ISPmožná služby Zástupce y SMTP potřebují vyřešit názvy domén na internetu. On Oliheň máte možnost deklarovat svůj DNS jako externí nebo ne, pokud jste na poštovním serveru založeném na Postfix o MDaemon® Můžeme také deklarovat servery DNS, které v této službě použijeme. V takových případech, tj. V případech, které neposkytují služby na internetu a které spadají pod a Poskytovatelé internetu, můžete nainstalovat BIND s Dopravci ukazuje na DNS serveru ISPa deklarovat jej jako sekundární DNS na serverech, které potřebují vyřešit externí dotazy do LAN, jinak je možné je deklarovat prostřednictvím vlastních konfiguračních souborů.
• Pokud máte delegovanou zónu pod plnou odpovědnostíPak další kohoutí vrána:
  • Nainstalujte server DNS na základě NSD, což je podle definice autoritativní server DNS, který odpovídá na dotazy z počítačů v Internetu. Pro nějaké informace schopnost ukázat nsd. 😉 Chraňte jej prosím velmi dobře tolika požárními zdmi, kolik je potřeba. Hardware i software. Bude to DNS pro internet a ten «Car»Nesmíme to dávat s nízkými kalhotami. 😉
  • Protože jsem se nikdy v takovém případě, tj. Osobě odpovědné za Delegovanou zónu, neviděl, musel bych velmi dobře přemýšlet, co doporučit pro řešení doménových jmen mimo naši LAN pro služby, které to potřebují. Klienti sítě SME to opravdu nepotřebují. Konzultujte odbornou literaturu nebo odborníka na tyto předměty, protože ani zdaleka nejsem jedním z nich. Vážně.
  • Rekurze na autoritářských serverech neexistuje. Dobře?. Pro případ, že by to někdo udělal s BIND.
• I když v souboru výslovně specifikujeme /etc/dhcp/dhcpd.conf prohlášení ignorovat aktualizace klienta;, pokud běžíme na počítačové konzole dnslinux.mordor.fan objednávka journalctl -f, uvidíme, že při spuštění klienta win7.mordor.fan dostáváme následující chybové zprávy:

  • 12. února 16:55:41 dnslinux s názvem [900]: klient 10.10.10.30 # 58762: aktualizace 'mordor.fan/IN' zamítnuta
    12. února 16:55:42 dnslinux s názvem [900]: klient 10.10.10.30 # 49763: aktualizace 'mordor.fan/IN' zamítnuta
    12. února 16:56:23 dnslinux s názvem [900]: klient 10.10.10.30 # 63161: aktualizace 'mordor.fan/IN' zamítnuta
    

  • Abychom tyto zprávy vyloučili, musíme přejít na pokročilé možnosti konfigurace síťové karty a zrušit zaškrtnutí možnosti «Zaregistrujte adresy tohoto připojení v DNS«. To zabrání tomu, aby se klient navždy pokusil o vlastní registraci v systému Linux DNS, a problém končí. Lituji, ale nemám kopii systému Windows 7 ve španělštině. 😉
• Chcete-li zjistit všechny vážné - a šílené - dotazy, které klient Windows 7 dělá, podívejte se na log dotazy.log že pro něco to deklarujeme v konfiguraci BIND. Objednávka by byla:

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

• Pokud svým klientským počítačům neumožňujete přímé připojení k internetu, proč potřebujete kořenové servery DNS? Tím se výrazně sníží výkon příkazu journalctl -f a z předchozího, pokud se váš autoritářský server DNS pro interní zóny nepřipojuje přímo k internetu, což je z bezpečnostního hlediska velmi doporučeno.

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

• Pokud nepotřebujete deklaraci kořenových serverů, tak proč potřebujete rekurzi - Rekurze?

  root @ dnslinux: ~ # nano /etc/bind/named.conf.options
  možnosti {
   ....
   rekurze ne;
   ....
  };

Konkrétní rady, z nichž stále nejsem příliš jasný

El muž dhcpd.conf mezi mnoha jinými nám říká:

        Prohlášení o optimalizaci aktualizace

            příznak optimalizace aktualizace;

            Pokud je parametr optimalizace aktualizace pro daného klienta nepravdivý, pokusí se server o aktualizaci DNS pro tohoto klienta pokaždé, když klient obnoví svůj nájem, spíše než o pokus o aktualizaci, až když to bude nutné. To umožní DNS snadněji se vyléčit z nekonzistencí databáze, ale cena spočívá v tom, že server DHCP musí provádět mnohem více aktualizací DNS. Tuto možnost doporučujeme číst povolenou, což je výchozí nastavení. Tato možnost ovlivňuje pouze chování prozatímního schématu aktualizace DNS a nemá žádný vliv na schéma aktualizace DNS ad-hoc. Pokud tento parametr není zadán nebo má hodnotu true, server DHCP se aktualizuje, pouze když se změní informace o klientovi, klient získá jiný nájem nebo vyprší jeho nájem.

Více či méně přesný překlad nebo tlumočení je ponecháno na vás, milý čtenáři.

Osobně se mi stalo - a stalo se to během vytváření tohoto článku - že když propojím BIND s Active Directory®, je to z Microsft® nebo Samba 4, pokud změním název klientského počítače registrovaného v doméně Active Directory® nebo AD–DC Samba 4, uchovává svůj starý název a IP adresu v přímé zóně, a ne naopak, která je správně aktualizována novým názvem. Jinými slovy, staré a nové názvy jsou namapovány na stejnou adresu IP v přímé zóně, zatímco naopak se zobrazí pouze nový název. Abyste mi dobře porozuměli, musíte to zkusit sami.

Myslím, že je to druh pomsty Fuegian - ne pro mě, prosím - za pokus o migraci vašich služeb na Linux.

Staré jméno samozřejmě zmizí, až bude 3600 TTLnebo čas, který jsme deklarovali v konfiguraci DHCP. Chceme však, aby to okamžitě zmizelo, jak se to stane v BIND + DHCP bez služby Active Directory přes.

Řešení této situace jsem našel vložením prohlášení aktualizace-optimalizace false; na konci horní části souboru /etc/dhcp/dhcpd.conf:

ddns-update-style prozatímní; ddns-aktualizace na; ddns-domainname "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; ignorovat aktualizace klienta;
aktualizace-optimalizace false;

Pokud o tom některý čtenář ví víc, osvětlete mě. Hodně si toho vážím.

Shrnutí

S tématem jsme si užili spoustu legrace, že? Žádné utrpení, protože máme BIND pracující jako server DNS v síti Microsoft®, nabízející všechny záznamy SRV a odpovídajícím způsobem reagovat na dotazy DNS, které jim byly poskytnuty. Na druhou stranu máme server DHCP, který přiděluje adresy IP a dynamicky správně aktualizuje zóny BIND.

Ale nemůžeme se zeptat ... pro tuto chvíli.

Doufám, příteli Fuegian buďte šťastní a spokojení s prvním krokem při migraci na Linux, aby byly nesnesitelné náklady na technickou podporu Microsft® snesitelné.

Důležitá poznámka

Znak "Fuegian»Je zcela fiktivní a je výsledkem mé fantazie. Jakákoli podobnost nebo náhoda se skutečnými lidmi je stejná: čistá nedobrovolná náhoda z mé strany. Vytvořil jsem ho jen proto, aby bylo psaní a čtení tohoto článku trochu příjemné. Nyní, pokud mi můžete říct, že problém s DNS je temný,