BIND e Active Directory® - Reti di PMI

Indice generale della serie: Reti di computer per le PMI: Introduzione

Ciao amici!. L'obiettivo principale di questo articolo è mostrare come possiamo integrare il servizio DNS basato su BIND9 in una rete Microsoft, molto comune in molte PMI.

Nasce dalla richiesta ufficiale di un amico che vive a La Tierra del Fuego -Il Fuegian- specializzato in reti Microsoft® -Certificati inclusi- per guidarti in questa parte della migrazione dei tuoi server a Linux. I costi di supporto I tecnici che pagano Microsoft® lo sono già Insopportabile per la Società in cui opera e di cui è Socio Principale.

mio amico Il Fuegian ha un grande senso dell'umorismo e da quando ha visto la serie di tre film «Il Signore degli Anelli»È stato affascinato da molti dei nomi dei suoi personaggi oscuri. Quindi, amico lettore, non essere sorpreso dai nomi del tuo dominio e dei tuoi server.

Ai nuovi arrivati ​​sull'argomento e prima di continuare a leggere, consigliamo di leggere e studiare i tre articoli precedenti sulle reti di PMI:

• DNS e DHCP in openSUSE 13.2 "Harlequin"
• DNS e DHCP su CentOS 7
• DNS e DHCP in Debian 8 "Jessie"

È come guardare tre delle quattro parti di «Malavita»Pubblicato fino ad oggi, e questo è il quarto.

Parametri generali

Dopo diversi scambi tramite e-mailFinalmente sono stato chiaro sui parametri principali della tua attuale rete, che sono:

Nome di dominio mordor.fan Rete LAN 10.10.10.0/24 ==================================== ========================================== Scopo dell'indirizzo IP dei server (server con sistema operativo Windows) ================================================ =============================== sauron.mordor.fan. 10.10.10.3 Active Directory® 2008 SR2 mamba.mordor.fan. 10.10.10.4 File server Windows darklord.mordor.fan. 10.10.10.6 Proxy, gateway e firewall su Kerios troll.mordor.fan. 10.10.10.7 Blog basato su ... non ricordo shadowftp.mordor.fan. 10.10.10.8 Server FTP blackelf.mordor.fan. 10.10.10.9 Servizio completo di posta elettronica blackspider.mordor.fan. 10.10.10.10 Servizio WWW palantir.mordor.fan. 10.10.10.11 Chat su Openfire per Windows

Ho chiesto il permesso Il Fuegian di impostare tutti gli alias necessari per schiarirmi la mente e mi ha dato il suo permesso:

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

Ho dichiarato tutti i record DNS importanti nella mia installazione di un Active Directory Windows 2008 che sono stato costretto a implementare per guidarmi nella realizzazione di questo post.

Informazioni sui record SRV DNS di Active Directory

I registri SRV o I Service Locator, ampiamente utilizzati in Microsoft Active Directory, sono definiti nel file Richiesta di commenti RFC 2782. Consentono la localizzazione di un servizio basato sul protocollo TCP / IP tramite una query DNS. Ad esempio, un cliente su una rete Microsoft può individuare la posizione dei controller di dominio: Controller di dominio che forniscono il servizio LDAP sul protocollo TCP sulla porta 389 tramite una singola query DNS.

È normale che nelle foreste - Le forestee alberi - Alberi di una grande rete Microsoft esistono diversi controller di dominio. Attraverso l'uso di record SRV nelle diverse Zone che compongono lo Spazio dei nomi di dominio di quella Rete, possiamo mantenere un Elenco di Server che forniscono servizi simili ben noti, ordinati per preferenza in base al protocollo di trasporto e alla porta di ciascuno uno dei server.

Qui alla Richiesta di commenti RFC 1700 Definizione di nomi simbolici universali per servizi ben noti - Servizio ben notoe nomi come «_telenet«,«_smpt»Per i servizi telnet y SMTP. Se un nome simbolico non è definito per un servizio ben noto, è possibile utilizzare un nome locale o un altro nome in base alle preferenze dell'utente.

Lo scopo di ogni campo «speciale»Quello utilizzato nella dichiarazione di un record di risorse SRV è il seguente:

• Dominio: "Pdc._msdcs.mordor.fan.«. Nome DNS del servizio a cui si riferisce il record SRV. Il nome DNS nell'esempio significa -more o meno- Controller di dominio primario della zona _msdcs.mordor.fan.
• Servizi: "_Ldap". Nome simbolico del servizio fornito definito secondo Richiesta di commenti RFC 1700.
• Protocollo: "_Tcp". Indica il tipo di protocollo di trasporto. In genere può assumere i valori _tcp o _udp, sebbene -e di fatto- qualsiasi tipo di protocollo di trasporto indicato nel Richiesta di commenti RFC 1700. Ad esempio, per un servizio chiacchierare basato su protocollo XMPP, questo campo avrebbe il valore di _xmpp.
• Priorità"0«. Dichiarare la priorità o la preferenza per il file Host che offre questo servizio che vedremo più avanti. Le query DNS dei client sul servizio definito da questo record SRV, dopo aver ricevuto la risposta appropriata, tenteranno di contattare il primo host disponibile con il numero più basso elencato nel campo. Priorità. L'intervallo di valori che questo campo può assumere è 0 a 65535.
• Peso"100«. Può essere utilizzato in combinazione con Priorità per fornire un meccanismo di bilanciamento del carico quando sono presenti più server che forniscono lo stesso servizio. Ci dovrebbe essere un record SRV simile per ogni server nel file Zone, con il suo nome dichiarato nel campo Host che offre questo servizio. Prima dei server con valori uguali sul campo Priorità, il valore del campo Peso può essere utilizzato come ulteriore livello di preferenza per ottenere una selezione esatta del server per il bilanciamento del carico. L'intervallo di valori che questo campo può assumere è 0 a 65535. Se il bilanciamento del carico non è richiesto, ad esempio come nel caso di un singolo server, si consiglia di assegnare il valore 0 per facilitare la lettura del record SRV.
• Numero di porta - Porta"389«. Numero di porta in Host che offre questo servizio che fornisce il servizio indicato nel campo Servizi. Il numero di porta consigliato per ciascun tipo di servizio ben noto è indicato nel file Richiesta di commenti RFC 1700, sebbene possa assumere un valore compreso tra 0 e 65535.
• Host che offre questo servizio - Target"sauron.mordor.fan.«. Specifica il FQDN che identifica inequivocabilmente il host che fornisce il servizio indicato dal record SRV. Un tipo di record «A»Nello spazio dei nomi di dominio per ciascuno FQDN dal server o host che fornisce il servizio. Più semplice, un record di tipo A nelle zone dirette.
  • Nota:
    Per indicare autorevolmente che il servizio specificato dal record SRV non è fornito su questo host, un singolo (.) macchiare.

