BIND i Active Directory® - sieci SME

Indeks ogólny serii: Sieci komputerowe dla MŚP: wprowadzenie

Cześć przyjaciele!. Głównym celem tego artykułu jest pokazanie, jak możemy zintegrować usługę DNS opartą na BIND9 w sieci Microsoft, bardzo powszechnej w wielu MŚP.

Wynika to z oficjalnej prośby przyjaciela, który mieszka w La Tierra del Fuego -Fuegian- specjalizuje się w sieciach Microsoft® Networks -Certyfikaty w zestawie- aby poprowadzić Cię przez tę część migracji Twoich serwerów do Linuksa. Koszty wsparcie Technicy, którzy płacą Microsoft®, już są Nie do zniesienia dla Spółki, w której pracuje i której jest jego Głównym Akcjonariuszem.

Mój przyjaciel Fuegian ma świetne poczucie humoru, a odkąd obejrzał cykl trzech filmów «Władca Pierścieni»Był urzeczony wieloma imionami swoich mrocznych postaci. Tak więc, przyjacielu Czytelniku, nie daj się zaskoczyć nazwom Twojej domeny i serwerów.

Nowicjuszom w temacie, a przed kontynuowaniem czytania, zalecamy przeczytanie i przestudiowanie trzech poprzednich artykułów na temat sieci MŚP:

• DNS i DHCP w openSUSE 13.2 „Harlequin”
• DNS i DHCP w CentOS 7
• DNS i DHCP w Debianie 8 „Jessie”

To jak oglądanie trzech z czterech części «Męt»Opublikowane do dziś i że jest to czwarte.

Parametry ogólne

Po kilku wymianach za pośrednictwem e-mail, w końcu miałem jasność co do głównych parametrów twojej obecnej sieci, którymi są:

Nazwa domeny mordor.fan Sieć LAN 10.10.10.0/24 ==================================== == =========================================== Adres IP serwerów Cel (serwery z systemem operacyjnym Windows ) =============================================== == ============================= sauron.mordor.fan. 10.10.10.3 Active Directory® 2008 SR2 mamba.mordor.fan. 10.10.10.4 Serwer plików Windows darklord.mordor.fan. 10.10.10.6 Serwer proxy, bramka i zapora sieciowa na Kerios troll.mordor.fan. 10.10.10.7 Blog oparty na ... nie pamiętam shadowftp.mordor.fan. 10.10.10.8 Serwer FTP blackelf.mordor.fan. 10.10.10.9 Pełna obsługa poczty e-mail blackspider.mordor.fan. 10.10.10.10 Serwis WWW palantir.mordor.fan. 10.10.10.11 Czat w Openfire dla Windows

Poprosiłem o pozwolenie Fuegian ustawić tyle aliasów, ile potrzeba, aby oczyścić umysł i dać mi jego pozwolenie:

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

Zadeklarowałem wszystkie ważne rekordy DNS w mojej instalacji Active Directory Windows 2008, które byłem zmuszony zaimplementować, aby pomóc mi w tworzeniu tego postu.

Informacje o rekordach SRV DNS usługi Active Directory

Rejestry SRV o Lokalizatory usług - szeroko stosowane w Microsoft Active Directory - są zdefiniowane w Prośba o komentarze RFC 2782. Pozwalają na lokalizację usługi w oparciu o protokół TCP / IP poprzez zapytanie DNS. Na przykład klient w sieci Microsoft może zlokalizować lokalizację kontrolerów domeny - Kontrolery domeny które zapewniają usługę LDAP za pośrednictwem protokołu TCP na porcie 389 za pośrednictwem pojedynczego zapytania DNS.

To normalne, że w lasach - lasyi drzewa - Drzewa dużej sieci Microsoft istnieje kilka kontrolerów domeny. Korzystając z rekordów SRV w różnych strefach, które tworzą przestrzeń nazw domen tej sieci, możemy utrzymywać listę serwerów, które zapewniają podobne, dobrze znane usługi, uporządkowane według preferencji zgodnie z protokołem transportowym i portem każdego z nich. serwery.

W Prośba o komentarze RFC 1700 Definiowanie uniwersalnych nazw symbolicznych dla dobrze znanych usług - Dobrze znana usługai nazwy takie jak «_telnet","_smtp»Za usługi telnet y SMTP. Jeśli nazwa symboliczna nie jest zdefiniowana dla dobrze znanej usługi, można użyć nazwy lokalnej lub innej, zgodnie z preferencjami użytkownika.

Cel każdego pola «specjalny»W deklaracji rekordu zasobów SRV jest używany:

• Domena: „Pdc._msdcs.mordor.fan.«. Nazwa DNS usługi, do której odnosi się rekord SRV. Nazwa DNS w przykładzie oznacza -więcej lub mniej- Podstawowy kontroler domeny obszaru _msdcs.mordor.fan.
• Usługi: „_Ldap”. Symboliczna nazwa świadczonej usługi zdefiniowana zgodnie z Prośba o komentarze RFC 1700.
• Protokół: „_Tcp”. Wskazuje typ protokołu transportowego. Zazwyczaj może przyjmować wartości _tcp o _udp, chociaż - i faktycznie - każdy typ protokołu transportowego wskazany w Prośba o komentarze RFC 1700. Na przykład za usługę pogawędzić oparte na protokole XMPP, to pole miałoby wartość _xmpp.
• Priorytet"0«. Zadeklaruj priorytet lub preferencje dla Host oferujący tę usługę że zobaczymy później. Zapytania DNS klientów dotyczące usługi zdefiniowanej przez ten rekord SRV, po otrzymaniu odpowiedniej odpowiedzi, spróbują skontaktować się z pierwszym dostępnym hostem o najniższym numerze podanym w polu. Priorytet. Zakres wartości, które może przyjmować to pole, to 0 65535 się.
• Waga"100«. Może być używany w połączeniu z Priorytet zapewnienie mechanizmu równoważenia obciążenia, gdy istnieje kilka serwerów, które zapewniają tę samą usługę. Powinien istnieć podobny rekord SRV dla każdego serwera w pliku strefy, z jego nazwą zadeklarowaną w polu Host oferujący tę usługę. Przed serwerami o równych wartościach w terenie Priorytet, wartość pola Waga może służyć jako dodatkowy poziom preferencji w celu uzyskania dokładnego wyboru serwera do równoważenia obciążenia. Zakres wartości, które może przyjmować to pole, to 0 65535 się. Jeśli równoważenie obciążenia nie jest wymagane, na przykład jak w przypadku pojedynczego serwera, zaleca się przypisanie wartości 0 aby ułatwić odczytywanie rekordu SRV.
• Numer portu - port"389«. Numer portu w Host oferujący tę usługę który świadczy usługę wskazaną w polu Usługi. Zalecany numer portu dla każdego typu dobrze znanych usług jest wskazany w Prośba o komentarze RFC 1700, chociaż może mieć wartość pomiędzy 0 i 65535.
• Host oferujący tę usługę - Target"sauron.mordor.fan.«. Określa Nazwa FQDN który jednoznacznie identyfikuje gospodarz który świadczy usługę wskazaną w rekordzie SRV. Typ rekordu «A»W przestrzeni nazw domeny dla każdego Nazwa FQDN z serwera lub gospodarz który świadczy usługę. Prościej, rekord typu A w strefie (-ach) bezpośredniej (-ych).
  • Uwaga:
    Aby autorytatywnie wskazać, że usługa określona przez rekord SRV nie jest świadczona na tym hoście, pojedynczy (.) punkt.

