BIND și Active Directory® - Rețele IMM-uri

Indice general al seriei: Rețele de calculatoare pentru IMM-uri: Introducere

Bună prieteni!. Obiectivul principal al acestui articol este să arătăm cum putem integra serviciul DNS bazat pe BIND9 într-o rețea Microsoft, care este foarte comună în multe IMM-uri.

Devine din cererea oficială a unui prieten care locuiește în La Tierra del Fuego –Fuegianul– specializat în rețele Microsoft® -Certificate incluse- pentru a vă ghida în această parte a migrării serverelor dumneavoastră către Linux. Costurile de suport Tehnicianul care plătește Microsoft® este deja Insuportabil pentru Compania la care lucrează și a cărui acționar este principal.

Prietenul meu Fuegianul are un simț al umorului și, de când a văzut seria a trei filme «Domnul inelelor» a fost captivat de multe dintre numele personajelor sale întunecate. Așadar, dragă cititor, nu fi surprins de numele domeniului tău și ale serverelor acestuia.

Pentru nou-veniți la subiect, înainte de a continua lectura, vă recomandăm să citiți și să studiați cele trei articole anterioare despre SME Networks:

• DNS și DHCP în openSUSE 13.2 „Arlequin”
• DNS și DHCP pe CentOS 7
• DNS și DHCP în Debian 8 „Jessie”

E ca și cum ai viziona trei din cele patru părți din «Lumea interlopă»Publicat până astăzi și că acesta este al patrulea.

Parametri generali

După mai multe schimburi prin e-mail, am devenit în cele din urmă clar despre principalii parametri ai rețelei sale actuale, care sunt:

Nume domeniu mordor.fan LAN Network 10.10.10.0/24 ======================================== ======================================= Servere Adresă IP Scop (Servere cu sistem de operare Windows) ==================================================== ============================ sauron.mordor.fan. 10.10.10.3 Active Directory® 2008 SR2 mamba.mordor.fan. 10.10.10.4 Server de fișiere Windows darklord.mordor.fan. 10.10.10.6 Proxy, gateway și firewall pe Kerios troll.mordor.fan. 10.10.10.7 Blog bazat pe ... nu-mi amintesc shadowftp.mordor.fan. 10.10.10.8 Server FTP blackelf.mordor.fan. 10.10.10.9 Serviciu complet de e-mail blackspider.mordor.fan. 10.10.10.10 WWW service palantir.mordor.fan. 10.10.10.11 Chat pe Openfire pentru Windows

Am cerut permisiunea să Fuegianul să stabilesc cât mai multe Aliasuri necesare pentru a-mi limpezi mintea și mi-a dat permisiunea lui:

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

Am declarat toate înregistrările DNS importante în instalarea mea a unui Windows 2008 Active Directory pe care am fost obligat să îl implementez pentru a mă ghida în pregătirea acestei postări.

Despre înregistrările SRV DNS Active Directory

Registrele SRV o Localizatoarele de servicii - utilizate pe scară largă în Microsoft Active Directory - sunt definite în Cerere de comentarii RFC 2782. Acestea permit localizarea unui serviciu bazat pe protocolul TCP/IP printr-o interogare DNS. De exemplu, un client dintr-o rețea Microsoft poate localiza locația controlerelor de domeniu - Controlere de domeniu care furnizează serviciul LDAP prin protocolul TCP prin portul 389 printr-o singură interogare DNS.

Este normal ca în păduri - Pădurile, și copaci - Copaci dintr-o rețea Microsoft mare există mai multe controlere de domeniu. Prin utilizarea înregistrărilor SRV în diferitele Zone care alcătuiesc Spațiul Nume de Domeniu al acelei Rețele, putem menține o Listă de Servere care oferă servicii similare binecunoscute, ordonate după preferință în funcție de protocolul de transport și portul fiecăruia dintre servere.

În Cerere de comentarii RFC 1700 Sunt definite denumirile simbolice universale pentru serviciile cunoscute - Serviciu bine cunoscutși nume precum «_telnet""_smtp»Pentru servicii Telnet y SMTP. Dacă nu este definit un nume simbolic pentru un serviciu binecunoscut, se poate folosi un nume local sau un alt nume în funcție de preferințele utilizatorului.

Scopul fiecărui câmp «special» care este utilizat în declarația unei înregistrări de resurse SRV este următorul:

• domeniu: "Pdc._msdcs.mordor.fan.«. Numele DNS al serviciului la care se referă înregistrarea SRV. Numele DNS din exemplu înseamnă -mai mult sau mai puțin- Controler de domeniu principal a zonei _msdcs.mordor.fan.
• serviciu: „_Ldap”. Numele simbolic al serviciului furnizat definit în conformitate cu Cerere de comentarii RFC 1700.
• Protocol: „_Tcp”. Indică tipul protocolului de transport. De obicei, pot lua valorile _tcp o _udp, deși -și de fapt- orice tip de protocol de transport indicat în Cerere de comentarii RFC 1700. De exemplu, pentru un serviciu Chat bazat pe protocol XMPP, acest câmp ar avea valoarea de _xmpp.
• Prioritate"0«. Declarați prioritatea sau preferința pentru Gazdă care oferă acest serviciu pe care o vom vedea mai târziu. Interogările DNS ale clientului pentru serviciul definit de această înregistrare SRV, la primirea răspunsului corespunzător, vor încerca să contacteze prima gazdă disponibilă cu cel mai mic număr listat în câmp. Prioritate. Intervalul de valori pe care acest câmp îl poate lua este 0 65535.
• Greutate"100«. Poate fi utilizat în combinație cu Prioritate pentru a oferi un mecanism de echilibrare a sarcinii atunci când există mai multe servere care oferă același serviciu. O înregistrare SRV similară ar trebui să existe pentru fiecare server din fișierul Zone, cu numele declarat în câmp Gazdă care oferă acest serviciu. Înainte de servere cu valori egale în teren Prioritate, valoarea câmpului Greutate poate fi folosit ca un nivel suplimentar de preferință pentru a obține selecția exactă a serverului pentru echilibrarea încărcăturii. Intervalul de valori pe care acest câmp îl poate lua este 0 65535. Dacă echilibrarea încărcăturii nu este necesară, de exemplu ca în cazul unui singur server, se recomandă alocarea valorii 0 pentru a face înregistrarea SRV mai ușor de citit.
• Număr port - Port"389«. Număr port în Gazdă care oferă acest serviciu care furnizează serviciul indicat în câmp serviciu. Numărul de port recomandat pentru fiecare tip de serviciu binecunoscut este indicat pe Cerere de comentarii RFC 1700, deși poate lua o valoare între 0 65535 și.
• Gazdă care oferă acest serviciu - Țintă"sauron.mordor.fan.«. Specifică FQDN care identifică fără echivoc pe gazdă care furnizează serviciul indicat de înregistrarea SRV. Este necesar un tip de „înregistrare”.A»În spațiul de nume al domeniului pentru fiecare FQDN de pe server sau gazdă care oferă serviciul. Mai simplu, o înregistrare de tip A în zona (zonele) directă (e).
  • Nota:
    Pentru a indica cu autoritate că serviciul specificat de înregistrarea SRV nu este furnizat pe această gazdă, un singur (.) punct.