Vogliamo solo ribadire che il corretto funzionamento di una rete o di un Active Directory® dipende fortemente dal corretto funzionamento del Domain Name Service..

Record DNS di Active Directory

Per rendere le zone del nuovo server DNS basate su BIND, dobbiamo ottenere tutti i record DNS da Active Directory®. Per semplificarci la vita, andiamo in squadra sauron.mordor.fan -Active Directory® 2008 SR2- e nella Console di Amministrazione DNS attiviamo il Trasferimento di Zona -diretto e inverso- per le principali zone dichiarate in questo tipo di servizio, che sono:

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

Una volta eseguito il passaggio precedente e preferibilmente da un computer Linux il cui indirizzo IP è compreso nell'intervallo della sottorete utilizzata dalla Rete Windows, eseguiamo:

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

• Ricorda dagli articoli precedenti che l'indirizzo IP del dispositivo amministratore di sistema.desdelinux.fan Es 10.10.10.1 o 192.168.10.1.

Nei tre comandi precedenti possiamo eliminare l'opzione 10.10.10.3 -chiedi al server DNS con quell'indirizzo- se dichiariamo nel file /etc/resolv.conf all'IP del server sauron.mordor.fan:

buzz@sysadmin:~$ cat /etc/resolv.conf # Generato dalla ricerca di NetworkManager desdelinux.fan server dei nomi 192.168.10.5 server dei nomi 10.10.10.3

Dopo aver modificato con estrema cura, come corrisponde a qualsiasi file di zona in un BIND, otterremo i seguenti dati:

Record RR dalla zona originale _msdcs.mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs._msdcs.mordor.fan 
; Relativo a SOA e NS _msdcs.mordor.fan. 3600 IN SOA sauron.mordor.fan. hostmaster.mordor.fan. 12 900 600 _msdcs.mordor.fan. 86400 IN NS sauron.mordor.fan. ; ; CATALOGO GLOBALE gc._msdcs.mordor.fan. 3600 IN A 3600; ; Alias ​​- nel database LDAP privato e modificato di una Active Directory - di SAURON 600-10.10.10.3a03296249-82aa-a1f49-4f0d28900b._msdcs.mordor.fan 5 IN CNAME sauron.mordor.fan. ; ; LDAP modificato e privato di un _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan di Active Directory. 256 IN SRV 600 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. _ldap._tcp.100d389d-600fdb-0cf-a100-d389c18b3360d8.domains._msdcs.mordor.fan. 40 IN SRV 678 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 7 IN SRV 420 6 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 775 IN SRV 600 0 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 100 IN SRV 389 sauron.mordor.fan. ; ; KERBEROS modificato e privato di un _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan di Active Directory. 600 IN SRV 0 100 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 3268 IN SRV 600 0 sauron.mordor.fan.

Record RR dalla zona originale mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs.mordor.fan 
; Relativo a SOA, NS, MX e al record A che mappa; il nome di dominio all'IP di SAURON; Cose da un mordor.fan di Active Directory. 3600 IN SOA sauron.mordor.fan. hostmaster.mordor.fan. 48 900 600 mordor.fan. 86400 IN A 3600 mordor.fan. 600 IN NS sauron.mordor.fan. mordor.fan. 10.10.10.3 IN MX 3600 blackelf.mordor.fan. _msdcs.mordor.fan. 3600 IN NS sauron.mordor.fan. ; ; Altrettanto importante A registra DomainDnsZones.mordor.fan. 10 IN A 3600 ForestDnsZones.mordor.fan. 600 IN A 10.10.10.3; ; CATALOGO GLOBALE _gc._tcp.mordor.fan. 600 IN SRV 10.10.10.3 600 sauron.mordor.fan. _gc._tcp.Default-First-Site-Name._sites.mordor.fan. 0 IN SRV 100 3268 sauron.mordor.fan. ; ; LDAP modificato e privato di un _ldap._tcp.mordor.fan di Active Directory. 600 IN SRV 0 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 100 IN SRV 3268 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 100 IN SRV 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 100 IN SRV 389 sauron.mordor.fan. ; ; KERBEROS modificato e privato di un _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan di Active Directory. 600 IN SRV 0 100 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 389 IN SRV 600 0 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 100 IN SRV 389 sauron.mordor.fan. _kerberos._udp.mordor.fan. 600 IN SRV 0 100 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 389 IN SRV 600 sauron.mordor.fan. ; ; Registra A con IP fisso -> Server blackelf.mordor.fan. 0 IN A 100 blackspider.mordor.fan. 389 IN A 600 darklord.mordor.fan. 0 IN A 100 mamba.mordor.fan. 88 IN A 600 palantir.mordor.fan. 0 IN A 100 sauron.mordor.fan. 88 IN A 600 shadowftp.mordor.fan. 0 IN A 100 troll.mordor.fan. 464 IN A 600; ; Record CNAME ad-dc.mordor.fan. 0 IN CNAME sauron.mordor.fan. blog.mordor.fan. 100 IN CNAME troll.mordor.fan. fileserver.mordor.fan. 88 IN CNAME mamba.mordor.fan. ftpserver.mordor.fan. 600 IN CNAME shadowftp.mordor.fan. mail.mordor.fan. 0 IN CNAME balckelf.mordor.fan. openfire.mordor.fan. 100 IN CNAME palantir.mordor.fan. proxy.mordor.fan. 464 IN CNAME darklord.mordor.fan. www.mordor.fan. 3600 IN CNAME blackspider.mordor.fan.

Record RR dalla zona originale 10.10.10.in-addr.arpa

