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 4, presso http://langfeldt.net/DNS-HOWTO/
Un indizio: forward only;
probabilmente avrete bisogno anche
della riga
query-source port 53;
all'interno della parte "options" del file named.conf
come
suggerito nella sezione-esempio
<@@ref>cachingcaching
www.sito.occupato
per ottenere un
effetto di bilanciamento del carico, 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 creerete solo i file di zona.
Questo significa anche che non dovrete aggiornare i file di hint tutte
le volte.
Se il server primario ha indirizzo 127.0.0.1 mettete una riga 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 server primari alternativi, la zona può
essere copiata dalla lista masters
, separata da ';'.
Ci sono quattro articoli che riguardano la questione:
Ho scoperto che con le ultime versioni di BIND non è più necessario
[<em/incasinare i file, -ed/]. 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 poi, se il tentativo fallisce, prova
da sola a fare il lavoro seguendo un approccio standard. 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 forwarder 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 righe
forward only;
forwarders { 193.133.58.5; };
nella sezione "options" { } del mio file named.conf. Funziona
veramente bene. L'unico svantaggio è che questo riduce un software
incredibilmente complicato ad una stupida cache.
In un certo senso, io vorrei solo far fuzionare una stupida cache al
posto del DNS, ma non sembra esserci un simile software disponibile per
Linux.
Faccio partire named sulla mia macchina che fa servizio di masquerading.
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 mi sconnetto copio il file root.hints.fake su root.hints e
faccio ripartire named.
Quando mi connetto 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 interrogazione da sconnesso, 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 name server per le
macchine locali quando sono sconnesso senza il ritardo del
timeout per i nomi di dominio esterni e mentre sono collegato alla rete
le interrogazioni per domini esterni funzionano normalmente.
Perte Denison pensa che Ian non andrà molto lontanto. Egli scrive:
Quando connesso) fornisce immediatamente tutte le voci presenti in cache e
quelle relative alla rete locale
per le voci non presenti in cache, fa il forward al
name server del mio ISP.
Quando sconnesso risponde alle interrogazioni relative alla rete locale
nega tutte le altre **immediatamente**
La combinazione di cambiare il cache file root e di inoltrare le
richieste non funziona.
Così, ho impostato (dopo un sacco di discussioni al LUG locale) due
named come segue:
named-online: inoltra al name server del mio provider
primario per la zona locale
primario per la zona locale inversa (1.168.192.in-addr.arpa)
primario per 0.0.127.in-addr.arpa
ascolta sulla porta 60053
named-offline: (niente forward)
file cache root "falso"
secondario per 3 zone locali (il primario è 127.0.0.1:60053)
ascolta sulla porta 61053
Combinando tutto questo con il port-forwarding , cioè reindirizzando
la porta 53 sulla 61053 quando sconnesso e sulla 60053 quando connesso.
(Io uso il vecchio pacchetto netfilter con kernel 2.3.18, ma dovrebbe
funzionare anche con il vecchio ipchains).
Notate che questo potrebbe non funzionare al di fuori della mia macchina,
poichè c'è un bug in BIND 8.2, che ho segnalato agli sviluppatori, che
impedisce a un server secondario di avere come primario lo stesso IP (anche
se su porte differenti). C'è una patch provvisoria che dovrebbe funzionare.
<item>Ho ricevuto anche informazioni su come bind interagisce con NFS e
con il portmapper su una macchina che in genere rimane sconnessa da Karl-Max
Wanger:
<tscreen><verb>
Sono abituato a eseguire il mio named su tutte le mie macchine che
solo occasionalmente sono connesse a Internet via modem. Solo il
name server fa da cache, esso non ha un'area di autorità e chiede
qualunque cosa ai name server 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 ed 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 uccide 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 suo codice sorgente. 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. Non è comunque un'operazione raccomandabile.
linux-rules.net
. Come posso avere il dominio
che vorrei mi fosse assegnato?
Contattate per favore il vostro provider. Loro sapranno aiutarvi in questo. Sappiate che in molte parti del mondo ci sarà bisogno di pagare per avere un dominio.