Chcemy tylko powtórzyć, że prawidłowe działanie sieci lub usługi Active Directory® zależy w dużej mierze od prawidłowego działania usługi nazw domenowych..

Rekordy DNS usługi Active Directory

Aby strefy nowego serwera DNS były oparte na BIND, musimy uzyskać wszystkie rekordy DNS z Active Directory®. Aby ułatwić życie, idziemy do zespołu sauron.mordor.fan -Active Directory® 2008 SR2- iw Konsoli administracyjnej DNS aktywujemy transfer strefy -direct i reverse- dla głównych stref zadeklarowanych w tego typu usługach, którymi są:

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

Po wykonaniu poprzedniego kroku, najlepiej z komputera z systemem Linux, którego adres IP znajduje się w zakresie podsieci używanej przez sieć Windows, wykonujemy:

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

• Przypomnij sobie z poprzednich artykułów, że adres IP urządzenia administrator systemu.desdelinux.wentylator es 10.10.10.1 lub 192.168.10.1.

W trzech poprzednich poleceniach możemy wyeliminować opcję 10.10.10.3 -zapytaj serwer DNS o tym adresie- jeśli zadeklarujemy w pliku / Etc / resolv.conf do adresu IP serwera sauron.mordor.fan:

buzz@sysadmin:~$ cat /etc/resolv.conf # Wygenerowane przez wyszukiwanie NetworkManager desdelinux.fan serwer nazw 192.168.10.5 serwer nazw 10.10.10.3

Po edycji z najwyższą starannością, jak to odpowiada każdemu plikowi strefy w BIND, uzyskamy następujące dane:

Rekordy RR z oryginalnej strefy _msdcs.mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs._msdcs.mordor.fan 
; W odniesieniu do SOA i NS _msdcs.mordor.fan. 3600 W SOA sauron.mordor.fan. hostmaster.mordor.fan. 12 900 600 _msdcs.mordor.fan. 86400 IN NS sauron.mordor.fan. ; ; GLOBALNY KATALOG gc._msdcs.mordor.fan. 3600 IN A 3600; ; Aliasy - w zmodyfikowanej i prywatnej bazie danych LDAP usługi Active Directory - firmy SAURON 600-10.10.10.3a03296249-82aa-a1f49-4f0d28900b._msdcs.mordor.fan. 5 W CNAME sauron.mordor.fan. ; ; Zmodyfikowany i prywatny protokół LDAP _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan usługi Active Directory. 256 IN SRV 600 600 0 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 100 IN SRV 389 600 0 sauron.mordor.fan. _ldap._tcp.100d389d-18fdb-3360cf-a8-d40c678b7d420.domains._msdcs.mordor.fan. 6 IN SRV 775 600 0 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 100 IN SRV 389 600 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 0 IN SRV 100 3268 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. ; ; Zmodyfikowany i prywatny KERBEROS _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan Active Directory. 600 IN SRV 0 100 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 389 IN SRV 600 0 sauron.mordor.fan.

Rekordy RRs z oryginalnej strefy mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs.mordor.fan 
; W odniesieniu do SOA, NS, MX i rekordu A, który mapuje; nazwa domeny dla adresu IP SAURON; Rzeczy z mordor.fan Active Directory. 3600 W 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. ; ; Również ważne rekordy A DomainDnsZones.mordor.fan. 600 IN A 10.10.10.3 ForestDnsZones.mordor.fan. 600 IN A 10.10.10.3; ; GLOBALNY 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. ; ; Zmodyfikowany i prywatny LDAP _ldap._tcp.mordor.fan Active Directory. 100 IN SRV 3268 600 0 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 100 IN SRV 389 600 0 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 100 IN SRV 389 600 0 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 100 IN SRV 389 600 0 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 100 IN SRV 389 600 0 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 100 IN SRV 389 600 0 sauron.mordor.fan. ; ; Zmodyfikowany i prywatny KERBEROS _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan Active Directory. 100 IN SRV 389 600 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 0 IN SRV 100 88 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. _kerberos._udp.mordor.fan. 100 IN SRV 88 600 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 0 IN SRV 100 sauron.mordor.fan. ; ; Rekordy A ze stałymi adresami IP -> serwery Blackelf.mordor.fan. 464 IN A 600 blackspider.mordor.fan. 0 W 100 darklord.mordor.fan. 88 IN A 600 mamba.mordor.fan. 0 IN A 100 palantir.mordor.fan. 464 IN A 3600 sauron.mordor.fan. 10.10.10.9 IN A 3600 shadowftp.mordor.fan. 10.10.10.10 IN A 3600 troll.mordor.fan. 10.10.10.6 IN A 3600; ; Rekordy CNAME ad-dc.mordor.fan. 10.10.10.4 W CNAME sauron.mordor.fan. blog.mordor.fan. 3600 W CNAME troll.mordor.fan. fileserver.mordor.fan. 10.10.10.11 W CNAME mamba.mordor.fan. ftpserver.mordor.fan. 3600 W CNAME shadowftp.mordor.fan. mail.mordor.fan. 10.10.10.3 W CNAME balckelf.mordor.fan. openfire.mordor.fan. 3600 W CNAME palantir.mordor.fan. proxy.mordor.fan. 10.10.10.8 W CNAME darklord.mordor.fan. www.mordor.fan. 3600 W CNAME blackspider.mordor.fan.

Rekordy RRs z oryginalnej strefy 10.10.10.in-addr.arpa

