BIND og Active Directory® - SMV-netværk

Generelt serieindeks: Computernetværk til SMV'er: Introduktion

Hej venner!. Hovedformålet med denne artikel er at vise, hvordan vi kan integrere DNS-tjenesten baseret på BIND9 i et Microsoft-netværk, meget almindeligt i mange SMV'er.

Det stammer fra den officielle anmodning fra en ven, der bor i La Tierra del Fuego -Fuegian- specialiseret i Microsoft®-netværk - Certifikater inkluderet - til at guide dig i denne del af migrationen af ​​dine servere til Linux. Omkostningerne ved støtte Teknikere, der betaler Microsoft®, er allerede Uudholdelig for det selskab, hvor han arbejder, og hvor han er hans hovedaktionær.

Min ven Fuegian han har en god sans for humor, og siden han så serien af ​​tre film «Ringenes Herre»Han blev betaget af mange af navnene på hans mørke karakterer. Så læserven, vær ikke overrasket over navnene på dit domæne og dine servere.

For nybegyndere til emnet, og inden du fortsætter med at læse, anbefaler vi, at du læser og studerer de tre tidligere artikler om SMV-netværk:

• DNS og DHCP i openSUSE 13.2 "Harlekin"
• DNS og DHCP på CentOS 7
• DNS og DHCP i Debian 8 "Jessie"

Det er som at se tre af de fire dele af «Underverden»Udgivet indtil i dag, og at dette er den fjerde.

Generelle parametre

Efter flere udvekslinger via e-mailEndelig var jeg klar over de vigtigste parametre for dit nuværende netværk, som er:

Domænenavn mordor.fan LAN-netværk 10.10.10.0/24 =========================================== ============================================ Servere IP-adresse Formål (Servere med OS Windows ) ==================================================== == =============================== sauron.mordor.fan. 10.10.10.3 Active Directory® 2008 SR2 mamba.mordor.fan. 10.10.10.4 Windows-filserver darklord.mordor.fan. 10.10.10.6 Proxy, gateway og firewall på Kerios troll.mordor.fan. 10.10.10.7 Blog baseret på ... kan ikke huske shadowftp.mordor.fan. 10.10.10.8 FTP-server blackelf.mordor.fan. 10.10.10.9 Fuld e-mail-service blackspider.mordor.fan. 10.10.10.10 WWW-tjeneste palantir.mordor.fan. 10.10.10.11 Chat på Openfire til Windows

Jeg spurgte tilladelse til Fuegian at indstille så mange aliasser som nødvendigt for at rydde mit sind og gav mig hans tilladelse:

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

Jeg erklærede alle de vigtige DNS-poster i min installation af en Active Directory Windows 2008, som jeg blev tvunget til at implementere for at guide mig i oprettelsen af ​​dette indlæg.

Om Active Directory DNS SRV-poster

Registerene SRV o Service Locators - meget brugt i Microsoft Active Directory - er defineret i Anmodning om kommentarer RFC 2782. De tillader placeringen af ​​en tjeneste baseret på TCP / IP-protokollen gennem en DNS-forespørgsel. For eksempel kan en kunde på et Microsoft-netværk finde placeringen af ​​domænekontrollere - Domænecontrollere der leverer LDAP-tjenesten via TCP-protokollen på port 389 gennem en enkelt DNS-forespørgsel.

Det er normalt, at i skovene - Skoveog træer - Træer i et stort Microsoft-netværk er der flere domænecontrollere. Gennem brug af SRV-poster i de forskellige zoner, der udgør domænenavnområdet for det netværk, kan vi opretholde en liste over servere, der leverer lignende kendte tjenester, bestilt efter præference i henhold til transportprotokollen og porten på hver enkelt af serverne.

I Anmodning om kommentarer RFC 1700 Definition af universelle symbolske navne til velkendte tjenester - Kendt serviceog navne som «_telnet""_smtp»For tjenester telnet y SMTP. Hvis et symbolsk navn ikke er defineret for en velkendt tjeneste, kan et lokalt navn eller et andet navn bruges i henhold til brugerens præferencer.

Formålet med hvert felt «special»Brugt i erklæringen om en SRV-ressourceoptegnelse er følgende:

• Domæne: Pdc._msdcs.mordor.fan.«. DNS-navn på den tjeneste, som SRV-posten henviser til. DNS-navnet i eksemplet betyder -mere eller mindre- Primær domænecontroller af området _msdcs.mordor.fan.
• Service: "_Ldap". Symbolisk navn på den tjeneste, der leveres defineret i henhold til Anmodning om kommentarer RFC 1700.
• protokol: "_Tcp". Angiver typen af ​​transportprotokol. Kan typisk tage værdierne _tcp o _udp, selvom - og faktisk - enhver form for transportprotokol, der er angivet i Anmodning om kommentarer RFC 1700. For eksempel til en tjeneste chatte protokolbaseret XMPP, ville dette felt have værdien af _xmpp.
• Prioritet'0«. Angiv prioritet eller præference for Vært, der tilbyder denne service som vi vil se senere. DNS-forespørgsler fra klienterne om den service, der er defineret af denne SRV-post, vil efter modtagelse af det relevante svar forsøge at kontakte den første tilgængelige vært med det laveste nummer, der er angivet i feltet. Prioritet. Det værdiområde, som dette felt kan tage, er 0 den 65535.
• Vægt'100«. Kan bruges i kombination med Prioritet at levere en belastningsbalanceringsmekanisme, når der er flere servere, der leverer den samme service. Der skal være en lignende SRV-post for hver server i Zone-filen med dens navn erklæret i feltet Vært, der tilbyder denne service. Før servere med lige værdier i marken Prioritet, feltværdien Vægt det kan bruges som et ekstra præferenceniveau for at opnå et nøjagtigt servervalg til belastningsafbalancering. Det værdiområde, som dette felt kan tage, er 0 den 65535. Hvis belastningsafbalancering ikke er påkrævet, f.eks. Som for en enkelt server, anbefales det at tildele værdien 0 for at gøre SRV-posten lettere at læse.
• Portnummer - Port'389«. Portnummer i Vært, der tilbyder denne service der leverer den service, der er angivet i marken Service. Det anbefalede portnummer for hver type velkendt service er angivet på Anmodning om kommentarer RFC 1700, selvom det kan tage en værdi mellem 0 og 65535.
• Vært, der tilbyder denne service - mål'sauron.mordor.fan.«. Angiver FQDN der entydigt identificerer host der leverer den service, der er angivet i SRV-posten. En posttype «A»I domænenavnsområdet for hver FQDN fra serveren eller host der leverer tjenesten. Enklere, en typepost A i den / de direkte zone (r).
  • Bemærk:
    For autoritativt at angive, at den service, der er specificeret af SRV-posten ikke leveres på denne vært, en enkelt (.) punkt.

