Configurare il server-dns-autorevole-bind9 su Debian 10 | Linuxiano.it
Privacy Policy

Configurare il server-dns-autorevole-bind9 su Debian 10

Configurare il server DNS autorevole su Debian 10 Buster con BIND9

Questo tutorial ti mostrerà come configurare ed eseguire il tuo server dei nomi autorevole su Debian 10 Buster con il software BIND 9 ampiamente usato

Che cos’è un server DNS autorevole?

Se possiedi un nome di dominio e desideri che il tuo server DNS gestisca la risoluzione del nome del tuo dominio anziché utilizzare il server DNS del registrar del tuo dominio, dovrai impostare un server DNS autorevole.

Un server DNS autorevole viene utilizzato dai proprietari dei nomi di dominio per archiviare i record DNS. Fornisce risposte autorevoli ai risolutori DNS (come 8.8.8.8 o 1.1.1.1), che interrogano i record DNS per conto degli utenti finali su PC, smartphone o tablet.

Informazioni su BIND

BIND (Berkeley Internet Name Domain) è un software DNS open source, flessibile e completo ampiamente utilizzato su Unix / Linux grazie alla sua stabilità e alta qualità. È stato originariamente sviluppato da UC Berkeley e successivamente nel 1994 il suo sviluppo è stato spostato in Internet Systems Consortium, Inc (ISC). Può agire come un server DNS autorevole per una zona e un risolutore DNS contemporaneamente. Un resolver DNS può anche essere chiamato un server dei nomi ricorsivo perché esegue ricerche DNS ricorsive per gli utenti finali. Tuttavia, assumere due ruoli contemporaneamente non è vantaggioso. È buona norma separare i due ruoli su due macchine diverse.

Mettere un server DNS su una rete consente la sostituzione di indirizzi IP di singole macchine con un nome. Di conseguenza, è anche possibile associare più nomi allo stesso computer per aggiornare i diversi servizi disponibili. Ad esempio, www.example.com e pop.example.com, entrambi potrebbero puntare al server primario in cui risiedono il server di posta e la rete Intranet aziendale e il dominio potrebbe essere example.com. È facile ricordare che questi due servizi sono in esecuzione sullo stesso computer il cui indirizzo IP è 192.168.0.1.

Ora immagina che il nostro amministratore di rete decida per un motivo o per l’altro di spostare il server di posta sul computer 192.168.0.11. L’unica cosa che deve essere modificata è il file di configurazione del server DNS. Potresti sempre andare a modificare la configurazione dell’host per tutti gli utenti, ma sarebbe dispendioso in termini di tempo e scomodo.

definizioni

  • DNS : Domain Name System o Domain Name Server
  • Server primario :
  • Server secondario :
  • Cache del server :
  • Layout di rete

Otteniamo l’accesso a Internet tramite un xxxbox (192.168.1.1), due server DNS forniti dal nostro ISP (80.10.249.2, 80.10.246.129). In effetti, questi ultimi due server verranno mai indicati nella configurazione perché xxxbox sarà responsabile della risoluzione dei nomi se la destinazione del pacchetto non è nota. Di conseguenza, considero xxxbox come un server primario al di fuori del nostro dominio. Il server “sid” (192.168.1.10) è collegato a xxxbox tramite la sua scheda di rete principale. È anche collegato alla LAN (192.168.0.0/24) dalla sua interfaccia di rete secondaria (192.168.0.1). È su questo che installeremo il server DNS primario per il nostro dominio example.com ( RFC 2606 ) A tutti i computer della LAN viene assegnato automaticamente un singolo indirizzo dal servizio DHCP. Il DHCP fornisce anche l’indirizzo del server DNS primario per il nostro dominio e aggiorna i nomi host per la zona example.com in modo che possano essere associati a un indirizzo IP.

Gestione del server-dns-autorevole-bind9

Installazione

Il pacchetto bind9 verrà utilizzato per l’installazione.

Terminale
  1. sudo apt update
  2. sudo apt install bind9 bind9utils bind9-doc

Controlla la versione:

Terminale
  • named  -v

Risultato:

Terminale
  • BIND 9.11.3-1ubuntu1.8-Ubuntu (Extended Support Version) <id:a375815>

Per controllare il numero di versione e le opzioni di creazione, eseguire

Terminale
  • named -V

server-dns-autorevole-bind9

Per impostazione predefinita, BIND si avvia automaticamente dopo l’installazione. Puoi verificarne lo stato con:

Terminale
  • systemctl status bind9

Risultato:

● bind9.service – BIND Domain Name Server
Loaded: loaded (/lib/systemd/system/bind9.service; enabled; vendor preset: en
Active: active (running) since Tue 2019-07-23 12:13:44 CEST; 2min 7s ago
Docs: man:named(8)
Main PID: 17058 (named)
Tasks: 5 (limit: 4469)
CGroup: /system.slice/bind9.service
└─17058 /usr/sbin/named -f -u bin

Se non è in esecuzione, quindi avviarlo con:

Terminale
  • sudo systemctl start bind9

E abilitare l’avvio automatico all’avvio:

Terminale
  • sudo systemctl enable bind9

Il server BIND verrà eseguito come utente bind, creato durante l’installazione e in ascolto sulla porta 53 e UDP TCP, come si può vedere eseguendo il comando seguente:

Terminale
  • sudo netstat -lnptu | grep named

server-dns-autorevole-bind9

Il demone BIND è chiamato nominato . (Un demone è un pezzo di software che viene eseguito in background.) Il named binario è installato dal pacchetto bind9 con un altro binario importante: rndc, il controller del demone nome remoto, che è installato dal pacchetto bind9utils. Il binario rndc viene utilizzato per ricaricare / arrestare e controllare altri aspetti del demone BIND. La comunicazione avviene tramite la porta TCP 953.

Ad esempio, possiamo verificare lo stato del server dei nomi BIND:

Terminale
  • sudo rndc status

server-dns-autorevole-bind9

Il file di configurazione principale di BIND è /etc/bind/named.conf con impostazioni da altri 3 file.

  • /etc/bind/named.conf.options
  • /etc/bind/named.conf.local
  • /etc/bind/named.conf.default-zones

Immediatamente, il server BIND9 su Debian fornisce un servizio ricorsivo per client di rete locale e host locale. Poiché stiamo configurando un server DNS autorevole, dobbiamo disabilitare la ricorsione. Modifica il file /etc/bind/named.conf.options:

Terminale
  • sudo nano /etc/bind/named.conf.options

Aggiungi le seguenti righe nella clausola opzioni {…}.

// hide version number from clients for security reasons.
version “not currently available”;

// disable recursion on authoritative DNS server.
recursion no;

// enable the query log
querylog yes;

// disallow zone transfer
allow-transfer { none; };

Tecnicamente parlando, devi solo aggiungere la recursion no; per disabilitare la ricorsione, ma è meglio aggiungere le altre 3 direttive. Salva e chiudi il file. Quindi riavviare BIND.

Terminale
  • sudo systemctl restart bind9

Configurazione del server DNS principale

Scegli uno dei due server come server DNS principale. Lo ns1.example.com.

Il server DNS principale contiene la copia principale del file di zona. Le modifiche ai record DNS vengono eseguite su questo server. Un dominio può avere una o più zone DNS. Ogni zona DNS ha un file di zona che contiene tutti i record DNS in quella zona. Per semplicità, in questo articolo desidero utilizzare una singola zona DNS per gestire tutti i record DNS per il proprio nome di dominio.

Il file /etc/bind/named.conf.default-zones definisce la zona radice e la zona localhost. Per aggiungere una zona al tuo nome di dominiserver-dns-autorevole-bind9o, modifica il file /etc/bind/named.conf.local come spiegato di seguito.

Terminale
  • sudo nano /etc/bind/named.conf.local

Aggiungi le seguenti righe a questo file. Sostituisci example.com con il tuo nome di dominio. Sostituire 12.34.56.78 con l’indirizzo IP del server DNS slave.

zone “example.com” {
type master;
file “/etc/bind/db.example.com”;
allow-transfer { 12.34.56.78; };
}

Nella configurazione sopra, abbiamo creato una nuova zona con la clausola zone e abbiamo specificato che questa è la zona principale. Il file della zona è /etc/bind/db.example.com , dove aggiungeremo i record DNS. Il trasferimento di zona sarà consentito solo per il server DNS slave.

Invece di creare un file di zona da zero, possiamo usare un file modello di zona. Copia il contenuto di db.empty in un nuovo file.

Terminale
  • sudo cp /etc/bind/db.empty /etc/bind/db.example.com

Un file di zona può contenere 3 tipi di voci:

  1. Commenti : inizia con un punto e virgola (;)
  2. Direttive : inizia con un segno di dollaro ($)
  3. Record delle risorse : ovvero record DNS

Un file di zona in genere è costituito dai seguenti tipi di record DNS:

  • Il record SOA (Start of Authority) : definisce le caratteristiche chiave di una zona. È il primo record DNS nel file di zona è obbligatorio.
  • Record NS (Name Server) : specifica quali server vengono utilizzati per archiviare i record DNS e rispondere alle query DNS per un nome di dominio. Devono essere presenti
  • almeno due record NS in un file di zona.
  • Record MX (Mail Exchanger) : specifica quali host sono responsabili della consegna della posta elettronica per un nome di dominio.
  • Un record (Indirizzo) : converte i nomi DNS in indirizzi IPv4.
  • Record AAAA (Quad A) : converte i nomi DNS in indirizzi IPv6.
  • Record CNAME (Nome canonico) : viene utilizzato per creare un alias per un nome DNS.
  • Record TXT : SPF, DKIM, DMARC, ecc.

Ora modifichiamo il file di zona.

Terminale
  • sudo nano /etc/bind/db.example.com

Dove:

  • La direttiva $TTL definisce il valore Time to Live predefinito per la zona, ovvero l’ora in cui un record DNS può essere memorizzato nella cache su un resolver DNS. Questa direttiva è obbligatoria. Il tempo è specificato in secondi.
  • La direttiva $ORIGIN definisce il dominio di base.
  • I nomi di dominio principalidevono terminare con un punto (.). Quando un nome di dominio termina con un punto, è un nome di dominio completo (FQDN).
  • Il simbolo @ fa riferimento al dominio di base.
  • IN è la classe DNS. Sta per Internet. Esistono altre classi DNS ma vengono utilizzate raramente.

Il primo record in un file di zona è il record SOA (Start of Authority). Questo record contiene le seguenti informazioni:

  • Il server DNS principale .
  • Indirizzo e-mail dell’amministratore della zona . RFC 2142 raccomanda l’indirizzo e- [email protected][email protected] . Nel file di zona, questo indirizzo e-mail assume questo formato: hostmaster.example.com perché il simbolo @ ha un significato speciale nel file di zona.
  • Numero di serie della zona . Il numero seriale è un modo per tenere traccia delle modifiche nella zona da parte del server DNS slave. Per convenzione, il numero seriale assume un formato data: yyyymmddss, dove yyyy è il numero dell’anno a quattro cifre, mm è il mese, dd è il giorno e ss è il numero yyyymmddss del giorno. È necessario aggiornare il numero seriale quando vengono apportate modifiche al file della zona.
  • Aggiorna valore . Quando viene raggiunto il valore di aggiornamento, il server DNS slave tenterà di leggere il record SOA dal server DNS principale. Se il numero seriale aumenta, viene avviato un trasferimento di zona.
  • Riprova valore . Definisce l’intervallo tra i tentativi in ​​secondi se il server DNS slave non riesce a connettersi al server DNS master.
  • Scadenza: se il server DNS slave non è riuscito a contattare il server DNS principale per questo periodo di tempo, lo slave smetterà di rispondere alle richieste DNS per questa zona.
  • TTL cache negativa: definisce il tempo di permanenza del valore delle risposte DNS per nomi DNS inesistenti (NXDOMAIN).

I record TXT sono generalmente racchiusi tra virgolette doppie. Se si aggiunge il record DKIM , dobbiamo necessario racchiudere il valore tra parentesi.

Salva e chiudi il file. Verifica con questo comando se ci sono errori di sintassi nel file di configurazione principale. Un output silenzioso indica che non sono stati trovati errori.

Terminale
  • sudo named-checkconf

Quindi controlla la sintassi dei file di zona:rndc

Terminale
  • sudo named-checkzone example.com /etc/bind/db.example.comrndc

Se non vengono rilevati errori, riavvia BIND9.

Terminale
  • sudo systemctl restart bind9

Se utilizzi il firewall semplice (UFW) , apri la porta 53 e UDP TCP:

Terminale
  1. sudo ufw allow 53/tcp
  2. sudo ufw allow 53/udp

Se utilizzi direttamente il firewall iptables, esegui questo comando:

Terminale
  1. sudo iptables -A INPUT -p tcp –dport 53 -j ACCEPT
  2. sudo iptables -A INPUT -p udp –dprot 53 -j ACCEPT

Configurazione del server DNS slave

Ora usiamo l’altro server come server DNS slave, con il nome ns2.example.com.

Innanzitutto, modifica il file named.conf.local:

Terminale
  • sudo nano /etc/bind/named.conf.local

Aggiungi una zona come di seguito. Sostituire 12.34.56.78 con l’indirizzo IP del server DNS principale:

zone “example.com” {
type slave;
file “db.example.com”;
masters { 12.34.56.78; };
};

Nella configurazione sopra, abbiamo specificato che si tratta di un server DNS slave per la zona example.com e che accetterà i trasferimenti di zona solo dal server DNS master.

Salva e chiudi il file. Quindi esegui il seguente comando per verificare se ci sono errori di sintassi nel file di configurazione principale:

Terminale
  • sudo named-checkconf

Se non vengono rilevati errori, riavvia BIND9.

Terminale
  • sudo systemctl restart bind9

Il file di zona sul server DNS slave viene caricato da un trasferimento di zona, il quale viene utilizzato per sincronizzare le modifiche al record DNS dal server DNS master al server DNS slave. Dopo il riavvio di BIND9, il trasferimento di zona inizierà immediatamente. Controllare il registro BIND9 con il seguente comando:

Terminale
  • sudo journalctl -eu bind9

Puoi vedere i messaggi come sotto, che indicano che il trasferimento di zona è riuscito:

  • named[31518]: transfer of ‘example.com/IN’ from 12.34.56.78#53: Transfer completed: 1 messages, 16 records, 886 bytes, 0.004 secs (221500 bytes/sec)

Il file della zona verrà salvato come /var/cache/bind/db.example.com sul server DNS slave.

Se utilizzate il firewall semplice (UFW) , aprire la porta 53 e UDP TCP:

Terminale
  1. sudo ufw allow 53/tcp
  2. sudo ufw allow 53/udp

Se utilizzate direttamente il firewall iptables, esegui il seguente comando:

Terminale
  1. sudo iptables -A INPUT -p tcp –dport 53 -j ACCEPT
  2. sudo iptables -A INPUT -p udp –dprot 53 -j ACCEPT

Ulteriori informazioni sul trasferimento di zona

Il server DNS slave contatterà nuovamente il master quando viene raggiunto il tempo di aggiornamento nel record SOA e se il numero seriale sul maserver-dns-autorevole-bind9ster è maggiore di quello sullo slave, verrà avviato un trasferimento di zona. Esistono due tipi di trasferimenti di zona:

  • Trasferimento zona completa (AXFR): viene trasferita la copia completa del file di zona.
  • Trasferimento di zona incrementale (IXFR): vengono trasferiti solo i record DNS modificati.

Entrambi i tipi di trasferimento di zona utilizzano la porta TCP 53. Per impostazione predefinita, BIND sul server DNS slave richiederà un trasferimento di zona incrementale e BIND sul server DNS master consentirà il trasferimento di zona incrementale solo quando la zona è dinamica.

L’intervallo di trasferimento di zona è un fattore importante della velocità di propagazione delle modifiche ai record DNS. Invece di attendere che il server DNS slave stabilisca un contatto, quando ci sono modifiche il master BIND avvisa lo slave. Ciò può ridurre considerevolmente il tempo di propagazione delle modifiche di zona a Internet.

Zona inversa

Una zona inversa contiene record PTR che associano un indirizzo IP a un nome DNS. È la controparte del record DNS A. Il record PTR è spesso necessario affinché i server di posta passino i filtri antispam. Questo record non appartiene a un dominio. Devi creare un record PTR nel pannello di controllo del tuo provider di hosting o chiedere al tuo ISP, quindi non tratterò della creazione di zone inverse in BIND.
Cambia record NS e crea record colla

Visitare il sito Web del tuo dominio per modificare il record NS, quindi Internet saprebbe che ora stai utilizzando il tuo server DNS. Normalmente si utilizzano nomi host nel record NS come ns1.example.com e ns2.example.com:

Terminale
  1. name server 1: ns1.example.com
  2. name server 2: ns2.example.com

Se hai un nome di dominio example.com e usi un sottodominio per i server DNS autorevoli ( ns1.example.com e ns2.example.com ), devi anche creare un record di colla nel tuo registrar di domini, così Internet può conoscere l’indirizzo IP del tuo server DNS. Il record di colla è un record A per ns1.example.com e ns2.example.com:

Terminale
  1. ns1.example.com IP-address-of-master-server
  2. ns2.example.com IP-address-of-slave-server

Le informazioni di cui sopra verranno inviate a un operatore del registro che esegue i server DNS TLD tramite il protocollo EPP (Extensible Provisioning Protocol), in modo che i server DNS TLD conoscano il nome e gli indirizzi IP dei server DNS autorevoli per il tuo nome di dominio.

Dopo che il record di colla e il record NS sono stati propagati su Internet, i server DNS risponderanno alle richieste DNS per il tuo nome di dominio. È possibile controllare il registro delle query con:

Terminale
  • sudo journalctl -eu bind9

Cose da sapere

Il termine master DNS server implica solo che questo server memorizza la copia principale del file di zona. Non ha priorità più alta quando si tratta di risoluzione DNS.
Aggiornare sempre il numero di serie SOA quando si apportano modifiche a un file di zona.

Di seguito alcuni esempi su server-dns-autorevole-bind9

Firma TSIG

Lo scopo di questa firma è autenticare le transazioni con BIND. Pertanto, il server DHCP non può aggiornare il dominio example.com se perde questa chiave. Copia e incolla una chiave esistente:

Terminale

# cd /etc/bind/
# cat rndc.key
key “rndc-key” {
algorithm hmac-md5;
secret “QJc08cnP1xkoF4a/eSZZbw==”;
};

# cp rndc.key ns-example-com_rndc-key

Possiamo generare una nuova chiave con le seguenti opzioni:

  • algoritmo HMAC-MD5: identifica 157 (richiesto per una firma TSIG e solo algoritmo supportato da BIND)
  • lunghezza di 512 ottetti (multiplo di 64 con una lunghezza massima di 512 per l’algoritmo sopra)
  • nome: ns-example-com_rndc-key

dnssec-keygen -a HMAC-MD5 -b 512 -n USER ns-example-com_rndc-key
Kns-example-com_rndc-key.+157+53334

L’impronta è associata alla chiave è 53334. Otteniamo due file, uno con una chiave d’ estensione e l’altro con un’ estensione privata. Questo sostituisce la chiave nel file ns-example-com_rndc-key con quella in uno di questi due file.

# cat Kns-example-com_rndc-key.+157+53334.private
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: LZ5m+L/HAmtc9rs9OU2RGstsg+Ud0TMXOT+C4rK7+YNUo3vNxKx/197o2Z80t6gA34AEaAf3F+hEodV4K+SWvA==
Bits: AAA=

# cat ns-example-com_rndc-key
key “ns-example-com_rndc-key” {
algorithm hmac-md5;
secret “LZ5m+L/HAmtc9rs9OU2RGstsg+Ud0TMXOT+C4rK7+YNUo3vNxKx/197o2Z80t6gA34AEaAf3F+hEodV4K+SWvA==”;
};

Per motivi di sicurezza il file ns-example-com_rndc-key non deve leggibile dal mondo intero. Questo dovrebbe essere inserito nella configurazione di bind perché la stessa configurazione di bind è leggibile da tutti. Inoltre, sarebbe meglio eliminare la chiave e i file privati ​​generati in precedenza.

File /etc/bind/named.conf

Questo file è il file di configurazione principale per il file DNS.

// Managing acls
acl internals { 127.0.0.0/8; 192.168.0.0/24; };

// Load options
include “/etc/bind/named.conf.options”;

// TSIG key used for the dynamic update
include “/etc/bind/ns-example-com_rndc-key”;

// Configure the communication channel for Administrative BIND9 with rndc
// By default, they key is in the rndc.key file and is used by rndc and bind9
// on the localhost
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; };
};