buzz @ sysadmin: ~ $ cat temp / rrs.10.10.10.in-addr.arpa 
; Relativo a SOA e NS 10.10.10.in-addr.arpa. 3600 IN SOA sauron.mordor.fan. hostmaster.mordor.fan. 21 900 600 86400.in-addr.arpa. 3600 IN NS sauron.mordor.fan. ; ; Record PTR 10.10.10.in-addr.arpa. 3600 IN PTR blackspider.mordor.fan. 10.10.10.10.in-addr.arpa. 3600 IN PTR palantir.mordor.fan. 11.10.10.10.in-addr.arpa. 3600 IN PTR sauron.mordor.fan. 3.10.10.10.in-addr.arpa. 3600 IN PTR mamba.mordor.fan. 4.10.10.10.in-addr.arpa. 3600 IN PTR dnslinux.mordor.fan. 5.10.10.10.in-addr.arpa. 3600 IN PTR darklord.mordor.fan. 6.10.10.10.in-addr.arpa. 3600 IN PTR troll.mordor.fan. 7.10.10.10.in-addr.arpa. 3600 IN PTR shadowftp.mordor.fan. 8.10.10.10.in-addr.arpa. 3600 IN PTR blackelf.mordor.fan.

Fino a questo punto possiamo pensare di avere i dati necessari per proseguire nella nostra avventura, non senza prima aver osservato il TTL e altri dati che in modo molto sintetico ci fornisce l'output e l'osservazione diretta del DNS di un Microsft® Active Directory® 2008 SR2 64 bit.

Immagini del DNS Manager in SAURON

Dnslinux.mordor.fan team.

Se guardiamo da vicino, all'indirizzo IP 10.10.10.5 non gli è stato assegnato alcun nome precisamente in modo che fosse occupato dal nome del nuovo DNS dnslinux.mordor.fan. Per installare la coppia DNS e DHCP possiamo farci guidare dagli articoli DNS e DHCP in Debian 8 "Jessie" y DNS e DHCP su CentOS 7.

Sistema operativo di base

mio amico Il FuegianOltre ad essere un vero specialista in Microsoft® Windows - ha un paio di Certificati emessi da quella società - ha letto e messo in pratica alcuni degli articoli sui desktop pubblicati in DesdeLinux., e mi ha detto che voleva espressamente una soluzione basata su Debian. 😉

Per farti piacere, inizieremo con un'installazione fresca e pulita di un server basato su Debian 8 "Jessie". Tuttavia, ciò che scriveremo in seguito è valido per le distribuzioni CentOS e openSUSE di cui abbiamo menzionato gli articoli in precedenza. BIND e DHCP sono gli stessi su qualsiasi distribuzione. Lievi variazioni sono introdotte dai manutentori dei pacchetti in ogni distribuzione.

Faremo l'installazione come indicato in DNS e DHCP in Debian 8 "Jessie", avendo cura di utilizzare l'IP 10.10.10.5 e la rete 10.10.10.0/24., anche prima di configurare BIND.

Configuriamo BIND in stile Debian

/etc/bind/named.conf

il file /etc/bind/named.conf lo lasciamo così come è installato.

/etc/bind/named.conf.options

il file /etc/bind/named.conf.opziones dovrebbe essere lasciato con il seguente contenuto:

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

root @ dnslinux: ~ # nano /etc/bind/named.conf.options
opzioni {directory "/ var / cache / bind"; // Se c'è un firewall tra te e i server dei nomi con cui // vuoi parlare, potresti dover aggiustare il firewall per consentire a più porte // di parlare. Vedi http://www.kb.cert.org/vuls/id/800113 // Se il tuo ISP ha fornito uno o più indirizzi IP per server dei nomi // stabili, probabilmente vorrai usarli come forwarder. // Rimuovere il commento dal blocco seguente e inserire gli indirizzi sostituendo // il segnaposto di tutti gli 0. // forwarders {// 0.0.0.0; //}; // =============================================== ===================== $ // Se BIND registra messaggi di errore sulla scadenza della chiave radice, // sarà necessario aggiornare le chiavi. Vedi https://www.isc.org/bind-keys // ================================= ===================================== $

    // Non vogliamo DNSSEC
        abilita dnssec no;
        //dnssec-convalida automatica;

        auth-nxdomain no; # conforme a RFC1035

 // Non è necessario ascoltare gli indirizzi IPv6
        // ascolta su v6 {qualsiasi; };
    ascolta su v6 {nessuno; };

 // Per i controlli da localhost e sysadmin
    // through // dig mordor.fan axfr // dig 10.10.10.in-addr.arpa axfr // dig _msdcs.mordor.fan axfr // Non abbiamo Slave DNS ... fino ad ora
 consentire-trasferimento {localhost; 10.10.10.1; };
};

// Registrazione di BIND
registrazione {

        query di canale {
        file "/var/log/named/queries.log" versioni 3 dimensione 1m;
        informazioni sulla gravità;
        tempo di stampa sì;
        gravità di stampa sì;
        categoria di stampa sì;
        };

        errore di query del canale {
        file "/var/log/named/query-error.log" versioni 3 dimensione 1m;
        informazioni sulla gravità;
        tempo di stampa sì;
        gravità di stampa sì;
        categoria di stampa sì;
        };

                                
query di categoria {
         interrogazioni;
         };

categoria query-errors {
         errore di query;
         };

};

• Introduciamo l'acquisizione dei registri BIND come file NOVITÁ apparizione nella serie di articoli sull'argomento. Creiamo luna cartella e i file richiesti per Registrazione di 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

Controlliamo la sintassi dei file configurati

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

/etc/bind/named.conf.local

Creiamo il file /etc/bind/zones.rfcFreeBSD con lo stesso contenuto come indicato in DNS e DHCP in Debian 8 "Jessie".

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

il file /etc/bind/named.conf.local dovrebbe essere lasciato con il seguente contenuto:

// // Esegui qui una configurazione locale // // Considera l'idea di aggiungere qui le zone 1918, se non sono utilizzate nella tua // organizzazione
includere "/etc/bind/zones.rfc1918"; includere "/etc/bind/zones.rfcFreeBSD";