Vi vil kun gentage, at den korrekte drift af et netværk eller en Active Directory® er stærkt afhængig af den korrekte funktion af Domain Name Service..

Active Directory DNS-poster

For at gøre zoner på den nye DNS-server baseret på BIND skal vi hente alle DNS-poster fra Active Directory®. For at gøre livet lettere går vi til holdet sauron.mordor.fan -Active Directory® 2008 SR2- og i DNS Administration Console aktiverer vi Zone Transfer -direct og reverse- for de vigtigste zoner, der er angivet i denne type tjenester, som er:

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

Når det foregående trin er udført og helst fra en Linux-computer, hvis IP-adresse er inden for området for det undernet, der bruges af Windows-netværket, udfører vi:

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

• Husk fra tidligere artikler, at enhedens IP-adresse sysadmin.desdelinux.ventilator det 10.10.10.1 eller 192.168.10.1.

I de tre foregående kommandoer kan vi fjerne muligheden 10.10.10.3 -spørg DNS-serveren med den adresse- hvis vi erklærer i sagen / Etc / resolv.conf til server-IP 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

Efter redigering med ekstrem omhu, som svarer til enhver zonefil i en BIND, får vi følgende data:

RR-poster fra den oprindelige zone _msdcs.mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs._msdcs.mordor.fan 
; Vedrørende SOA og 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. ; ; GLOBAL KATALOG gc._msdcs.mordor.fan. 600 IN A 10.10.10.3; ; Aliasser -i den modificerede og private LDAP-database i en Active Directory- af SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 I CNAME sauron.mordor.fan. ; ; Modificeret og privat LDAP for en Active Directory _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 100 IN SRV 389 sauron.mordor.fan. _ldap._tcp.600d0d-100fdb-389cf-a18-d3360c8b40d678.domæner._msdcs.mordor.fan. 7 IN SRV 420 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 6 IN SRV 775 600 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 0 IN SRV 100 389 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. ; ; KERBEROS modificeret og privat fra en Active Directory _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 100 IN SRV 3268 600 0 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 100 IN SRV 3268 600 0 sauron.mordor.fan.

RR-poster fra den oprindelige zone mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs.mordor.fan 
; Vedrørende SOA, NS, MX og A-posten, som den kortlægger; domænenavnet til IP-adressen for SAURON; Ting fra en 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. ; ; Også vigtig A registrerer DomainDnsZones.mordor.fan. 600 IN A 10.10.10.3 ForestDnsZones.mordor.fan. 600 IN A 10.10.10.3; ; GLOBAL 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. ; ; Modificeret og privat LDAP for en Active Directory _ldap._tcp.mordor.fan. 100 IN SRV 3268 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 100 IN SRV 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 100 IN SRV 389 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. ; ; Modificeret og privat KERBEROS af en Active Directory _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan. 100 IN SRV 389 600 0 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 100 IN SRV 389 600 0 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 100 IN SRV 389 600 0 sauron.mordor.fan. _kerberos._udp.mordor.fan. 100 IN SRV 389 600 0 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 100 IN SRV 88 600 0 sauron.mordor.fan. ; ; Optager A med fast IP -> Servere blackelf.mordor.fan. 100 IN A 88 blackspider.mordor.fan. 600 IN A 0 darklord.mordor.fan. 100 IN A 464 mamba.mordor.fan. 600 IN A 0 palantir.mordor.fan. 100 IN A 88 sauron.mordor.fan. 600 IN A 0 shadowftp.mordor.fan. 100 IN A 464 troll.mordor.fan. 3600 IN A 10.10.10.9; ; CNAME registrerer ad-dc.mordor.fan. 3600 I CNAME sauron.mordor.fan. blog.mordor.fan. 10.10.10.10 I CNAME troll.mordor.fan. fileserver.mordor.fan. 3600 I CNAME mamba.mordor.fan. ftpserver.mordor.fan. 10.10.10.6 I CNAME shadowftp.mordor.fan. mail.mordor.fan. 3600 I CNAME balckelf.mordor.fan. openfire.mordor.fan. 10.10.10.4 I CNAME palantir.mordor.fan. proxy.mordor.fan. 3600 I CNAME darklord.mordor.fan. www.mordor.fan. 10.10.10.11 I CNAME blackspider.mordor.fan.

RR-registreringer fra den oprindelige zone 10.10.10.in-addr.arpa

buzz @ sysadmin: ~ $ cat temp / rrs.10.10.10.in-addr.arpa 
; Vedrørende SOA og 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. ; ; PTR registrerer 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.

Indtil dette punkt kan vi tro, at vi har de nødvendige data til at fortsætte i vores eventyr, ikke uden først at observere TTL'er og andre data, der på en meget kortfattet måde giver os output og direkte observation af DNS fra en Microsft® Active Directory® 2008 SR2 64 bit.

Billeder af DNS Manager i SAURON