// prime the server with knowledge of the root servers
zone “.” {
type hint;
file “/etc/bind/db.root”;
};

include “/etc/bind/named.conf.default-zones”;
include “/etc/bind/named.conf.local”;

Nota: con Debian Jessie la ‘zona “.” La parte {…} è all’interno del file “named.conf.default-zone”. Non è necessario aggiungerlo nel file “named.conf”.

File /etc/bind/named.conf.default-zones

Nota: a partire da Debian 7 “Wheezy” bind9 viene fornito con un file contenente le zone di inoltro, inversione e trasmissione predefinite.

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone “localhost” {
type master;
file “/etc/bind/db.local”;
};
zone “127.in-addr.arpa” {
type master;
file “/etc/bind/db.127”;
};
zone “0.in-addr.arpa” {
type master;
file “/etc/bind/db.0”;
};
zone “255.in-addr.arpa” {
type master;
file “/etc/bind/db.255”;
};

File /etc/bind/named.conf.options

Questo file contiene tutte le opzioni di configurazione per il server DNS

options {
directory “/var/cache/bind”;

// Exchange port between DNS servers
query-source address * port *;

// Transmit requests to 192.168.1.1 if
// this server doesn’t know how to resolve them
forward only;
forwarders { 192.168.1.1; };

auth-nxdomain no; # conform to RFC1035

// From 9.9.5 ARM, disables interfaces scanning to prevent unwanted stop listening
interface-interval 0;
// Listen on local interfaces only(IPV4)
listen-on-v6 { none; };
listen-on { 127.0.0.1; 192.168.0.1; };

// Do not transfer the zone information to the secondary DNS
allow-transfer { none; };

// Accept requests for internal network only
allow-query { internals; };

// Allow recursive queries to the local hosts
allow-recursion { internals; };

// Do not make public version of BIND
version none;
};