buzz @ sysadmin: ~ $ cat temp / rrs.10.10.10.in-addr.arpa 
; Dotyczy SOA i NS 10.10.10.in-addr.arpa. 3600 W SOA sauron.mordor.fan. hostmaster.mordor.fan. 21 900 600 86400 3600 10.10.10.in-addr.arpa. 3600 IN NS sauron.mordor.fan. ; ; Rekordy PTR 10.10.10.10.in-addr.arpa. 3600 IN PTR blackspider.mordor.fan. 11.10.10.10.in-addr.arpa. 3600 W PTR palantir.mordor.fan. 3.10.10.10.in-addr.arpa. 3600 W 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 W PTR dnslinux.mordor.fan. 6.10.10.10.in-addr.arpa. 3600 W 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 W PTR shadowftp.mordor.fan. 9.10.10.10.in-addr.arpa. 3600 IN PTR blackelf.mordor.fan.

Do tego momentu możemy myśleć, że mamy dane niezbędne do kontynuowania naszej przygody, nie bez uprzedniej obserwacji TTL oraz inne dane, które w bardzo zwięzły sposób dostarczają nam dane wyjściowe i bezpośrednia obserwacja DNS 2008-bitowego Microsft® Active Directory® 2 SR64.

Obrazy Menedżera DNS w SAURON

Zespół Dnslinux.mordor.fan.

Jeśli przyjrzymy się bliżej, adresowi IP 10.10.10.5 żadna nazwa nie została mu przypisana, aby była zajęta przez nazwę nowego DNS dnslinux.mordor.fan. Aby zainstalować parę DNS i DHCP, możemy kierować się artykułami DNS i DHCP w Debianie 8 „Jessie” y DNS i DHCP w CentOS 7.

Podstawowy system operacyjny

Mój przyjaciel FuegianOprócz tego, że jest prawdziwym specjalistą od Microsoft® Windows - ma kilka certyfikatów wydanych przez tę firmę - przeczytał i zastosował w praktyce niektóre artykuły na temat komputerów stacjonarnych opublikowane w DesdeLinux., i powiedział mi, że wyraźnie chciał rozwiązania opartego na Debianie. 😉

Aby Cię zadowolić, zaczniemy od świeżej, czystej instalacji serwera opartego na Debian 8 „Jessie”. Jednak to, co napiszemy dalej, dotyczy dystrybucji CentOS i openSUSE, o których wspominaliśmy wcześniej. BIND i DHCP są takie same w każdej dystrybucji. Opiekunowie pakietów wprowadzają niewielkie zmiany w każdej dystrybucji.

Wykonamy instalację zgodnie z opisem w DNS i DHCP w Debianie 8 „Jessie”, uważając, aby używać adresu IP 10.10.10.5 i sieć 10.10.10.0/24., nawet przed skonfigurowaniem BIND.

Konfigurujemy BIND w stylu Debiana

/etc/bind/named.conf

plik /etc/bind/named.conf zostawiamy to tak, jak jest zainstalowane.

/etc/bind/named.conf.options

plik /etc/bind/named.conf.options należy pozostawić następującą treść:

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

root @ dnslinux: ~ # nano /etc/bind/named.conf.options
opcje {katalog "/ var / cache / bind"; // Jeśli między tobą a serwerami nazw istnieje zapora ogniowa, z którą chcesz // rozmawiać, może być konieczne naprawienie zapory, aby umożliwić komunikację wielu // portom. Zobacz http://www.kb.cert.org/vuls/id/800113 // Jeśli twój ISP dostarczył jeden lub więcej adresów IP dla stabilnych // serwerów nazw, prawdopodobnie chcesz ich użyć jako usług przesyłania dalej. // Usuń komentarz z następującego bloku i wstaw adresy, zastępując // symbol zastępczy all-0. // usługi przesyłania dalej {// 0.0.0.0; //}; // ================================================= = ==================== $ // Jeśli BIND rejestruje komunikaty o błędach dotyczące wygaśnięcia klucza głównego, // będziesz musiał zaktualizować swoje klucze. Zobacz https://www.isc.org/bind-keys // ================================= = ================================== $

    // Nie chcemy DNSSEC
        dnsec-włącz nie;
        //automatyczne sprawdzanie poprawności dnssec;

        auth-nxdomain no; # zgodne z RFC1035

 // Nie musimy nasłuchiwać adresów IPv6
        // nasłuchiwanie na v6 {dowolne; };
    Listen-on-v6 {none; };

 // Do sprawdzeń z localhost i sysadmin
    // przez // dig mordor.fan axfr // dig 10.10.10.in-addr.arpa axfr // dig _msdcs.mordor.fan axfr // Nie mamy Slave DNS ... aż do teraz
 zezwolić na transfer {localhost; 10.10.10.1; };
};

// Rejestrowanie BIND
Logowanie {

        zapytania dotyczące kanałów {
        plik "/var/log/named/queries.log" wersje 3 rozmiar 1m;
        informacje o wadze;
        czas druku tak;
        stopień ważności druku tak;
        kategoria druku tak;
        };

        błąd zapytania kanału {
        plik "/var/log/named/query-error.log" wersje 3 rozmiar 1m;
        informacje o wadze;
        czas druku tak;
        stopień ważności druku tak;
        kategoria druku tak;
        };

                                
zapytania dotyczące kategorii {
         zapytania;
         };

kategorie błędów zapytań {
         błąd zapytania;
         };

};

• Przedstawiamy przechwytywanie dzienników BIND jako plik NOWOŚĆ pojawienie się w serii artykułów na ten temat. Tworzymy lfolder i pliki wymagane dla Logowanie 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

Sprawdzamy składnię skonfigurowanych plików

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

/etc/bind/named.conf.local

Tworzymy plik /etc/bind/zones.rfcFreeBSD o takiej samej treści, jak wskazano w DNS i DHCP w Debianie 8 „Jessie”.

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

plik /etc/bind/named.conf.local należy pozostawić następującą treść:

// // Wykonaj dowolną konfigurację lokalną tutaj // // Rozważ dodanie tutaj stref 1918, jeśli nie są używane w Twojej // organizacji
include "/etc/bind/zones.rfc1918"; include "/etc/bind/zones.rfcFreeBSD";

zone "mordor.fan" {typ master; plik "/var/lib/bind/db.mordor.fan"; }; zone "10.10.10.in-addr.arpa" {typ master; plik "/var/lib/bind/db.10.10.10.in-addr.arpa"; };

