Per favore leggete questa sezione prima di scrivermi in email.
State leggendo l'HOWTO sbagliato. Leggete per favore la vecchia versione di questo HOWTO, che tratta bind 5, presso http://www.math.uio.no/~janl/DNS/
Un indizio: forward only; probabilmemte avrete bisogno anche
della riga
query-source port 53;
all'interno della parte ``options'' del file named.conf come
suggerito nella sezione-esempio
Un name server caching only.
www.sito.occupato per ottenere un
effetto di bilanciamento, o simile??
Create numerosi record A per www.sito.occupato e usate bind
4.9.3 o successivo. Poi sarà bind a far ruotare le risposte. Non
funziona con le precedenti versioni di bind.
Cancellerete il file root.hints e farete solo i file di zona.
Questo significa anche che non dovrete aggiornare i file di hint tutte
le volte.
Se il server primario/master ha indirizzo 127.0.0.1 mettete una linea come questa nel file named.conf del vostro secondario:
zone "linux.bogus" {
type slave;
file "sz/linux.bogus";
masters { 127.0.0.1; };
};
Potrete elencare numerosi master server alternativi, la zona può
essere copiata da dentro la lista masters, separata da ';'.
Ci sono quattro articoli che riguardano questo:
Ho scoperto che con le ultime versioni di BIND questo [<em/mischiare i
file, -ed/] non è più necessario. C'è una direttiva "forward" oltre a
quella "forwarders" che controlla come queste vengono
usate. L'impostazione di default è "forward first", la quale prima
chiede a ognuno dei forwarder, e poi se il tentativo fallisce, prova
da sola a fare il lavoro seguendo un normale approccio. Questo
implica un normale comportamento di gethostbyname() e impiega una
quantità spropositata di tempo quando il link non è attivo. Ma se
"forward only" è l'impostazione scelta, allora BIND si blocca quando
non riesce a ottenere una risposta dai forwarders, e gethostbyname()
si ferma immediatamente. Quindi in questo caso non c'è bisogno di
smanettare con i file di /etc e di far ripartire il server.
Per quanto mi riguarda, ho solo aggiunto le linee
forward only;
forwarders { 193.133.58.5; };
nella sezione opzioni { } del mio file named.conf. Tutto ciò funziona
veramente bene. L'unico svantaggio è che questo riduce un software
incredibilmente complicato per il DNS allo stato di una stupida cache.
In un certo senso, io vorrei solo far fuzionare una stupida cache al
posto del DNS, ma ciò non sembra essere altro che un pezzo di software
disponibile per Linux.
Faccio partire named sulla mia macchina che fa servizio di 'Masquerading'
(mascheramento). Ho due file root.hints, uno chiamato root.hints.real che
contiene i veri nomi dei root server e l'altro chiamato root.hints.fake
che contiene...
----
; root.hints.fake
; this file contains no information
----
Quando vado off line copio il file root.hints.fake su root.hints e
faccio ripartire named.
Quando vado on line copio root.hints.real su root.hints e faccio
ripartire named.
Tutto ciò viene eseguito da ip-down e ip-up rispettivamente.
La prima volta che faccio una richiesta (query) off line, named non
avendo dettagli su di essa lascia una riga simile a questo messaggio...
Jan 28 20:10:11 hazchem named[10147]: No root nameserver for class IN
con la quale posso convivere.
Questo per me funziona certamente. Posso usare il nameserver per le
macchina locali quando sono fuori dalla rete senza il ritardo del
timeout per i nomi di dominio esterni e mentre sono collegato alla rete
le richieste (query) per i domini esterni funzionano normalmente.
Sono abituato a eseguire il mio named su tutte le mie macchine che
solo occasionalmente sono connesse a Internet via modem. Solo il
nameserver fa da cache, esso non ha un'area di autorità e chiede
qualunque cosa ai nameserver del file root.cache. Come è prassi comune
con Slackware, viene fatto partire prima di nfsd e mountd.
Con una delle mie macchine (un notebook Libretto 30), avevo il problema
che qualche volta avrei voluto fare il mount di essa da un altro sistema
connesso alla mia rete locale, ma la maggior parte delle volte non
funzionava. Avevo lo stesso effetto usando indistintamente PLIP, una
scheda ethernet PCMCIA o il PPP su una interfaccia seriale.
Dopo qualche supposizione e esperimento scoprii che apparentemente
named incasinava il processo di registrazione con portmapper che nfsd
e mountd devono fare all'avvio (faccio partire questi demoni all'avvio
come al solito). Eseguire named dopo nfsd e mountd elimina completamente
questo problema.
Anche se non ci sono svantaggi da attendersi da una sequenza di boot così
modificata, vorrei consigliare a tutti di farla in questo modo per prevenire
potenziali problemi.
La cache è completamente immagazzinata in memoria, non verrà mai scritta sul disco in nessuna occasione. Ogni volta che si blocca named (con il comando 'kill') la cache è persa. La cache non è controllabile in alcun modo. Named la gestisce in accordo a qualche semplice regola e basta. Non potete controllare la cache o la sua dimensione in nessun modo per nessuna ragione. Se questo non vi andasse bene potrete sempre cercare di modificare named andando ad agire sul codice sorgente di esso. Non è comunque un'operazione raccomandabile.
No, named non salva la cache quando si ferma. Questo significa che la cache deve essere ricostituita ogni volta che fermate e fate ripartire named. Non c'è modo di salvare la cache in un file. Se questo non vi andasse bene potrete sempre cercare di modificare named andando ad agire sul codice sorgente di esso. Non è comunque un'operazione raccomandabile.
linux-rules.net. Come posso avere il dominio
che vorrei mi fosse assegnato?
Contattate per favore il vostro provider di servizi di rete. Loro sapranno aiutarvi in questo. Sappiate che in molte parti del mondo ci sarà bisogno di pagare per avere un dominio.