Vrem doar să repetăm ​​că funcționarea corectă a unei rețele sau a unui Active Directory® se bazează enorm pe funcționarea corectă a Serviciului de nume de domeniu..

Înregistrări DNS Active Directory

Pentru a crea Zonele noului Server DNS bazat pe BIND, trebuie să obținem toate înregistrările DNS din Active Directory®. Pentru a ne ușura viața, să mergem la echipă sauron.mordor.fan -Active Directory® 2008 SR2- iar în Consola de Administrare DNS activăm Zone Transfer -direct și invers- pentru principalele zone declarate în acest tip de serviciu, care sunt:

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

Odată ce pasul anterior a fost efectuat și de preferință de pe un computer Linux a cărui adresă IP se află în intervalul subrețelei utilizate de rețeaua Windows, executăm:

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

• Reamintim din articolele anterioare că adresa IP a dispozitivului administrator de sistem.desdelinux.ventilator este 10.10.10.1 sau 192.168.10.1.

În cele trei comenzi anterioare putem elimina opțiunea 10.10.10.3 -întrebați serverul DNS cu acea adresă- dacă declarăm în dosar /etc/resolv.conf la adresa IP a serverului sauron.mordor.fan:

buzz@sysadmin:~$ cat /etc/resolv.conf 
# Generated by NetworkManager
search desdelinux.fan
nameserver 192.168.10.5
nameserver 10.10.10.3

După editarea cu grijă extremă, așa cum corespunde oricărui fișier de zonă BIND, vom obține următoarele date:

Înregistrări RR din zona originală _msdcs.mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs._msdcs.mordor.fan 
; În legătură cu SOA și NS _msdcs.mordor.fan. 3600 IN SOA sauron.mordor.fan. hostmaster.mordor.fan. 12 900 600 86400 3600 _msdcs.mordor.fan. 3600 IN NS sauron.mordor.fan. ; ; CATALOG GLOBAL gc._msdcs.mordor.fan. 600 IN A 10.10.10.3; ; Aliasuri -n baza de date LDAP modificată și privată a unui Active Directory- a SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 IN CNAME sauron.mordor.fan. ; ; LDAP modificat și privat al unui Active Directory _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. ; ; KERBEROS modificat și privat dintr-un Active Directory _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan.

Înregistrări RR din zona originală mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs.mordor.fan 
; În legătură cu înregistrările SOA, NS, MX și A pe care le mapează; numele de domeniu la adresa IP a SAURON; Lucruri dintr-un Active Directory mordor.fan. 3600 IN SOA sauron.mordor.fan. hostmaster.mordor.fan. 48 900 600 86400 3600 mordor.fan. 600 IN A 10.10.10.3 mordor.fan. 3600 IN NS sauron.mordor.fan. mordor.fan. 3600 IN MX 10 blackelf.mordor.fan. _msdcs.mordor.fan. 3600 IN NS sauron.mordor.fan. ; ; De asemenea, o înregistrare importantă DomainDnsZones.mordor.fan. 600 IN A 10.10.10.3 ForestDnsZones.mordor.fan. 600 IN A 10.10.10.3; ; CATALOG GLOBAL _gc._tcp.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _gc._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. ; ; LDAP modificat și privat al unui Active Directory _ldap._tcp.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. ; ; KERBEROS modificat și privat al unui Active Directory _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 600 IN SRV 0 100 464 sauron.mordor.fan. _kerberos._udp.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 600 IN SRV 0 100 464 sauron.mordor.fan. ; ; Înregistrează A cu IP fix -> Servere blackelf.mordor.fan. 3600 IN A 10.10.10.9 blackspider.mordor.fan. 3600 IN A 10.10.10.10 darklord.mordor.fan. 3600 IN A 10.10.10.6 mamba.mordor.fan. 3600 IN A 10.10.10.4 palantir.mordor.fan. 3600 IN A 10.10.10.11 sauron.mordor.fan. 3600 ÎN A 10.10.10.3 shadowftp.mordor.fan. 3600 IN A 10.10.10.8 troll.mordor.fan. 3600 ÎN A 10.10.10.7; ; CNAME înregistrează ad-dc.mordor.fan. 3600 IN CNAME sauron.mordor.fan. blog.mordor.fan. 3600 IN CNAME troll.mordor.fan. fileserver.mordor.fan. 3600 IN CNAME mamba.mordor.fan. ftpserver.mordor.fan. 3600 IN CNAME shadowftp.mordor.fan. mail.mordor.fan. 3600 IN CNAME balckelf.mordor.fan. openfire.mordor.fan. 3600 IN CNAME palantir.mordor.fan. proxy.mordor.fan. 3600 IN CNAME darklord.mordor.fan. www.mordor.fan. 3600 IN CNAME blackspider.mordor.fan.

Înregistrări RR din zona originală 10.10.10.in-addr.arpa

