BIND og Active Directory®

Generell indeks for serien: Datanettverk for SMB: Introduksjon

Hei venner!. Hovedmålet med denne artikkelen er å vise hvordan vi kan integrere DNS-tjenesten basert på BIND9 i et Microsoft-nettverk, veldig vanlig i mange SMB.

Det kommer av den offisielle forespørselen fra en venn som bor i La Tierra del Fuego -Fuegian- spesialisert på Microsoft®-nettverk - sertifikater inkludert - for å veilede deg i denne delen av overføringen av serverne dine til Linux. Kostnadene ved støtte Teknikere som betaler Microsoft® er allerede Uutholdelig for selskapet hvor han jobber og som han er hovedaksjonær i.

Min venn Fuegian han har en god sans for humor, og siden han så serien med tre filmer «Ringenes Herre»Han ble betatt av mange av navnene på hans mørke karakterer. Så leservenn, ikke bli overrasket over navnene på domenet ditt og serverne dine.

For nykommere i emnet, og før du fortsetter å lese, anbefaler vi at du leser og studerer de tre tidligere artiklene om SMB-nettverk:

Det er som å se på tre av de fire delene av «Underverden»Publisert til i dag, og at dette er den fjerde.

Generelle parametere

Etter flere utvekslinger via e-postTil slutt var jeg klar over hovedparametrene til ditt nåværende nettverk, som er:

Domenenavn mordor.fan LAN Network 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 brannmur på Kerios troll.mordor.fan. 10.10.10.7 Blogg basert på ... husker ikke shadowftp.mordor.fan. 10.10.10.8 FTP-server blackelf.mordor.fan. 10.10.10.9 Full e-posttjeneste blackspider.mordor.fan. 10.10.10.10 WWW-tjenesten palantir.mordor.fan. 10.10.10.11 Chat på Openfire for Windows

Jeg ba om tillatelse til Fuegian å sette så mange aliaser som er nødvendige for å rydde tankene mine og ga meg tillatelse:

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

Jeg erklærte alle viktige DNS-poster i installasjonen av en Active Directory Windows 2008 som jeg ble tvunget til å implementere for å veilede meg i utformingen av dette innlegget.

Om Active Directory DNS SRV-poster

Registerene SRV o Service Locators - mye brukt i Microsoft Active Directory - er definert i Forespørsel om kommentarer RFC 2782. De tillater lokalisering av en tjeneste basert på TCP / IP-protokollen gjennom et DNS-spørsmål. For eksempel kan en kunde i et Microsoft-nettverk finne plasseringen til domenekontrollere - Domenekontrollere som gir LDAP-tjenesten over TCP-protokollen på port 389 gjennom et enkelt DNS-spørsmål.

Det er normalt at i skogene - Skogog trær - Trær i et stort Microsoft-nettverk er det flere domenekontrollere. Ved å bruke SRV-postene i de forskjellige sonene som utgjør domenenavnområdet til det nettverket, kan vi opprettholde en liste over servere som tilbyr lignende kjente tjenester, bestilt etter preferanse i henhold til transportprotokollen og porten til hver av servere.

I Forespørsel om kommentarer RFC 1700 Universelle symbolske navn for kjente tjenester er definert - Kjent tjeneste, og navn som «_telnet" '_smtp»For tjenester telnet y SMTP. Hvis et symbolsk navn ikke er definert for en kjent tjeneste, kan et lokalt navn eller et annet navn brukes i henhold til brukerens preferanser.

Hensikten med hvert felt «spesiell»Det som brukes i erklæringen om en SRV Resource Record er følgende:

Domene: "Pdc._msdcs.mordor.fan.«. DNS-navnet på tjenesten som SRV-posten refererer til. DNS-navnet i eksemplet betyr -mer eller mindre- Primær domenekontroller av området _msdcs.mordor.fan.
Service: "_Ldap". Symbolsk navn på tjenesten som leveres definert i henhold til Forespørsel om kommentarer RFC 1700.
Protokoll: "_Tcp". Indikerer type transportprotokoll. Kan vanligvis ta verdiene _tcp o _udp, selv om - og faktisk - enhver form for transportprotokoll som er angitt i Forespørsel om kommentarer RFC 1700. For eksempel for en tjeneste chatte protokollbasert XMPP, ville dette feltet ha verdien av _xmpp.
Prioritet'0«. Erklære prioritet eller preferanse for Vert som tilbyr denne tjenesten som vi får se senere. DNS-spørringene til klienter om tjenesten som er definert av denne SRV-posten, vil etter å ha mottatt riktig svar, prøve å kontakte den første tilgjengelige verten med det laveste nummeret som er oppført i feltet. Prioritet. Verdiområdet som dette feltet kan ta er 0 den 65535.
Vekt'100«. Kan brukes i kombinasjon med Prioritet å tilby en lastbalanseringsmekanisme når det er flere servere som gir den samme tjenesten. Det skal være en lignende SRV-post for hver server i Zone-filen, med navnet deklarert i feltet Vert som tilbyr denne tjenesten. Før servere med like verdier i feltet Prioritet, feltverdien Vekt den kan brukes som et ekstra preferansenivå for å oppnå et nøyaktig servervalg for lastbalansering. Verdiområdet som dette feltet kan ta er 0 den 65535. Hvis belastningsbalansering ikke er nødvendig, for eksempel som for en enkelt server, anbefales det å tilordne verdien 0 for å gjøre SRV-posten lettere å lese.
Portnummer - Port'389«. Portnummer i Vert som tilbyr denne tjenesten som gir tjenesten som er angitt i feltet Service. Portnummeret som anbefales for hver type velkjent tjeneste er angitt i Forespørsel om kommentarer RFC 1700, selv om det kan ta en verdi mellom 0 og 65535.
Vert som tilbyr denne tjenesten - Target'sauron.mordor.fan.«. Spesifiserer FQDN som utvetydig identifiserer vert som gir tjenesten angitt av SRV-posten. En platetype «A»I domenenavnområdet for hver FQDN fra serveren eller vert som gir tjenesten. Enklere, en typepost A i direkte sone (r).
- Merk:
  For autoritativt å indikere at tjenesten spesifisert av SRV-posten ikke leveres på denne verten, en.) poeng.