La porta associata all’opzione query-source non deve in ogni caso essere congelata perché mette a rischio le transazioni DNS nel caso di un resolver.

M. Rash ha scritto un articolo interessante su questo e su come forzare la porta di origine in modo casuale tramite iptables: Attenuazione degli attacchi di avvelenamento della cache DNS con iptables

Per ridurre il timeout di ritardo per le connessioni UDP e quindi evidenziare la randomizzazione, che per impostazione predefinita è di 30 tupla, è sufficiente aggiornare il parametro

net.netfilter.nf_conntrack_udp_timeout

Terminale
  • sysctl -w net.netfilter.nf_conntrack_udp_timeout=10

per ottenere un timeout di 10 secondi.

File /etc/bind/named.conf.local

Questo file contiene la configurazione del server DNS locale ed è qui che dichiari le zone associate ai domini di questo server.

// Manage the file logs
include “/etc/bind/named.conf.log”;

// Domain Management example.com
// ——————————
// – The server is defined as the master on the domain.
// – There are no forwarders for this domain.
// – Entries in the domain can be added dynamically
// with the key ns-example-com_rndc-key
zone “example.com” {
type master;
file “/var/lib/bind/db.example.com”;
//forwarders {};
// If we do not comment the ”forwarders” “empty” clients of the local subnet in my case don’t have access to the upstream DNS ?
//allow-update { key ns-example-com_rndc-key; };
allow-update { key rndc-key; };
//confusion between the file name to import (ns-example-com_rndc-key) and the key label (rndc-key) ?
};
zone “0.168.192.in-addr.arpa” {
type master;
file “/var/lib/bind/db.example.com.inv”;
//see comment below (zone “example.com”)
//forwarders {};
//allow-update { key ns-example-com_rndc-key; };
allow-update { key rndc-key; };
};