buzz @ sysadmin: ~ $ cat temp / rrs.10.10.10.in-addr.arpa 
; În legătură cu SOA și NS 10.10.10.in-addr.arpa. 3600 IN SOA sauron.mordor.fan. hostmaster.mordor.fan. 21 900 600 86400 3600 10.10.10.in-addr.arpa. 3600 IN NS sauron.mordor.fan. ; ; Înregistrări PTR 10.10.10.10.in-addr.arpa. 3600 IN PTR blackspider.mordor.fan. 11.10.10.10.in-addr.arpa. 3600 IN PTR palantir.mordor.fan. 3.10.10.10.in-addr.arpa. 3600 IN PTR sauron.mordor.fan. 4.10.10.10.in-addr.arpa. 3600 IN PTR mamba.mordor.fan. 5.10.10.10.in-addr.arpa. 3600 IN PTR dnslinux.mordor.fan. 6.10.10.10.in-addr.arpa. 3600 IN PTR darklord.mordor.fan. 7.10.10.10.in-addr.arpa. 3600 IN PTR troll.mordor.fan. 8.10.10.10.in-addr.arpa. 3600 IN PTR shadowftp.mordor.fan. 9.10.10.10.in-addr.arpa. 3600 IN PTR blackelf.mordor.fan.

Până în acest punct ne putem gândi că avem datele necesare pentru a continua aventura noastră, dar nu înainte de a observa TTL-uri și alte date care sunt furnizate foarte concis de ieșirea și observarea directă a DNS-ului unui Active Directory® 2008 SR2 Microsft® pe 64 de biți.

Imagini ale Managerului DNS din SAURON

Echipa Dnslinux.mordor.fan.

Dacă ne uităm atent, la adresa IP 10.10.10.5 Nu i s-a atribuit niciun nume, astfel încât să fie ocupat tocmai de numele noului DNS dnslinux.mordor.fan. Pentru a instala perechea DNS și DHCP putem fi ghidați de articole DNS și DHCP în Debian 8 „Jessie” y DNS și DHCP pe CentOS 7.

Sistem de operare de bază

Prietenul meu Fuegianul, pe langa faptul ca este un adevarat specialist in Microsoft® Windows - are cateva Certificate emise de firma respectiva - a citit si pus in practica cateva dintre articolele despre desktop-uri publicate in DesdeLinux. și mi-a spus că vrea în mod specific o soluție bazată pe Debian. 😉

Pentru a vă mulțumi, vom începe cu o instalare nouă, curată, a unui server bazat pe Debian 8 "Jessie". Totuși, ceea ce vom scrie mai jos este valabil pentru distribuțiile CentOS și openSUSE ale căror articole le-am menționat anterior. BIND și DHCP sunt aceleași pe orice distribuție. Ușoare variații sunt introduse de menținătorii de pachete în fiecare distribuție.

Instalarea o vom face conform indicațiilor din DNS și DHCP în Debian 8 „Jessie”, având grijă să utilizați IP 10.10.10.5 și rețeaua 10.10.10.0/24., chiar înainte de configurarea BIND.

Configurăm BIND în stil Debian

/etc/bind/named.conf

Dosarul /etc/bind/named.conf îl lăsăm așa cum este instalat.

/etc/bind/named.conf.options

Dosarul /etc/bind/named.conf.options ar trebui să rămână cu următorul conținut:

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

root @ dnslinux: ~ # nano /etc/bind/named.conf.options
opțiuni {director "/ var / cache / bind"; // Dacă există un firewall între dvs. și serverele de nume cu care doriți // să vorbiți, poate fi necesar să reparați firewall-ul pentru a permite // porturilor multiple să vorbească. Consultați http://www.kb.cert.org/vuls/id/800113 // Dacă ISP-ul dvs. a furnizat una sau mai multe adrese IP pentru // servere de nume stabile, probabil că doriți să le utilizați ca expeditori. // Decomentați următorul bloc și introduceți adresele înlocuind // substituentul all-0. // expeditori {// 0.0.0.0; //}; // ================================================ ===================== $ // Dacă BIND înregistrează mesaje de eroare despre cheia rădăcină expirată, // va trebui să vă actualizați cheile. Vezi https://www.isc.org/bind-keys // ================================== =================================== $

    // Nu vrem DNSSEC
        dnssec-enable nu;
        //dnssec-validare auto;

        auth-nxdomain nu; # conform cu RFC1035

 // Nu este nevoie să ascultăm adresele IPv6
        // listen-on-v6 {any; };
    listen-on-v6 {none; };

 // Pentru verificări de la localhost și sysadmin
    // prin // dig mordor.fan axfr // dig 10.10.10.in-addr.arpa axfr // dig _msdcs.mordor.fan axfr // Nu avem Slave DNS... până acum
 allow-transfer {localhost; 10.10.10.1; };
};

// Înregistrare BIND
Logare {

        interogări de canal {
        fișierul "/var/log/named/queries.log" versiuni 3 dimensiune 1m;
        informații despre severitate;
        timp de imprimare da;
        tipar-severitate da;
        print-category da;
        };

        eroare de interogare a canalului {
        fișierul "/var/log/named/query-error.log" versiuni 3 dimensiune 1m;
        informații despre severitate;
        timp de imprimare da;
        tipar-severitate da;
        print-category da;
        };

                                
interogări de categorie {
         întrebări;
         };

categorie interogare-erori {
         interogare-eroare;
         };

};

• Introducem captura jurnalelor BIND ca NEW apariția în seria de articole pe această temă. Creăm lun dosar și fișiere necesare pentru Exploatari forestiere de 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

Verificăm sintaxa fișierelor configurate

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

/etc/bind/named.conf.local

Creăm fișierul /etc/bind/zones.rfcFreeBSD cu același conținut indicat în DNS și DHCP în Debian 8 „Jessie”.

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

Dosarul /etc/bind/named.conf.local ar trebui să rămână cu următorul conținut:

// // Faceți orice configurație locală aici // // Luați în considerare adăugarea zonelor 1918 aici, dacă acestea nu sunt utilizate în // organizația dvs.
includeți „/etc/bind/zones.rfc1918”; includeți „/etc/bind/zones.rfcFreeBSD”;

zone "mordor.fan" { tip master; fișierul „/var/lib/bind/db.mordor.fan”; }; zona "10.10.10.in-addr.arpa" { tip master; fișierul „/var/lib/bind/db.10.10.10.in-addr.arpa”; };

zona "_msdcs.mordor.fan" {tip master;
 numele-verifica ignorate; fișierul „/etc/bind/db._msdcs.mordor.fan”; }; root@dnslinux:~# named-checkconf