zona "mordor.fan" {tipo master; file "/var/lib/bind/db.mordor.fan"; }; zona "10.10.10.in-addr.arpa" {tipo master; file "/var/lib/bind/db.10.10.10.in-addr.arpa"; };

zona "_msdcs.mordor.fan" {tipo master;
 i nomi di controllo ignorano; file "/etc/bind/db._msdcs.mordor.fan"; }; root @ dnslinux: ~ # named-checkconf
root @ dnslinux: ~ #

File di zona mordor.fan

root @ dnslinux: ~ # nano /var/lib/bind/db.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; seriale 1D; aggiornamento 1H; riprova 1W; scadenza 3H); minimo o; Tempo di caching negativo da vivere;
; STA MOLTO ATTENTO CON I SEGUENTI RECORD
@ IN NS dnslinux.mordor.fan.
@ IN A 10.10.10.5
@ IN MX 10 blackelf.mordor.fan. @ IN TXT "Benvenuto in The Dark Lan of Mordor";
_msdcs.mordor.fan. IN NS dnslinux.mordor.fan.
;
dnslinux.mordor.fan. IN A 10.10.10.5
; TERMINA MOLTO ATTENTAMENTE CON I SEGUENTI RECORD;
DomainDnsZones.mordor.fan. IN A 10.10.10.3 ForestDnsZones.mordor.fan. IN A 10.10.10.3; ; CATALOGO GLOBALE _gc._tcp.mordor.fan. 600 IN SRV 0 0 3268 sauron.mordor.fan. _gc._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 0 3268 sauron.mordor.fan. ; ; LDAP modificato e privato di un _ldap._tcp.mordor.fan di Active Directory. 600 IN SRV 0 0 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 389 IN SRV 600 0 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 0 IN SRV 389 600 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 0 IN SRV 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 IN SRV 0 0 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 389 IN SRV 600 0 sauron.mordor.fan. ; ; KERBEROS modificato e privato di un _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan di Active Directory. 0 IN SRV 389 600 0 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 0 IN SRV 389 600 0 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 0 IN SRV 88 600 0 sauron.mordor.fan. _kerberos._udp.mordor.fan. 0 IN SRV 88 600 0 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 0 IN SRV 464 600 0 sauron.mordor.fan. ; ; Registra A con IP fisso -> Server blackelf.mordor.fan. IN A 0 blackspider.mordor.fan. IN A 88 darklord.mordor.fan. IN A 600 mamba.mordor.fan. IN A 0 palantir.mordor.fan. IN A 0
sauron.mordor.fan. IN A 10.10.10.3
shadowftp.mordor.fan. IN A 10.10.10.8 troll.mordor.fan. IN A 10.10.10.7; ; Record CNAME ad-dc.mordor.fan. IN CNAME sauron.mordor.fan. blog.mordor.fan. IN CNAME troll.mordor.fan. fileserver.mordor.fan. IN CNAME mamba.mordor.fan. ftpserver.mordor.fan. IN CNAME shadowftp.mordor.fan. mail.mordor.fan. IN CNAME balckelf.mordor.fan. openfire.mordor.fan. IN CNAME palantir.mordor.fan. proxy.mordor.fan. IN CNAME darklord.mordor.fan. www.mordor.fan. IN CNAME blackspider.mordor.fan.

root @ dnslinux: ~ # named-checkzone mordor.fan /var/lib/bind/db.mordor.fan 
zona mordor.fan/IN: caricata seriale 1 OK

I tempi TL 600 di tutti i registri SRV li terremo nel caso in cui installassimo uno Slave BIND in tempo utile. Questi record rappresentano i servizi di Active Directory® che leggono principalmente i dati dal database LDAP. Poiché il database cambia frequentemente, i tempi di sincronizzazione devono essere ridotti, in uno schema DNS master-slave. Secondo la filosofia Microsoft osservata da Active Directory 2000 al 2008, il valore di 600 viene mantenuto per questi tipi di record SRV.

I TTL dei server con IP fisso, sono al di sotto del tempo dichiarato in SOA di 3 ore.

File di zona 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; seriale 1D; aggiornamento 1H; riprova 1W; scadenza 3H); minimo o; Tempo di caching negativo da vivere; @ IN NS dnslinux.mordor.fan. ; 10 IN PTR blackspider.mordor.fan. 11 IN PTR palantir.mordor.fan. 3 IN PTR sauron.mordor.fan. 4 IN PTR mamba.mordor.fan. 5 IN PTR dnslinux.mordor.fan. 6 IN PTR darklord.mordor.fan. 7 IN PTR troll.mordor.fan. 8 IN PTR shadowftp.mordor.fan. 9 IN PTR blackelf.mordor.fan.

root @ dnslinux: ~ # named-checkzone 10.10.10.in-addr.arpa /var/lib/bind/db.10.10.10.in-addr.arpa 
zone 10.10.10.in-addr.arpa/IN: seriale 1 caricata OK

File di zona _msdcs.mordor.fan

Prendiamo in considerazione ciò che è consigliato nel file /usr/share/doc/bind9/README.Debian.gz Informazioni sulla posizione dei file delle Zone Master non soggette ad aggiornamenti dinamici da DHCP.

root @ dnslinux: ~ # nano /etc/bind/db._msdcs.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; seriale 1D; aggiornamento 1H; riprova 1W; scadenza 3H); minimo o; Tempo di caching negativo da vivere; @ IN NS dnslinux.mordor.fan. ; ; ; CATALOGO GLOBALE gc._msdcs.mordor.fan. 600 IN A 10.10.10.3; ; Alias ​​- nel database LDAP privato e modificato di una Active Directory - di SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan 600 IN CNAME sauron.mordor.fan. ; ; LDAP modificato e privato di un _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan di Active Directory. 600 IN SRV 0 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 100 IN SRV 389 sauron.mordor.fan. _ldap._tcp.600d0d-100fdb-389cf-a18-d3360c8b40d678.domains._msdcs.mordor.fan. 7 IN SRV 420 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 6 IN SRV 775 600 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 0 IN SRV 100 389 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 sauron.mordor.fan. ; ; KERBEROS modificato e privato di un _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan di Active Directory. 100 IN SRV 3268 600 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 0 IN SRV 100 3268 sauron.mordor.fan.