Vi vil bare gjenta at riktig drift av et nettverk eller en Active Directory® er sterkt avhengig av riktig drift av Domain Name Service..

Active Directory DNS-poster

For å gjøre sonene til den nye DNS-serveren basert på BIND, må vi skaffe alle DNS-postene fra Active Directory®. For å gjøre livet lettere, går vi til teamet sauron.mordor.fan -Active Directory® 2008 SR2- og i DNS-administrasjonskonsollen aktiverer vi Zone Transfer -direct og inverse- for hovedsoner som er angitt i denne typen tjenester, som er:

_msdcs.mordor.fan
mordor.fan
10.10.10.in-addr.harpe

Når det forrige trinnet er utført og helst fra en Linux-datamaskin hvis IP-adresse er innenfor området for nettverket som brukes av Windows-nettverket, utfører vi:

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

Husk fra tidligere artikler at IP-adressen til enheten sysadmin.desdelinux.fan Jeg 10.10.10.1 eller 192.168.10.1.

I de tre forrige kommandoene kan vi eliminere alternativet 10.10.10.3 -spør DNS-serveren med den adressen- hvis vi erklærer i filen / Etc / resolv.conf til server-IP sauron.mordor.fan:

buzz@sysadmin:~$ cat /etc/resolv.conf # Generert av NetworkManager-søk desdelinux.fan navneserver 192.168.10.5 navneserver 10.10.10.3

Etter redigering med ekstrem forsiktighet, som tilsvarer en hvilken som helst sonefil i en BIND, vil vi få følgende data:

RR-poster fra den opprinnelige sonen _msdcs.mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs._msdcs.mordor.fan 
; Forhold til SOA og NS _msdcs.mordor.fan. 3600 I 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; ; Aliaser - i den modifiserte og private LDAP-databasen til en Active Directory - av SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 I CNAME sauron.mordor.fan. ; ; Modifisert og privat LDAP for en 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. ; ; Modifisert og privat KERBEROS av en 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.

RR-poster fra den opprinnelige sonen mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs.mordor.fan 
; Forhold til SOA, NS, MX og A-posten som den kartlegger; domenenavnet til IP-adressen til SAURON; Ting fra en Active Directory mordor.fan. 3600 I 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å viktig 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 3268 sauron.mordor.fan. _gc._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. ; ; Modifisert og privat LDAP for en 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. ; ; Modifisert og privat KERBEROS fra en 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. ; ; A poster med faste IP-er -> Blackelf.mordor.fan-servere. 3600 IN A 10.10.10.9 blackspider.mordor.fan. 3600 IN A 10.10.10.10 darklord.mordor.fan. 3600 IN A 10.10.10.6 mamba.mordor.fan. 3600 IN A 10.10.10.4 palantir.mordor.fan. 3600 IN A 10.10.10.11 sauron.mordor.fan. 3600 IN A 10.10.10.3 shadowftp.mordor.fan. 3600 IN A 10.10.10.8 troll.mordor.fan. 3600 IN A 10.10.10.7; ; CNAME registrerer ad-dc.mordor.fan. 3600 I CNAME sauron.mordor.fan. blogg.mordor.fan. 3600 I CNAME troll.mordor.fan. fileserver.mordor.fan. 3600 I CNAME mamba.mordor.fan. ftpserver.mordor.fan. 3600 I CNAME shadowftp.mordor.fan. mail.mordor.fan. 3600 I CNAME balckelf.mordor.fan. openfire.mordor.fan. 3600 I CNAME palantir.mordor.fan. proxy.mordor.fan. 3600 I CNAME darklord.mordor.fan. www.mordor.fan. 3600 I CNAME blackspider.mordor.fan.

RR-poster fra opprinnelig sone 10.10.10.in-addr.arpa

buzz @ sysadmin: ~ $ cat temp / rrs.10.10.10.in-addr.arpa 
; Forhold til SOA og NS 10.10.10.in-addr.arpa. 3600 I 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.

Inntil dette punktet kan vi tro at vi har de nødvendige dataene for å fortsette i vårt eventyr, ikke uten først å observere TTL og andre data som på en veldig kort måte gir oss utdata og direkte observasjon av DNS til en 2008-biters Active Directory® 2 SR64 fra Microsft®.

