A meno da non acquistare dei costosi libri, la documentazione che spiega chiaramente come far si che il DHCP aggiorni i file di zona del DNS è realmente scarna e criptica.
Vediamo brevemente cosa si deve fare dal lato named per prepararlo a questo tipo di aggiornamenti.
Un server DHCP per comunicare con named e fargli aggiornare i file di zona utilizza il DNS Dynamic Update. Se si vuole approfondire l'argomento la request for comments interessata è la rfc 2136. Questo è disponibile dalla versione 8 del BIND e superiori, in precedenza non si era prevista questa funzione visto che si considerava il DNS un database per dati statici e che subivano pochi cambiamenti tranquillamente gestibili a mano dall'amministratore. Con l'ingrandirsi delle reti e l'ampiamento dell'uso di sistemi per l'assegnazione automatica degli ip si è reso necessario trovare uno strumento in grado di tenere traccia di questi cambiamenti, di inserire nuovi records e di cancellarli.
Qui vedremo quali direttive si rendono necessarie nel named.conf per implementare l'update dinamico di un server DHCP presente sulla stessa macchina.
key DHCP_UPDATER {
algorithm HMAC-MD5;
secret "Yj95beDnn=34fghSN";
};
Nonostante sia possibile con l'istruzione allow-update specificare un lista di indirizzi ip o una acl per controllare gli update dinamici è sconsigliato per ragioni di sicurezza e preferibile utilizzare TSIG per le autenticazioni. Pertanto si crea l'istanza per la chiave che il server DHCP userà per autenticare i suoi update. Nel dhcpd.conf si dovrà creare l'istanza per la chiave corrispondente
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "DHCP_UPDATER"; };
};
Stabilisco il canale di controllo attraverso il quale il mio server DHCP si connetterà per inviare i dati da aggiornare. In questo caso solo localhost ha la possibilità di accedervi.
options {
directory "/var/named";
pid-file "/var/run/named.pid";
};
zone "." in {
type hint;
file "named.root";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.db";
};
zone "0.168.192.in-addr.arpa" IN {
type master;
file "192.168.0.db";
allow-update { key DHCP_UPDATER; };
};
Per singolo file di zona delineo la direttiva che conceda la possibilità di update solo ai possessori della chiave giusta.
zone "esempio.com" IN {
type master;
file "esempio.com.db";
allow-update { key DHCP_UPDATER; };
};
Vediamo ora come named processa le richieste di update. Come immaginabile dovrebbe incrementare il numero di serie ogni volta che viene aggiunto o eliminato un record. Quando una richiesta di update arriva al server quest'ultimo dovrebbe andare ad aggiornare il relativo file di zona. Riscrivere un file di zona ogni volta che un update viene processato in casi in cui ci si trovi in un contesto di rete molto grosso e con molti update come immaginabile diventa un lavoro realmente oneroso per il server con il rischio che non sia possibile riuscire a processarli tutti. Infatti sia BIND 8 che BIND 9 quando ricevono una richiesta di update dinamico salvano questo record su un file di log che serve a tenere traccia dei nuovi record. In questo modo il nameserver ha sempre in memoria un file di zona con tutti i nuovi record ma si appresta a riscrivere i file di zona a intervalli (generalmente un'ora) prestabiliti. BIND 8 in seguito cancella questi file mentre BIND 9 li conserva perchè vengono utilizzati anche per gli incremental zone transfers. In BIND 9 questi file sono salvati con come nome il nome del file di zona e con estensione .jnl
, infatti vengono chiamati journal files. Non c'è da stupirsi infatti se ci si ritrova la directory contenente i file di zona piena di questi jnl files.
Per finire vediamo in breve quello che si dovrebbe aggiungere al dhcpd.conf per il nostro esempio.
Innanzi tutto la direttiva ddns-update-style
va settata utilizzando il metodo "interim". Esiste anche il metodo ad-hoc ma è deprecato e considerato obsoleto. Se si desidera approfondire l'argomento leggere il man per il dhcpd.conf.
Infine vanno date le specifiche per l'uso della chiave per l'autenticazione sicura.
La sintassi è la seguente:
key DHCP_UPDATER {
algorithm HMAC-MD5;
secret "Yj95beDnn=34fghSN";
};
zone esempio.com. {
primary 127.0.0.1;
key DHCP_UPDATER;
};
zone 0.168.192.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
};
In questo caso come si vede con l'istruzione primary definisco dove si trova il nameserver che in questo caso è localhost ma che va modificato se il dhcp e il DNS sono su due host differenti. Notare anche che nella direttiva zone si deve aggiungere il punto finale anche se in caso non presente il dhcp server dovrebbe aggiungerlo da solo.
bug !?
ciao.
con dhcp isc-dhcpd-V3.0.1rc9, non bisogna mettere il ";" alla fine delle parti configurate in dhcpd.conf.
per intenderci:
key DHCP_UPDATER {
algorithm HMAC-MD5;
secret "Yj95beDnn=34fghSN";
}
zone esempio.com. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
zone 0.168.192.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
altimenti da come errore:
Mar 8 19:09:23 fraser dhcpd: /etc/dhcp3/dhcpd.conf line 26: expecting a parameter or declaration
Mar 8 19:09:23 fraser dhcpd: };
Mar 8 19:09:23 fraser dhcpd: ^
Mar 8 19:09:23 fraser dhcpd: Configuration file errors encountered -- exiting
comunque, ottimo howto
DHCP_UPDATER in ch file va impostato in linux
Ciao,
Ho creato tutti gli indirizzi ,ho creato tutti i reverse..ma non funzionano....ho settato i file di reverse con DHCP_UPDATER ma non ho ottenuto nulla...premetto ho linux suse server...
ciao grazie
Fallimento autenticazione
Ho provato a fare com descritto nell'articolo ma nn funziona: continua a fallire l'autenticazione :( Avrà provato risettando tutto almeno 4 volte ma nn va. Questi gli errori
Aug 9 20:10:34 balthasar named[569]: client 192.168.1.1#50851: request has invalid signature: tsig verify failure
Aug 9 20:10:34 balthasar dhcpd: Unable to add forward map from caspar.valhalla.lan to 192.168.1.250: bad DNS key
Aug 9 20:10:34 balthasar dhcpd: DHCPREQUEST for 192.168.1.250 from 00:04:76:60:d8:5f (caspar) via eth0
Aug 9 20:10:34 balthasar dhcpd: DHCPACK on 192.168.1.250 to 00:04:76:60:d8:5f (caspar) via eth0
Sempre indirizzi fissi
ho provato ma nulla da fare, i file jnl non vengono creati.e named mi dice "not a top of zone"...potrebbe essere un indizio?
grazie comunque
Indirizzi fissi
Probabilmente si, dal momento che macchine che hanno il mac preimpostato in dhcpd.conf comunque avranno un loro ip e se il DNS updating è attivo, verrà fatto anche per loro
Rispondiindirizzi fissi
sapete se assegnando ip fissi legati al mac il file dhcpd.leases viene aggiornato e così anche il dns?
grazie
Grazie
Ho letto 10 pagine di documentazione e alla fine ho capito meglio con le 50 righe della vostra pagina.