Controlliamo la sintassi e possiamo ignorare l'errore che restituisce, poiché nella configurazione di questa Zona nel file /etc/bind/named.conf.local includiamo la dichiarazione i nomi di controllo ignorano;. La zona verrà caricata correttamente da 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: nome del proprietario errato (nomi di controllo) zona _msdcs.mordor.fan/IN: seriale 1 caricata OK

root @ dnslinux: ~ # systemctl riavvia bind9.service 
root @ dnslinux: ~ # systemctl status bind9.service 
● bind9.service - BIND Domain Name Server caricato: caricato (/lib/systemd/system/bind9.service; attivato) Drop-In: /run/systemd/generator/bind9.service.d └─50-insserv.conf- $ named.conf Attivo: attivo (in esecuzione) da Sun 2017-02-12 08:48:38 EST; 2s fa Docs: man: named (8) Process: 859 ExecStop = / usr / sbin / rndc stop (code = exited, status = 0 / SUCCESS) PID principale: 864 (named) CGroup: /system.slice/bind9.service └─864 / usr / sbin / named -f -u bind 12 feb 08:48:38 dnslinux named [864]: zone 3.efip6.arpa/IN: caricato seriale 1 feb 12 08:48:38 dnslinux named [864 ]: zone befip6.arpa/IN: caricata seriale 1 feb 12 08:48:38 dnslinux named [864]: zone 0.efip6.arpa/IN: caricata seriale 1 feb 12 08:48:38 dnslinux named [864]: zona 7.efip6.arpa/IN: caricata seriale 1 feb 12 08:48:38 dnslinux denominata [864]: zona mordor.fan/IN: caricata seriale 1 feb 12 08:48:38 dnslinux denominata [864]: esempio zona .org / IN: caricata seriale 1 feb 12 08:48:38 dnslinux denominata [864]: zone _msdcs.mordor.fan/IN: caricata seriale 1 feb 12 08:48:38 dnslinux denominata [864]: zona non valida / IN : caricato seriale 1 Feb 12 08:48:38 dnslinux denominato [864]: tutte le zone caricate
12 febbraio 08:48:38 dnslinux named [864]: running

Consultiamo BIND

Prima Dopo aver installato DHCP, dobbiamo effettuare una serie di controlli che includono anche l'adesione al dominio di un client Windows 7 mordor.fan rappresentato da Active Directory installato sul computer sauron.mordor.fan.

La prima cosa che dobbiamo fare è interrompere il servizio DNS sul computer sauron.mordor.fane dichiara nella tua interfaccia di rete che d'ora in poi il tuo server DNS sarà il 10.10.10.5 dnslinux.mordor.fan.

In una console del server stesso sauron.mordor.fan eseguiamo:

Microsoft Windows [Versione 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. Tutti i diritti riservati.

C: \ Users \ Administrator> nslookup
Server predefinito: dnslinux.mordor.fan Indirizzo: 10.10.10.5

> gc._msdcs
Server: dnslinux.mordor.fan Indirizzo: 10.10.10.5 Nome: gc._msdcs.mordor.fan Indirizzo: 10.10.10.3

> mordor.fan
Server: dnslinux.mordor.fan Indirizzo: 10.10.10.5 Nome: mordor.fan Indirizzo: 10.10.10.3

> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs
Server: dnslinux.mordor.fan Indirizzo: 10.10.10.5 Nome: sauron.mordor.fan Indirizzo: 10.10.10.3 Alias: 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan

> tipo di impostazione = SRV
> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
Server: dnslinux.mordor.fan Indirizzo: 10.10.10.5 _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan Posizione del servizio SRV: priorità = 0 peso = 100 porta = 88 svr nome host = sauron.mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan indirizzo internet = 10.10.10.3 dnslinux.mordor.fan indirizzo internet = 10.10.10.5
> _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs
Server: dnslinux.mordor.fan Indirizzo: 10.10.10.5 _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan Posizione del servizio SRV: priorità = 0 peso = 100 porta = 389 svr hostname = sauron .mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan indirizzo internet = 10.10.10.3 dnslinux.mordor.fan indirizzo internet = 10.10.10.5
> esci

C: \ Users \ Administrator>

Query DNS effettuate da sauron.mordor.fan sono soddisfacenti.

Il prossimo passo sarà creare un'altra macchina virtuale con Windows 7 installato. Dato che ancora non abbiamo il servizio DHCP installato, daremo al computer il nome «win7»L'indirizzo IP 10.10.10.251. Dichiariamo inoltre che il tuo server DNS sarà il 10.10.10.5 dnslinux.mordor.fane che il dominio di ricerca sarà mordor.fan. Non registreremo quel computer nel DNS perché lo useremo anche per testare il servizio DHCP dopo averlo installato.

Successivamente apriamo una console CMD e in esso eseguiamo:

Microsoft Windows [Versione 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Tutti i diritti riservati.

C: \ Users \ buzz> nslookup
Server predefinito: dnslinux.mordor.fan Indirizzo: 10.10.10.5

> mordor.fan
Server: dnslinux.mordor.fan Indirizzo: 10.10.10.5 Nome: mordor.fan Indirizzo: 10.10.10.3

> tipo di impostazione = SRV
> _ldap._tcp.DomainDnsZones
Server: dnslinux.mordor.fan Indirizzo: 10.10.10.5 _ldap._tcp.DomainDnsZones.mordor.fan Posizione del servizio SRV: priorità = 0 peso = 0 porta = 389 svr hostname = sauron.mordor.fan mordor.fan nameserver = dnslinux.mordor .fan sauron.mordor.fan indirizzo Internet = 10.10.10.3 dnslinux.mordor.fan indirizzo Internet = 10.10.10.5
> _kpasswd._udp
Server: dnslinux.mordor.fan Indirizzo: 10.10.10.5 _kpasswd._udp.mordor.fan Posizione del servizio SRV: priorità = 0 weight = 0 porta = 464 svr hostname = sauron.mordor.fan mordor.fan nameserver = dnslinux.mordor.fan indirizzo Internet sauron.mordor.fan = 10.10.10.3 indirizzo Internet dnslinux.mordor.fan = 10.10.10.5
> _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones
Server: dnslinux.mordor.fan Indirizzo: 10.10.10.5 _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan Posizione del servizio SRV: priorità = 0 peso = 0 porta = 389 svr hostname = sauron. mordor.fan mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan indirizzo internet = 10.10.10.3 dnslinux.mordor.fan indirizzo internet = 10.10.10.5
> exit

C: \ Users \ buzz>

Query DNS effettuate dal client «win7»Sono stati anche soddisfacenti.

In Active Directory creiamo l'utente «Saruman«, Con l'obiettivo di utilizzarlo quando si unisce al cliente win7 al dominio mordor.fan., utilizzando il metodo «ID di rete«, Utilizzando nomi utente saruman@mordor.fan y amministratore@mordor.fan. L'unione ha avuto esito positivo ed è dimostrato dal seguente screenshot:

Informazioni sugli aggiornamenti dinamici in Microsoft® DNS e BIND

Poiché abbiamo il servizio DNS interrotto in Active Directory® non è stato possibile per il client «win7»Registra il tuo nome e indirizzo IP in quel DNS. Molto meno in dnslinux.mordor.fan poiché non abbiamo rilasciato alcuna dichiarazione consentire-aggiornamento per una qualsiasi delle aree coinvolte.

Ed è qui che si è formata la buona battaglia con il mio amico Il Fuegian. Nella mia prima email su questo aspetto ho commentato:

• Negli articoli Microsoft sull'uso di BIND e Active Directory® raccomandano che, in particolare la Direct Zone, sia consentito l'aggiornamento -penetrato- direttamente da client Windows già aggiunti al dominio Active Directory.
• Ecco perché, per impostazione predefinita, nelle zone DNS di Active Directory® sono consentiti gli aggiornamenti dinamici protetti da client Windows già aggiunti al dominio Active Directory. Se non sono uniti, si astengono dalle conseguenze.
• Il DNS di un Active Directory supporta gli aggiornamenti dinamici "Solo protetto", "Non protetto e protetto" o "Nessuno", che equivale a dire NESSUN aggiornamento o Nessuno.
• Sì davvero La filosofia Microsoft non concorda sul fatto che i suoi clienti NON aggiorneranno i propri dati nei loro DNS, non lascerebbe aperta la possibilità di disabilitare gli aggiornamenti dinamici nei loro DNS, a meno che questa opzione verrà lasciato per scopi più nascosti.
• Microsoft offre "Sicurezza" in cambio di Darkness, come mi ha detto un collega e amico che ha superato i corsi di certificazione Microsft®. Vero. Inoltre, me lo ha confermato El Fueguino.
• Un client che acquisisce un indirizzo IP tramite DHCP installato su una macchina UNIX® / Linux, ad esempio, non sarà in grado di risolvere l'indirizzo IP del proprio nome fino a quando non ti unisci al dominio Active Directory, purché Microsoft® o un BIND vengano utilizzati come DNS senza aggiornamenti dinamici da un DHCP.
• Se installo DHCP nella stessa Active Directory®, devo dichiarare che le zone vengono aggiornate da Microsoft® DHCP.
• Se utilizziamo BIND come DNS per la rete Windows, è logico e consigliato di installare il duo BIND-DHCP, con quest'ultimo che aggiorna dinamicamente il BIND e la questione si conclude.
• Nel mondo delle reti LAN su UNIX® / Linux, da quando sono stati inventati gli aggiornamenti dinamici su BIND, è consentito solo il signor DHCP «penetrare»Alla signora BIND con i suoi aggiornamenti. Il relax che è con ordine, per favore.
• Quando dichiaro nella zona mordor.fan per esempio: consentire-aggiornamento {10.10.10.0/24; };, BIND stesso mi informa all'avvio o al riavvio che:

  • zone 'mordor.fan' consente gli aggiornamenti in base all'indirizzo IP, che non è sicuro

• Nel sacrosanto mondo UNIX® / Linux, una tale conoscenza del DNS è semplicemente inammissibile.

Puoi immaginare il resto dello scambio con il mio amico Il Fuegian attraverso e-mail, Chat di Telegram, telefonate pagate da lui (certo amico, non ho un chilo per quello), e persino messaggi attraverso i piccioni viaggiatori nel XXI secolo!

Ha persino minacciato di non mandarmi un figlio del suo animale domestico, la sua Iguana «Petra»Che mi aveva promesso come parte del pagamento. Là mi sono davvero spaventato. Così ho ricominciato, ma da un'altra angolazione.

• La "quasi" Active Directory che si può ottenere con Samba 4, risolve questo aspetto in modo magistrale, sia quando si usa il suo DNS interno, sia il BIND compilato per supportare le zone DLZ - Zone caricate dinamyco Zone caricate dinamicamente.
• Continua a soffrire dello stesso: quando un client acquisisce un indirizzo IP tramite un DHCP installato in Otra Macchina UNIX® / Linux, non sarai in grado di risolvere l'indirizzo IP del tuo nome finché non viene unito al dominio di Samba 4 AD-DC.
• Integra BIND-DLZ e DHCP duo sulla stessa macchina in cui il file AD-DC Samba 4 è un lavoro per un vero specialista.

Il Fuegian Mi ha chiamato al capitolo e mi ha urlato: NON stiamo parlando AD-DC Samba 4, ma da Microsoft® Active Directory®!. E ho risposto umilmente che ero felicissimo di parte dei seguenti articoli che stavo per scrivere.

Fu allora che gli dissi che la decisione finale sugli aggiornamenti dinamici dei computer client sulla sua rete era lasciata alla sua libera volontà. Che gli darei solo il tipo scritto prima circa consentire-aggiornamento {10.10.10.0/24; };e più niente. Che non ero responsabile di ciò che risultava da quella promiscuità che ogni client Windows -o Linux- nella propria rete «penetrerà»Impunemente al BIND.

Se sapessi, amico mio, lettore che quello era il punto finale della rissa, non ci crederesti. mio amico Il Fuegian ha accettato la soluzione - e mi manderà l'iguana «Pete«- che ora condivido con te.

Installiamo e configuriamo DHCP

Per maggiori dettagli leggi DNS e DHCP in Debian 8 "Jessie".

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

root @ dnslinux: ~ # nano / etc / default / isc-dhcp-server .... # Su quali interfacce il server DHCP (dhcpd) dovrebbe servire le richieste DHCP? # Separare più interfacce con spazi, ad esempio "eth0 eth1". INTERFACCE = "eth0" root @ dnslinux: ~ # dnssec-keygen -a HMAC-MD5 -b 128 -r / dev / urandom -n USER dhcp-key
Kdhcp-key. + 157 + 29836

root @ dnslinux: ~ # cat Kdhcp-key. +157 + 29836.private
Formato chiave privata: v1.3 Algoritmo: 157 (HMAC_MD5) Chiave: 3HT / bg / 6YwezUShKYofj5g == Bit: AAA = Creato: 20170212205030 Pubblica: 20170212205030 Attiva: 20170212205030

root @ dnslinux: ~ # nano dhcp.key
chiave dhcp-chiave {algoritmo hmac-md5; segreto "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
// // Esegui qui una configurazione locale // // Considera l'idea di aggiungere qui le zone 1918, se non vengono utilizzate nella tua // organizzazione, includi "/etc/bind/zones.rfc1918"; includere "/etc/bind/zones.rfcFreeBSD";
// Non dimenticare ... ho dimenticato e pagato con errori. ;-)
includere "/etc/bind/dhcp.key";


zona "mordor.fan" {tipo master;
        consentire-aggiornamento {10.10.10.3; chiave dhcp-chiave; };
        file "/var/lib/bind/db.mordor.fan"; }; zona "10.10.10.in-addr.arpa" {tipo master;
        consentire-aggiornamento {10.10.10.3; chiave dhcp-chiave; };
        file "/var/lib/bind/db.10.10.10.in-addr.arpa"; }; zona "_msdcs.mordor.fan" {tipo master; i nomi di controllo ignorano; file "/etc/bind/db._msdcs.mordor.fan"; };

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

root @ dnslinux: ~ # nano /etc/dhcp/dhcpd.conf
ddns-update-style interim; ddns-updates su; ddns-domainname "mordor.fan."; ddns-rev-nome-dominio "in-addr.arpa."; ignorare gli aggiornamenti del client; autorevole; opzione ip-forwarding disattivata; opzione nome-dominio "mordor.fan"; includere "/etc/dhcp/dhcp.key"; zone mordor.fan. {primaria 127.0.0.1; chiave dhcp-chiave; } zone 10.10.10.in-addr.arpa. {primaria 127.0.0.1; chiave dhcp-chiave; } rete condivisa redlocal {subnet 10.10.10.0 netmask 255.255.255.0 {opzione router 10.10.10.1; opzione subnet-mask 255.255.255.0; opzione broadcast-address 10.10.10.255; opzione nome-dominio-server 10.10.10.5; opzione netbios-name-servers 10.10.10.5; intervallo 10.10.10.30 10.10.10.250; }} # END dhcpd.conf

root @ dnslinux: ~ # dhcpd -t
Server DHCP di Internet Systems Consortium 4.3.1 Copyright 2004-2014 Internet Systems Consortium. Tutti i diritti riservati. Per informazioni, visitare https://www.isc.org/software/dhcp/ File di configurazione: /etc/dhcp/dhcpd.conf File di database: /var/lib/dhcp/dhcpd.leases File PID: / var / run /dhcpd.pid

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

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

Relativo a Controlli con i clienti, E il Modifica manuale dei file di zona, lasciamo a te, amico lettore, di leggerlo direttamente da DNS e DHCP in Debian 8 "Jessie"e applicalo alle tue condizioni reali. Abbiamo effettuato tutti i controlli necessari e ottenuto risultati soddisfacenti. Ovviamente inviamo una copia di tutti a Il Fuegian. Non ci saranno più!

Consigli

generale

• Ottieni una buona dose di pazienza prima di iniziare.
  
• Installa e configura prima BIND. Controlla tutto e vedi tutti i record che hai dichiarato in ogni file delle tre-o più- zone, sia da Active Directory che dal server DNS stesso su Linux. Se possibile, da una macchina Linux che non è unita al dominio, effettuare le query DNS necessarie a BIND.
  
• Unisciti a un client Windows con un indirizzo IP fisso al dominio esistente e ricontrolla tutte le impostazioni BIND dal client Windows.
• Dopo che sei indubbiamente sicuro che la configurazione del tuo nuovissimo BIND sia completamente corretta, avventurati nell'installazione, configurazione e avvio del servizio DHCP.
• In caso di errori, ripetere l'intera procedura da zero 0.
• Fai attenzione con il copia e incolla! e gli spazi extra in ogni riga dei file named.conf.xxxx
  
• In seguito non si è lamentato - tanto meno al mio amico Fuegiano - di non essere stato adeguatamente consigliato.

Altri suggerimenti

• Dividere e conquistare.
• In una rete di PMI è più sicuro e vantaggioso installare un BIND autorevole per le zone LAN interne che non ricorre ad alcun server root: ricorsione no;.
• In una rete di PMI situata sotto un provider di accesso a Internet - ISP, forse i servizi delega y SMTP devono risolvere i nomi di dominio su Internet. Lui Calamaro hai la possibilità di dichiarare il tuo DNS esterno o meno, mentre sei su un server di posta basato su Postfix o MDaemon® Possiamo anche dichiarare i server DNS che useremo in quel servizio. In casi come questo, cioè i casi che non forniscono servizi a Internet e che rientrano in un Provider di servizi Internet, puoi installare un BIND con Spedizionieri che punta al DNS del ISP, e dichiararlo come DNS secondario nei server che devono risolvere le query esterne alla LAN, altrimenti è possibile dichiararli tramite i propri file di configurazione.
• Se hai una Zona Delegata sotto la tua intera responsabilitàPoi un altro canto del gallo:
  • Installa un server DNS basato su NSD, che è un server DNS autorevole per definizione, che risponde alle query dei computer su Internet. Per alcune informazioni attitudinale mostra nsd. 😉 Si prega di proteggerlo molto bene con tutte le pareti tagliafuoco necessarie. Sia hardware che software. Sarà un DNS per Internet e che «cara»Non dobbiamo darlo con i pantaloni bassi. 😉
  • Non essendomi mai visto in un caso come questo, cioè totalmente responsabile di una Zona Delegata, dovrei pensare molto bene cosa consigliare per la risoluzione di nomi a dominio esterni alla nostra LAN per i servizi che ne hanno bisogno. I clienti della rete PMI non ne hanno davvero bisogno. Consulti la letteratura specializzata, o uno specialista in queste materie, poiché sono lontano dall'essere uno di loro. Sul serio.
  • La ricorsione non esiste sui server autoritari. Va bene?. Nel caso in cui qualcuno lo faccia con un BIND.
• Sebbene specifichiamo esplicitamente nel file /etc/dhcp/dhcpd.conf la dichiarazione ignorare gli aggiornamenti del client;, se giriamo su una console di computer dnslinux.mordor.fan l'ordine journalctl -f, lo vedremo all'avvio del client win7.mordor.fan otteniamo i seguenti messaggi di errore:

  • 12 febbraio 16:55:41 dnslinux denominato [900]: client 10.10.10.30 # 58762: aggiornamento 'mordor.fan/IN' negato
    12 febbraio 16:55:42 dnslinux denominato [900]: client 10.10.10.30 # 49763: aggiornamento 'mordor.fan/IN' negato
    12 febbraio 16:56:23 dnslinux denominato [900]: client 10.10.10.30 # 63161: aggiornamento 'mordor.fan/IN' negato
    

  • Per eliminare questi messaggi, dobbiamo andare nelle opzioni avanzate della configurazione della scheda di rete e deselezionare l'opzione «Registra gli indirizzi di questa connessione in DNS«. Ciò impedirà al client di provare a registrarsi automaticamente nel DNS di Linux per sempre e la fine del problema. Mi spiace, ma non ho una copia di Windows 7 in spagnolo. 😉
• Per scoprire tutte le domande serie - e folli - che un client Windows 7 fa, controlla il log query.log che per qualcosa lo dichiariamo nella configurazione BIND. L'ordine sarebbe:

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

• Se non si consente ai computer client di connettersi direttamente a Internet, perché sono necessari i server DNS principali? Ciò ridurrà notevolmente l'output del comando journalctl -f e dal precedente, se il tuo server DNS Autoritario per le Zone Interne non si connette direttamente a Internet, cosa altamente raccomandata dal punto di vista della sicurezza.

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

• Se non hai bisogno della dichiarazione dei root server, allora perché hai bisogno della ricorsione - Ricorsione?

  root @ dnslinux: ~ # nano /etc/bind/named.conf.options
  opzioni {
   ....
   ricorsione no;
   ....
  };

Consigli specifici di cui non sono ancora molto chiaro

El uomo dhcpd.conf ci dice quanto segue tra molte altre cose:

        La dichiarazione di ottimizzazione dell'aggiornamento

            flag di ottimizzazione dell'aggiornamento;

            Se il parametro di ottimizzazione dell'aggiornamento è falso per un determinato client, il server tenterà un aggiornamento DNS per quel client ogni volta che il client rinnova il contratto di locazione, invece di tentare un aggiornamento solo quando sembra essere necessario. Ciò consentirà al DNS di riparare più facilmente dalle incoerenze del database, ma il costo è che il server DHCP deve eseguire molti più aggiornamenti DNS. Si consiglia di leggere questa opzione abilitata, che è l'impostazione predefinita. Questa opzione influisce solo sul comportamento dello schema di aggiornamento DNS provvisorio e non ha alcun effetto sullo schema di aggiornamento DNS ad-hoc. Se questo parametro non è specificato o è true, il server DHCP si aggiornerà solo quando le informazioni sul client cambiano, il client riceve un lease diverso o il lease del client scade.

La traduzione o interpretazione più o meno esatta è lasciata a te, caro lettore.

Personalmente, mi è capitato - ed è successo durante la stesura di questo articolo - che quando collego un BIND ad un Active Directory®, è da Microsft® o Samba 4, se cambio il nome di un computer client registrato nel dominio Active Directory® o di dC-DC di Samba 4, mantiene il suo vecchio nome e indirizzo IP nella Direct Zone, e non viceversa, che è correttamente aggiornato con il nuovo nome. In altre parole, il vecchio e il nuovo nome vengono mappati allo stesso indirizzo IP nella Direct Zone, mentre al contrario viene visualizzato solo il nuovo nome. Per capirmi bene, devi provare tu stesso.

Penso che sia una sorta di vendetta nei confronti Il Fuegian -non a me, per favore- per aver provato a migrare i tuoi servizi su Linux.

Ovviamente il vecchio nome scomparirà quando sarà TL 3600o l'ora che abbiamo dichiarato nella configurazione DHCP. Ma vogliamo che scompaia immediatamente come accade in un BIND + DHCP senza Active Directory tramite.

La soluzione a quella situazione l'ho trovata inserendo la dichiarazione aggiornamento-ottimizzazione false; alla fine dell'inizio del file /etc/dhcp/dhcpd.conf:

ddns-update-style interim; ddns-updates su; ddns-domainname "mordor.fan."; ddns-rev-nome-dominio "in-addr.arpa."; ignorare gli aggiornamenti del client;
aggiornamento-ottimizzazione false;

Se qualche lettore ne sa di più, per favore illuminami. Lo apprezzerò molto.

Riassunto

Ci siamo divertiti molto con l'argomento, giusto? Nessuna sofferenza perché abbiamo un BIND che funziona come un server DNS in una rete Microsoft®, che offre tutti i record SRV e risponde in modo appropriato alle query DNS fatte loro. D'altra parte abbiamo un server DHCP che garantisce gli indirizzi IP e aggiorna dinamicamente correttamente le zone BIND.

Ma non possiamo chiedere ... per il momento.

Spero amico mio Il Fuegian sii felice e soddisfatto del primo passo della tua migrazione a Linux per rendere sopportabili i costi insopportabili dell'assistenza tecnica Microsft®.

Nota importante

Personaggio "Il Fuegian»È completamente immaginario e un prodotto della mia immaginazione. Qualsiasi somiglianza o coincidenza con persone reali è la stessa cosa: pura coincidenza involontaria da parte mia. L'ho creato solo per rendere un po 'piacevole scrivere e leggere questo articolo. Ora, se puoi dirmi che il problema DNS è oscuro,