Newsgroup: it.comp.os.linux.sys
Titolo: Domanda - DNS primario e secondario

Onestamente non so perchè non m'ero mai posto il problema, forse
perchè in tutti i posti in cui ho lavorato finora i DNS primari per i
sistemi di produzione erano sempre ridondanti dietro a qualche tipo di
load balancer. Comunque...
Abbiamo DNS primario e secondario sotto Windows (non li gestisco io),
non-ridondanti. Stamattina, per un errore, un collega che stava
lavorando nell'hosting centre ha fisicamente staccato la spina al
primario. Tutti i server Linux, tranne due macchine RHEL3, hanno
continuato a funzionare diventando però patologicamente lenti. Da
indagini e test successivi abbiamo trovato che ogni richiesta di
risoluzione andava al DNS primario, il client aspettava il timeout, e
poi faceva la stessa richiesta al secondario, che rispondeva
immediatamente. Ovviamente una serie di operazioni sono diventate
lentissime. Per qualche ragione, le due macchine RHEL3 hanno
continuato a funzionare come se nulla fosse.
Qualcuno, per caso, sa come influenzare il comportamento del resolver
su una macchina Linux? In altre parole, c'è modo di istruire il
resolver perchè in caso di timeout sul primario non riprovi ogni
singola risoluzione ma passi al secondario per un certo tempo? Ho
controllati i file "ovvi" sulle due macchine RHEL3, ma nsswitch.conf,
host.conf e resolv.conf non sembrano diversi da quelli sulle altre
macchine (un mix di CENTOS4, CENTOS5 e Fedora Core 4)
La cosa che mi rode veramente è che tutte le macchine Windows, invece,
sono passate in maniera trasparente a risolvere col secondario e non
hanno perso un colpo, con grande gongolamento del mio collega MCSE.
Eugenio

 di DNS 'locale' (cache?)
Posso dire con certezza che nscd non girava su nessuna delle macchine,
né c'erano caching dns locali.
Mi sembra strano che una differenza nelle librerie porti a cambiamenti
così macroscopici senza che nessuno se ne accorga - soprattutto, mi
pare strano che una macchina Linux diventi inservibile quando salta il
DNS primario e non ci si possa far nulla... però non riesco a trovare
nulla in proposito.

 hanno perso un colpo, con grande gongolamento del mio collega MCSE.
Sei proprio certo che risolvessero con il secondario? Magari hanno il DC 
(se c'è) come DNS primario. O magari hanno quell'inutile e merdosissimo 
servizio di cache client attivo...

 servizio di cache client attivo...
no e no, questa è la cosa strana. A meno che ad un certo punto non
abbiano cambiato il default timeout in <resolver.h>, ma anche così
risolvono molto più velocemente delle macchine settate con timeout:1

 singola risoluzione ma passi al secondario per un certo tempo?
Puoi provare con resolvconf; altrimenti come già detto un caching dns
locale, come 
p.es
. pdnsd
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 hanno perso un colpo, con grande gongolamento del mio collega MCSE.
Probabilmente avevano il servizio "client dns" attivo, che 1) fornisce
il caching locale e 2) attiva il fallback sul secondario, per un certo 
periodo di tempo, dopo che le query su primario falliscono.
Fabio

 hanno perso un colpo, con grande gongolamento del mio collega MCSE.
Se non ricordo male se sono previsti due o più server vengono 
interrogati nell'ordine in cui sono elencati nel file /etc/resolv.conf
$ man 5 resolver
Verifiche se nelle macchine in cui non c'era rallentamento sono nello 
stesso ordine in cui sono elencati negli altri.
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   Registered Linux user #337974  < 
http://giovanni.homelinux.net/
 >

 mentre il _secondario_ ca$$o funziona sempre come una scheggia???
E' la legge di murphy.
Le cose si guastano in proporzione diretta alla loro utilita'.
Come mio corollario, aggiungo:
Se hai due o piu' strumenti che forniscono lo stesso servizio,
si rompe sempre quello piu' comodo, o piu' veloce, o ...
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 mentre il _secondario_ ca$$o funziona sempre come una scheggia???
Se tu in resolv.conf metti per primo il secondario, vedrai che il primario
funzionerà sempre perfettamente e sarà il secondario ad aver problemi.
Se invece, stupidamente, ti saltasse in mente di mettere su metà dei client
il primario al primo posto e sull'altra metà al primo posto il secondario,
otterrai che entrambi i DNS avranno problemi di funzionamento con la stessa
frequenza dei casi precedenti, duplicando ai fini pratici il disservizio ed
il lavoro.


 hanno perso un colpo, con grande gongolamento del mio collega MCSE.
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/96406.mspx?mfr=true
ciao

 
credo che l'unica cosa sia un accricco di script che cambi l'ordine dei 
resolver in resolv.conf. diciamo un qualcosa che faccia:
chiedo a dns1 l'indirizzo di una voce dns che non cambia
	se risponde NOERROR
		bene
	se no
		stessa richiesta a dns2
			se risponde NOERROR
				cambio l'ordine in resolv.conf
			se no
				è colpa dell'host