// Consider adding the 1918 zones here, if they are not used in your
// organization
include “/etc/bind/zones.rfc1918”;

NOTA: se si crea un nome di dominio locale non FQDN e lo si chiama .local, si scontrerà con altri pacchetti (quali?). Modifica /etc/nsswitch.conf e sposta dns subito dopo che i file sulla linea host fanno funzionare i domini .local.

File /etc/bind/named.conf.log

Con Debian Jessie, devi creare questo file in /etc/bind

logging {
channel update_debug {
file “/var/log/update_debug.log” versions 3 size 100k;
severity debug;
print-severity yes;
print-time yes;
};
channel security_info {
file “/var/log/security_info.log” versions 1 size 100k;
severity info;
print-severity yes;
print-time yes;
};
channel bind_log {
file “/var/log/bind.log” versions 3 size 1m;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};

category default { bind_log; };
category lame-servers { null; };
category update { update_debug; };
category update-security { update_debug; };
category security { security_info; };
};

Qui definiamo diversi metodi di registro per le diverse categorie. La prima categoria è, poiché il suo nome indica la categoria predefinita che viene solitamente assegnata a syslog. Tutte le categorie non menzionate sono simili alla categoria predefinita. Per un elenco delle diverse categorie, consultare il manuale di riferimento dell’amministratore bind9. http://www.bind9.net/manual/bind/9.3.2/Bv9ARM In termini di server blade, ignora tutti i registri associati. Potrebbe essere necessario creare /var/log nel chroot in un secondo momento.