Bilder av DNS Manager i SAURON

Dnslinux.mordor.fan-teamet.

Hvis vi ser nøye, til IP-adressen 10.10.10.5 ingen navn ble tildelt den nøyaktig slik at den ville bli okkupert av navnet på den nye DNS dnslinux.mordor.fan. For å installere DNS- og DHCP-paret kan vi bli ledet av artiklene DNS og DHCP i Debian 8 "Jessie" y DNS og DHCP på CentOS 7.

Basis operativsystem

Min venn FuegianI tillegg til å være en ekte spesialist i Microsoft® Windows - han har et par sertifikater utstedt av det selskapet - har han lest og praktisert noen av artiklene på stasjonære PC-er publisert i Fra Linux., og han fortalte meg at han uttrykkelig ønsket en løsning basert på Debian. 

For å behage deg, vil vi starte med en frisk, ren installasjon av en server basert på Debian 8 "Jessie". Imidlertid er det vi skal skrive gyldig for CentOS- og openSUSE-distribusjoner hvis artikler vi nevnte tidligere. BIND og DHCP er de samme på alle distroer. Små variasjoner introduseres av pakkeholderne i hver distribusjon.

Vi vil gjøre installasjonen som angitt i DNS og DHCP i Debian 8 "Jessie", tar vare på å bruke IP 10.10.10.5 og nettverket 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 lar den være som den er installert.

/etc/bind/named.conf.options

Filen /etc/bind/named.conf.options bør sitte igjen med følgende innhold:

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

root @ dnslinux: ~ # nano /etc/bind/named.conf.options
alternativer {katalog "/ var / cache / bind"; // Hvis det er en brannmur mellom deg og navneserverne du vil // å snakke med, må du kanskje fikse brannmuren for å tillate at flere // porter snakker. Se http://www.kb.cert.org/vuls/id/800113 // Hvis Internett-leverandøren din oppgav en eller flere IP-adresser for stabile // navneservere, vil du sannsynligvis bruke dem som videresendere. // Fjern merking av følgende blokk, og sett inn adressene som erstatter // all-0s plassholder. // speditører {// 0.0.0.0; //}; // ================================================== = ==================== $ $ // Hvis BIND logger feilmeldinger om at rotnøkkelen er utløpt, // må du oppdatere nøklene. Se https://www.isc.org/bind-keys // =================================== = ===================================== $

    // Vi vil ikke ha DNSSEC
        dnssec-aktivere nei;
        //dnssec-validering auto;

        auth-nxdomain no; # samsvarer med RFC1035

 // Vi trenger ikke lytte etter IPv6-adresser
        // listen-on-v6 {any; };
    listen-on-v6 {none; };

 // For sjekker fra localhost og sysadmin
    // gjennom // dig mordor.fan axfr // dig 10.10.10.in-addr.arpa axfr // dig _msdcs.mordor.fan axfr // Vi har ikke Slave DNS ... før nå
 tillat-overføring {localhost; 10.10.10.1; };
};

// BIND logging
hogst {

        kanalspørsmål {
        fil "/var/log/named/queries.log" versjoner 3 størrelse 1m;
        alvorlighetsinfo;
        utskriftstid ja;
        trykk-alvorlighetsgrad ja;
        utskriftskategori ja;
        };

        kanalsøkefeil {
        fil "/var/log/named/query-error.log" versjoner 3 størrelse 1m;
        alvorlighetsinfo;
        utskriftstid ja;
        trykk-alvorlighetsgrad ja;
        utskriftskategori ja;
        };

                                
kategorispørsmål {
         spørsmål;
         };

feil på kategori {
         spørringsfeil;
         };

};

Vi introduserer fangsten av BIND-loggene som en NUEVO utseende i artikelserien om emnet. Vi lager len mappe og filer som kreves for Logging av BINDEN:

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

Vi sjekker syntaksen til de konfigurerte filene

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

/etc/bind/named.conf.local

Vi oppretter filen /etc/bind/zones.rfcFreeBSD med samme innhold som angitt i DNS og DHCP i Debian 8 "Jessie".

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

Filen /etc/bind/named.conf.local bør sitte igjen med følgende innhold:

// // Gjør noen lokal konfigurasjon her // // Vurder å legge til 1918-sonene her, hvis de ikke brukes i // organisasjonen din
inkluderer "/etc/bind/zones.rfc1918"; inkluderer "/etc/bind/zones.rfcFreeBSD";

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

sone "_msdcs.mordor.fan" {type master;
 sjekknavn ignorerer; fil "/etc/bind/db._msdcs.mordor.fan"; }; root @ dnslinux: ~ # named-checkconf
root @ dnslinux: ~ #

Sonefil mordor.fan

root @ dnslinux: ~ # nano /var/lib/bind/db.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; seriell 1D; oppdater 1H; prøv 1W; utløper 3H); minimum eller; Negativ cachetid for å leve;
; VÆR VELDIG FORSIKTIG MED FØLGENDE OPPTAKER
@ 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 VELDIG NØYE MED FØLGENDE OPPTAKER;
DomainDnsZones.mordor.fan. I 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. ; ; Modifisert 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. ; ; Modifisert og privat KERBEROS fra 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. ; ; A poster med faste IP-er -> Blackelf.mordor.fan-servere. I A 10.10.10.9 blackspider.mordor.fan. I A 10.10.10.10 darklord.mordor.fan. I 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. I ET 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: ~ # named-checkzone mordor.fan /var/lib/bind/db.mordor.fan 
sone mordor.fan/IN: lastet serie 1 OK