root @ dnslinux: ~ #

Zone File mordor.fan

root @ dnslinux: ~ # nano /var/lib/bind/db.mordor.fan
$TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. ( 1 ; serial 1D ; reîmprospătare 1H ; reîncercați 1W ; expirare 3H ) ; minim sau ; Timp negativ de stocare în cache;
; FII FOARTE ATENȚIONANT CU URMĂTOARELE ÎNREGISTRĂRI
@ IN NS dnslinux.mordor.fan.
@ ÎN A 10.10.10.5
@ IN MX 10 blackelf.mordor.fan. @ IN TXT „Bine ați venit în The Dark Lan of Mordor” ;
_msdcs.mordor.fan. IN NS dnslinux.mordor.fan.
;
dnslinux.mordor.fan. ÎN A 10.10.10.5
; ÎNCHEIEȚI FOARTE ATENȚIONAL CU URMĂTOARELE DOCUMENTE;
DomainDnsZones.mordor.fan. ÎN A 10.10.10.3 ForestDnsZones.mordor.fan. ÎN A 10.10.10.3; ; CATALOG GLOBAL _gc._tcp.mordor.fan. 600 IN SRV 0 0 3268 sauron.mordor.fan. _gc._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 0 3268 sauron.mordor.fan. ; ; LDAP modificat și privat al unui Active Directory _ldap._tcp.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. ; ; KERBEROS modificat și privat al unui Active Directory _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 0 88 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 600 IN SRV 0 0 88 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 600 IN SRV 0 0 464 sauron.mordor.fan. _kerberos._udp.mordor.fan. 600 IN SRV 0 0 88 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 600 IN SRV 0 0 464 sauron.mordor.fan. ; ; Înregistrează A cu IP fix -> Servere blackelf.mordor.fan. ÎN A 10.10.10.9 blackspider.mordor.fan. ÎN A 10.10.10.10 darklord.mordor.fan. ÎN A 10.10.10.6 mamba.mordor.fan. ÎN A 10.10.10.4 palantir.mordor.fan. ÎN A 10.10.10.11
sauron.mordor.fan. ÎN A 10.10.10.3
shadowftp.mordor.fan. ÎN A 10.10.10.8 troll.mordor.fan. ÎN A 10.10.10.7; ; CNAME înregistrează ad-dc.mordor.fan. ÎN CNAME sauron.mordor.fan. blog.mordor.fan. ÎN CNAME troll.mordor.fan. fileserver.mordor.fan. IN CNAME mamba.mordor.fan. ftpserver.mordor.fan. ÎN CNAME shadowftp.mordor.fan. mail.mordor.fan. ÎN CNAME balckelf.mordor.fan. openfire.mordor.fan. IN CNAME palantir.mordor.fan. proxy.mordor.fan. ÎN CNAME darklord.mordor.fan. www.mordor.fan. ÎN CNAME blackspider.mordor.fan.

root @ dnslinux: ~ # named-checkzone mordor.fan /var/lib/bind/db.mordor.fan 
zona mordor.fan/IN: serial încărcat 1 OK

Timpurile TTL 600 din toate registrele SRV le vom păstra în cazul în care instalăm un Slave BIND la timp. Aceste înregistrări reprezintă servicii Active Directory® care citesc în mare parte date din baza de date LDAP. Deoarece acea bază de date se schimbă frecvent, timpul de sincronizare trebuie să fie scurt, într-o schemă DNS Master-Slave. Conform filosofiei Microsoft observată de la Active Directory 2000 până în 2008, valoarea de 600 este menținută pentru aceste tipuri de înregistrări SRV.

L TTL-uri a serverelor cu IP fix, acestea sunt sub timpul declarat în SOA de 3 ore.

Zone File 10.10.10.in-addr.arpa

root @ dnslinux: ~ # nano /var/lib/bind/db.10.10.10.in-addr.arpa
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; serial 1D; reîmprospătare 1H; reîncercați 1W; expiră 3H); minim sau; Timp negativ de stocare în cache; @ IN NS dnslinux.mordor.fan. ; 10 IN PTR blackspider.mordor.fan. 11 IN PTR palantir.mordor.fan. 3 IN PTR sauron.mordor.fan. 4 IN PTR mamba.mordor.fan. 5 IN PTR dnslinux.mordor.fan. 6 IN PTR darklord.mordor.fan. 7 IN PTR troll.mordor.fan. 8 IN PTR shadowftp.mordor.fan. 9 IN PTR blackelf.mordor.fan.

root@dnslinux:~# named-checkzone 10.10.10.in-addr.arpa /var/lib/bind/db.10.10.10.in-addr.arpa 
zona 10.10.10.in-addr.arpa/IN: serial încărcat 1 OK

Zone File _msdcs.mordor.fan

Să luăm în considerare ceea ce este recomandat în fișier /usr/share/doc/bind9/README.Debian.gz dublarea locației fișierelor din Zonele Master care nu sunt supuse actualizărilor dinamice prin DHCP.

root @ dnslinux: ~ # nano /etc/bind/db._msdcs.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; serial 1D; reîmprospătare 1H; reîncercați 1W; expiră 3H); minim sau; Timp negativ de stocare în cache; @ IN NS dnslinux.mordor.fan. ; ; ; CATALOG GLOBAL gc._msdcs.mordor.fan. 600 IN A 10.10.10.3; ; Aliasuri -n baza de date LDAP modificată și privată a unui Active Directory- a SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 IN CNAME sauron.mordor.fan. ; ; LDAP modificat și privat al unui Active Directory _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. ; ; KERBEROS modificat și privat al unui Active Directory _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan.

Verificăm sintaxa și putem ignora eroarea pe care o returnează, deoarece în configurarea acestei Zone în fișier /etc/bind/named.conf.local includem declarația numele de verificare sunt ignorate;. Zona va fi încărcată corect de 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: numele proprietarului defectuos (nume de verificare) zona _msdcs.mordor.fan/IN: seria încărcată 1 OK