sintassi a parte seconso me è l'unica soluzione

 mentre il _secondario_ ca$$o funziona sempre come una scheggia???
per lo stesso motivo per cui se ci sono due code parallele (tipo in
autostrada) la coda in cui tu NON sei e' la piu' veloce.
Va da se' che se cambi fila, quella in cui eri diventa automaticamente
la piu' veloce.
Ciao Jack

 [...]
Senza ricorrere a uno script, forse la cosa che ci si avvicina di più
è un resolv.conf come questo:
nameserver 208.67.222.222
nameserver 208.67.220.220
nameserver 213.205.36.70
options rotate timeout:1
Naturalmente qui la rotazione round robin c'è sempre, quindi può
anche capitare di spostarsi da un DNS che funziona a uno che non
funziona (il che sarebbe escluso dal tuo script).
Però mi viene in mente che, con tre DNS, se uno non funziona (evento
comunque raro) la penalizzazione media è di 1/3 di secondo a
richiesta. Se ci potessero essere più di tre DNS, magari cinque o
sei, la si potrebbe ridurre ancora (il che la renderebbe più che
accettabile in molte situazioni).
BTW: perché questa limitazione a tre DNS?
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
__________________________________
Combatti l'AIDS col tuo computer: 
http://fightaidsathome.scripps.edu/

 allora sulla macchina locale?
Un attimo, che devo imparare!
dnsmasq può andare, o mi consigli qualcosa di meglio?


 Dnsmasq va' benissimo, raramente ti serve tutto Bind...
Per quanto, prima di sposare una soluzione, mi assicurerei dell'aderenza 
alle RFC della stessa: poco importante se si usano queste funzionalità 
lato client, potenzialmente vitale se vi si appoggiano servizi ad alto 
flusso e progettati per una scalabilità fortemente orizzontale.
Molte soluzioni tendono a sgarrare in svariati aspetti, da questo punto 
di vista, quindi assicurati che la soluzione che adotti non abbia 
limitazioni che ti possano causare problemi poi.
(esempio tipico è la gestione della randomizzazione in caso di reply con 
più di 1 RR)

 dnsmasq può andare, o mi consigli qualcosa di meglio?
Dopo aver provato dnsmasq e pdnsd ho valutato che quest'ultimo è decisamente
più versatile sui server.
dnsmasq rappresenta invece un buon compromesso sui piccoli gateway perché
integra la parte dhcp, ma è meno flessibile di pdnsd


 alle RFC della stessa:
Ringrazio entrambi.
Mentre stavo già decidendo per dnsmasq, ho notato che installare e
configurare banalmente bind9 come caching DNS server è sulla mia
distribuzione cosa di quindici secondi netti, e ho optato per questa
soluzione.
Metto qui il link alle istruzioni di base, casomai dovessero
interessare a qualche lurker:
http://www.zaphu.com/2007/09/10/ubuntu-dns-server-guide-bind-caching-name-server-setup/
Qui, invece, le istruzioni per dnsmasq:
http://ubuntu.wordpress.com/2006/08/02/local-dns-cache-for-faster-browsing/
Ora passo a leggermi qualcosa qui:
http://www.nacs.uci.edu/dcslib/bind/bind-9.2.1/Bv9ARM.html


 soluzione.
Su suggerimento non mio, perchè non l'ho ancora mai usato seriamente, 
aggiungo che powerdns (che dovresti avere a sua volta a disposizione 
nella distro, credo) ha, a differenza di bind, una componente resolver 
per i fatti suoi che è buona (in termini di aderenza alle RFC) quanto 
bind stesso e più leggera.
Valuta tu.

 si rompe sempre quello piu' comodo, o piu' veloce, o ...
Non sara' perche' tutte le richieste vanno sempre prima al primo e cosi' il 
secondo e` per cosi' dire "disoccupato" ???? :-)
-- 
Faciait li signeur!
Roy Batty
http://www.biolabnet.it/