Tidene TTL 600 av alle SRV-registre vil vi beholde dem i tilfelle vi installerer en Slave BIND i tider å gå. Disse postene representerer Active Directory®-tjenester som for det meste leser data fra LDAP-databasen din. Siden databasen endres ofte, må synkroniseringstidene holdes korte, i en Master - Slave DNS-ordning. I henhold til Microsofts filosofi observert fra Active Directory 2000 til 2008, opprettholdes verdien på 600 for disse typer SRV-poster.

den TTL av serverne med fast IP, er de under den oppgitte tiden i SOA på 3 timer.

Sonefil 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; seriell 1D; oppdater 1H; prøv 1W; utløper 3H); minimum eller; Negativ cachetid for å leve; @ IN NS dnslinux.mordor.fan. ; 10 IN PTR blackspider.mordor.fan. 11 I PTR palantir.mordor.fan. 3 IN PTR sauron.mordor.fan. 4 I PTR mamba.mordor.fan. 5 IN 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: ~ # named-checkzone 10.10.10.in-addr.arpa /var/lib/bind/db.10.10.10.in-addr.arpa 
sone 10.10.10.in-addr.arpa/IN: lastet serie 1 OK

Sonefil _msdcs.mordor.fan

La oss ta hensyn til hva som anbefales i filen /usr/share/doc/bind9/README.Debian.gz Om plasseringen av filene til hovedsonene som ikke er utsatt for dynamiske oppdateringer av DHCP.

root @ dnslinux: ~ # nano /etc/bind/db._msdcs.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; seriell 1D; oppdater 1H; prøv 1W; utløper 3H); minimum eller; Negativ cachetid for å leve; @ IN NS dnslinux.mordor.fan. ; ; ; GLOBAL KATALOG gc._msdcs.mordor.fan. 600 IN A 10.10.10.3; ; Aliaser - i den modifiserte og private LDAP-databasen til en Active Directory - av SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 I CNAME sauron.mordor.fan. ; ; Modifisert og privat LDAP for en 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. ; ; Modifisert og privat KERBEROS av en 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.

Vi sjekker syntaksen, og vi kan ignorere feilen den returnerer, siden i konfigurasjonen av denne sonen i filen /etc/bind/named.conf.local vi inkluderer uttalelsen sjekknavn ignorerer;. Sonen blir riktig lastet av 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: dårlig eiernavn (kontrollnavn) sone _msdcs.mordor.fan/IN: lastet serie 1 OK

root @ dnslinux: ~ # systemctl start bind9.service på nytt 
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 (kjører) siden søn 2017-02-12 08:48:38 EST; 2s siden Docs: man: named (8) Prosess: 859 ExecStop = / usr / sbin / rndc stop (code = exited, status = 0 / SUCCESS) Main PID: 864 (named) CGroup: /system.slice/bind9.service └─864 / usr / sbin / heter -f -u bind 12 feb 08:48:38 dnslinux heter [864]: sone 3.efip6.arpa/IN: lastet seriell 1. feb 12 08:48:38 dnslinux heter [864 ]: sone befip6.arpa/IN: lastet serie 1. februar 12 08:48:38 dnslinux kalt [864]: sone 0.efip6.arpa/IN: lastet serie 1. februar 12 08:48:38 dnslinux kalt [864]: sone 7.efip6.arpa/IN: lastet serie 1. februar 12 08:48:38 dnslinux kalt [864]: sone mordor.fan/IN: lastet serie 1. februar 12 08:48:38 dnslinux kalt [864]: soneeksempel .org / IN: lastet serie 1. februar 12 08:48:38 dnslinux kalt [864]: sone _msdcs.mordor.fan/IN: lastet serie 1. februar 12 08:48:38 dnslinux kalt [864]: sone ugyldig / IN : lastet serie 1. februar 12 08:48:38 dnslinux med navnet [864]: alle soner lastet
12. feb 08:48:38 dnslinux kalt [864]: rennende

Vi konsulterer BIND

Før Etter å ha installert DHCP, må vi utføre en rekke sjekker som inkluderer til og med å bli med en Windows 7-klient til domenet mordor.fan representert av Active Directory installert på datamaskinen sauron.mordor.fan.

Det første vi må gjøre er å stoppe DNS-tjenesten på datamaskinen sauron.mordor.fan, og erklær i nettverksgrensesnittet at fra nå av blir DNS-serveren din 10.10.10.5 dnslinux.mordor.fan.

I en konsoll på selve serveren sauron.mordor.fan vi utfører:

Microsoft Windows [Versjon 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. Alle rettigheter forbeholdes.

C: \ Brukere \ Administrator> nslookup
Standard server: 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

> sett 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 isplassering: prioritet = 0 vekt = 100 port = 88 svr vertsnavn = sauron.mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan internettadresse = 10.10.10.3 dnslinux.mordor.fan internettadresse = 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.domains._msdcs.mordor.fan SRV-tjenesteplass: prioritet = 0 vekt = 100 port = 389 svr vertsnavn = sauron .mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan internettadresse = 10.10.10.3 dnslinux.mordor.fan internettadresse = 10.10.10.5
> gå ut

C: \ Brukere \ Administrator>

DNS-spørsmål laget av sauron.mordor.fan er tilfredsstillende.

Neste trinn vil være å lage en annen virtuell maskin med Windows 7 installert. Siden vi fremdeles ikke har DHCP-tjenesten installert, vil vi gi datamaskinen navnet «win7»IP-adressen 10.10.10.251. Vi erklærer også at DNS-serveren din vil være den 10.10.10.5 dnslinux.mordor.fan, og at søkedomenet vil være mordor.fan. Vi registrerer ikke datamaskinen i DNS fordi vi også vil bruke den til å teste DHCP-tjenesten etter at vi har installert den.

Deretter åpner vi en konsoll CMD og i den utfører vi:

Microsoft Windows [Versjon 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle rettigheter forbeholdes.

C: \ Brukere \ buzz> nslookup
Standard server: 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

> sett type = SRV
> _ldap._tcp.DomainDnsZones
Server: dnslinux.mordor.fan Adresse: 10.10.10.5 _ldap._tcp.DomainDnsZones.mordor.fan SRV serviceplassering: prioritet = 0 vekt = 0 port = 389 svr vertsnavn = sauron.mordor.fan mordor.fan navneserver = dnslinux.mordor .fan sauron.mordor.fan internettadresse = 10.10.10.3 dnslinux.mordor.fan internettadresse = 10.10.10.5
> _kpasswd._udp
Server: dnslinux.mordor.fan Adresse: 10.10.10.5 _kpasswd._udp.mordor.fan SRV-tjenesteplass: prioritet = 0 vekt = 0 port = 464 svr vertsnavn = sauron.mordor.fan mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan internettadresse = 10.10.10.3 dnslinux.mordor.fan internettadresse = 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 isplassering: prioritet = 0 vekt = 0 port = 389 svr vertsnavn = sauron. mordor.fan mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan internettadresse = 10.10.10.3 dnslinux.mordor.fan internettadresse = 10.10.10.5
> avslutte

C: \ Brukere \ buzz>

DNS-spørsmål gjort fra klienten «win7»Var også tilfredsstillende.

I Active Directory oppretter vi brukeren «Saruman«, Med sikte på å bruke den når du blir med i klienten win7 til domenet mordor.fan., ved hjelp av metoden «Nettverks-ID«, Bruke brukernavn saruman@mordor.fan y administrator@mordor.fan. Delta ble vellykket og er bevist med følgende skjermbilde:

Om dynamiske oppdateringer i Microsoft® DNS og BIND

Siden vi har stoppet DNS-tjenesten i Active Directory®, var det ikke mulig for klienten «win7»Registrer navn og IP-adresse i den DNSen. Mye mindre i dnslinux.mordor.fan siden vi ikke uttalte oss tillat-oppdatering for noen av områdene som er involvert.

Og det var her den gode kampen med vennen min ble dannet Fuegian. I min første e-post om dette aspektet kommenterte jeg:

Microsofts artikler om bruk av BIND og Active Directory® anbefaler at, spesielt Direct Zone, får lov til å bli oppdatert -trengt inn- direkte av Windows-klienter som allerede er koblet til Active Directory-domenet.
Det er derfor som standard i DNS-sonene til en Active Directory® Secure Dynamic Updates er tillatt av Windows-klienter som allerede er koblet til Active Directory-domenet. Hvis de ikke er samlet, avstår de fra konsekvensene.
DNS for en Active Directory støtter dynamiske oppdateringer "Bare sikker", "Usikker og sikker" eller "Ingen", som er det samme som å si NO Updates eller None.
Ja virkelig Microsoft Philosophy er ikke enig i at kundene IKKE vil oppdatere dataene sine i DNS-ene sine, de vil ikke la muligheten for å deaktivere dynamiske oppdateringer i DNS-ene sine, med mindre det alternativet blir igjen for mer skjulte formål.
Microsoft tilbyr "Sikkerhet" i bytte mot Darkness, som en kollega og venn som passerte Microsft®-sertifikatkurs fortalte meg. ekte. I tillegg bekreftet El Fueguino det for meg.
En klient som for eksempel skaffer seg en IP-adresse gjennom DHCP installert på en UNIX® / Linux-maskin, vil ikke kunne løse IP-adressen til sitt eget navn til du er tilknyttet Active Directory-domenet, så lenge Microsoft® eller en BIND brukes som DNS uten dynamiske oppdateringer fra en DHCP.
Hvis jeg installerer DHCP i selve Active Directory®, må jeg erklære at sonene er oppdatert av Microsoft® DHCP.
Hvis vi skal bruke BIND som DNS for Windows-nettverket, er det logisk og anbefales at vi installerer BIND-DHCP-duoen, med sistnevnte som oppdaterer BIND dynamisk og saken avsluttet.
I en verden av LAN-nettverk på UNIX® / Linux, siden dynamiske oppdateringer ble oppfunnet på BIND, er bare Mr. DHCP tillatt «trenge»Til fru BIND med oppdateringene. Avslapningen som er med ordre, vær så snill.
Når jeg erklærer i sonen mordor.fan for eksempel: tillat oppdatering {10.10.10.0/24; };, BIND selv informerer meg når jeg starter eller starter den på nytt at:
- ```
sone 'mordor.fan' tillater oppdateringer etter IP-adresse, som er usikker
```
I den hellige, UNIX® / Linux-verdenen, er så sur med DNS rett og slett ikke tillatt.

Du kan forestille deg resten av utvekslingen med min venn Fuegian gjennom e-post, telegramchat, telefonsamtaler betalt av ham (selvfølgelig mann, jeg har ikke kilo for det), og til og med meldinger gjennom bærerduer i det XXI århundre!

Han truet til og med ikke å sende meg en sønn av kjæledyret hans, leguanen hans «Petra»At han hadde lovet meg som en del av betalingen. Der var jeg veldig redd. Så jeg begynte igjen, men fra en annen vinkel.

Den "nesten" Active Directory som kan oppnås med Samba 4, løser dette aspektet på en mesterlig måte, både når vi bruker den interne DNS, eller BIND kompilert for å støtte DLZ-soner - Dinamyc -lastede soner, eller dynamisk lastede soner.
Det lider fortsatt av det samme: når en klient skaffer seg en IP-adresse gjennom en DHCP installert i andre UNIX® / Linux-maskin, vil du ikke kunne løse IP-adressen til ditt eget navn til den er koblet til domenet til Samba 4 AD-DC.
Integrer BIND-DLZ- og DHCP-duoen på den samme maskinen der AD-DC Samba 4 det er en jobb for en ekte spesialist.

Fuegian Han kalte meg til kapittel og ropte på meg: Vi snakker IKKE om AD-DC Samba 4, men fra Microsoft® Active Directory®!. Og jeg svarte ydmykt at jeg var fornøyd med en del av følgende artikler som jeg skulle skrive.

Det var da jeg fortalte ham at den endelige avgjørelsen om dynamiske oppdateringer av klientdatamaskiner i nettverket hans var overlatt til sin egen frie vilje. At jeg bare ville gi ham den typen skrevet før om tillat oppdatering {10.10.10.0/24; };, og mer ingenting. At jeg ikke var ansvarlig for hva som skyldtes den promiskuiteten som hver Windows-klient - eller Linux - i nettverket deres «vil trenge gjennom»Med straffrihet mot BIND.

Hvis du visste, min venn, leser at det var sluttpunktet for slagsmål, ville du ikke tro det. Min venn Fuegian han godtok løsningen - og han vil sende meg leguanen «Pete«- at nå deler jeg med deg.

Vi installerer og konfigurerer DHCP

For mer informasjon, les DNS og DHCP i Debian 8 "Jessie".

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

root @ dnslinux: ~ # nano / etc / default / isc-dhcp-server .... # På hvilke grensesnitt skal DHCP-serveren (dhcpd) tjene DHCP-forespørsler? # Separer flere grensesnitt med mellomrom, f.eks. "Eth0 eth1". INTERFACES = "eth0" root @ dnslinux: ~ # dnssec-keygen -a HMAC-MD5 -b 128 -r / dev / urandom -n USER dhcp-key
Kdhcp-nøkkel. + 157 + 29836

root @ dnslinux: ~ # cat Kdhcp-key. +157 + 29836. privat
Privatnøkkelformat: v1.3 Algoritme: 157 (HMAC_MD5) Nøkkel: 3HT / bg / 6YwezUShKYofj5g == Biter: AAA = Laget: 20170212205030 Publiser: 20170212205030 Aktiver: 20170212205030

root @ dnslinux: ~ # nano dhcp.key
nøkkel dhcp-nøkkel {algoritme hmac-md5; hemmelig "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
// // Gjør noen lokal konfigurasjon her // // Vurder å legge til 1918-sonene her, hvis de ikke brukes i // organisasjonen din inkluderer "/etc/bind/zones.rfc1918"; inkluderer "/etc/bind/zones.rfcFreeBSD";
// Ikke glem ... Jeg glemte og betalte med feil. ;-)
inkluderer "/etc/bind/dhcp.key";


sone "mordor.fan" {type master;
        tillat oppdatering {10.10.10.3; nøkkel dhcp-nøkkel; };
        fil "/var/lib/bind/db.mordor.fan"; }; sone "10.10.10.in-addr.arpa" {type master;
        tillat oppdatering {10.10.10.3; nøkkel dhcp-nøkkel; };
        fil "/var/lib/bind/db.10.10.10.in-addr.arpa"; }; sone "_msdcs.mordor.fan" {type master; sjekknavn ignorerer; fil "/etc/bind/db._msdcs.mordor.fan"; };

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

root @ dnslinux: ~ # nano /etc/dhcp/dhcpd.conf
ddns-oppdatering-stil midlertidig; ddns-oppdateringer på; ddns-domenenavn "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; ignorere klientoppdateringer; autoritær; alternativet ip-videresending av; alternativ domenenavn "mordor.fan"; inkluderer "/etc/dhcp/dhcp.key"; sone mordor.fan. {primær 127.0.0.1; nøkkel dhcp-nøkkel; } sone 10.10.10.in-addr.arpa. {primær 127.0.0.1; nøkkel dhcp-nøkkel; } redlokal for delt nettverk {subnet 10.10.10.0 netmask 255.255.255.0 {option routers 10.10.10.1; opsjon undernettmaske 255.255.255.0; alternativ kringkastingsadresse 10.10.10.255; opsjon domenenavnservere 10.10.10.5; opsjon netbios-name-servers 10.10.10.5; rekkevidde 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 rettigheter forbeholdes. For info, besøk https://www.isc.org/software/dhcp/ Config file: /etc/dhcp/dhcpd.conf Databasefil: /var/lib/dhcp/dhcpd.leier PID-fil: / var / run /dhcpd.pid

root @ dnslinux: ~ # systemctl start bind9.service på nytt 
root @ dnslinux: ~ # systemctl status bind9.service 

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

Hva er relatert til Sjekker med klienter, og Manuell modifisering av sonefiler, vi lar det være for deg, leservenn, å lese det direkte fra DNS og DHCP i Debian 8 "Jessie", og bruk den på dine faktiske forhold. Vi utførte alle nødvendige kontroller og oppnådde tilfredsstillende resultater. Selvfølgelig sender vi en kopi av dem alle til Fuegian. Det blir ikke mer!

Tips

Generelt

Få en god del tålmodighet før du begynner.
Installer og konfigurer BIND først. Sjekk alt og se alle postene du har deklarert i hver fil av de tre eller flere sonene, både fra Active Directory og fra selve DNS-serveren. Hvis det er mulig, fra en Linux-maskin som ikke er koblet til domenet, gjør du de nødvendige DNS-spørsmålene til BIND.
Bli med i en Windows-klient med en fast IP-adresse til det eksisterende domenet, og kontroller alle BIND-innstillinger fra Windows-klienten.
Når du utvilsomt er sikker på at den splitter nye BIND-konfigurasjonen din er helt riktig, våger du deg ut for å installere, konfigurere og starte DHCP-tjenesten.
I tilfelle feil, gjenta hele prosedyren fra null 0.
Vær forsiktig med kopiering og liming! og de ekstra mellomrommene i hver linje i de navngitte.conf.xxxx-filene
Etterpå klaget han ikke - langt mindre til min venn Fuegian - at han ikke ble ordentlig rådet.

Andre tips

Splitt og hersk.
I et SMB-nettverk er det tryggere og mer fordelaktig å installere en autoritativ BIND for de interne LAN-sonene som ikke går tilbake til noen rotserver: rekursjon nr;.
I et SMB-nettverk under en Internett-tilgangsleverandør - ISP, kanskje tjenestene Proxy y SMTP de trenger å løse domenenavn på Internett. Han Akkar du har muligheten til å erklære DNS-en din for å være ekstern eller ikke, mens du er på en e-postserver basert på postfix o MDaemon® Vi kan også erklære DNS-serverne som vi vil bruke i den tjenesten. I tilfeller som dette, det vil si tilfeller som ikke leverer tjenester til Internett og som er under en Internett-leverandør, kan du installere en BIND med Speditører peker på DNS til ISP, og erklærer det som sekundær DNS på serverne som trenger å løse eksterne spørsmål til LAN, ellers er det mulig å erklære dem gjennom sine egne konfigurasjonsfiler.
Hvis du har en delegert sone under hele ditt ansvarSå kråker en annen hane:
- Installer en DNS-server basert på NSD, som per definisjon er en autoritativ DNS-server, som svarer på spørsmål fra datamaskiner på Internett. For litt informasjon egnethetsshow nsd.  Beskytt den godt med så mange brannvegger som nødvendig. Både maskinvare og programvare. Det vil være en DNS vendt mot Internett, og at «Tsar» Vi skal ikke gi den med buksene nede. 
- Siden jeg aldri har sett meg selv i en sak som dette, det vil si den personen som har ansvaret for en delegert sone, må jeg tenke veldig godt hva jeg skal anbefale for løsning av domenenavn utenfor vårt LAN for tjenestene som trenger det . SME-nettverksklienter trenger det egentlig ikke. Rådfør deg med spesialisert litteratur, eller en spesialist i disse fagene, da jeg langt fra er en av dem. Alvor.
- Rekursjon eksisterer ikke på autoritære servere. Greit?. I tilfelle noen tilfeldigvis gjør det med en BIND.
Selv om vi eksplisitt spesifiserer i filen /etc/dhcp/dhcpd.conf erklæringen ignorere klientoppdateringer;, hvis vi kjører på en datakonsoll dnslinux.mordor.fan ordren journalctl -f, vil vi se at når du starter klienten win7.mordor.fan vi får følgende feilmeldinger:
- ```
12. feb 16:55:41 dnslinux kalt [900]: klient 10.10.10.30 # 58762: oppdatering 'mordor.fan/IN' nektet
12. feb 16:55:42 dnslinux kalt [900]: klient 10.10.10.30 # 49763: oppdatering 'mordor.fan/IN' nektet
12. feb 16:56:23 dnslinux kalt [900]: klient 10.10.10.30 # 63161: oppdatering 'mordor.fan/IN' nektet
```
- For å eliminere disse meldingene, må vi gå til de avanserte alternativene for nettverkskortkonfigurasjonen og fjerne merket for alternativet «Registrer denne tilkoblingens adresser i DNS«. Det vil for alltid forhindre klienten i å prøve å selvregistrere seg i Linux DNS og avslutte problemet. Beklager, men jeg har ikke en kopi av Windows 7 på spansk. 
For å finne ut alle de alvorlige - og sprø - spørsmålene en Windows 7-klient lager, sjekk ut loggforespørsler.logg at for noe erklærer vi det i BIND-konfigurasjonen. Bestillingen vil være:
- ```
root @ dnslinux: ~ # tail -f /var/log/named/queries.log
```
Hvis du ikke lar klientdatamaskinene dine koble seg direkte til Internett, hvorfor trenger du da Root DNS-servere? Dette vil redusere utdataene fra kommandoen betydelig journalctl -f og fra den forrige, hvis den autoritære DNS-serveren for de interne sonene ikke kobles direkte til Internett, noe som sterkt anbefales fra et sikkerhetssynspunkt.
```
root @ dnslinux: ~ # cp /etc/bind/db.root /etc/bind/db.root.original
root @ dnslinux: ~ # cp / dev / null /etc/bind/db.root
```

Hvis du ikke trenger erklæringen fra rotserverne, hvorfor trenger du rekursjon - Rekursjon?

root @ dnslinux: ~ # nano /etc/bind/named.conf.options
alternativer {
 ....
 rekursjon nr;
 ....
};

Spesifikke råd som jeg fremdeles ikke er veldig klare på

El mann dhcpd.conf forteller oss følgende blant mange -mange andre ting:

        Oppdateringsoptimaliseringserklæringen

            flagg for oppdateringsoptimalisering;

            Hvis oppdateringsoptimaliseringsparameteren er falsk for en gitt klient, vil serveren prøve en DNS-oppdatering for den klienten hver gang klienten fornyer leiekontrakten, i stedet for bare å prøve en oppdatering når det ser ut til å være nødvendig. Dette vil gjøre det mulig for DNS å gro fra databasekonsekvenser lettere, men kostnaden er at DHCP-serveren må gjøre mange flere DNS-oppdateringer. Vi anbefaler å lese dette alternativet aktivert, som er standard. Dette alternativet påvirker bare oppførselen til den midlertidige DNS-oppdateringsplanen, og har ingen effekt på ad-hoc DNS-oppdateringsordningen. Hvis denne parameteren ikke er spesifisert, eller er sant, oppdateres DHCP-serveren bare når klientinformasjonen endres, klienten får en annen leieavtale eller klientens leieavtale utløper.

Den mer eller mindre nøyaktige oversettelsen eller tolkningen er overlatt til deg, kjære leser.

Personlig har det skjedd meg - og det skjedde under skrivingen av denne artikkelen - at når jeg kobler en BIND til en Active Directory®, er den fra Microsft® eller Samba 4, hvis jeg endrer navnet på en klientdatamaskin registrert i Active Directory®-domenet eller AD–DC av Samba 4, holder det sitt gamle navn og IP-adresse i Direct Zone, og ikke omvendt, som er riktig oppdatert med det nye navnet. Med andre ord blir de gamle og nye navnene tilordnet den samme IP-adressen i Direct Zone, mens det motsatte bare det nye navnet vises. For å forstå meg godt, må du prøve det selv.

Jeg tror det er en slags hevn mot Fuegian -Ikke for meg, vær så snill- for å prøve å migrere tjenestene dine til Linux.

Selvfølgelig vil det gamle navnet forsvinne når det TTL 3600, eller tiden vi har deklarert i DHCP-konfigurasjonen. Men vi vil at den skal forsvinne umiddelbart slik det skjer i en BIND + DHCP uten en Active Directory gjennom.

Løsningen på den situasjonen fant jeg ved å sette inn uttalelsen oppdatering-optimalisering falsk; på slutten av toppen av filen /etc/dhcp/dhcpd.conf:

ddns-oppdatering-stil midlertidig; ddns-oppdateringer på; ddns-domenenavn "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; ignorere klientoppdateringer;
oppdatering-optimalisering falsk;

Hvis noen lesere vet mer om det, kan du opplyse meg. Jeg vil sette stor pris på det.

Oppsummering

Vi har hatt mye moro med emnet, ikke sant? Ingen lidelse fordi vi har en BIND som fungerer som DNS-server i et Microsoft®-nettverk, og tilbyr alle SRV-poster og svarer riktig på DNS-spørsmålene som er gjort til dem. På den annen side har vi en DHCP-server som gir IP-adresser og dynamisk oppdaterer BIND-sonene riktig.

Men vi kan ikke spørre for øyeblikket.

Jeg håper min venn Fuegian vær fornøyd og fornøyd med det første trinnet i overføringen til Linux for å gjøre de uutholdelige kostnadene med Microsft® teknisk støtte tålelige.

Viktig merknad

Karakter "Fuegian»Er helt fiktivt og et produkt av fantasien min. Enhver likhet eller tilfeldighet med ekte mennesker er den samme: Ren ufrivillig tilfeldighet fra min side. Jeg opprettet den bare for å gjøre skrivingen og lesingen av denne artikkelen litt hyggelig. Nå hvis du kan fortelle meg at DNS-problemet er mørkt. 

DesdeLinux

BIND og Active Directory® - SME Networks