zone "_msdcs.mordor.fan" {typ master;
 check-names ignoruj; plik "/etc/bind/db._msdcs.mordor.fan"; }; root @ dnslinux: ~ # named-checkconf
root @ dnslinux: ~ #

Archiwum stref 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; odśwież 1 godz; ponów 1 W; wygaśnięcie 3 godz.); minimum lub; Ujemny czas buforowania do życia;
; UWAŻAJ NA PONIŻSZE ZAPISY
@ IN NS dnslinux.mordor.fan.
@ IN A 10.10.10.5
@ IN MX 10 blackelf.mordor.fan. @ IN TXT "Witamy w Dark Lan of Mordor";
_msdcs.mordor.fan. IN NS dnslinux.mordor.fan.
;
dnslinux.mordor.fan. W A 10.10.10.5
; ZAKOŃCZ BARDZO OSTROŻNIE NASTĘPUJĄCY ZAPIS;
DomainDnsZones.mordor.fan. W 10.10.10.3 ForestDnsZones.mordor.fan. IN A 10.10.10.3; ; GLOBALNY KATALOG _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. ; ; Zmodyfikowany i prywatny LDAP _ldap._tcp.mordor.fan Active Directory. 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. ; ; Zmodyfikowany i prywatny KERBEROS _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan Active Directory. 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. ; ; Rekordy A ze stałymi adresami IP -> serwery Blackelf.mordor.fan. W 10.10.10.9 blackspider.mordor.fan. W 10.10.10.10 darklord.mordor.fan. W 10.10.10.6 mamba.mordor.fan. W 10.10.10.4 palantir.mordor.fan. W A 10.10.10.11
sauron.mordor.fan. W A 10.10.10.3
shadowftp.mordor.fan. W 10.10.10.8 troll.mordor.fan. IN A 10.10.10.7; ; Rekordy CNAME ad-dc.mordor.fan. W CNAME sauron.mordor.fan. blog.mordor.fan. W CNAME troll.mordor.fan. fileserver.mordor.fan. W CNAME mamba.mordor.fan. ftpserver.mordor.fan. W CNAME shadowftp.mordor.fan. mail.mordor.fan. W CNAME balckelf.mordor.fan. openfire.mordor.fan. W CNAME palantir.mordor.fan. proxy.mordor.fan. W CNAME darklord.mordor.fan. www.mordor.fan. W CNAME blackspider.mordor.fan.

root @ dnslinux: ~ # named-checkzone mordor.fan /var/lib/bind/db.mordor.fan 
zone mordor.fan/IN: załadowano serial 1 OK

Czasy 600 TTL wszystkich rejestrów SRV zachowamy je na wypadek, gdybyśmy zainstalowali Slave BIND w przyszłości. Te rekordy reprezentują usługi Active Directory®, które w większości odczytują dane z bazy danych LDAP. Ponieważ ta baza danych często się zmienia, czasy synchronizacji muszą być krótkie w schemacie DNS Master - Slave. Zgodnie z filozofią Microsoftu obserwowaną od Active Directory 2000 do 2008, dla tego typu rekordów SRV utrzymywana jest wartość 600.

L TTL serwerów ze stałym IP, są one poniżej deklarowanego czasu w SOA 3 godziny.

Plik strefy 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; odśwież 1 godz; ponów 1 W; wygaśnięcie 3 godz.); minimum lub; Ujemny czas buforowania do życia; @ IN NS dnslinux.mordor.fan. ; 10 IN PTR blackspider.mordor.fan. 11 W PTR palantir.mordor.fan. 3 W PTR sauron.mordor.fan. 4 W PTR mamba.mordor.fan. 5 W PTR dnslinux.mordor.fan. 6 NA PTR darklord.mordor.fan. 7 W PTR troll.mordor.fan. 8 W 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 
strefa 10.10.10.in-addr.arpa/IN: załadowany serial 1 OK

Plik strefy _msdcs.mordor.fan

Weźmy pod uwagę to, co jest zalecane w pliku /usr/share/doc/bind9/README.Debian.gz O lokalizacji plików stref głównych nie poddawanych dynamicznej aktualizacji przez DHCP.

root @ dnslinux: ~ # nano /etc/bind/db._msdcs.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; serial 1D; odśwież 1 godz; ponów 1 W; wygaśnięcie 3 godz.); minimum lub; Ujemny czas buforowania do życia; @ IN NS dnslinux.mordor.fan. ; ; ; GLOBALNY KATALOG gc._msdcs.mordor.fan. 600 IN A 10.10.10.3; ; Aliasy - w zmodyfikowanej i prywatnej bazie danych LDAP usługi Active Directory - firmy SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 W CNAME sauron.mordor.fan. ; ; Zmodyfikowany i prywatny LDAP usługi 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 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 3268 IN SRV 600 0 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 100 IN SRV 3268 600 0 sauron.mordor.fan. ; ; Zmodyfikowany i prywatny KERBEROS _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan Active Directory. 100 IN SRV 389 600 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 0 IN SRV 100 88 sauron.mordor.fan.

Sprawdzamy składnię i możemy zignorować zwrócony błąd, ponieważ w konfiguracji tej Strefy w pliku /etc/bind/named.conf.local załączamy oświadczenie check-names ignoruj;. Strefa zostanie poprawnie załadowana przez 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: zła nazwa właściciela (check-names) zone _msdcs.mordor.fan/IN: wczytano serial 1 OK

root @ dnslinux: ~ # systemctl zrestartuj bind9.service 
root @ dnslinux: ~ # systemctl status bind9.service 
● bind9.service - Załadowano serwer nazw domen BIND: załadowano (/lib/systemd/system/bind9.service; włączone) Drop-In: /run/systemd/generator/bind9.service.d └─50-insserv.conf- $ named.conf Aktywny: aktywny (bieg) od niedziela 2017 02:12:08 EST; 48 s temu Dokumenty: man: named (38) Process: 2 ExecStop = / usr / sbin / rndc stop (kod = wyjście, stan = 8 / SUCCESS) Główny PID: 859 (nazwany) CGroup: /system.slice/bind0.service └─864 / usr / sbin / named -f -u bind 9 lutego 864:12:08 dnslinux named [48]: zone 38.efip864.arpa/IN: załadowano serial 3 6 lutego 1:12:08 dnslinux named [48] ]: zone befip38.arpa/IN: załadowano serial 864 6 lutego 1:12:08 dnslinux o nazwie [48]: strefa 38.efip864.arpa/IN: załadowano serial 0 6 lutego 1:12:08 dnslinux o nazwie [48]: zone 38.efip864.arpa/IN: załadowano serial 7 6 lutego 1:12:08 dnslinux o nazwie [48]: strefa mordor.fan/IN: wczytano serial 38 864 lutego 1:12:08 dnslinux o nazwie [48]: przykład strefy .org / IN: załadowano serial 38 864 lutego 1:12:08 nazwa dnslinux [48]: strefa _msdcs.mordor.fan/IN: wczytano serial 38 864 lutego 1:12:08 nazwa dnslinux [48]: strefa nieprawidłowa / IN : załadowano serial 38 864 lutego 1:12:08 nazwa dnslinux [48]: załadowano wszystkie strefy
12 lutego 08:48:38 o nazwie dnslinux [864]: bieganie