Dnslinux.mordor.fan hold.

Hvis vi ser nøje, til IP-adressen 10.10.10.5 intet navn blev tildelt det nøjagtigt, så det ville blive besat af navnet på den nye DNS dnslinux.mordor.fan. For at installere DNS- og DHCP-parret kan vi blive styret af artiklerne DNS og DHCP i Debian 8 "Jessie" y DNS og DHCP på CentOS 7.

Basis operativsystem

Min ven FuegianUd over at være en ægte specialist i Microsoft® Windows - han har et par certifikater udstedt af det firma - har han læst og omsat nogle af artiklerne om desktops, der er offentliggjort i DesdeLinux., og han fortalte mig, at han udtrykkeligt ønskede en Debian-baseret løsning. 😉

For at behage dig starter vi med en frisk, ren installation af en server baseret på Debian 8 "Jessie". Det, vi skriver nedenfor, er dog gyldigt for CentOS- og openSUSE-distributioner, hvis artikler vi nævnte tidligere. BIND og DHCP er de samme på enhver distro. Små variationer introduceres af pakkeholderne i hver distribution.

Vi udfører installationen som angivet i DNS og DHCP i Debian 8 "Jessie", passe på at bruge IP 10.10.10.5 og netværket 10.10.10.0/24., selv før du konfigurerer BIND.

Vi konfigurerer BIND i Debian-stil

/etc/bind/named.conf

filen /etc/bind/named.conf vi lader det være, når det er installeret.

/etc/bind/named.conf.options

filen /etc/bind/named.conf.options skal have følgende indhold:

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

root @ dnslinux: ~ # nano /etc/bind/named.conf.options
indstillinger {katalog "/ var / cache / bind"; // Hvis der er en firewall mellem dig og navneserverne, du vil // til at tale med, skal du muligvis rette firewallen, så flere // porte kan tale. Se http://www.kb.cert.org/vuls/id/800113 // Hvis din internetudbyder leverede en eller flere IP-adresser til stabile // navneservere, vil du sandsynligvis bruge dem som videresendere. // Fjern kommentar til den følgende blok, og indsæt adresserne, der erstatter // all-0's pladsholder. // speditører {// 0.0.0.0; //}; // ================================================== ====================== $ // Hvis BIND logger fejlmeddelelser om, at rodnøglen er udløbet, // skal du opdatere dine nøgler. Se https://www.isc.org/bind-keys // =================================== ====================================== $

    // Vi ønsker ikke DNSSEC
        dnssec-aktiveret nej;
        //dnssec-validering auto;

        autor-nxdomæne nr; # er i overensstemmelse med RFC1035

 // Vi behøver ikke at lytte efter IPv6-adresser
        // listen-on-v6 {any; };
    lyt-på-v6 {ingen; };

 // For kontrol fra localhost og sysadmin
    // gennem // dig mordor.fan axfr // dig 10.10.10.in-addr.arpa axfr // dig _msdcs.mordor.fan axfr // Vi har ikke Slave DNS ... indtil nu
 tillad-overførsel {localhost; 10.10.10.1; };
};

// Logning BIND
logning {

        kanalforespørgsler {
        fil "/var/log/named/queries.log" version 3 størrelse 1m;
        sværhedsgrad info;
        udskrivningstid ja;
        print-sværhedsgrad ja;
        print-kategori ja;
        };

        kanalforespørgselsfejl {
        fil "/var/log/named/query-error.log" version 3 størrelse 1m;
        sværhedsgrad info;
        udskrivningstid ja;
        print-sværhedsgrad ja;
        print-kategori ja;
        };

                                
kategoriforespørgsler {
         forespørgsler
         };

kategori forespørgsel-fejl {
         forespørgsel-fejl;
         };

};

• Vi introducerer fangsten af ​​BIND-logfiler som en NY optræden i artikelserien om emnet. Vi opretter len mappe og filer, der kræves til Logning af BINDEN:

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

Vi kontrollerer syntaksen for de konfigurerede filer

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

/etc/bind/named.conf.local

Vi opretter filen /etc/bind/zones.rfcFreeBSD med det samme indhold som angivet i DNS og DHCP i Debian 8 "Jessie".

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

filen /etc/bind/named.conf.local skal have følgende indhold:

// // Lav en lokal konfiguration her // // Overvej at tilføje 1918-zoner her, hvis de ikke bruges i din // organisation
inkluderer "/etc/bind/zones.rfc1918"; inkluderer "/etc/bind/zones.rfcFreeBSD";

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

zone "_msdcs.mordor.fan" {type master;
 check-navne ignorere; fil "/etc/bind/db._msdcs.mordor.fan"; }; root @ dnslinux: ~ # navngivet-checkconf
root @ dnslinux: ~ #

Zone arkiv mordor.fan

root @ dnslinux: ~ # nano /var/lib/bind/db.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; seriel 1D; opdater 1H; prøv igen 1W; udløber 3H); minimum eller; Negativ cachetid for at leve;
; VÆR MEGET FORSIGTIG MED FØLGENDE OPTAGELSER
@ IN NS dnslinux.mordor.fan.
@ IN A 10.10.10.5
@ IN MX 10 blackelf.mordor.fan. @ IN TXT "Velkommen til The Dark Lan of Mordor";
_msdcs.mordor.fan. I NS dnslinux.mordor.fan.
;
dnslinux.mordor.fan. I A 10.10.10.5
; SLUT MEGET OMHYGGELIGT MED FØLGENDE OPTAGELSER;
DomainDnsZones.mordor.fan. IN A 10.10.10.3 ForestDnsZones.mordor.fan. I A 10.10.10.3; ; GLOBAL 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. ; ; Modificeret og privat LDAP for en 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. ; ; Modificeret og privat KERBEROS af en 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. ; ; Optager A med fast IP -> Servere blackelf.mordor.fan. I A 10.10.10.9 blackspider.mordor.fan. I A 10.10.10.10 darklord.mordor.fan. IN A 10.10.10.6 mamba.mordor.fan. I A 10.10.10.4 palantir.mordor.fan. I A 10.10.10.11
sauron.mordor.fan. I A 10.10.10.3
shadowftp.mordor.fan. IN A 10.10.10.8 troll.mordor.fan. I A 10.10.10.7; ; CNAME registrerer ad-dc.mordor.fan. I CNAME sauron.mordor.fan. blog.mordor.fan. I CNAME troll.mordor.fan. fileserver.mordor.fan. I CNAME mamba.mordor.fan. ftpserver.mordor.fan. I CNAME shadowftp.mordor.fan. mail.mordor.fan. I CNAME balckelf.mordor.fan. openfire.mordor.fan. I CNAME palantir.mordor.fan. proxy.mordor.fan. I CNAME darklord.mordor.fan. www.mordor.fan. I CNAME blackspider.mordor.fan.

