Introduzione
Una parte importante della gestione della configurazione del server e dell’infrastruttura riguarda il mantenimento di un modo per trovare le interfacce di rete e gli indirizzi IP per nome. Un modo per farlo è configurare un sistema di nome di dominio (DNS) corretto. L’utilizzo di nomi di dominio completi (FQDN), anziché indirizzi IP, per specificare gli indirizzi di rete ottimizza la configurazione dei servizi e delle applicazioni e aumenta la manutenibilità dei file di configurazione. Configurare il proprio DNS per la propria rete privata è un ottimo modo per migliorare la gestione dei server.
In questo tutorial, configurerai un server DNS interno utilizzando due server Ubuntu 22.04. Utilizzerai il software del server di nome BIND (BIND9) per risolvere i nomi host privati e gli indirizzi IP privati. Questo fornisce un modo centralizzato per gestire i nomi host interni e gli indirizzi IP privati, che è indispensabile quando l’ambiente si espande a più di alcuni host.
Prerequisiti
Per completare questo tutorial, avrai bisogno dell’infrastruttura seguente. Assicurati di creare ogni server nella stessa rete privata del data center:
- A fresh Ubuntu 22.04 server to serve as the Primary DNS server, ns1.
- (Consigliato) Un secondo server Ubuntu 22.04 da utilizzare come server DNS secondario, ns2.
- Almeno un server aggiuntivo. Questa guida assume che tu abbia altri due server, che verranno chiamati server client. Questi server client devono essere creati nello stesso datacenter in cui si trovano i tuoi server DNS.
Su ciascuno di questi server, configura un utente amministrativo sudo e configura un firewall seguendo la nostra guida Configurazione iniziale del server Ubuntu 22.04.
Se non sei familiare con i concetti DNS, ti consigliamo di leggere almeno le prime tre parti della nostra Introduzione alla gestione dei DNS
Su DigitalOcean, tutti i nuovi Droplet creati vengono inseriti automaticamente in una Virtual Private Cloud (VPC). Consulta la nostra documentazione sul prodotto VPC per saperne di più.
Esempio di infrastruttura e obiettivi
Per gli scopi di questo articolo, supporremo quanto segue:
- Hai due server che saranno designati come tuoi server di nomi DNS. Questa guida farà riferimento a questi come ns1 e ns2.
- Hai due server client aggiuntivi che utilizzeranno l’infrastruttura DNS che creerai, denominati host1 e host2 in questa guida. Puoi aggiungere quanti server client desideri.
- Tutti questi server esistono nello stesso datacenter. Questo tutorial assume che questo datacenter sia chiamato
nyc3. - Tutti questi server hanno abilitata la rete privata e si trovano nella subnet
10.128.0.0/16(probabilmente dovrai adattarlo per i tuoi server). - Tutti i server sono connessi a un progetto che funziona su
example.com. Questa guida descrive come configurare un sistema DNS interno e privato, in modo da poter utilizzare qualsiasi nome di dominio desideri invece diexample.com. I server DNS cercheranno sempre di instradare prima le richieste internamente, il che significa che non cercheranno di raggiungere il dominio dato su internet pubblico. Tuttavia, l’utilizzo di un dominio di tua proprietà potrebbe aiutare a evitare conflitti con domini pubblicamente instradabili.
Tenendo presente queste ipotesi, gli esempi in questa guida utilizzeranno uno schema di denominazione basato sul sottodominio nyc3.example.com per fare riferimento alla sotto rete o zona privata di esempio. Pertanto, il Nome di Dominio Completo (FQDN) privato di host1 sarà host1.nyc3.example.com. La seguente tabella contiene i dettagli rilevanti utilizzati negli esempi in tutta questa guida:
| Host | Role | Private FQDN | Private IP Address |
|---|---|---|---|
| ns1 | Primary DNS Server | ns1.nyc3.example.com |
10.128.10.11 |
| ns2 | Secondary DNS Server | ns2.nyc3.example.com |
10.128.20.12 |
| host1 | Generic Host 1 | host1.nyc3.example.com |
10.128.100.101 |
| host2 | Generic Host 2 | host2.nyc3.example.com |
10.128.200.102 |
Nota: La tua configurazione sarà diversa, ma i nomi degli esempi e gli indirizzi IP verranno utilizzati per mostrare come configurare un server DNS per fornire un DNS interno funzionante. Dovresti essere in grado di adattare questa configurazione al tuo ambiente sostituendo i nomi host e gli indirizzi IP privati con i tuoi. Non è necessario utilizzare il nome della regione del datacenter nel tuo schema di denominazione, ma lo usiamo qui per indicare che questi host appartengono alla rete privata di un particolare datacenter. Se esegui server in più datacenter, puoi configurare un DNS interno all’interno di ciascun datacenter rispettivo.
Alla fine di questo tutorial, avrai un server DNS primario, ns1, e facoltativamente un server DNS secondario, ns2, che fungerà da backup.
Mentre segui questo tutorial, ci saranno momenti in cui dovrai eseguire determinati comandi su un server specifico in questa configurazione. Qualsiasi comando che deve essere eseguito su ns1 avrà uno sfondo blu, come questo:
-
Allo stesso modo, qualsiasi comando che deve essere eseguito su ns2 avrà uno sfondo rosso:
-
E qualsiasi comando che deve essere eseguito su uno dei tuoi server client avrà uno sfondo verde:
-
E qualsiasi comando che deve essere eseguito su più server avrà uno sfondo blu standard:
-
Infine, sii consapevole che ogni volta che un comando o un blocco di codice contiene testo evidenziato come questo, significa che quel testo è importante. Questo tipo di evidenziazione verrà utilizzato in tutta questa guida per indicare dettagli che devono essere sostituiti con le tue impostazioni o che il testo evidenziato deve essere modificato o aggiunto a un file di configurazione. Ad esempio, se un esempio contiene qualcosa come host1.nyc3.example.com, sostituiscilo con il FQDN del tuo server.
Cominciamo installando BIND su entrambi i tuoi server DNS primario e secondario, ns1 e ns2.
Passo 1 — Installazione di BIND sui server DNS
Su entrambi i server DNS, ns1 e ns2, aggiorna la cache dei pacchetti apt digitando:
- sudo apt update
Quindi installa BIND su ogni macchina:
- sudo apt install bind9 bind9utils bind9-doc
La rete privata di DigitalOcean utilizza esclusivamente IPv4. Se questo è il tuo caso, imposta BIND in modalità IPv4. Su entrambi i server, modifica il file delle impostazioni predefinite di named usando il tuo editor di testo preferito. L’esempio seguente utilizza nano:
- sudo nano /etc/default/named
Aggiungi -4 alla fine del parametro OPTIONS:
. . .
OPTIONS="-u bind -4"
Salva e chiudi il file quando hai finito. Se hai usato nano per modificare il file, puoi farlo premendo CTRL + X, Y, quindi ENTER.
Riavviare BIND per implementare le modifiche:
- sudo systemctl restart bind9
Ora che BIND è installato, configuriamo il server DNS primario.
Passaggio 2 — Configurazione del Server DNS Primario
La configurazione di BIND consiste in più file inclusi nel file di configurazione principale, named.conf. Questi nomi di file iniziano con named perché è il nome del processo eseguito da BIND (named è l’abbreviazione di “name daemon”, come in “domain name daemon”). Inizieremo con la configurazione del file named.conf.options.
Configurazione del File delle Opzioni
Su ns1, apri il file named.conf.options per la modifica:
- sudo nano /etc/bind/named.conf.options
Sopra il blocco options esistente, crea un nuovo blocco ACL (access control list) chiamato trusted. Qui definirai una lista di clienti da cui consentirai query DNS ricorsive (cioè i tuoi server che si trovano nello stesso datacenter di ns1). Aggiungi le seguenti righe per aggiungere ns1, ns2, host1 e host2 alla tua lista di clienti fidati, assicurandoti di sostituire gli esempi di indirizzi IP privati con quelli dei tuoi server:
acl "trusted" {
10.128.10.11; # ns1
10.128.20.12; # ns2
10.128.100.101; # host1
10.128.200.102; # host2
};
options {
. . .
Ora che hai la tua lista di clienti DNS fidati, puoi modificare il blocco options. Questo è attualmente l’inizio del blocco:
. . .
};
options {
directory "/var/cache/bind";
. . .
}
Sotto la direttiva directory, aggiungi le righe di configurazione evidenziate (e sostituisci con l’indirizzo IP privato appropriato di ns1):
. . .
};
options {
directory "/var/cache/bind";
recursion yes; # enables recursive queries
allow-recursion { trusted; }; # allows recursive queries from "trusted" clients
listen-on { 10.128.10.11; }; # ns1 private IP address - listen on private network only
allow-transfer { none; }; # disable zone transfers by default
forwarders {
8.8.8.8;
8.8.4.4;
};
. . .
};
Nota il blocco forwarders, che include due indirizzi IP: 8.8.8.8 e 8.8.4.4. Questo blocco definisce forwarders, un meccanismo speciale che BIND utilizza per ridurre il traffico sui collegamenti verso i nameserver esterni. BIND può anche utilizzare i forwarder per consentire query da parte di server che non hanno accesso diretto a Internet. Questo può contribuire a rendere più veloci le risposte a queste query riducendo il carico sulla rete locale.
I due indirizzi IP in questo blocco rappresentano i risolutori DNS pubblici di Google, ma l’indirizzo IP di qualsiasi server di nomi ricorsivo pubblico funzionerà qui. Ad esempio, potresti utilizzare l’indirizzo IP del server DNS di Cloudflare (1.1.1.1) al suo posto.
Quando hai finito, salva e chiudi il file named.conf.options. La configurazione sopra specifica che solo i tuoi server (quelli trusted) potranno interrogare il tuo server DNS per domini esterni.
Successivamente, specifica le tue zone DNS configurando il file named.conf.local.
Configurazione del File Locale
Su ns1, apri il file named.conf.local per la modifica:
- sudo nano /etc/bind/named.conf.local
A parte qualche commento, il file sarà vuoto. Qui, specifica le tue zone forward e reverse. Le zone DNS designano uno specifico ambito per la gestione e la definizione dei record DNS. Dato che gli esempi di questo guida saranno tutti nel sottodominio nyc3.example.com, lo utilizzeremo come zona forward. Poiché gli indirizzi IP privati dei nostri server di esempio sono tutti nello spazio 10.128.0.0/16, l’esempio seguente configurerà una zona reverse per definire ricerche inverse all’interno di quel range.
Aggiungi la zona forward con le seguenti righe, sostituendo il nome della zona con il tuo e l’indirizzo IP privato del server DNS secondario nella direttiva allow-transfer:
. . .
zone "nyc3.example.com" {
type primary;
file "/etc/bind/zones/db.nyc3.example.com"; # zone file path
allow-transfer { 10.128.20.12; }; # ns2 private IP address - secondary
};
Assumendo che il nostro subnet privato sia 10.128.0.0/16, aggiungi la zona reverse con le seguenti righe (nota che il nome della nostra zona reverse inizia con 128.10 che è l’inversione degli ottetti di 10.128):
. . .
};
zone "128.10.in-addr.arpa" {
type primary;
file "/etc/bind/zones/db.10.128"; # 10.128.0.0/16 subnet
allow-transfer { 10.128.20.12; }; # ns2 private IP address - secondary
};
Se i tuoi server si estendono su più subnet private ma sono nello stesso datacenter, assicurati di specificare una zona aggiuntiva e un file di zona per ciascuna subnet distinta. Quando hai finito di aggiungere tutte le zone desiderate, salva e chiudi il file “named.conf.local”.
Ora che le tue zone sono specificate in BIND, devi creare i corrispondenti file di zona forward e reverse.
Creazione del file di zona forward
Il file di zona forward è dove definisci i record DNS per le ricerche forward DNS. Cioè, quando il DNS riceve una query di nome, ad esempio “host1.nyc3.example.com”, cercherà nel file di zona forward per risolvere l’indirizzo IP privato corrispondente a “host1”.
Crea la directory in cui risiederanno i tuoi file di zona. Secondo la configurazione del file “named.conf.local”, quella posizione dovrebbe essere “/etc/bind/zones”:
- sudo mkdir /etc/bind/zones
Basiamo il nostro esempio di file di zona forward sul file di zona “db.local” di esempio. Copialo nella posizione corretta con i seguenti comandi:
- sudo cp /etc/bind/db.local /etc/bind/zones/db.nyc3.example.com
Ora modifica il tuo file di zona forward:
- sudo nano /etc/bind/zones/db.nyc3.example.com
Inizialmente, conterrà contenuti simili ai seguenti:
$TTL 604800
@ IN SOA localhost. root.localhost. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost. ; delete this line
@ IN A 127.0.0.1 ; delete this line
@ IN AAAA ::1 ; delete this line
Prima di tutto, vorrai modificare il record SOA. Sostituisci il primo localhost con l’FQDN di ns1, quindi sostituisci root.localhost con admin.nyc3.example.com. Ogni volta che modifichi un file di zona, devi incrementare il valore di Serial prima di riavviare il processo named. Qui, incrementalo a 3:
. . .
;
$TTL 604800
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
. . .
In seguito, elimina i tre record alla fine del file (dopo il record SOA). Se non sei sicuro quali righe eliminare, sono contrassegnate con commenti che indicano delete this line nell’esempio precedente.
Alla fine del file, aggiungi i record del tuo server di nomi con le seguenti righe (sostituisci i nomi con i tuoi). Nota che la seconda colonna specifica che si tratta di record NS:
. . .
; name servers - NS records
IN NS ns1.nyc3.example.com.
IN NS ns2.nyc3.example.com.
Ora, aggiungi i record A per gli host che appartengono a questa zona. Questo include qualsiasi server il cui nome termina con .nyc3.example.com (sostituisci i nomi e gli indirizzi IP privati). Utilizzando i nostri esempi di nomi e indirizzi IP privati, aggiungeremo i record A per ns1, ns2, host1 e host2 come segue:
. . .
; name servers - A records
ns1.nyc3.example.com. IN A 10.128.10.11
ns2.nyc3.example.com. IN A 10.128.20.12
; 10.128.0.0/16 - A records
host1.nyc3.example.com. IN A 10.128.100.101
host2.nyc3.example.com. IN A 10.128.200.102
Il nostro file di zona forward finale conterrà il seguente contenuto:
$TTL 604800
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; name servers - NS records
IN NS ns1.nyc3.example.com.
IN NS ns2.nyc3.example.com.
; name servers - A records
ns1.nyc3.example.com. IN A 10.128.10.11
ns2.nyc3.example.com. IN A 10.128.20.12
; 10.128.0.0/16 - A records
host1.nyc3.example.com. IN A 10.128.100.101
host2.nyc3.example.com. IN A 10.128.200.102
Salva e chiudi il file db.nyc3.example.com.
Ora passiamo ai file di zona inversa.
Creazione dei file di zona inversa
File di zona inversa sono dove si definiscono i record DNS PTR per le ricerche DNS inverse. In pratica, quando il DNS riceve una richiesta tramite indirizzo IP, ad esempio 10.128.100.101, esso cercherà nel file o nei file di zona inversa per risolvere il corrispondente FQDN, in questo caso host1.nyc3.example.com.
Su ns1, per ogni zona inversa specificata nel file named.conf.local, creare un file di zona inversa. Esempi di file di zona inversa possono essere basati sul file di zona di esempio db.127. BIND utilizza questo file per memorizzare le informazioni per l’interfaccia loopback locale; 127 è il primo ottetto dell’indirizzo IP che rappresenta localhost (127.0.0.1). Copiare questo file nella posizione corretta utilizzando i comandi seguenti (sostituendo il nome del file di destinazione in modo che corrisponda alla definizione della zona inversa):
- sudo cp /etc/bind/db.127 /etc/bind/zones/db.10.128
Modificare il file di zona inversa corrispondente alle zone inverse definite in named.conf.local:
- sudo nano /etc/bind/zones/db.10.128
Inizialmente, il file conterrà contenuti simili ai seguenti:
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost. ; delete this line
1.0.0 IN PTR localhost. ; delete this line
Nello stesso modo del file di zona diretta, sarà necessario modificare il record SOA e incrementare il valore di serial:
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
. . .
Eliminare ora i due record alla fine del file (dopo il record SOA). Se non si è sicuri quali righe eliminare, sono contrassegnate con il commento delete this line nell’esempio precedente.
Alla fine del file, aggiungere i record del server di nomi con le seguenti righe (sostituendo i nomi con quelli propri). Notare che la seconda colonna specifica che si tratta di record NS:
. . .
; name servers - NS records
IN NS ns1.nyc3.example.com.
IN NS ns2.nyc3.example.com.
Quindi aggiungi record PTR per tutti i tuoi server il cui indirizzo IP è nella subnet del file di zona che stai modificando. Nel nostro esempio, questo include tutti i nostri host perché sono tutti sulla subnet 10.128.0.0/16. Nota che la prima colonna consiste negli ultimi due ottetti degli indirizzi IP privati dei tuoi server in ordine invertito. Assicurati di sostituire nomi e indirizzi IP privati per corrispondere ai tuoi server:
. . .
; PTR Records
11.10 IN PTR ns1.nyc3.example.com. ; 10.128.10.11
12.20 IN PTR ns2.nyc3.example.com. ; 10.128.20.12
101.100 IN PTR host1.nyc3.example.com. ; 10.128.100.101
102.200 IN PTR host2.nyc3.example.com. ; 10.128.200.102
Il tuo file di zona inversa finale sarà simile al seguente:
$TTL 604800
@ IN SOA nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
; name servers
IN NS ns1.nyc3.example.com.
IN NS ns2.nyc3.example.com.
; PTR Records
11.10 IN PTR ns1.nyc3.example.com. ; 10.128.10.11
12.20 IN PTR ns2.nyc3.example.com. ; 10.128.20.12
101.100 IN PTR host1.nyc3.example.com. ; 10.128.100.101
102.200 IN PTR host2.nyc3.example.com. ; 10.128.200.102
Salva e chiudi il file di zona inversa. Se è necessario aggiungere altri file di zona inversa, ripeti questa sezione.
Hai finito di modificare i tuoi file, quindi puoi controllare i tuoi file per eventuali errori.
Controllo della sintassi della configurazione BIND
Esegui il seguente comando per controllare la sintassi dei file named.conf*:
- sudo named-checkconf
Se i tuoi file di configurazione di named non hanno errori di sintassi, non ci saranno messaggi di errore e tornerai al prompt della shell. Se ci sono problemi con i tuoi file di configurazione, rivedi il messaggio di errore e la sezione Configurazione del server DNS primario, quindi riprova named-checkconf nuovamente.
Il comando named-checkzone può essere utilizzato per verificare la correttezza dei file di zona. Il primo argomento specifica il nome della zona, mentre il secondo argomento specifica il file di zona corrispondente, entrambi definiti in named.conf.local.
Ad esempio, per verificare la configurazione della zona forward nyc3.example.com, eseguire il seguente comando (modificare i nomi per corrispondere alla vostra zona forward e al file):
- sudo named-checkzone nyc3.example.com /etc/bind/zones/db.nyc3.example.com
Outputzone nyc3.example.com/IN: loaded serial 3
OK
E per verificare la configurazione della zona reverse 128.10.in-addr.arpa, eseguire il seguente comando (modificare i numeri per corrispondere alla vostra zona reverse e al file):
- sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128
Quando tutte le configurazioni e i file di zona non contengono errori, sarete pronti per riavviare il servizio BIND.
Riavvio di BIND
Riavviare BIND:
- sudo systemctl restart bind9
Se avete configurato il firewall UFW, aprite l’accesso a BIND digitando:
- sudo ufw allow Bind9
Il vostro server DNS primario è ora configurato e pronto a rispondere alle richieste DNS. Passiamo alla configurazione del server DNS secondario.
Passaggio 3 — Configurazione del Server DNS Secondario
Nella maggior parte degli ambienti, è una buona idea configurare un server DNS secondario che risponda alle richieste nel caso in cui il primario diventi non disponibile. Fortunatamente, la configurazione del server DNS secondario è molto meno complicata rispetto alla configurazione del primario.
Su ns2, modifica il file named.conf.options:
- sudo nano /etc/bind/named.conf.options
All’inizio del file, aggiungi l’ACL con gli indirizzi IP privati di tutti i tuoi server affidabili:
acl "trusted" {
10.128.10.11; # ns1
10.128.20.12; # ns2
10.128.100.101; # host1
10.128.200.102; # host2
};
options {
. . .
Sotto la direttiva directory, aggiungi le seguenti righe:
. . .
recursion yes;
allow-recursion { trusted; };
listen-on { 10.128.20.12; }; # ns2 private IP address
allow-transfer { none; }; # disable zone transfers by default
forwarders {
8.8.8.8;
8.8.4.4;
};
. . .
Salva e chiudi il file named.conf.options. Questo file dovrebbe essere identico al file named.conf.options di ns1, ad eccezione che dovrebbe essere configurato per ascoltare l’indirizzo IP privato di ns2.
Ora modifica il file named.conf.local:
- sudo nano /etc/bind/named.conf.local
Definisci zone secondarie che corrispondano alle zone primarie presenti nel server DNS primario. Nota che il tipo è secondary, il file non contiene un percorso e c’è una direttiva primaries che dovrebbe essere impostata sull’indirizzo IP privato del server DNS primario. Se hai definito più zone inverse nel server DNS primario, assicurati di aggiungerle tutte qui:
zone "nyc3.example.com" {
type secondary;
file "db.nyc3.example.com";
primaries { 10.128.10.11; }; # ns1 private IP
};
zone "128.10.in-addr.arpa" {
type secondary;
file "db.10.128";
primaries { 10.128.10.11; }; # ns1 private IP
};
Salva e chiudi il file named.conf.local.
Esegui il seguente comando per verificare la validità dei file di configurazione:
- sudo named-checkconf
Se questo comando non restituisce errori, riavvia BIND:
- sudo systemctl restart bind9
Quindi permetti le connessioni DNS al server modificando le regole del firewall UFW:
- sudo ufw allow Bind9
Con ciò, ora hai server DNS primari e secondari per la risoluzione dei nomi e degli indirizzi IP della rete privata. Ora devi configurare i tuoi server client per utilizzare i tuoi server DNS privati.
Passo 4 — Configurazione dei Client DNS
Prima che tutti i tuoi server nell’ACL trusted possano interrogare i tuoi server DNS, devi configurare ognuno di essi per usare ns1 e ns2 come server di nomi.
Assumendo che i tuoi server client utilizzino Ubuntu, dovrai scoprire quale dispositivo è associato alla tua rete privata. Puoi farlo interrogando la sottorete privata con il comando ip address. Esegui il seguente comando su ciascuna delle tue macchine client, sostituendo la sottorete evidenziata con la tua:
- ip address show to 10.128.0.0/16
Output3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
altname enp0s4
altname ens4
inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1
valid_lft forever preferred_lft forever
In questo esempio, l’interfaccia privata è eth1. Gli esempi in questa sezione faranno riferimento a eth1 come interfaccia privata, ma dovresti cambiare questi esempi per riflettere le interfacce private dei tuoi server.
Su Ubuntu 22.04, la configurazione di rete è gestita con Netplan, un’astrazione che consente di scrivere configurazioni di rete standardizzate e applicarle a software di rete di backend compatibili. Per configurare DNS, è necessario scrivere un file di configurazione Netplan.
Crea un nuovo file in /etc/netplan chiamato 00-private-nameservers.yaml:
- sudo nano /etc/netplan/00-private-nameservers.yaml
All’interno, aggiungi i seguenti contenuti. Sarà necessario modificare l’interfaccia della rete privata, gli indirizzi dei tuoi server DNS ns1 e ns2, e la zona DNS:
Nota: Netplan utilizza il formato di serializzazione dati YAML per i suoi file di configurazione. Poiché YAML utilizza l’indentazione e gli spazi bianchi per definire la sua struttura dati, assicurati che la tua definizione utilizzi un’indentazione coerente per evitare errori.
Puoi risolvere i problemi nel tuo file YAML utilizzando uno strumento di verifica YAML come YAML Lint.
network:
version: 2
ethernets:
eth1: # Private network interface
nameservers:
addresses:
- 10.128.10.11 # Private IP for ns1
- 10.132.20.12 # Private IP for ns2
search: [ nyc3.example.com ] # DNS zone
Salva e chiudi il file quando hai finito.
Successivamente, digita il comando netplan try per cercare di utilizzare il nuovo file di configurazione. Se ci sono problemi che causano la perdita di connettività di rete, Netplan ripristinerà automaticamente le modifiche dopo un determinato periodo di tempo.
- sudo netplan try
OutputWarning: Stopping systemd-networkd.service, but it can still be activated by:
systemd-networkd.socket
Do you want to keep these settings?
Press ENTER before the timeout to accept the new configuration
Changes will revert in 120 seconds
Se il conto alla rovescia si aggiorna correttamente in basso, la nuova configurazione è almeno sufficientemente funzionale da non interrompere la connessione SSH. Premi INVIO per accettare la nuova configurazione.
Ora, controlla il risolutore DNS del sistema per verificare se la tua configurazione DNS è stata applicata.
- sudo resolvectl status
Scorri verso il basso fino a trovare la sezione relativa all’interfaccia della tua rete privata. Gli indirizzi IP privati dei tuoi server DNS dovrebbero essere elencati per primi, seguiti da alcuni valori di fallback. Il tuo dominio dovrebbe essere elencato dopo DNS Domain:
Output. . .
Link 3 (eth1)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 67.207.67.3
DNS Servers: 10.128.10.11 10.128.20.12 67.207.67.3 67.207.67.2
DNS Domain: nyc3.example.com
Il tuo client Ubuntu è ora configurato per utilizzare i tuoi server DNS interni.
Passaggio 5 — Test dei Clienti
Utilizza nslookup per testare se i tuoi clienti possono interrogare i tuoi server dei nomi. Dovresti essere in grado di farlo su tutti i clienti che hai configurato e che sono nella ACL trusted.
Puoi iniziare eseguendo una ricerca diretta.
Ricerca Diretta
Per eseguire una ricerca diretta per recuperare l’indirizzo IP di host1.nyc3.example.com, esegui il seguente comando:
- nslookup host1
La query su host1 si espande a host1.nyc3.example.com perché l’opzione search è impostata sul tuo sottodominio privato, e le query DNS cercheranno su quel sottodominio prima di cercare l’host altrove. Il comando precedente restituirà un output simile al seguente:
OutputServer: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: host1.nyc3.example.com
Address: 10.128.100.101
Successivamente, puoi controllare le ricerche inverse.
Ricerca Inversa
Per testare la ricerca inversa, interroga il server DNS con l’indirizzo IP privato di host1:
- nslookup 10.128.100.101
Questo dovrebbe restituire un output simile al seguente:
Output11.10.128.10.in-addr.arpa name = host1.nyc3.example.com.
Authoritative answers can be found from:
Se tutti i nomi e gli indirizzi IP si risolvono correttamente, significa che i tuoi file di zona sono configurati correttamente. Se ricevi valori inaspettati, assicurati di controllare i file di zona sul tuo server DNS primario (ad esempio, db.nyc3.example.com e db.10.128).
Come ultimo passaggio, questo tutorial ti mostrerà come mantenere i tuoi record di zona.
Passaggio 6 – Mantenere i record DNS
Ora che hai un DNS interno funzionante, è necessario mantenere i tuoi record DNS in modo che riflettano accuratamente l’ambiente del tuo server.
Aggiunta di un host a DNS
Ogni volta che aggiungi un host al tuo ambiente (nella stessa infrastruttura), vorrai aggiungerlo a DNS. Ecco una lista dei passaggi che devi seguire:
Name Server Primario
- File di zona forward: Aggiungi un record
Aper il nuovo host, incrementa il valore diSerial - File di zona reverse: Aggiungi un record
PTRper il nuovo host, incrementa il valore diSerial - Aggiungi l’indirizzo IP privato del tuo nuovo host all’ACL
trusted(named.conf.options)
Verifica i tuoi file di configurazione:
- sudo named-checkconf
- sudo named-checkzone nyc3.example.com /etc/bind/zones/db.nyc3.example.com
- sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128
Quindi ricarica BIND:
- sudo systemctl reload bind9
Il tuo server primario dovrebbe essere configurato per il nuovo host ora.
Server DNS secondario
- Aggiungi l’indirizzo IP privato del nuovo host all’ACL
trusted(named.conf.options)
Controlla la sintassi della configurazione:
- sudo named-checkconf
Quindi ricarica BIND:
- sudo systemctl reload bind9
Il tuo server secondario ora accetterà connessioni dal nuovo host.
Configura il nuovo host per utilizzare il tuo DNS
- Configura
/etc/resolv.confper utilizzare i tuoi server DNS - Testa usando
nslookup
Rimuovere un host dal DNS
Se rimuovi un host dal tuo ambiente o vuoi semplicemente eliminarlo dal DNS, rimuovi tutte le cose che sono state aggiunte quando hai aggiunto il server al DNS (cioè il contrario dei passaggi precedenti).
Conclusione
Ora puoi fare riferimento alle interfacce di rete private dei tuoi server per nome, anziché per indirizzo IP. Ciò semplifica la configurazione di servizi e applicazioni perché non devi più ricordare gli indirizzi IP privati, e i file saranno meno difficili da leggere e capire. Inoltre, ora puoi modificare le tue configurazioni per puntare a un nuovo server in un unico punto, il tuo server DNS primario, invece di dover modificare una varietà di file di configurazione distribuiti, il che ottimizza la manutenzione.
Una volta che hai configurato il tuo DNS interno e i tuoi file di configurazione utilizzano FQDN privati per specificare le connessioni di rete, è critico che i tuoi server DNS siano adeguatamente mantenuti. Se entrambi diventano non disponibili, i tuoi servizi e le tue applicazioni che dipendono da essi smetteranno di funzionare correttamente. Ecco perché si consiglia di configurare il tuo DNS con almeno un server secondario e di mantenere backup funzionanti di tutti.
Se desideri saperne di più su DNS, ti invitiamo a consultare il nostro articolo Introduzione alla Terminologia, ai Componenti e ai Concetti del DNS.