Konsultujemy BIND

Przed Po zainstalowaniu DHCP musimy przeprowadzić serię kontroli, która obejmuje nawet dołączenie klienta Windows 7 do domeny mordor.fan reprezentowana przez Active Directory zainstalowany na komputerze sauron.mordor.fan.

Pierwszą rzeczą do zrobienia jest zatrzymanie usługi DNS na komputerze sauron.mordor.fan, i zadeklaruj w interfejsie sieciowym, że od teraz Twój serwer DNS będzie 10.10.10.5 dnslinux.mordor.wentylator.

W konsoli samego serwera sauron.mordor.fan wykonujemy:

Microsoft Windows [Wersja 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. Wszelkie prawa zastrzeżone.

C: \ Users \ Administrator> nslookup
Serwer domyślny: dnslinux.mordor.fan Adres: 10.10.10.5

> gc._msdcs
Serwer: dnslinux.mordor.fan Adres: 10.10.10.5 Nazwa: gc._msdcs.mordor.fan Adres: 10.10.10.3

> mordor.fan
Serwer: dnslinux.mordor.fan Adres: 10.10.10.5 Nazwa: mordor.fan Adres: 10.10.10.3

> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs
Serwer: dnslinux.mordor.fan Adres: 10.10.10.5 Nazwa: sauron.mordor.fan Adres: 10.10.10.3 Aliasy: 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan

> ustaw typ = SRV
> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
Serwer: dnslinux.mordor.fan Adres: 10.10.10.5 _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan Lokalizacja serwera SRV: priorytet = 0 waga = 100 port = 88 nazwa_hosta svr = sauron.mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan adres internetowy = 10.10.10.3 dnslinux.mordor.fan adres internetowy = 10.10.10.5
> _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs
Serwer: dnslinux.mordor.fan Adres: 10.10.10.5 _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan Lokalizacja usługi SRV: priorytet = 0 waga = 100 port = 389 nazwa hosta svr = sauron .mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan adres internetowy = 10.10.10.3 dnslinux.mordor.fan adres internetowy = 10.10.10.5
> wyjdź

C: \ Users \ Administrator>

Zapytania DNS utworzone z sauron.mordor.fan są zadowalające.

Następnym krokiem będzie utworzenie kolejnej maszyny wirtualnej z zainstalowanym systemem Windows 7. Ponieważ nadal nie mamy zainstalowanej usługi DHCP, nadamy komputerowi nazwę «win7»Adres IP 10.10.10.251. Deklarujemy również, że Twoim serwerem DNS będzie 10.10.10.5 dnslinux.mordor.wentylator, a domeną wyszukiwania będzie mordor.fan. Nie zarejestrujemy tego komputera w DNS, ponieważ użyjemy go również do przetestowania usługi DHCP po jej zainstalowaniu.

Następnie otwieramy konsolę CMD aw nim wykonujemy:

Microsoft Windows [Wersja 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Wszelkie prawa zastrzeżone.

C: \ Users \ buzz> nslookup
Serwer domyślny: dnslinux.mordor.fan Adres: 10.10.10.5

> mordor.fan
Serwer: dnslinux.mordor.fan Adres: 10.10.10.5 Nazwa: mordor.fan Adres: 10.10.10.3

> ustaw typ = SRV
> _ldap._tcp.DomainDnsZones
Serwer: dnslinux.mordor.fan Adres: 10.10.10.5 _ldap._tcp.DomainDnsZones.mordor.fan Lokalizacja usługi SRV: priorytet = 0 waga = 0 port = 389 nazwa hosta svr = sauron.mordor.fan mordor.fan nameserver = dnslinux.mordor .fan sauron.mordor.fan adres internetowy = 10.10.10.3 dnslinux.mordor.fan adres internetowy = 10.10.10.5
> _kpasswd._udp
Serwer: dnslinux.mordor.fan Adres: 10.10.10.5 _kpasswd._udp.mordor.fan Lokalizacja usługi SRV: priorytet = 0 waga = 0 port = 464 nazwa hosta svr = sauron.mordor.fan mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan adres internetowy = 10.10.10.3 dnslinux.mordor.fan adres internetowy = 10.10.10.5
> _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones
Serwer: dnslinux.mordor.fan Adres: 10.10.10.5 _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan Lokalizacja serwera SRV: priorytet = 0 waga = 0 port = 389 nazwa hosta svr = sauron. mordor.fan mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan adres internetowy = 10.10.10.3 dnslinux.mordor.fan adres internetowy = 10.10.10.5
> wyjście

C: \ Users \ buzz>

Zapytania DNS wykonane od klienta «win7»Były również zadowalające.

W Active Directory tworzymy użytkownika «Saruman«, W celu wykorzystania go podczas dołączania do klienta win7 do domeny mordor.fan., używając metody «ID sieci«, Używanie nazw użytkowników saruman@mordor.fan y administrator@mordor.fan. Połączenie powiodło się, o czym świadczy poniższy zrzut ekranu:

Informacje o aktualizacjach dynamicznych w Microsoft® DNS i BIND

Ponieważ usługa DNS została zatrzymana w Active Directory®, klient nie mógł tego zrobić «win7»Zarejestruj swoje imię i nazwisko oraz adres IP w tym DNS. Znacznie mniej w dnslinux.mordor.fan ponieważ nie złożyliśmy żadnego oświadczenia zezwolić na aktualizację dla dowolnego z zaangażowanych obszarów.

I tak powstała dobra walka z moim przyjacielem Fuegian. W moim pierwszym e-mailu dotyczącym tego aspektu skomentowałem:

• Artykuły Microsoftu dotyczące korzystania z BIND i Active Directory® zalecają, zwłaszcza w przypadku Direct Zone, możliwość aktualizacji -przeniknął- bezpośrednio przez klientów Windows, którzy są już przyłączeni do domeny Active Directory.
• Dlatego domyślnie w strefach DNS bezpiecznych aktualizacji dynamicznych Active Directory® są dozwolone przez klientów Windows już przyłączonych do domeny Active Directory. Jeśli nie są zjednoczeni, powstrzymują się od konsekwencji.
• DNS usługi Active Directory obsługuje aktualizacje dynamiczne „Tylko bezpieczne”, „Niezabezpieczone i bezpieczne” lub „Brak”, co oznacza brak aktualizacji lub Brak.
• Tak naprawdę Filozofia firmy Microsoft nie zgadza się, że jej klienci NIE będą aktualizować swoich danych w swoich DNS, nie pozostawi otwartej możliwości wyłączenia dynamicznych aktualizacji w ich DNS, chyba że ta opcja zostanie pozostawiona dla bardziej ukrytych celów.
• Microsoft oferuje „Bezpieczeństwo” w zamian za Ciemność, jak powiedział mi kolega i przyjaciel, który przeszedł kursy Certyfikatów Microsft®. Prawdziwe. Ponadto El Fueguino mi to potwierdził.
• Klient, który uzyska adres IP przez DHCP zainstalowany na przykład na komputerze z systemem UNIX® / Linux, nie będzie w stanie rozwiązać adresu IP swojej własnej nazwy do momentu przyłączenia się do domeny Active Directory, o ile Microsoft® lub BIND jest używany jako DNS bez dynamicznych aktualizacji przez DHCP.
• Jeśli zainstaluję DHCP w samym Active Directory®, muszę zadeklarować, że Strefy są aktualizowane przez Microsoft® DHCP.
• Jeśli zamierzamy używać BIND jako DNS dla sieci Windows, logiczne i zalecane jest zainstalowanie duetu BIND-DHCP, przy czym ten ostatni dynamicznie aktualizuje BIND i sprawa jest zakończona.
• W świecie sieci LAN w systemie UNIX® / Linux, ponieważ aktualizacje dynamiczne zostały wynalezione w BIND, dozwolony jest tylko Pan DHCP «przenikać»Do pani BIND z jej aktualnościami. Relaks z porządkiem, proszę.
• Kiedy deklaruję w strefie mordor.fan na przykład: allow-update {10.10.10.0/24; };, Sam BIND informuje mnie podczas uruchamiania lub ponownego uruchamiania, że:

  • strefa „mordor.fan” umożliwia aktualizacje według adresu IP, co jest niezabezpieczone

• W świętym świecie UNIX® / Linux taka znajomość DNS jest po prostu niedopuszczalna.

Możesz sobie wyobrazić resztę wymiany z moim przyjacielem Fuegian przez e-maile, Telegram Czat, opłacone przez niego rozmowy telefoniczne (oczywiście stary, kilograma na to nie mam), a nawet wiadomości przez gołębie pocztowe w XXI wieku!

Zagroził nawet, że nie wyśle ​​mi syna swojego zwierzaka, jego Iguany «Petra»Że obiecał mi jako część zapłaty. Tam naprawdę się przestraszyłem. Zacząłem więc od nowa, ale pod innym kątem.

• „Prawie” Active Directory, który można osiągnąć za pomocą Samby 4, rozwiązuje ten aspekt w mistrzowski sposób, zarówno gdy używamy jej wewnętrznego DNS, jak i BIND skompilowanego do obsługi stref DLZ - Strefy załadowane Dinamyclub Strefy ładowane dynamicznie.
• Nadal cierpi na to samo: gdy klient uzyskuje adres IP za pośrednictwem protokołu DHCP zainstalowanego w inny Na komputerze z systemem UNIX® / Linux nie będziesz w stanie rozwiązać adresu IP własnej nazwy dopóki nie zostanie przyłączony do domeny Samby 4 AD-DC.
• Zintegruj duet BIND-DLZ i DHCP na tym samym komputerze, na którym AD-DC Samba 4 to praca dla prawdziwego specjalisty.

Fuegian Wezwał mnie do rozdziału i wrzasnął na mnie: NIE mówimy o AD-DC Samba 4, ale Microsoft® Active Directory®!. Odpowiedziałem pokornie, że jestem zachwycony częścią poniższych artykułów, które zamierzam napisać.

Wtedy powiedziałem mu, że ostateczna decyzja o dynamicznych aktualizacjach komputerów klienckich w jego sieci została pozostawiona jego własnej woli. Że dałbym mu tylko typ napisane wcześniej o allow-update {10.10.10.0/24; };i więcej nic. Że nie byłem odpowiedzialny za to, co wynikło z rozwiązłości, jaką każdy klient Windows - lub Linux - w swojej sieci «przeniknie»Bezkarnie wobec BIND.

Gdybyś wiedział, mój przyjacielu, Czytelniku, że to był punkt końcowy tej bijatyki, nie uwierzyłbyś. Mój przyjaciel Fuegian przyjął rozwiązanie - i przyśle mi iguanę «Pete«- tym teraz dzielę się z wami.

Instalujemy i konfigurujemy DHCP

Aby uzyskać więcej informacji, przeczytaj DNS i DHCP w Debianie 8 „Jessie”.

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

root @ dnslinux: ~ # nano / etc / default / isc-dhcp-server .... # Na jakich interfejsach serwer DHCP (dhcpd) powinien obsługiwać żądania DHCP? # Poszczególne interfejsy oddziel spacjami, np. „Eth0 eth1”. INTERFEJSY = "eth0" root @ dnslinux: ~ # dnssec-keygen -a HMAC-MD5 -b 128 -r / dev / urandom -n USER dhcp-key
Klucz Kdhcp. + 157 + 29836

root @ dnslinux: ~ # cat Kdhcp-key. +157 + 29836.private
Format klucza prywatnego: v1.3 Algorytm: 157 (HMAC_MD5) Klucz: 3HT / bg / 6YwezUShKYofj5g == Bity: AAA = Utworzono: 20170212205030 Publikacja: 20170212205030 Aktywacja: 20170212205030

root @ dnslinux: ~ # nano dhcp.key
klucz dhcp-key {algorytm hmac-md5; sekret "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
// // Wykonaj tutaj dowolną konfigurację lokalną // // Rozważ dodanie tutaj stref 1918, jeśli nie są one używane w Twojej // organizacji include "/etc/bind/zones.rfc1918"; include "/etc/bind/zones.rfcFreeBSD";
// Nie zapomnij ... Zapomniałem i zapłaciłem błędami. ;-)
include "/etc/bind/dhcp.key";


zone "mordor.fan" {typ master;
        allow-update {10.10.10.3; klucz dhcp-key; };
        plik "/var/lib/bind/db.mordor.fan"; }; zone "10.10.10.in-addr.arpa" {typ master;
        allow-update {10.10.10.3; klucz dhcp-key; };
        plik "/var/lib/bind/db.10.10.10.in-addr.arpa"; }; zone "_msdcs.mordor.fan" {typ master; check-names ignoruj; plik "/etc/bind/db._msdcs.mordor.fan"; };

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

root @ dnslinux: ~ # nano /etc/dhcp/dhcpd.conf
ddns-update-style interim; aktualizacje ddns włączone; ddns-domainname "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; ignoruj ​​aktualizacje klienta; autorytatywny; opcja IP-forwarding wyłączona; opcja nazwa-domeny "mordor.fan"; include "/etc/dhcp/dhcp.key"; zone mordor.fan. {pierwotne 127.0.0.1; klucz dhcp-key; } strefa 10.10.10.in-addr.arpa. {pierwotne 127.0.0.1; klucz dhcp-key; } redlokalna sieć współdzielona {podsieć 10.10.10.0 maska ​​sieci 255.255.255.0 {opcjonalne routery 10.10.10.1; opcja maska ​​podsieci 255.255.255.0; opcja broadcast-address 10.10.10.255; opcja serwery nazw-domen 10.10.10.5; opcja netbios-name-server 10.10.10.5; zakres 10.10.10.30 10.10.10.250; }} # KONIEC dhcpd.conf

root @ dnslinux: ~ # dhcpd -t
Konsorcjum Internet Systems Serwer DHCP 4.3.1 Copyright 2004-2014 Konsorcjum Internet Systems. Wszelkie prawa zastrzeżone. Więcej informacji można znaleźć na stronie https://www.isc.org/software/dhcp/ Plik konfiguracyjny: /etc/dhcp/dhcpd.conf Plik bazy danych: /var/lib/dhcp/dhcpd.leases Plik PID: / var / run /dhcpd.pid

root @ dnslinux: ~ # systemctl zrestartuj bind9.service 
root @ dnslinux: ~ # systemctl status bind9.service 

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

Z czym jest związane Sprawdza z klientamii Ręczna modyfikacja plików Zone, zostawiamy to Tobie, przyjacielu czytelnika, do przeczytania bezpośrednio DNS i DHCP w Debianie 8 „Jessie”i zastosuj go do swoich rzeczywistych warunków. Przeprowadziliśmy wszystkie niezbędne kontrole i uzyskaliśmy zadowalające wyniki. Oczywiście wysyłamy ich kopie na adres Fuegian. Nie będzie więcej!

wskazówki

Ogólny

• Zanim zaczniesz, uzbrój się w cierpliwość.
  
• Najpierw zainstaluj i skonfiguruj BIND. Sprawdź wszystko i zobacz wszystkie rekordy zadeklarowane w każdym pliku trzech lub więcej stref, zarówno z Active Directory, jak iz samego serwera DNS w systemie Linux. Jeśli to możliwe, z komputera z systemem Linux, który nie jest przyłączony do domeny, wykonaj niezbędne zapytania DNS do BIND.
  
• Dołącz do klienta Windows ze stałym adresem IP do istniejącej domeny i ponownie sprawdź wszystkie ustawienia BIND z klienta Windows.
• Gdy będziesz mieć pewność, że nowa konfiguracja BIND jest całkowicie poprawna, wyrusz się, aby zainstalować, skonfigurować i uruchomić usługę DHCP.
• W przypadku błędów powtórz całą procedurę od zera 0.
• Uważaj na kopiowanie i wklejanie! i pozostałe spacje w każdym wierszu plików named.conf.xxxx
  
• Później nie narzekał - a tym bardziej mojemu przyjacielowi, Fuegianowi - że nie otrzymał właściwej porady.

Inne wskazówki

• Dziel i rządź.
• W sieci SME bezpieczniej i korzystniej jest zainstalować autorytatywny BIND dla wewnętrznych stref LAN, który nie powtarza się na żadnym serwerze głównym: rekurencja nie;.
• W sieci MŚP znajdującej się pod dostawcą dostępu do Internetu - ISP, być może usługi pełnomocnik y SMTP muszą rozwiązywać nazwy domen w Internecie. On Kałamarnica masz możliwość zadeklarowania zewnętrznego DNS lub nie, podczas gdy na serwerze pocztowym opartym na Postfix o MDaemon® Możemy również zadeklarować serwery DNS, których będziemy używać w tej usłudze. W takich przypadkach, to znaczy w przypadkach, w których nie są świadczone usługi dla Internetu i które są objęte lit. Dostawca usług internetowych, możesz zainstalować BIND z Spedytorzy wskazujący na DNS pliku ISP, i zadeklaruj go jako pomocniczy DNS na serwerach, które muszą rozwiązywać zewnętrzne zapytania do sieci LAN, w przeciwnym razie można je zadeklarować poprzez własne pliki konfiguracyjne.
• Jeśli masz delegowaną strefę, za którą jesteś całkowicie odpowiedzialnyPotem kolejna wrona koguta:
  • Zainstaluj serwer DNS oparty na NSD, który z definicji jest autorytatywnym serwerem DNS, odpowiadającym na zapytania z komputerów w Internecie. Po trochę informacji aptitude pokaż nsd. 😉 Należy go bardzo dobrze zabezpieczyć za pomocą tylu ścian przeciwpożarowych, ile potrzeba. Zarówno sprzęt, jak i oprogramowanie. Będzie to DNS dla Internetu i to «Cara»Nie możemy tego dać z niskimi spodniami. 😉
  • Ponieważ nigdy nie widziałem siebie w takim przypadku, czyli osobie zarządzającej Strefą Delegowaną, musiałbym bardzo dobrze pomyśleć, co polecić przy rozwiązywaniu nazw domen zewnętrznych w naszej sieci LAN dla usług, które tego potrzebują . Klienci sieci SME tak naprawdę tego nie potrzebują. Skonsultuj się z literaturą specjalistyczną lub specjalistą w tych dziedzinach, ponieważ daleko mi do nich. Poważnie.
  • Rekursja nie istnieje na serwerach autorytarnych. W porządku?. Na wypadek, gdyby ktoś pomyślał o zrobieniu tego z BIND.
• Chociaż wyraźnie określamy w pliku /etc/dhcp/dhcpd.conf Deklaracja ignoruj ​​aktualizacje klienta;, jeśli uruchamiamy na konsoli komputera dnslinux.mordor.fan zamówienie Journalctl -fzobaczymy to podczas uruchamiania klienta win7.mordor.fan otrzymujemy następujące komunikaty o błędach:

  • 12 lutego 16:55:41 nazwa dnslinux [900]: klient 10.10.10.30 # 58762: odmowa aktualizacji „mordor.fan/IN”
    12 lutego 16:55:42 nazwa dnslinux [900]: klient 10.10.10.30 # 49763: odmowa aktualizacji „mordor.fan/IN”
    12 lutego 16:56:23 nazwa dnslinux [900]: klient 10.10.10.30 # 63161: odmowa aktualizacji „mordor.fan/IN”
    

  • Aby wyeliminować te komunikaty, musimy przejść do zaawansowanych opcji konfiguracji karty sieciowej i odznaczyć opcję «Zarejestruj adresy tego połączenia w DNS«. Uniemożliwi to klientowi próbę samodzielnej rejestracji w systemie Linux DNS na zawsze i problem się zakończy. Przepraszamy, ale nie mam kopii systemu Windows 7 w języku hiszpańskim. 😉
• Aby dowiedzieć się o wszystkich poważnych - i szalonych - zapytaniach, które zadaje klient Windows 7, zapoznaj się z logowanie zapytań.log że dla czegoś deklarujemy to w konfiguracji BIND. Kolejność byłaby taka:

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

• Jeśli nie pozwalasz swoim komputerom klienckim na bezpośrednie łączenie się z Internetem, to dlaczego potrzebujesz głównych serwerów DNS? Spowoduje to znaczne zmniejszenie wydajności polecenia Journalctl -f iz poprzedniego, jeśli Twój autorytarny serwer DNS dla stref wewnętrznych nie łączy się bezpośrednio z Internetem, co jest wysoce zalecane z punktu widzenia bezpieczeństwa.

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

• Jeśli nie potrzebujesz deklaracji serwerów głównych, dlaczego potrzebujesz rekursji - Rekurencja?

  root @ dnslinux: ~ # nano /etc/bind/named.conf.options
  opcje {
   ....
   rekurencja nie;
   ....
  };

Konkretne rady, których nadal nie jestem do końca jasne

El człowiek dhcpd.conf mówi nam między wieloma innymi rzeczami:

        Instrukcja aktualizacji-optymalizacji

            flaga optymalizacji aktualizacji;

            Jeśli parametr optymalizacji aktualizacji ma wartość false dla danego klienta, serwer będzie próbował zaktualizować DNS dla tego klienta za każdym razem, gdy klient odnowi dzierżawę, zamiast podejmować próby aktualizacji tylko wtedy, gdy wydaje się to konieczne. Umożliwi to DNS łatwiejsze naprawianie niespójności bazy danych, ale koszt jest taki, że serwer DHCP musi wykonać o wiele więcej aktualizacji DNS. Zalecamy czytanie tej opcji jako włączonej, która jest domyślna. Ta opcja wpływa tylko na zachowanie tymczasowego schematu aktualizacji DNS i nie ma wpływu na schemat aktualizacji DNS ad hoc. Jeśli ten parametr nie jest określony lub jest prawdziwy, serwer DHCP będzie aktualizował się tylko wtedy, gdy zmienią się informacje o kliencie, klient otrzyma inną dzierżawę lub wygaśnie dzierżawa klienta.

Mniej lub bardziej dokładne tłumaczenie lub interpretacja pozostawiamy tobie, drogi czytelniku.

Osobiście zdarzyło mi się - i stało się podczas pisania tego artykułu - że kiedy łączę BIND z Active Directory®, to pochodzi z Microsft® lub Samby 4, jeśli zmienię nazwę komputera klienckiego zarejestrowanego w domeny Active Directory® lub domeny AD-DC Samby 4 zachowuje swoją starą nazwę i adres IP w strefie bezpośredniej, a nie na odwrót, która jest poprawnie aktualizowana nową nazwą. Innymi słowy, stare i nowe nazwy są mapowane na ten sam adres IP w strefie bezpośredniej, podczas gdy na odwrót pojawia się tylko nowa nazwa. Aby mnie dobrze zrozumieć, musisz sam spróbować.

Myślę, że to rodzaj zemsty Fuegian -nie mnie, proszę- za próbę migracji twoich usług do Linuksa.

Oczywiście stara nazwa zniknie, gdy jej 3600 TTL, czyli czas, który zadeklarowaliśmy w konfiguracji DHCP. Chcemy jednak, aby zniknął natychmiast, jak to się dzieje w BIND + DHCP bez usługi Active Directory za pośrednictwem.

Rozwiązanie tej sytuacji znalazłem, wstawiając oświadczenie aktualizacja optymalizacji fałsz; na końcu początku pliku /etc/dhcp/dhcpd.conf:

ddns-update-style interim; aktualizacje ddns włączone; ddns-domainname "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; ignoruj ​​aktualizacje klienta;
aktualizacja optymalizacji fałsz;

Jeśli któryś Czytelnik wie o tym więcej, proszę mnie oświecić. Bardzo to docenię.

streszczenie

Świetnie się bawiliśmy z tematem, prawda? Żadnych cierpień, ponieważ mamy BIND pracujący jako serwer DNS w sieci Microsoft®, oferujący wszystkie rekordy SRV i odpowiadający odpowiednio na zapytania DNS do nich kierowane. Z drugiej strony mamy serwer DHCP przyznający adresy IP i dynamicznie aktualizujący strefy BIND.

Ale nie możemy prosić ... w tej chwili.

Mam nadzieję, mój przyjacielu Fuegian bądź zadowolony i usatysfakcjonowany pierwszym krokiem migracji do Linuksa, aby nie do zniesienia koszty pomocy technicznej Microsft® mogły znieść.

Ważna uwaga

Postać "Fuegian»Jest całkowicie fikcyjna i wytworem mojej wyobraźni. Każde podobieństwo lub zbieg okoliczności z prawdziwymi ludźmi to to samo: czysty mimowolny zbieg okoliczności z mojej strony. Stworzyłem go tylko po to, aby pisanie i czytanie tego artykułu było trochę przyjemne. Teraz, jeśli możesz mi powiedzieć, że problem DNS jest ciemny,