root @ dnslinux: ~ # systemctl reporniți bind9.service 
root @ dnslinux: ~ # systemctl status bind9.service 
● bind9.service - Server de nume de domeniu BIND încărcat: încărcat (/lib/systemd/system/bind9.service; activat) Drop-In: /run/systemd/generator/bind9.service.d └─50-insserv.conf- $named.conf Activ: activ (funcționare) de la Duminică 2017 02:12:08 EST; Acum 48 sec. Documente: man: named (38) Proces: 2 ExecStop = / usr / sbin / rndc stop (cod = ieșit, status = 8 / SUCCES) PID principal: 859 (numit) CGroup: /system.slice/bind0.service └─864 / usr / sbin / named -f -u bind 9 Feb 864:12:08 dnslinux named [48]: zone 38.efip864.arpa/IN: serial încărcat 3 Feb 6 1:12:08 dnslinux named [48 ]: zone befip38.arpa/IN: serial încărcat 864 6 februarie 1:12:08 dnslinux numit [48]: zonă 38.efip864.arpa/IN: serial încărcat 0 6 februarie 1:12:08 dnslinux numit [48]: zone 38.efip864.arpa/IN: serial încărcat 7 6 februarie 1:12:08 dnslinux numit [48]: zona mordor.fan/IN: serial încărcat 38 864 februarie 1:12:08 dnslinux numit [48]: exemplu de zonă .org / IN: încărcat serial 38 februarie 864 1:12:08 dnslinux numit [48]: zone _msdcs.mordor.fan/IN: încărcat serial 38 februarie 864 1:12:08 dnslinux numit [48]: zonă invalid / IN : încărcat serial 38 864 februarie 1:12:08 dnslinux numit [48]: toate zonele încărcate
12 februarie 08:48:38 dnslinux numit [864]: funcţionare

Consultăm BIND

Înainte După instalarea DHCP, trebuie să efectuăm o serie întreagă de verificări care includ chiar alăturarea unui client Windows 7 la domeniu mordor.fan reprezentat de Active Directory instalat pe computer sauron.mordor.fan.

Primul lucru pe care trebuie să-l facem este să oprim serviciul DNS de pe computer sauron.mordor.fan, și declarați pe interfața de rețea că de acum înainte serverul dvs. DNS va fi 10.10.10.5 dnslinux.mordor.fan.

Într-o consolă a serverului în sine sauron.mordor.fan executăm:

Microsoft Windows [versiunea 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. Toate drepturile rezervate.

C: \ Users \ Administrator> nslookup
Server implicit: dnslinux.mordor.fan Adresă: 10.10.10.5

> gc._msdcs
Server: dnslinux.mordor.fan Adresa: 10.10.10.5 Nume: gc._msdcs.mordor.fan Adresa: 10.10.10.3

> mordor.fan
Server: dnslinux.mordor.fan Adresa: 10.10.10.5 Nume: mordor.fan Adresa: 10.10.10.3

> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs
Server: dnslinux.mordor.fan Adresa: 10.10.10.5 Nume: sauron.mordor.fan Adresa: 10.10.10.3 Aliasuri: 03296249-82a1-49aa-a4f0-28900f5d256b._msdors.fans

> set type = SRV
> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
Server: dnslinux.mordor.fan Adresă: 10.10.10.5 _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan Locația serviciului SRV: prioritate = 0 greutate = 100 port = 88 svr nume gazdă sauron.mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan adresa de internet sauron.mordor.fan = 10.10.10.3 adresa de internet dnslinux.mordor.fan = 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 SRV service locație: = prioritate = 0 port sauron host = 100 sauron 389 porturi .mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan adresa de internet = 10.10.10.3 dnslinux.mordor.fan adresa de internet = 10.10.10.5
> ieși

C: \ Utilizatori \ Administrator>

Interogări DNS realizate din sauron.mordor.fan sunt satisfăcătoare.

Următorul pas va fi crearea unei alte mașini virtuale cu Windows 7 instalat. Deoarece nu avem încă instalat serviciul DHCP, vom da dispozitivului numele "win7»Adresa IP 10.10.10.251. De asemenea, declarăm că serverul dvs. DNS va fi 10.10.10.5 dnslinux.mordor.fanși că domeniul de căutare va fi mordor.fan. Nu vom înregistra acel dispozitiv în DNS pentru că îl vom folosi și pentru a testa serviciul DHCP după ce îl vom instala.

Apoi deschidem o consolă CMD și în el executăm:

Microsoft Windows [versiunea 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Toate drepturile rezervate.

C: \ Users \ buzz> nslookup
Server implicit: dnslinux.mordor.fan Adresă: 10.10.10.5

> mordor.fan
Server: dnslinux.mordor.fan Adresa: 10.10.10.5 Nume: mordor.fan Adresa: 10.10.10.3

> set type = SRV
> _ldap._tcp.DomainDnsZones
Server: dnslinux.mordor.fan Adresă: 10.10.10.5 _ldap._tcp.DomainDnsZones.mordor.fan Locația serviciului SRV: prioritate = 0 greutate = 0 port = 389 svr nume gazdă = sauron.mordor.fan mordor.fan nameserver = dnslinux.mordor .fan sauron.mordor.fan adresa de internet = 10.10.10.3 dnslinux.mordor.fan adresa de internet = 10.10.10.5
> _kpasswd._udp
Server: dnslinux.mordor.fan Adresă: 10.10.10.5 _kpasswd._udp.mordor.fan Locație serviciu SRV: prioritate = 0 greutate = 0 port = 464 svr nume gazdă = sauron.mordor.fan mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan adresa de internet = 10.10.10.3 dnslinux.mordor.fan adresa de internet = 10.10.10.5
> _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones
Server: dnslinux.mordor.fan Adresă: 10.10.10.5 _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan SRV Locația serviciului: prioritate = 0 greutate = 0 port = 389 svr nume gazdă = sauron. mordor.fan mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan adresa de internet = 10.10.10.3 dnslinux.mordor.fan adresa de internet = 10.10.10.5
> ieşire

C: \ Users \ buzz>

Interogări DNS făcute de la client «win7»Au fost, de asemenea, satisfăcătoare.

În Active Directory creăm utilizatorul «Saruman«, Cu scopul de a-l folosi la aderarea la client win7 la domeniu mordor.fan., folosind metoda «ID de rețea«, Utilizarea numelor de utilizator saruman@mordor.fan y administrator@mordor.fan. Unirea a avut succes și este dovedită de următoarea captură de ecran:

Despre actualizări dinamice în Microsoft® DNS și BIND

Întrucât avem serviciul DNS oprit în Active Directory®, nu a fost posibil pentru client «win7»Înregistrați-vă numele și adresa IP în acel DNS. Mult mai puțin în dnslinux.mordor.fan întrucât nu am făcut nicio declarație permite-actualizare pentru oricare dintre domeniile implicate.

Și aici s-a format lupta bună cu prietenul meu Fuegianul. În primul meu e-mail despre acest aspect am comentat:

• În articolele Microsoft despre utilizarea BIND și Active Directory®, ei recomandă ca, în special Zona Direct, să se permită actualizarea –pătruns- direct de către clienți Windows care sunt deja conectați la domeniul Active Directory.
• De aceea, în mod implicit, actualizările dinamice securizate sunt permise în zonele DNS ale unui Active Directory®. de către clienții Windows deja alăturați domeniului Active Directory. Dacă nu sunt uniți, se abțin de la consecințe.
• DNS-ul unui Active Directory acceptă actualizări dinamice „Numai sigur”, „Nesigur și sigur” sau „Niciuna”, care este același cu a spune NU Actualizări sau Niciunul.
• Da într-adevăr Filosofie Microsoft nu ar fi de acord ca clienții săi să NU-și actualizeze datele în DNS-urile lor, nu ar lăsa deschisă posibilitatea de a dezactiva actualizările dinamice în DNS-urile lor, cu excepția cazului în care această opțiune va fi lăsată în scopuri mai ascunse..
• Microsoft oferă „Securitate” în schimbul Întunericului, după cum mi-a spus un coleg și un prieten care a urmat cursuri cu Certificat Microsft®. ADEVĂRAT. În plus, El Fueguino mi-a confirmat-o.
• Un client care dobândește o adresă IP printr-un DHCP instalat pe o mașină UNIX®/Linux, de exemplu, nu va putea rezolva adresa IP din propriul nume. până când sunteți conectat la domeniul Active Directory, atâta timp cât Microsoft® sau un BIND este utilizat ca DNS fără actualizări dinamice de către un DHCP.
• Dacă instalez DHCP în Active Directory® însuși, atunci trebuie să declar că Zonele sunt actualizate de Microsoft® DHCP.
• Dacă urmează să folosim BIND ca DNS pentru rețeaua Windows, lucrul logic și recomandat este să instalăm duo-ul BIND-DHCP, acesta din urmă actualizând dinamic BIND și chestiunea este încheiată.
• În lumea rețelelor LAN pe UNIX®/Linux, de când au fost inventate actualizări dinamice pe BIND, doar domnul DHCP este permis «pătrunde»Doamnei BIND cu actualizările ei. Relaxarea cu ordinea, vă rog.
• Când declar în zonă mordor.fan de exemplu: allow-update {10.10.10.0/24; };, BIND însuși mă informează la pornire sau repornire că:

  • zona 'mordor.fan' permite actualizări după adresa IP, care este nesigură

• În lumea sacră UNIX®/Linux, această obrăznicie cu DNS este pur și simplu inadmisibilă.

Vă puteți imagina restul schimbului cu prietenul meu Fuegianul prin e-mail-uri, Chat prin telegramă, telefoane plătite de el (bineînțeles omule, nu am un kilogram pentru asta), și chiar mesaje prin porumbei voiajori în secolul XXI!

Ba chiar a amenințat că nu-mi trimite un copil al animalului său de companie, Iguana lui.Petra» pe care mi-a promis ca parte a plății. Atunci m-am speriat cu adevărat. Așa că am început din nou, dar din alt unghi.

• „Aproape” Active Directory care poate fi realizat cu Samba 4, rezolvă acest aspect cu măiestrie, atât atunci când folosim DNS-ul său intern, cât și BIND-ul compilat pentru a suporta zonele DLZ - Zonele încărcate dinamic, sau zone încărcate dinamic.
• Încă suferă de același lucru: atunci când un client dobândește o adresă IP printr-un DHCP instalat pe otra Mașina UNIX® / Linux, nu veți putea rezolva adresa IP a propriului nume până când este alăturat domeniului Samba 4 AD-DC.
• Integrați duoul BIND-DLZ și DHCP pe aceeași mașină în care AD-DC Samba 4 este o meserie pentru un adevărat specialist.

Fuegianul M-a chemat la capitol și mi-a strigat: NU vorbim despre AD-DC Samba 4, dar de la Microsoft® Active Directory®!. Și am răspuns cu umilință că am fost derutat de unele dintre următoarele articole pe care urma să le scriu.

Atunci i-am spus că decizia finală cu privire la actualizările dinamice ale computerelor client din rețeaua lui era la latitudinea lui. Că i-aș da numai pe sfat scris înainte despre allow-update {10.10.10.0/24; };, si nimic mai mult. Că nu eram responsabil pentru ceea ce a rezultat din acea promiscuitate a fiecărui client Windows - sau Linux - din rețeaua lor «va pătrunde»Cu impunitate la BIND.

Dacă ai ști, dragă Cititor, că acesta este punctul final al ceartei, nu aș crede. Prietenul meu Fuegianul a acceptat soluția - și îmi va trimite iguana «petrika«- că acum vă împărtășesc.

Instalăm și configurăm DHCP

Pentru mai multe detalii citiți DNS și DHCP în Debian 8 „Jessie”.

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

root@dnslinux:~# nano /etc/default/isc-dhcp-server .... # Pe ce interfețe ar trebui serverul DHCP (dhcpd) să servească cererile DHCP? # Separați mai multe interfețe cu spații, de exemplu „eth0 eth1”. INTERFACES="eth0" root@dnslinux:~# dnssec-keygen -a HMAC-MD5 -b 128 -r /dev/urandom -n USER dhcp-key
Tasta Kdhcp. +157 + 29836

root @ dnslinux: ~ # cat Kdhcp-key. +157 + 29836.private
Format cheie privată: v1.3 Algoritm: 157 (HMAC_MD5) Cheie: 3HT/bg/6YwezUShKYofj5g== Biți: AAA= Creat: 20170212205030 Publicare: 20170212205030 Activare: 20170212205030

root @ dnslinux: ~ # nano dhcp.key
cheie dhcp-key { algoritm hmac-md5; secret „3HT/bg/6YwezUShKYofj5g=="; };

root@dnslinux:~# install -o root -g bind -m 0640 dhcp.key /etc/bind/dhcp.key
root@dnslinux:~# install -o root -g root -m 0640 dhcp.key /etc/dhcp/dhcp.key

root @ dnslinux: ~ # nano /etc/bind/named.conf.local
// // Faceți orice configurație locală aici // // Luați în considerare adăugarea zonelor 1918 aici, dacă acestea nu sunt utilizate în // organizația dvs., includeți „/etc/bind/zones.rfc1918”; includ „/etc/bind/zones.rfcFreeBSD”;
// Nu uita ... Am uitat și am plătit cu greșeli. ;-)
includeți „/etc/bind/dhcp.key”;


zona "mordor.fan" {tip master;
        allow-update {10.10.10.3; cheie dhcp-cheie; };
        fișierul „/var/lib/bind/db.mordor.fan”; }; zona "10.10.10.in-addr.arpa" { tip master;
        allow-update {10.10.10.3; cheie dhcp-cheie; };
        fișierul „/var/lib/bind/db.10.10.10.in-addr.arpa”; }; zona "_msdcs.mordor.fan" { tip master; numele-verifica ignorate; fișierul „/etc/bind/db._msdcs.mordor.fan”; };

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

root @ dnslinux: ~ # nano /etc/dhcp/dhcpd.conf
ddns-update-style interim; ddns-actualizări pe; ddns-nume de domeniu "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; ignorați actualizările clientului; autoritar; opțiune redirecționare ip dezactivată; opțiune nume de domeniu "mordor.fan"; includeți „/etc/dhcp/dhcp.key”; zone mordor.fan. {primar 127.0.0.1; cheie dhcp-cheie; } zona 10.10.10.in-addr.arpa. {primar 127.0.0.1; cheie dhcp-cheie; } redlocal rețea partajată {subrețea 10.10.10.0 netmask 255.255.255.0 {routere opțiune 10.10.10.1; opțiune sub-mască 255.255.255.0; opțiune broadcast-address 10.10.10.255; opțiune nume-domeniu-servere 10.10.10.5; opțiunea netbios-name-servers 10.10.10.5; interval 10.10.10.30 10.10.10.250; }} # END dhcpd.conf

root@dnslinux:~# dhcpd -t
Internet Systems Consortium DHCP Server 4.3.1 Copyright 2004-2014 Internet Systems Consortium. Toate drepturile rezervate. Pentru informații, vă rugăm să vizitați https://www.isc.org/software/dhcp/ Fișier de configurare: /etc/dhcp/dhcpd.conf Fișier bază de date: /var/lib/dhcp/dhcpd.leases fișier PID: / var / run /dhcpd.pid

root @ dnslinux: ~ # systemctl reporniți bind9.service 
root @ dnslinux: ~ # systemctl status bind9.service 

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

Cu ce ​​este legat Verificări cu clienții, și Modificarea manuală a fișierelor Zone, vă lăsăm, prieten cititor, să îl citiți direct din DNS și DHCP în Debian 8 „Jessie”și aplicați-l la condițiile dvs. reale. Am efectuat toate verificările necesare și am obținut rezultate satisfăcătoare. Desigur, trimitem o copie a tuturor acestora Fuegianul. Nu vor mai fi!

sfaturi

General

• Aveți multă răbdare înainte de a începe.
  
• Mai întâi instalați și configurați BIND. Verifică totul și consultă toate înregistrările pe care le-ai declarat în fiecare fișier din cele trei - sau mai multe - zone, atât din Active Directory, cât și de pe serverul DNS propriu-zis pe Linux. Dacă este posibil, de la o mașină Linux care nu este conectată la domeniu, faceți interogările DNS necesare la BIND.
  
• Alăturați-vă domeniului existent cu un client Windows cu o adresă IP fixă ​​și verificați din nou toate setările BIND din clientul Windows.
• După ce sunteți sigur că configurația noului dumneavoastră BIND este complet corectă, aventurați-vă să instalați, să configurați și să porniți serviciul DHCP.
• În caz de erori, repetați întreaga procedură de la zero 0.
• Atenție la copy & paste! și spațiile suplimentare din fiecare linie a fișierelor named.conf.xxxx
  
• După aceea, nu te plânge – cu atât mai puțin prietenului meu Fuegianul – că nu te-au sfătuit cum trebuie..

Alte sfaturi

• Diviza și cuceri.
• Într-o rețea pentru IMM-uri este mai sigur și mai benefic să instalați un BIND autorizat pentru zonele LAN interne care nu recurge la niciun server rădăcină: recursivitate nr;.
• Într-o rețea de IMM-uri situată sub un furnizor de acces la internet - ISP, poate serviciile Împuternicire y SMTP trebuie să rezolve numele de domenii pe Internet. Calamar aveți opțiunea de a declara DNS-ul dvs. ca fiind extern sau nu, în timp ce vă aflați pe un server de e-mail bazat pe remediere post o MDaemon® De asemenea, putem declara serverele DNS pe care le vom folosi în acel serviciu. În astfel de cazuri, adică cazurile care nu oferă servicii de internet și sunt sub a Furnizor de servicii de internet, puteți instala un BIND cu Expeditori arătând către DNS-ul ISP, și să-l declare ca DNS secundar pe serverele care trebuie să rezolve interogări externe LAN, altfel este posibil să le declare prin propriile fișiere de configurare.
• Dacă aveți o zonă delegată sub întreaga dvs. responsabilitateApoi, un alt cocoș cântă:
  • Instalați un server DNS bazat pe NSD, care este un server DNS autorizat prin definiție, care răspunde la interogările de la computerele de pe Internet. Pentru unele informatii aptitude show nsd. 😉 Vă rugăm să o protejați foarte bine cu cât mai mulți pereți antifoc este necesar. Atât hardware cât și software. Va fi un DNS orientat spre Internet și că «Țar»Nu trebuie să-l dăm cu pantalonii mici. 😉
  • Deoarece nu m-am văzut niciodată într-un caz ca acesta, adică total responsabil pentru o zonă delegată, ar trebui să mă gândesc foarte bine ce să recomand pentru rezolvarea numelor de domenii externe LAN-ului nostru pentru serviciile care au nevoie de ea . Clienții de rețea pentru IMM-uri nu prea au nevoie de el. Consultați literatură de specialitate sau un specialist în aceste subiecte, deoarece sunt departe de a fi unul dintre ei. Serios.
  • Recursiunea nu există pe serverele Autoritare. Bine?. În cazul în care cineva se gândește să o facă cu un BIND.
• Deși specificăm în mod explicit în fișier /etc/dhcp/dhcpd.conf declarația ignorați actualizările clientului;, dacă rulăm pe o consolă de computer dnslinux.mordor.fan comanda journalctl -f, vom vedea asta la pornirea clientului win7.mordor.fan primim următoarele mesaje de eroare:

  • 12 februarie 16:55:41 dnslinux numit[900]: client 10.10.10.30#58762: actualizare „mordor.fan/IN” refuzată
    12 februarie 16:55:42 dnslinux numit[900]: client 10.10.10.30#49763: actualizare „mordor.fan/IN” refuzată
    12 februarie 16:56:23 dnslinux numit[900]: client 10.10.10.30#63161: actualizare „mordor.fan/IN” refuzată
    

  • Pentru a șterge aceste mesaje, trebuie să mergem la opțiunile avansate ale configurației plăcii de rețea și să debifam opțiunea «Înregistrați adresele acestei conexiuni în DNS«. Acest lucru va împiedica pentru totdeauna clientul să încerce să se autoînregistreze în DNS Linux și să pună capăt problemei. Îmi pare rău, dar nu am o copie a Windows 7 în spaniolă. 😉
• Pentru a afla toate întrebările serioase - și nebunești - pe care le face un client Windows 7, consultați log interogări.log că pentru ceva o declarăm în configurația BIND. Comanda ar fi:

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

• Dacă nu permiteți computerelor dvs. client să se conecteze direct la Internet, atunci de ce aveți nevoie de servere DNS rădăcină? Acest lucru va reduce considerabil rezultatul comenzii journalctl -f iar din cel precedent, dacă serverul tău DNS Autoritar pentru Zonele Interne nu se conectează direct la Internet, ceea ce este foarte recomandat din punct de vedere al securității.

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

• Dacă nu aveți nevoie de declarația serverelor rădăcină, atunci de ce aveți nevoie de Recursie - Recursivitate?

  root @ dnslinux: ~ # nano /etc/bind/named.conf.options
  Opțiuni {
   ....
   recursivitate nr;
   ....
  };

Sfaturi specifice despre care încă nu sunt foarte clar

El om dhcpd.conf ne spune următoarele printre multe-multe- alte lucruri:

        Declarația de actualizare-optimizare

            steag actualizare-optimizare;

            Dacă parametrul de actualizare-optimizare este fals pentru un anumit client, serverul va încerca o actualizare DNS pentru acel client de fiecare dată când clientul își reînnoiește contractul de închiriere, mai degrabă decât să încerce doar o actualizare atunci când pare a fi necesar. Acest lucru va permite DNS-ului să se vindece de inconsecvențele bazei de date mai ușor, dar costul este că serverul DHCP trebuie să facă mai multe actualizări DNS. Vă recomandăm să citiți această opțiune activată, care este implicită. Această opțiune afectează doar comportamentul schemei de actualizare DNS interimare și nu are niciun efect asupra schemei de actualizare DNS ad-hoc. Dacă acest parametru nu este specificat sau este adevărat, serverul DHCP se va actualiza numai atunci când informațiile despre client se modifică, clientul primește un contract de leasing diferit sau contractul de închiriere al clientului expiră.

Vă lăsăm traducerea sau interpretarea mai mult sau mai puțin exactă, dragă cititor.

Mi s-a întâmplat personal - și s-a întâmplat în timpul scrierii acestui articol - ca atunci când conectez un BIND la un Active Directory®, fie de la Microsoft® sau Samba 4, dacă schimb numele unui computer client înregistrat în Active Directory. Domeniul Directory® sau al AD–DC de Samba 4, își păstrează vechiul nume și adresa IP în Zona Direct, și nu invers, care este corect actualizat cu noul nume. Adică, vechiul și noul nume sunt mapate la aceeași adresă IP în Zona Directă, în timp ce în sens invers apare doar noul nume. Pentru a mă înțelege bine, trebuie să încercați singuri.

Cred că este un fel de răzbunare față de Fuegianul -nu pentru mine, vă rog- pentru că am încercat să-și migreze serviciile pe Linux.

Desigur, vechiul nume va dispărea când va fi TTL 3600, sau timpul pe care l-am declarat în configurația DHCP. Dar vrem să dispară imediat așa cum se întâmplă într-un BIND + DHCP fără un Active Directory prin.

Soluția la situația respectivă am găsit-o prin inserarea declarației actualizare-optimizare falsă; la sfârșitul părții de sus a fișierului /etc/dhcp/dhcpd.conf:

ddns-update-style interimar; ddns-actualizări pe; ddns-domainname "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; ignora actualizările clientului;
actualizare-optimizare falsă;

Dacă vreun cititor știe mai multe despre asta, vă rog să mă lumineze. Voi aprecia foarte mult.

Rezumat

Ne-am distrat foarte tare cu subiectul, nu? Fără suferință pentru că avem un BIND care funcționează ca un server DNS pe o rețea Microsoft®, oferind toate înregistrările SRV și răspunzând în mod corespunzător la interogările DNS făcute acestuia. Pe de altă parte, avem un server DHCP care acordă adrese IP și actualizează corect dinamic zonele BIND.

Dar nu putem cere ... pentru moment.

Sper că prietenul meu Fuegianul Fii mulțumit și mulțumit de primul pas în migrarea către Linux pentru a face suportabile costurile insuportabile ale asistenței tehnice Microsoft®.

Notă importantă

Caracter "Fuegianul» este complet fictiv și este un produs al imaginației mele. Orice asemănare sau coincidență cu oameni reali este doar atât: pură coincidență involuntară din partea mea. L-am creat doar pentru a face scrisul și citirea acestui articol puțin mai plăcută. Acum puteți să-mi spuneți că problema DNS este obscură.