Resource Records (RR)

Il DNS è composto da diverse registrazioni, record RR o risorse, che definiscono le varie informazioni sul dominio. Il primo è dedicato alla risoluzione dei nomi, nel nostro caso è il file db.example.com. Il secondo verrà utilizzato per la risoluzione inversa del nome, è il file db.example.com.inv.

File in var/cache/bind/

RR per nome reso (file db.example.com)

$TTL 3600
@ IN SOA sid.example.com. root.example.com. (
2007010401 ; Serial
3600 ; Refresh [1h] 600 ; Retry [10m] 86400 ; Expire [1d] 600 ) ; Negative Cache TTL [1h] ;
@ IN NS sid.example.com.
@ IN MX 10 sid.example.com.

sid IN A 192.168.0.1
etch IN A 192.168.0.2

pop IN CNAME sid
www IN CNAME sid
mail IN CNAME sid

RR per la risoluzione inversa del nome (file db.example.com.inv)

@ IN SOA sid.example.com. root.example.com. (
2007010401 ; Serial
3600 ; Refresh [1h] 600 ; Retry [10m] 86400 ; Expire [1d] 600 ) ; Negative Cache TTL [1h] ;
@ IN NS sid.example.com.

1 IN PTR sid.example.com.
2 IN PTR etch.example.com.

Alcune spiegazioni:

$ TTL: per impostazione predefinita (Time To Live) esprime la durata (in secondi) della validità, delle informazioni contenute nei RR. Una volta scaduto questo tempo, dobbiamo ricontrollare i dati. Tipi:

SOA: mostra la romanizzazione

per definire informazioni sull’area. In questo caso, il nome del server DNS primario “sid.example.com”. e l’indirizzo e-mail del contatto tecnico (root.example.com .; la @ è sostituita da un punto). È composto da diversi campi:

  1. Seriale: è l’intero 32 bit non firmato. Questo è il numero seriale da incrementare ad ogni cambio di file. Consente al server secondario di ricaricare le informazioni in loro possesso. Lo scopo generale è quello di formattarlo in questo modo AAAAMMGG, sia per il primo emendamento 01/04/2007 -> 2007040101, per il secondo 2007040102.
  2. Aggiorna: definisce il periodo di aggiornamento dei dati.
  3. Riprova: se si verifica un errore durante l’ultimo aggiornamento, verrà ripetuto alla fine del tempo Riprova.
  4. Scadenza”: il server è considerato non disponibile dopo la scadenza del tempo.
  5. Negative cache TTL’: imposta la durata di una risposta NXDOMAIN da parte nostra.

“NS: informazioni per conto dei nameserver per il dominio.

‘X.: informazioni sul server di posta. Molti possono essere definiti. Pertanto, possiamo dare loro una priorità, assegnando un numero. Più basso è il numero, maggiore è la priorità.