root @ dnslinux: ~ # navngivet-checkzone mordor.fan /var/lib/bind/db.mordor.fan 
zone mordor.fan/IN: indlæst serie 1 OK

Tiderne TTL 600 af alle SRV-registre opbevarer vi dem, hvis vi installerer en Slave BIND i tider at gå. Disse poster repræsenterer Active Directory®-tjenester, der for det meste læser data fra din LDAP-database. Da databasen ændres ofte, skal synkroniseringstiderne holdes korte i et Master - Slave DNS-skema. I henhold til Microsoft-filosofien observeret fra Active Directory 2000 til 2008 opretholdes værdien på 600 for disse typer SRV-poster.

masse TTL'er af serverne med fast IP, er de under den angivne tid i SOA på 3 timer.

Zonefil 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; seriel 1D; opdater 1H; prøv igen 1W; udløber 3H); minimum eller; Negativ cachetid for at leve; @ IN NS dnslinux.mordor.fan. ; 10 IN PTR blackspider.mordor.fan. 11 I PTR palantir.mordor.fan. 3 I PTR sauron.mordor.fan. 4 I PTR mamba.mordor.fan. 5 I PTR dnslinux.mordor.fan. 6 I PTR darklord.mordor.fan. 7 I PTR troll.mordor.fan. 8 IN PTR shadowftp.mordor.fan. 9 IN PTR blackelf.mordor.fan.

root @ dnslinux: ~ # navngivet-checkzone 10.10.10.in-addr.arpa /var/lib/bind/db.10.10.10.in-addr.arpa 
zone 10.10.10.in-addr.arpa/IN: indlæst seriel 1 OK

Zonefil _msdcs.mordor.fan

Lad os tage højde for, hvad der anbefales i filen /usr/share/doc/bind9/README.Debian.gz Om placeringen af ​​filerne i Master Zones, der ikke udsættes for dynamiske opdateringer af DHCP.

root @ dnslinux: ~ # nano /etc/bind/db._msdcs.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; seriel 1D; opdater 1H; prøv igen 1W; udløber 3H); minimum eller; Negativ cachetid for at leve; @ IN NS dnslinux.mordor.fan. ; ; ; GLOBAL KATALOG gc._msdcs.mordor.fan. 600 IN A 10.10.10.3; ; Aliasser -i den modificerede og private LDAP-database i en Active Directory- af SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 I CNAME sauron.mordor.fan. ; ; Modificeret og privat LDAP for en Active Directory _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 100 IN SRV 389 sauron.mordor.fan. _ldap._tcp.600d0d-100fdb-389cf-a18-d3360c8b40d678.domæner._msdcs.mordor.fan. 7 IN SRV 420 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 6 IN SRV 775 600 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 0 IN SRV 100 389 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. ; ; KERBEROS modificeret og privat fra en Active Directory _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 100 IN SRV 3268 600 0 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 100 IN SRV 3268 600 0 sauron.mordor.fan.

Vi kontrollerer syntaksen, og vi kan ignorere den fejl, den returnerer, da i konfigurationen af ​​denne zone i filen /etc/bind/named.conf.local vi inkluderer erklæringen check-navne ignorere;. Zonen indlæses korrekt af BIND.

root @ dnslinux: ~ # navngivet-checkzone _msdcs.mordor.fan /etc/bind/db._msdcs.mordor.fan 
/etc/bind/db._msdcs.mordor.fan:14: gc._msdcs.mordor.fan: dårlig ejernavn (kontrolnavne) zone _msdcs.mordor.fan/IN: indlæst serie 1 OK

root @ dnslinux: ~ # systemctl genstart bind9.service 
root @ dnslinux: ~ # systemctl status bind9.service 
● bind9.service - BIND Domain Name Server Loaded: loaded (/lib/systemd/system/bind9.service; enabled) Drop-In: /run/systemd/generator/bind9.service.d └─50-insserv.conf- $ named.conf Aktiv: aktiv (kører) siden sø 2017-02-12 08:48:38 EST; 2s siden Docs: mand: navngivet (8) Proces: 859 ExecStop = / usr / sbin / rndc stop (kode = afsluttet, status = 0 / SUCCESS) Hoved PID: 864 (navngivet) CGroup: /system.slice/bind9.service └─864 / usr / sbin / navngivet -f -u bind 12 feb 08:48:38 dnslinux navngivet [864]: zone 3.efip6.arpa/IN: indlæst seriel 1. feb 12 08:48:38 dnslinux navngivet [864 ]: zone befip6.arpa/IN: indlæst seriel 1. februar 12 08:48:38 dnslinux navngivet [864]: zone 0.efip6.arpa/IN: indlæst seriel 1. februar 12 08:48:38 dnslinux navngivet [864]: zone 7.efip6.arpa/IN: indlæst seriel 1 feb 12 08:48:38 dnslinux navngivet [864]: zone mordor.fan/IN: indlæst seriel 1 feb 12 08:48:38 dnslinux navngivet [864]: zoneeksempel .org / IN: indlæst seriel 1. februar 12 08:48:38 dnslinux med navnet [864]: zone _msdcs.mordor.fan/IN: indlæst seriel 1. februar 12 08:48:38 dnslinux med navnet [864]: zone ugyldig / IN : indlæst serie 1. feb. 12 08:48:38 dnslinux med navnet [864]: alle zoner er indlæst
12. feb 08:48:38 dnslinux med navnet [864]: kører

Vi konsulterer BIND

Før Efter installation af DHCP skal vi udføre en række kontroller, der inkluderer endda tilslutning til en Windows 7-klient til domænet mordor.fan repræsenteret af Active Directory installeret på computeren sauron.mordor.fan.

Den første ting, vi skal gøre, er at stoppe DNS-tjenesten på computeren sauron.mordor.fan, og erklær i din netværksgrænseflade, at din DNS-server fra nu af bliver den 10.10.10.5 dnslinux.mordor.fan.

I en konsol på selve serveren sauron.mordor.fan vi udfører:

Microsoft Windows [version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. Alle rettigheder forbeholdes.

C: \ Brugere \ Administrator> nslookup
Standardserver: dnslinux.mordor.fan Adresse: 10.10.10.5

> gc._msdcs
Server: dnslinux.mordor.fan Adresse: 10.10.10.5 Navn: gc._msdcs.mordor.fan Adresse: 10.10.10.3

> mordor.fan
Server: dnslinux.mordor.fan Adresse: 10.10.10.5 Navn: mordor.fan Adresse: 10.10.10.3

> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs
Server: dnslinux.mordor.fan Adresse: 10.10.10.5 Navn: sauron.mordor.fan Adresse: 10.10.10.3 Aliaser: 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan

> sæt type = SRV
> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
Server: dnslinux.mordor.fan Adresse: 10.10.10.5 _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan SRV serv isplacering: prioritet = 0 vægt = 100 port = 88 svr værtsnavn = sauron.mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan internetadresse = 10.10.10.3 dnslinux.mordor.fan internetadresse = 10.10.10.5
> _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs
Server: dnslinux.mordor.fan Adresse: 10.10.10.5 _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domæner._msdcs.mordor.fan SRV-serviceplacering: prioritet = 0 vægt = 100 port = 389 svr værtsnavn = sauron .mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan internetadresse = 10.10.10.3 dnslinux.mordor.fan internetadresse = 10.10.10.5
> afslut

C: \ Brugere \ Administrator>

DNS-forespørgsler lavet af sauron.mordor.fan er tilfredsstillende.

Det næste trin vil være at oprette en anden virtuel maskine med Windows 7 installeret. Da vi stadig ikke har DHCP-tjenesten installeret, giver vi computeren navnet «win7»IP-adressen 10.10.10.251. Vi erklærer også, at din DNS-server vil være 10.10.10.5 dnslinux.mordor.fan, og at søgedomænet vil være mordor.fan. Vi registrerer ikke den computer i DNS, fordi vi også bruger den til at teste DHCP-tjenesten, efter at vi har installeret den.

Dernæst åbner vi en konsol CMD og i det udfører vi:

Microsoft Windows [version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle rettigheder forbeholdes.

C: \ Brugere \ buzz> nslookup
Standardserver: dnslinux.mordor.fan Adresse: 10.10.10.5

> mordor.fan
Server: dnslinux.mordor.fan Adresse: 10.10.10.5 Navn: mordor.fan Adresse: 10.10.10.3

> sæt type = SRV
> _ldap._tcp.DomainDnsZones
Server: dnslinux.mordor.fan Adresse: 10.10.10.5 _ldap._tcp.DomainDnsZones.mordor.fan SRV serviceplacering: prioritet = 0 vægt = 0 port = 389 svr værtsnavn = sauron.mordor.fan mordor.fan navneserver = dnslinux.mordor .fan sauron.mordor.fan internetadresse = 10.10.10.3 dnslinux.mordor.fan internetadresse = 10.10.10.5
> _kpasswd._udp
Server: dnslinux.mordor.fan Adresse: 10.10.10.5 _kpasswd._udp.mordor.fan SRV-serviceplacering: prioritet = 0 vægt = 0 port = 464 svr værtsnavn = sauron.mordor.fan mordor.fan navneserver = dnslinux.mordor.fan sauron.mordor.fan internetadresse = 10.10.10.3 dnslinux.mordor.fan internetadresse = 10.10.10.5
> _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones
Server: dnslinux.mordor.fan Adresse: 10.10.10.5 _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan SRV serv isplacering: prioritet = 0 vægt = 0 port = 389 svr værtsnavn = sauron. mordor.fan mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan internetadresse = 10.10.10.3 dnslinux.mordor.fan internetadresse = 10.10.10.5
> frakørsel

C: \ Brugere \ buzz>

DNS-forespørgsler fra klienten «win7»Var også tilfredsstillende.

I Active Directory opretter vi brugeren «Saruman«, Med det formål at bruge det, når du tilmelder dig klienten win7 til domænet mordor.fan., ved hjælp af metoden «Netværks-id«, Brug af brugernavne saruman@mordor.fan y administrator@mordor.fan. Deltagelsen var vellykket og bevises ved følgende skærmbillede:

Om dynamiske opdateringer i Microsoft® DNS og BIND

Da vi har stoppet DNS-tjenesten i Active Directory®, var det ikke muligt for klienten «win7»Registrer dit navn og din IP-adresse i den pågældende DNS. Meget mindre i dnslinux.mordor.fan da vi ikke afgav nogen erklæring tilladelse-opdatering for et af de involverede områder.

Og det var her, den gode kamp med min ven blev dannet Fuegian. I min første e-mail om dette aspekt kommenterede jeg:

• Microsofts artikler om brugen af ​​BIND og Active Directory® anbefaler, at, især Direct Zone, får lov til at blive opdateret -trængte ind- direkte af Windows-klienter, der allerede er knyttet til Active Directory-domænet.
• Derfor er som standard DNS-zoner i en Active Directory® Secure Dynamic Updates tilladt. af Windows-klienter, der allerede er tilsluttet Active Directory-domænet. Hvis de ikke er forenede, afstår de fra konsekvenserne.
• DNS i en Active Directory understøtter dynamiske opdateringer "kun sikker", "usikker og sikker" eller "ingen", hvilket er det samme som at sige NO-opdateringer eller ingen.
• Ja virkelig Microsoft Philosophy accepterer ikke, at kunderne IKKE opdaterer deres data i deres DNS (er), den vil ikke lade åbne muligheden for at deaktivere dynamiske opdateringer i deres DNS (er), medmindre denne mulighed forbliver til mere skjulte formål.
• Microsoft tilbyder "Sikkerhed" til gengæld for mørke, som en kollega og ven, der bestod Microsft®-certifikater, fortalte mig det. Rigtigt. Derudover bekræftede El Fueguino det for mig.
• En klient, der f.eks. Erhverver en IP-adresse via DHCP installeret på en UNIX® / Linux-maskine, kan ikke løse IP-adressen for sit eget navn indtil du er knyttet til Active Directory-domænet, så længe Microsoft® eller en BIND bruges som DNS uden dynamiske opdateringer af DHCP.
• Hvis jeg installerer DHCP i selve Active Directory®, skal jeg erklære, at zoner opdateres af Microsoft® DHCP.
• Hvis vi skal bruge BIND som DNS til Windows-netværket, er den logiske og anbefalede ting, at vi installerer BIND-DHCP-parret, hvor sidstnævnte dynamisk opdaterer BIND og sagen afsluttes.
• I en verden af ​​LAN-netværk på UNIX® / Linux, da dynamiske opdateringer blev opfundet på BIND, er kun Mr. DHCP tilladt «trænge ind»Til fru BIND med sine opdateringer. Den afslapning, der er med orden, tak.
• Når jeg erklærer i zonen mordor.fan for eksempel: tillad opdatering {10.10.10.0/24; };, BIND selv informerer mig, når jeg starter eller genstarter det, at:

  • zone 'mordor.fan' tillader opdateringer efter IP-adresse, som er usikker

• I den hellige, UNIX® / Linux-verden er sådan kyndig med DNS simpelthen afviselig.

Du kan forestille dig resten af ​​udvekslingen med min ven Fuegian gennem emails, Telegram chat, telefonopkald betalt af ham (selvfølgelig mand, jeg har ikke et kilo for det) og endda beskeder gennem bæreduer i det XXI århundrede!

Han truede endda med ikke at sende mig en søn af hans kæledyr, hans leguan «Petra»At han havde lovet mig som en del af betalingen. Der var jeg virkelig bange. Så jeg startede igen, men fra en anden vinkel.

• Den "næsten" Active Directory, der kan opnås med Samba 4, løser dette aspekt på en mesterlig måde, både når vi bruger dets interne DNS eller BIND, der er kompileret til at understøtte DLZ-zoner - Dinamyc-belastede zonereller dynamisk indlæste zoner.
• Det lider fortsat under det samme: når en klient erhverver en IP-adresse via en DHCP installeret i andre UNIX® / Linux-maskine, kan du ikke løse IP-adressen på dit eget navn indtil det er knyttet til domænet for Samba 4 AD-DC.
• Integrer BIND-DLZ- og DHCP-duoen på den samme maskine, hvor AD-DC Samba 4 det er et job for en rigtig specialist.

Fuegian Han kaldte mig til kapitel og råbte til mig: Vi taler IKKE om AD-DC Samba 4, men fra Microsoft® Active Directory®!. Og jeg svarede ydmygt, at jeg var meget glad for en del af følgende artikler, som jeg skulle skrive.

Det var da jeg fortalte ham, at den endelige beslutning om dynamiske opdateringer af klientcomputere på hans netværk blev overladt til sin egen frie vilje. At jeg kun ville give ham den tip skrevet før om tillad opdatering {10.10.10.0/24; };og mere intet. At jeg ikke var ansvarlig for, hvad der skyldtes den promiskuitet, som hver Windows-klient - eller Linux - i deres netværk «vil trænge ind»Med straffrihed over for BIND.

Hvis du vidste, min ven, læser, at det var slutpunktet for slagsmål, ville du ikke tro det. Min ven Fuegian han accepterede løsningen - og han vil sende mig leguanen «Pete«- at jeg nu deler med dig.

Vi installerer og konfigurerer DHCP

For flere detaljer læs DNS og DHCP i Debian 8 "Jessie".

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

root @ dnslinux: ~ # nano / etc / default / isc-dhcp-server .... # På hvilke grænseflader skal DHCP-serveren (dhcpd) tjene DHCP-anmodninger? # Adskil flere grænseflader med mellemrum, f.eks. "Eth0 eth1". INTERFACES = "eth0" root @ dnslinux: ~ # dnssec-keygen -a HMAC-MD5 -b 128 -r / dev / urandom -n BRUGER dhcp-key
Kdhcp-nøgle. +157 + 29836

root @ dnslinux: ~ # cat Kdhcp-key. +157 + 29836. privat
Privatnøgleformat: v1.3 Algoritme: 157 (HMAC_MD5) Nøgle: 3HT / bg / 6YwezUShKYofj5g == Bits: AAA = Oprettet: 20170212205030 Publicer: 20170212205030 Aktivér: 20170212205030

root @ dnslinux: ~ # nano dhcp.key
nøgle dhcp-nøgle {algoritme hmac-md5; hemmelighed "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
// // Lav en lokal konfiguration her // // Overvej at tilføje 1918-zoner her, hvis de ikke bruges i din // organisation inkluderer "/etc/bind/zones.rfc1918"; inkluderer "/etc/bind/zones.rfcFreeBSD";
// Glem ikke ... Jeg har glemt og betalt med fejl. ;-)
inkluderer "/etc/bind/dhcp.key";


zone "mordor.fan" {type master;
        tillad opdatering {10.10.10.3; nøgle dhcp-nøgle; };
        fil "/var/lib/bind/db.mordor.fan"; }; zone "10.10.10.in-addr.arpa" {type master;
        tillad opdatering {10.10.10.3; nøgle dhcp-nøgle; };
        fil "/var/lib/bind/db.10.10.10.in-addr.arpa"; }; zone "_msdcs.mordor.fan" {type master; check-navne ignorere; fil "/etc/bind/db._msdcs.mordor.fan"; };

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

root @ dnslinux: ~ # nano /etc/dhcp/dhcpd.conf
ddns-opdatering-stil midlertidig; ddns-opdateringer på; ddns-domænenavn "mordor.fan."; ddns-rev-domænenavn "in-addr.arpa."; ignorere klientopdateringer; autoritativ; option ip-videresendelse fra; option domænenavn "mordor.fan"; inkluderer "/etc/dhcp/dhcp.key"; zone mordor.fan. {primær 127.0.0.1; nøgle dhcp-nøgle; } zone 10.10.10.in-addr.arpa. {primær 127.0.0.1; nøgle dhcp-nøgle; } redlokal med delt netværk {subnet 10.10.10.0 netmask 255.255.255.0 {option routere 10.10.10.1; option undernetmaske 255.255.255.0; mulighed for udsendelsesadresse 10.10.10.255; option domæne-servere 10.10.10.5; option 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. Alle rettigheder forbeholdes. For information, besøg venligst https://www.isc.org/software/dhcp/ Config file: /etc/dhcp/dhcpd.conf Databasefil: /var/lib/dhcp/dhcpd.leases PID-fil: / var / run /dhcpd.pid

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

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

Hvad er relateret til Kontrol med klienterOg Manuel ændring af zonefiler, vi overlader det til dig, læserven, at læse det direkte fra DNS og DHCP i Debian 8 "Jessie", og anvend det på dine faktiske forhold. Vi gennemførte alle de nødvendige kontroller og opnåede tilfredsstillende resultater. Naturligvis sender vi en kopi af dem alle til Fuegian. Der vil ikke være mere!

tips

General

• Få en god del tålmodighed inden du starter.
  
• Først skal du installere og konfigurere BIND. Kontroller alt, og se alle de poster, du har deklareret i hver fil af de tre eller flere zoner, både fra Active Directory og fra selve DNS-serveren. Hvis det er muligt, fra en Linux-maskine, der ikke er knyttet til domænet, skal du foretage de nødvendige DNS-forespørgsler til BIND.
  
• Deltag i en Windows-klient med en fast IP-adresse til det eksisterende domæne, og kontroller alle BIND-indstillinger igen fra Windows-klienten.
• Når du utvivlsomt er sikker på, at din helt nye BIND-konfiguration er helt korrekt, skal du vove dig ud for at installere, konfigurere og starte DHCP-tjenesten.
• I tilfælde af fejl gentages hele proceduren fra nul 0.
• Vær forsigtig med kopiering og indsættelse! og de ekstra mellemrum i hver linje i de namngivne.conf.xxxx-filer
  
• Bagefter klagede han ikke - meget mindre til min ven Fuegian - over at han ikke blev ordentligt rådgivet.

Andre tips

• Del og erobre.
• I et SMV-netværk er det sikrere og mere fordelagtigt at installere en autoritativ BIND til de interne LAN-zoner, der ikke gentager sig til nogen rodserver: rekursionsnr..
• I et SMV-netværk placeret under en internetadgangsudbyder - ISPmåske tjenesterne proxy y SMTP de har brug for at løse domænenavne på Internettet. Han Blæksprutte du har mulighed for at erklære din DNS ekstern eller ej, mens du er på en mailserver baseret på postfix o MDaemon® Vi kan også erklære de DNS-servere, som vi vil bruge i denne tjeneste. I tilfælde som dette, dvs. tilfælde, der ikke leverer tjenester til Internettet, og som er under et Internet Service Providers, kan du installere en BIND med Udkørselsmaskine peger på DNS ​​for ISP, og erklære det som sekundær DNS på de servere, der har brug for at løse eksterne forespørgsler til LAN, ellers er det muligt at erklære dem gennem deres egne konfigurationsfiler.
• Hvis du har en delegeret zone under hele dit ansvarSå krager en anden hane:
  • Installer en DNS-server baseret på NSD, som pr. definition er en autoritativ DNS-server, der svarer på forespørgsler fra computere på Internettet. For nogle oplysninger egnethedshow nsd. Protect Beskyt det meget godt med så mange brandvægge som nødvendigt. Både hardware og software. Det vil være en DNS til internettet, og at «Tsar»Vi må ikke give det med lave bukser. 😉
  • Da jeg aldrig har set mig selv i en sag som denne, det vil sige fuldstændig ansvarlig for en delegeret zone, bliver jeg nødt til at tænke meget godt over, hvad jeg kan anbefale til løsning af domænenavne uden for vores LAN for de tjenester, der har brug for det . SMV-netværksklienter har ikke rigtig brug for det. Konsulter speciallitteratur eller en specialist inden for disse emner, da jeg langt fra er en af ​​dem. Helt seriøst.
  • Rekursion findes ikke på autoritære servere. Okay?. Hvis nogen overvejer at gøre det med en BIND.
• Selvom vi udtrykkeligt angiver i filen /etc/dhcp/dhcpd.conf erklæringen ignorere klientopdateringer;, hvis vi kører på en computerkonsol dnslinux.mordor.fan ordren journalctl -f, vil vi se, at når vi starter klienten win7.mordor.fan vi får følgende fejlmeddelelser:

  • 12. feb 16:55:41 dnslinux navngivet [900]: klient 10.10.10.30 # 58762: opdatering 'mordor.fan/IN' nægtet
    12. feb 16:55:42 dnslinux navngivet [900]: klient 10.10.10.30 # 49763: opdatering 'mordor.fan/IN' nægtet
    12. feb 16:56:23 dnslinux navngivet [900]: klient 10.10.10.30 # 63161: opdatering 'mordor.fan/IN' nægtet
    

  • For at fjerne disse meddelelser skal vi gå til de avancerede indstillinger for netværkskortkonfigurationen og fjerne markeringen fra indstillingen «Registrer denne forbindelses adresser i DNS«. Det forhindrer klienten i at prøve at selvregistrere sig i Linux DNS for evigt og slutningen af ​​problemet. Beklager, men jeg har ikke en kopi af Windows 7 på spansk. 😉
• For at finde ud af alle de seriøse - og skøre - forespørgsler, en Windows 7-klient stiller, skal du tjekke logforespørgsler.log at for noget erklærer vi det i BIND-konfigurationen. Ordren ville være:

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

• Hvis du ikke tillader dine klientcomputere at oprette forbindelse direkte til Internettet, hvorfor har du så brug for Root DNS-serverne? Dette vil reducere kommandooutputtet markant journalctl -f og fra den foregående, hvis din autoritære DNS-server til de interne zoner ikke opretter forbindelse direkte til Internettet, hvilket anbefales stærkt fra et sikkerhedsmæssigt synspunkt.

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

• Hvis du ikke har brug for erklæringen fra rodserverne, hvorfor har du brug for rekursion - rekursion?

  root @ dnslinux: ~ # nano /etc/bind/named.conf.options
  muligheder {
   ....
   rekursionsnr.
   ....
  };

Specifikke råd, som jeg stadig ikke er særlig klare om

El mand dhcpd.conf fortæller os følgende blandt mange -mange- andre ting:

        Opdateringsoptimeringserklæringen

            flag til opdateringsoptimering;

            Hvis opdateringsoptimeringsparameteren er falsk for en given klient, vil serveren forsøge en DNS-opdatering for den pågældende klient hver gang klienten fornyer sin lejekontrakt, snarere end kun at prøve en opdatering, når det ser ud til at være nødvendigt. Dette gør det lettere for DNS at helbrede fra databasekonsekvenser lettere, men prisen er, at DHCP-serveren skal udføre mange flere DNS-opdateringer. Vi anbefaler at læse denne indstilling aktiveret, hvilket er standard. Denne indstilling påvirker kun adfærdsproceduren for det midlertidige DNS-opdateringsskema og har ingen indvirkning på ad-hoc DNS-opdateringsskemaet. Hvis denne parameter ikke er angivet, eller hvis den er sand, opdateres DHCP-serveren kun, når klientoplysningerne ændres, klienten får en anden lejekontrakt, eller klientens lejekontrakt udløber.

Den mere eller mindre nøjagtige oversættelse eller fortolkning overlades til dig, kære læser.

Personligt er det sket for mig - og det skete under udarbejdelsen af ​​denne artikel - at når jeg linker en BIND til en Active Directory®, er den fra Microsft® eller Samba 4, hvis jeg ændrer navnet på en klientcomputer, der er registreret i Active Directory®-domæne eller af AD-DC af Samba 4, holder det sit gamle navn og IP-adresse i Direct Zone og ikke omvendt, som opdateres korrekt med det nye navn. Med andre ord kortlægges de gamle og nye navne til den samme IP-adresse i den direkte zone, mens omvendt kun det nye navn vises. For at forstå mig godt, skal du prøve det selv.

Jeg synes, det er en slags hævn mod Fuegian -ikke for mig, tak for at prøve at migrere dine tjenester til Linux.

Naturligvis forsvinder det gamle navn, når det er TTL 3600eller det tidspunkt, vi har deklareret i DHCP-konfigurationen. Men vi vil have det til at forsvinde med det samme, som det sker i en BIND + DHCP uden Active Directory igennem.

Løsningen på den situation fandt jeg ved at indsætte erklæringen opdateringsoptimering falsk; i slutningen af ​​toppen af ​​filen /etc/dhcp/dhcpd.conf:

ddns-opdatering-stil midlertidig; ddns-opdateringer på; ddns-domænenavn "mordor.fan."; ddns-rev-domænenavn "in-addr.arpa."; ignorere klientopdateringer;
opdateringsoptimering falsk;

Hvis nogen læsere ved mere om det, bedes du oplyse mig. Jeg vil sætte stor pris på det.

Resumé

Vi har haft en masse sjov med emnet, ikke? Ingen lidelse, fordi vi har en BIND, der fungerer som en DNS-server i et Microsoft®-netværk, der tilbyder alle SRV-poster og reagerer passende på de DNS-forespørgsler, der er stillet til dem. På den anden side har vi en DHCP-server, der giver IP-adresser og dynamisk opdaterer BIND-zoner korrekt.

Men vi kan ikke spørge ... for øjeblikket.

Jeg håber min ven Fuegian vær glad og tilfreds med det første skridt i din migrering til Linux for at gøre de uudholdelige omkostninger ved Microsft® teknisk support tålelige.

Vigtig note

Karakter "Fuegian»Er fuldstændig fiktiv og et produkt af min fantasi. Enhver lighed eller tilfældighed med rigtige mennesker er den samme: Ren ufrivillig tilfældighed fra min side. Jeg oprettede det kun for at gøre skrivning og læsning af denne artikel lidt underholdende. Hvis du nu kan fortælle mig, at DNS-problemet er mørkt,