‘A: associa un nome host a un indirizzo IPv4 (32 bit)

‘AAAA: associa un nome host a un indirizzo IPv6 (128 bit)

“CNAME: identifica il nome canonico di un alias (un nome che punta a un altro nome)

‘PTR: questa è semplicemente la risoluzione inversa (l’opposto del tipo A).

Le classi dell’associazione determinano la classe Internet. Sono disponibili altre classi (CH e HS). Per ulteriori informazioni, consultare RFC 1035

File /etc/resolv.conf

Terminale
  • search example.com

Più complicato di così!

Bind Chroot

Come impostazione predefinita il demone denominato viene avviato utilizzando l’utente di bind.

Questa opzione si trova nel file di configurazione del servizio bind /etc/default/bind9 (NOTA: questo non è valido per jessie che ha usato systemd):

OPTIONS = “- u bind”

Lo script bind start /etc/init.d/bind9 legge questo file di configurazione all’avvio del servizio.

È sconsigliato avviare Bind come utente, avvialo sempre come amministratore per eseguire il demone in un ambiente chroot dobbiamo anche specificare la directory chroot. Questo viene fatto usando la stessa variabile OPTIONS in /etc/default/bind9.

Per iniziare, inizia arrestando il servizio di bind:

Terminale
  • /etc/init.d/bind9 stop

Quindi modifica /etc/default/bind9 (non per jessie):

Terminale
  • OPZIONI = “- u bind -t / var / bind9 / chroot”

Per Jessie, crea il file /etc/systemd/system/bind9.service con le opzioni “-t / var / bind9 / chroot“:

[Unit] Description=BIND Domain Name Server
Documentation=man:named(8)
After=network.target

[Service] ExecStart=/usr/sbin/named -f -u bind -t /var/bind9/chroot
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop

[Install] WantedBy=multi-user.target

Per Jessie, dopo aver creato il file di unità sopra, aggiorna il link simbolico al file di unity con:

Terminale
  • systemctl reenable bind9

Ora crea la struttura della directory chroot:

Terminale
  • mkdir -p /var/bind9/chroot/{etc,dev,var/cache/bind,var/run/named}

Creare i file speciali del dispositivo richiesti e impostare le autorizzazioni corrette:

Terminale
  • mknod /var/bind9/chroot/dev/null c 1 3
  • mknod /var/bind9/chroot/dev/random c 1 8
  • mknod /var/bind9/chroot/dev/urandom c 1 9
  • chmod 660 /var/bind9/chroot/dev/{null,random,urandom}

Sposta la directory di configurazione corrente nella nuova directory chroot:

Terminale
  • mv /etc/bind /var/bind9/chroot/etc

Ora crea un link simbolico in / etc per la compatibilità:

Terminale
  • ln -s /var/bind9/chroot/etc/bind /etc/bind
[/su_box

Se desiderate utilizzare il fuso orario locale nella chroot (ad esempio per syslog):

Terminale
  • cp /etc/localtime /var/bind9/chroot/etc/

Cambia la proprietà dei file che hai appena spostato e il resto della struttura della directory chroot appena creata:

Terminale
  • chown bind:bind /var/bind9/chroot/etc/bind/rndc.key
  • chmod 775 /var/bind9/chroot/var/{cache/bind,run/named}
  • chgrp bind /var/bind9/chroot/var/{cache/bind,run/named}

Modifica la variabile PIDFILE in /etc/init.d/bind9 nel percorso corretto:

PIDFILE=/var/bind9/chroot/var/run/named/named.pid

Infine dì a rsyslog di ascoltare i log di bind nella posizione corretta:

echo “\$AddUnixListenSocket /var/bind9/chroot/dev/log” > /etc/rsyslog.d/bind-chroot.conf

Riavvia rsyslog e avvia bind:

Terminale
  • /etc/init.d/rsyslog restart; /etc/init.d/bind9 start

Gestione client

Come ho detto all'inizio, l'assegnazione degli indirizzi IP sulla LAN viene eseguita dal server DHCP. Pertanto, per impostare il nostro server DNS su client diversi, dobbiamo aggiungere il file di configurazione DHCP alle seguenti due righe:

opzione nome-dominio “esempio.com”

opzione domain-name-server sid.example.com

Deve essere aggiunto al file (credo) le aree per le quali DHCP dovrebbe eseguire automaticamente gli aggiornamenti.

Sintassi (tutto dopo “=>” sono i miei commenti):

zone [name.of.the.zone.] {

primario 127.0.0.1; => il server DNS primario si trova sullo stesso computer del DHCP

chiave rndc-key; => è necessario fornire la chiave di sicurezza (tramite un’inclusione ) all’inizio del file di configurazione del server DHCP,

questa deve essere la stessa chiave che protegge il consentire-aggiornamento per la zona in named.conf.local di Bind9.

}

Esempi di [name.of.the.zone.] (Con il "." Alla fine):

-esempio.com.: per la zona diretta di questo articolo,

-0.168.192.in-addr.arpa.: per la zona inversa di questo articolo.

Per ulteriori informazioni sull'implementazione dell'aggiornamento dinamico dei record DNS tramite DHCP è disponibile qui http://www.dthconnex.com/dhcp_server.html

Strumenti di test per server-dns-autorevole-bind9

Dig Command: questo può cercare direttamente il server DNS di tua scelta e ottenere molte informazioni oltre alla risoluzione dei nomi e alla risoluzione del contrasto.

$ dig nomade-frjo.stones.lan
; <<>> DiG 9.4.2 <<>> nomade-frjo.stones.lan
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15760
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;nomade-frjo.stones.lan. IN A

;; ANSWER SECTION:
nomade-frjo.stones.lan. 900 IN A 192.168.0.242

;; AUTHORITY SECTION:
stones.lan. 604800 IN NS emerald.stones.lan.
stones.lan. 604800 IN NS diamond.stones.lan.

;; ADDITIONAL SECTION:
diamond.stones.lan. 604800 IN A 192.168.0.1
emerald.stones.lan. 604800 IN A 192.168.0.2

;; Query time: 20 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Mar 28 20:53:09 2008
;; MSG SIZE rcvd: 131

$ dig -x 192.168.0.242
; <<>> DiG 9.4.2 <<>> -x 192.168.0.242
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37702
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;242.0.168.192.in-addr.arpa. IN PTR

;; ANSWER SECTION:
242.0.168.192.in-addr.arpa. 900 IN PTR nomade-frjo.stones.lan.

;; AUTHORITY SECTION:
0.168.192.in-addr.arpa. 604800 IN NS diamond.stones.lan.
0.168.192.in-addr.arpa. 604800 IN NS emerald.stones.lan.

;; ADDITIONAL SECTION:
diamond.stones.lan. 604800 IN A 192.168.0.1
emerald.stones.lan. 604800 IN A 192.168.0.2

;; Query time: 19 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Mar 28 20:53:31 2008
;; MSG SIZE rcvd: 155

nslookup : un po 'lento ma comunque utile:

$ nslookup etch
Server: 192.168.0.1
Address: 192.168.0.1#53
Name: etch.example.com
Address: 192.168.0.2

$ nslookup 192.168.0.2
Server: 192.168.0.1
Address: 192.168.0.1#53
2.0.168.192.in-addr.arpa name = etch.example.com.

named-checkconf : verifica la sintassi dei file di configurazione per Bind9:

# named-checkconf -z
zone localhost/IN: loaded serial 1
zone 127.in-addr.arpa/IN: loaded serial 1
zone 0.in-addr.arpa/IN: loaded serial 1
zone 255.in-addr.arpa/IN: loaded serial 1
zone estar.lan/IN: loaded serial 20080315
zone 0.168.192.in-addr.arpa/IN: loaded serial 20080315
zone 10.in-addr.arpa/IN: loaded serial 1
zone 16.172.in-addr.arpa/IN: loaded serial 1
zone 17.172.in-addr.arpa/IN: loaded serial 1
zone 18.172.in-addr.arpa/IN: loaded serial 1
zone 19.172.in-addr.arpa/IN: loaded serial 1
zone 20.172.in-addr.arpa/IN: loaded serial 1
zone 21.172.in-addr.arpa/IN: loaded serial 1
zone 22.172.in-addr.arpa/IN: loaded serial 1
zone 23.172.in-addr.arpa/IN: loaded serial 1
zone 24.172.in-addr.arpa/IN: loaded serial 1
zone 25.172.in-addr.arpa/IN: loaded serial 1
zone 26.172.in-addr.arpa/IN: loaded serial 1
zone 27.172.in-addr.arpa/IN: loaded serial 1
zone 28.172.in-addr.arpa/IN: loaded serial 1
zone 29.172.in-addr.arpa/IN: loaded serial 1
zone 30.172.in-addr.arpa/IN: loaded serial 1
zone 31.172.in-addr.arpa/IN: loaded serial 1
zone 168.192.in-addr.arpa/IN: loaded serial 1

named-checkzone : verifica la validità dei file di zona prima di ripristinare la configurazione:

named-checkzone example.com /var/lib/bind/db.example.com
zone example.com/IN: loaded serial 20080315
OK

named-checkzone 0.168.192.in-addr.arpa /var/lib/bind/db.example.com.inv
zone 0.168.192.in-addr.arpa/IN: loaded serial 20080315
O

Grazie! per l’utilizzo della Guida di Linuxiano.

Trovi questo tutorial utile? Condividi con i tuoi amici per tenerlo in vita.
Sii il primo a commentare, apprezzo i tuoi suggerimenti. Per ulteriori domande potete commentare qui sotto.