Newsgroup: it.comp.os.linux.sys
Titolo: log di named

named[3127]: client 127.0.0.1#59166: no more recursive clients: quota
reached
ho numerosi messaggi del genere nei log , che significano? che named limita
il numero degli accessi al server?
come posso modificare? per aumentare la quota se è così?
grazie

EMC wrote:

ok ho trovato dovrebbe essere questo 
options {
        ...       
        recursive-clients       10000;
};
recursive-clients
    The maximum number of simultaneous recursive lookups the server will
perform on behalf of
    clients. The default is 1000. Because each recursing client uses a fair
bit of memory, on the order of
    20 kilobytes, the value of the recursive-clients option may have to be
decreased on hosts with
    limited memory.
domanda ho un server con 1gb di memoria e dove do hosting a diversi domini ,
non metto il numero perchè tendenzialmente in aumento , 
problemi di banda non dovrebbero esserci visto che non raggiungo
assolutamente i limiti impostati, che impostazione dovrei metterci?
se ho capito bene in named.conf
adesso non c'è niente
dei limiti impostati erano solo su apache ma credo che non c'entri nulla

 adesso non c'č niente
come sarebbe a dire che "non c'č niente"; diavolo, per lo
meno quelle quattro direttive di base e due ACL le avrai
pure messe, spero !
al minimo (configurando ovviamente la ACL) ...
acl "ourclients" {
 
10.0.0.0/8
;
 
169.254.0.0/16
;
 
192.168.0.0/16
;
 
172.16.0.0/20
;
 
127.0.0.0/8
;
                 };
options {
  directory "...quella che contiene i files di config...";
  version "-";
  hostname none;
  server-id none;
  dialup no;
  interface-interval 0;
  recursion yes;
  allow-query { any; };
  allow-recursion { "ourclients"; };
  auth-nxdomain no;
  minimal-responses no;
  transfer-format many-answers;
  edns-udp-size 512;
  max-transfer-time-in 60;
  request-ixfr yes;
  provide-ixfr yes;
  recursive-clients 2000;
  tcp-clients 1000;
  max-cache-size 8m;
  max-ncache-ttl 30;
  lame-ttl 100;
  cleaning-interval 240;
};

 come sarebbe a dire che "non c'è niente"; diavolo, per lo


         };
...figuriamoci questa...
;-)

 EMC wrote:


         };
Questa invece re-interroga sempre se stessa.  Ma che ti serve usare 
forwarders?
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   Registered Linux user #337974  < 
http://giovanni.homelinux.net/
 >

 dove c'è il db di altri server, giusto?
...no....
La lista di forwarders indica a bind che quello che non sa già (leggasi: 
non ne è il master *e* non ha già in cache) lo deve andare a domandare a 
quei tipi lì. Prima al primo, poi al secondo, ecc. Se nessuno di quelli 
fornisce risposta, parte per andare a cercarsela da solo scalando la 
gerarchia dai root-server (a meno che non gli specifichi anche "forward 
only;" tra le direttive, il default è questo).
Già l'errore dovrebbe esser lampante: come fai a domandare qualcosa che 
non sai a te stesso? A meno di personalità multiple, è difficile che tu 
ottenga una risposta diversa da "'zzo vuoi?!?"...

 non ne è il master *e* non ha già in cache
               ^^^^^^
Refuso: volevo dire non ne è *autoritativo*...

 Giovanni
dunque se nel forward levo il localhost cerca sempre il file interno?
il terrore è che dall'interno non risolva e quindi con anche un forward in
ogni caso dovrebbe riuscire a lavorare 
o sbaglio?
interroga se stessa perchè nelle zone è previsto un file dove ci sono i db 
ho sbaglio?
non so ripeto ho trovato così, poi hanno provato a metterci mano quelli
della farm, ma devo dire che senza l'aiuto di te e di skull il server non
sarebbe andato 
quindi mi fido che faccio
tolgo tutto?
utilizzando solo il file del db?

Skull wrote:

:)

Skull wrote:

concludendo se riscrivo il named.conf così?
options {
        directory "/var/named/chroot/var/named";
 
        auth-nxdomain no;
 
     recursive-clients       10000; << CHE VALORE METTERESTI? >>
};


 
Se vuoi essere autoritativo per una certa zona devi usare i file, ma 
l'esempio che viene in genere riportato per un servizio 'caching only' è:
named.conf
//----------------------
options {
         directory "/var/named";
         /*
          * If there is a firewall between you and nameservers you want
          * to talk to, you might need to uncomment the query-source
          * directive below.  Previous versions of BIND always asked
          * questions using port 53, but BIND 8.1 uses an unprivileged
          * port by default.
          */
         // query-source address * port 53;
};
//
// a caching only nameserver config
//
zone "." IN {
         type hint;
         file "
named.ca
";
};
zone "localhost" IN {
         type master;
         file "localhost.zone";
         allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
         type master;
         file "named.local";
         allow-update { none; };
};
// end named.conf
file "localhost.zone"
//-----------------
$TTL    86400
$ORIGIN localhost.
@              1D IN SOA       @ root
                          42     ; serial (d. adams)
                          3H     ; refresh
                          15M    ; retry
                          1W     ; expiry
                          1D )   ; minimum
                    IN NS        @
                    IN A         127.0.0.1
// end localhost.zone
file "named.local"
//-----------------
$TTL    86400
@       IN      SOA     localhost. root.localhost.  (
                       1997022700 ; Serial
                       4h      ; Refresh
                       15m     ; Retry
                       1w      ; Expire
                       1d )    ; Minimum
         IN      NS      localhost.
1       IN      PTR     localhost.
// end named.local
Il file 
named.ca
 è il classico degli hints dove vengono forniti gli IP 
dei server di più alto livello.
In questo modo il servizio fornito è di essere solo un tramite verso 
il mondo esterno e di mantenere in memoria per qualche tempo i 
nomi/indirizzi risolti per accelerare le riposte.  Non viene usato 
alcun forwarder perché analizza il nome da risolvere ed interroga 
direttamente il server più appropriato, partendo da quelli di livello 
più alto.  Se necessario puoi aggiungere i forwarders nelle opzioni 
per interrogare quelli (in genere i dns del provider, che però non 
funzionano troppo bene.
Se devi gestire anche una zona in modo autoritativo puoi aggiungere la 
direttiva della zona e relativi file (forward e reverse)


 ...figuriamoci questa...
tra l'altro se i root-hints sono a posto i forwarders non
servono ad una beata

> concludendo se riscrivo il named.conf così?
concludendo, visto e considerato che quel server
a quanto hai scritto tiene in piedi un tot di zone, non
credi sarebbe il caso di farsi aiutare da qualcuno
che sappia come configurare ammodino il tutto invece
di pastrocchiare con la config creando una mostruosità
come quella che proponi ?

ObiWan wrote:

si certo , e ho già ringraziato skull e giovanni, perchè chi doveva darmi
una mano per la manutenzione si è dissolto, altri tecnici non sono riusciti
a cavarci le gambe ; adesso il server va, è acceso da più di un anno e se
non era per quel upgrade del caiser non c'erano problemi.
solo arrivando l'email che suggeriva upgrade io ho agito con yum upgrade e è
andato in cacc....
ringrazio te e tutti quanti hanno sempre con pazienza risposto alle mie
domande da ignorante. 
adesso ho da risolvere due problemi 
capire se cosi va bene e che valore dare 
options {
        directory "/var/named/chroot/var/named";
 
        auth-nxdomain no;
     
     recursive-clients       10000; << CHE VALORE METTERESTI? >>
};
zone "." {
        type hint;
        file "named.root";
        #type master;
        #file "default";
};
e capire perchè dopo l'upgrade 
se scrivo
 echo "test" |mail root 
 echo "test" |mail 
ro...@bitit.it
la posta non arriva
devo mettere echo "test" |mail root@localhost 
la posta arriva a 
ro...@localhost.bitit.it
poi ci sono problemi relativi anche all'interfaccia del pannello, ma quelli
dopo e penso comunque di avere una strada per risolverli
Ancora grazie

ok grazie, poichè nella macchina hanno messo le mani delle persone che
dovevano risolvere ma non lo hanno fatto, credo che sia stato fatto un bel
po di casino, solo grazie a voi sono riuscito a farla ripartire alla meno
peggio. 
adesso le zone localhost e 0.0.127.in-addr.arpa non le ho nel named.conf e
la zona "." punta a named.root che contiene i gli appropriati server e
funziona.
adesso ho da risolvere due problemi 
capire se cosi va bene e che valore dare 
options {
        directory "/var/named/chroot/var/named";
 
        auth-nxdomain no;
     
     recursive-clients       10000; << CHE VALORE METTERESTI? >>
};
zone "." {
        type hint;
        file "named.root";
        #type master;
        #file "default";
};
poi se ho capito bene credo sia opportuno aggiungere anche :
zone "localhost" IN {
         type master;
         file "localhost.zone";
         allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
         type master;
         file "named.local";
         allow-update { none; };
};
per ultimo devo capire perchè dopo l'upgrade 
se scrivo
 echo "test" |mail root 
 echo "test" |mail 
ro...@bitit.it
la posta non arriva
devo mettere echo "test" |mail root@localhost 
la posta arriva a 
ro...@localhost.bitit.it


>      recursive-clients       10000; << CHE VALORE METTERESTI? >>
il problema è un altro; se, come mi sembra di aver capito questo DNS
è un DNS *autoritativo* NON dovresti offrire la ricorsione al mondo
intero
ma esclusivamente ai tuoi indirizzi permettendo però la query per tutte
le zone autoritative a chiunque, a questo punto la config, lasciando il
resto da parte, potrebbe essere qualcosa di questo tipo
acl "private" { 
10.0.0.0/8
; 
169.254.0.0/16
; 
192.168.0.0/16
;
172.16.0.0/20
; 
127.0.0.0/8
; };
options {
  directory "/var/named/chroot/var/named";
  dialup no;
  interface-interval 0;
  allow-query { any; };
  allow-recursion { "private"; };
  auth-nxdomain no;
  minimal-responses no;
  transfer-format many-answers;
  max-transfer-time-in 60;
  request-ixfr yes;
  provide-ixfr yes;
  recursive-clients 1000;
  tcp-clients 500;
  max-cache-size 4m;
  max-ncache-ttl 30;
  lame-ttl 100;
  zone-statistics no;
  cleaning-interval 240;
};
in tal modo (sorvolo sui valori degli altri parametri) il server fornirà
risposte
autoritative per le proprie zone a chiunque (allow-query) ma permetterà
di
effettuare queries ricorsive solo ai clients "locali" (allow-recursion)
questo
oltre ad evitare che il DNS possa essere "abusato" e/o utilizzato per
(es.)
amplification attacks o simili, eviterà anche l'esaurimento dei
recursive
clients ed il problema da te lamentato
detto questo, ti consiglio di dare una scorsa a questo online book
http://www.zytrax.com/books/dns/
non sarà la "cavalletta" di Cricket ma dovrebbe permetterti di capire
per lo meno i fondamentali

 la posta arriva a 
ro...@localhost.bitit.it
Cosa hai in /etc/resolv/conf?
Potrebbe anche essere per come è configurata la mail.


 Giovanni
/etc/resolv.conf
nameserver 127.0.0.1
nameserver 195.225.168.2
ancora grazie
.

 nameserver 195.225.168.2
Senza avere una idea chiara della configurazione non è facile dare 
consigli, ma per fare in modo che i locali programmi usino sempre il 
dns locale la seconda linea la toglierei.  Inoltre per garantire che i 
nomi locali vengano risolti correttamente occorre aggiungere:
domain dominio_locale
oppure
search lista_di_domini
Senza una di queste direttive viene usato il nome del dominio locale 
(che sembra, nel tuo caso, essere 
bitit.it
).
Non ho capito se devi avere un dns autoritativo per 
bitit.it
 o se vuoi 
solo fare in modo che i tuoi programmi interroghino il dns locale.  Le 
due situazioni sono diverse e i file di named sono diversi.  Quello 
che ho suggerito io sono solo per la seconda configurazione.


 Giovanni
ho messo su resolv.conf
nameserver 127.0.0.1
domain 
bitit.it
 
ma niente la posta arriva solo a 
ro...@localhost.bitit.it
 
non a root e neanche a 
ro...@bitit.it
se faccio hostname risponde 
bitit.it
premesso che adesso tranne un paio di cose , il server sembra andare bene, 
è autoritativo, su i dns 
ns.bitit.it
 
ns1.bitit.it
  punta la registrazione di
diversi domini, in oltre nel server c'è l'hosting per gli stessi domini,
con web e posta elettronica. 
comunqe i dns adesso risolvono correttamente sia gli interni che l'esterni 
dig @
bitit.it
 
bitit.net
dig @
bitit.it
 
google.com
questo mi leva i problemi che erano arrivati nell'aggiornamento che era
stato fatto, che mi impediva di spedire correttamente la posta sia
internamente che esternamente. ( ripeto purtroppo mi sono affidato a delle
persone che alla fine non sono state in grado di risolvere un tubo e
sicuramente mi hanno fatto un po di casino ).
nb. dopo gli aggiornamenti fatti sembra aver bisogno di molta meno memoria ,
nonostante gli accessi siano aumentati.

 Questa direttiva non ha molto senso. Trasferisce gli update a se stesso.
Veramente consente gli axfr a sè stesso...

 io vedo quello che c'ha messo il pannello 
Peccato che un nameserver sia un oggetto estremamente critico e delicato
e non un giocattolo.
Consiglierei vivamente, come base minima, la lettura di "DNS & Bind" e
del relativo cookbook della O'Reilly.

whiplash wrote:

Quindi non è da togliere?

 Quindi non Ãš da togliere?
E' inutile, fondamentalmente.
Quel che dovresti controllare sul serio è la recursion, al momento
abilitata per chiunque.

 al momento abilitata per chiunque.
esatto, e come ho già scritto, è QUELLA la causa del
"problema" manifestato, evidentemente qualcuno
(bots ?) sta usando il suo DNS come resolver.. oppure
come reflector per un "amplification attack"

 Questa direttiva non ha molto senso. Trasferisce gli update a se stesso.
Veramente consente gli axfr a sè stesso...
devo solo impedire che dall'esterno vengano fatti attacchi, solo che il
server dall'esterno deve comunque risolvere , se no come si trovano i
servizi web e posta e ftp? (ci sono una 60 di domini sopra)
i log che ci sono adesso :
Jan 18 09:06:06 bitit named[31212]: lame server
resolving '
84.128.234.124.broad.cc.jl.dynamic.163data.com.cn
'
(in '
163data.com.cn
'?): 202.97.7.17#53
Jan 18 09:32:46 bitit named[31212]: lame server
resolving '55.176.201.66.in-addr.arpa' (in '176.201.66.in-addr.arpa'?):
66.119.93.4#53
Jan 18 09:32:46 bitit named[31212]: lame server
resolving '55.176.201.66.in-addr.arpa' (in '176.201.66.in-addr.arpa'?):
66.119.95.4#53
Jan 18 09:32:47 bitit named[31212]: lame server
resolving '55.176.201.66.in-addr.arpa' (in '176.201.66.in-addr.arpa'?):
216.184.96.4#53
Jan 18 09:32:48 bitit named[31212]: lame server
resolving '55.176.201.66.in-addr.arpa' (in '176.201.66.in-addr.arpa'?):
66.119.93.4#53
Jan 18 09:32:48 bitit named[31212]: lame server
resolving '55.176.201.66.in-addr.arpa' (in '176.201.66.in-addr.arpa'?):
66.119.95.4#53
Jan 18 09:32:48 bitit named[31212]: lame server
resolving '55.176.201.66.in-addr.arpa' (in '176.201.66.in-addr.arpa'?):
216.184.96.4#53
Jan 18 09:33:41 bitit named[31212]: lame server
resolving '172.60.20.196.in-addr.arpa' (in '60.20.196.in-addr.arpa'?):
212.122.224.10#53
Jan 18 09:33:41 bitit named[31212]: lame server
resolving '172.60.20.196.in-addr.arpa' (in '60.20.196.in-addr.arpa'?):
212.122.224.11#53
Jan 18 09:33:42 bitit named[31212]: lame server
resolving '172.60.20.196.in-addr.arpa' (in '60.20.196.in-addr.arpa'?):
212.122.224.11#53
Jan 18 09:33:42 bitit named[31212]: lame server
resolving '172.60.20.196.in-addr.arpa' (in '60.20.196.in-addr.arpa'?):
212.122.224.10#53
Jan 18 09:34:47 bitit named[31212]: lame server
resolving '55.176.201.66.in-addr.arpa' (in '176.201.66.in-addr.arpa'?):
66.119.95.4#53
Jan 18 09:34:47 bitit named[31212]: lame server
resolving '55.176.201.66.in-addr.arpa' (in '176.201.66.in-addr.arpa'?):
216.184.96.4#53
Jan 18 09:34:47 bitit named[31212]: lame server
resolving '55.176.201.66.in-addr.arpa' (in '176.201.66.in-addr.arpa'?):
66.119.93.4#53
Jan 18 09:34:49 bitit named[31212]: lame server
resolving '55.176.201.66.in-addr.arpa' (in '176.201.66.in-addr.arpa'?):
216.184.96.4#53
Jan 18 09:34:49 bitit named[31212]: lame server
resolving '55.176.201.66.in-addr.arpa' (in '176.201.66.in-addr.arpa'?):
66.119.95.4#53
Jan 18 09:34:49 bitit named[31212]: lame server
resolving '55.176.201.66.in-addr.arpa' (in '176.201.66.in-addr.arpa'?):
66.119.93.4#53
Jan 18 09:36:22 bitit clamd[9972]: SelfCheck: Database status OK. 
Jan 18 09:54:18 bitit
clamd[9972]: /var/amavis/tmp/amavis-20080118T094004-21109/parts/p004:
Worm.SomeFool.P FOUND 
Jan 18 09:58:34 bitit
clamd[9972]: /var/amavis/tmp/amavis-20080118T094004-21109/parts/p002:
Exploit.HTML.IFrame FOUND 
Jan 18 09:58:34 bitit
clamd[9972]: /var/amavis/tmp/amavis-20080118T094004-21109/parts/p003:
Worm.SomeFool.P FOUND 
Jan 18 09:59:38 bitit named[31212]: invalid command from 127.0.0.1#60753:
bad auth
Jan 18 10:06:35 bitit clamd[9972]: SelfCheck: Database status OK. 
Jan 18 10:20:47 bitit named[31212]: lame server
resolving '148.187.5.74.in-addr.arpa' (in '5.74.in-addr.arpa'?):
138.210.81.3#53
Jan 18 10:20:47 bitit named[31212]: lame server
resolving '148.187.5.74.in-addr.arpa' (in '5.74.in-addr.arpa'?):
205.160.188.2#53
Jan 18 10:20:48 bitit named[31212]: lame server
resolving '148.187.5.74.in-addr.arpa' (in '5.74.in-addr.arpa'?):
205.160.188.2#53
Jan 18 10:20:48 bitit named[31212]: lame server
resolving '148.187.5.74.in-addr.arpa' (in '5.74.in-addr.arpa'?):
138.210.81.3#53
Jan 18 10:28:52 bitit named[31212]: lame server
resolving '
157.189.223.87.dynamic.jazztel.es
'
(in '
87.dynamic.jazztel.es
'?): 62.14.4.66#53
Jan 18 10:28:52 bitit named[31212]: lame server
resolving '
157.189.223.87.dynamic.jazztel.es
'
(in '
87.dynamic.jazztel.es
'?): 62.14.4.67#53
Jan 18 10:28:54 bitit named[31212]: lame server
resolving '
157.189.223.87.dynamic.jazztel.es
'
(in '
87.dynamic.jazztel.es
'?): 62.14.4.66#53
Jan 18 10:28:54 bitit named[31212]: lame server
resolving '
157.189.223.87.dynamic.jazztel.es
'
(in '
87.dynamic.jazztel.es
'?): 62.14.4.67#53
Jan 18 10:36:55 bitit clamd[9972]: SelfCheck: Database status OK. 
Jan 18 10:39:14 bitit named[31212]: lame server
resolving '90.64/26.246.195.81.in-addr.arpa'
(in '64/26.246.195.81.in-addr.arpa'?): 212.188.8.37#53
Jan 18 10:39:14 bitit named[31212]: lame server
resolving '90.64/26.246.195.81.in-addr.arpa'
(in '64/26.246.195.81.in-addr.arpa'?): 222.122.63.8#53
Jan 18 10:39:15 bitit named[31212]: lame server
resolving '90.64/26.246.195.81.in-addr.arpa'
(in '64/26.246.195.81.in-addr.arpa'?): 212.188.8.37#53
Jan 18 10:39:15 bitit named[31212]: lame server
resolving '90.64/26.246.195.81.in-addr.arpa'
(in '64/26.246.195.81.in-addr.arpa'?): 222.122.63.8#53
Jan 18 10:39:20 bitit named[31212]: lame server
resolving '90.64/26.246.195.81.in-addr.arpa'
(in '64/26.246.195.81.in-addr.arpa'?): 212.188.8.37#53
Jan 18 10:39:20 bitit named[31212]: lame server
resolving '90.64/26.246.195.81.in-addr.arpa'
(in '64/26.246.195.81.in-addr.arpa'?): 222.122.63.8#53
Jan 18 10:59:10 bitit named[31212]: lame server
resolving '195.180.176.69.in-addr.arpa' (in '180.176.69.in-addr.arpa'?):
64.114.55.100#53
Jan 18 10:59:10 bitit named[31212]: lame server
resolving '195.180.176.69.in-addr.arpa' (in '180.176.69.in-addr.arpa'?):
209.145.111.62#53
Jan 18 11:06:56 bitit clamd[9972]: SelfCheck: Database status OK. 

 servizi web e posta e ftp? (ci sono una 60 di domini sopra)
esatto, il server deve fornire risposte relative ai domini per i quali è
autoritativo ma NON deve fornire risposte relative ad altri domini,
o meglio, deve fornirle solo agli hosts autorizzati; ripeto, riguardati
la config che avevo postato ed assicurati di configurare in maniera
opportuna il parametro "allow-recursion"

> ACL solo hosts su una LAN potranno utilizzare la ricorsione
Spunti di riflessione sull'uso di ACL in dns ricorsivi :-)
- se invio da un host qualsiasi una query ricorsiva spoofando 
  l'indirizzo sorgente in uno dei range privati abilitati, la
  risposta a chi va? E in genere quant'e' l'ampiezza di banda
  di chi riceve la risposta?
- se dallo stesso host invio una query ricorsiva spoofando l'
  indirizzo sorgente in uno dei range pubblici abilitati, che
  cosa cambia? Qual'e' l'ampiezza di banda di chi, anche 'sta
  volta, riceve la risposta?
- quanti dns e' meglio usare quando devo sia pubblicare delle
  zone, sia consentire query ricorsive a ip abilitati?
- cosa metto tra il dns ricorsivo e i cattivi?
Fabio

> Spunti di riflessione sull'uso di ACL in dns ricorsivi :-)
<snip>
azz c'entra tutto ciň con il thread :) ?

 - cosa metto tra il dns ricorsivo e i cattivi?
Un firewall?
P.S.
wargame?
Io mi sono appena iscritto...:-)

 Un firewall?
naah, il nano armato di ascia !

 - cosa metto tra il dns ricorsivo e i cattivi?
un bel filtro L-7 ... o magari un netasq ?

 Io mi sono appena iscritto...:-)
Ci si "vede" nella ml :-)
Fabio
[1] a rigor di termini, le acl non impediscono di effettuare delle
    query ricorsive ma solo di riceverne i risultati ;-)

 che si vuole dirottare, diventano molto piu' semplici.
si ok... però, considera che già applicare le ACL sarebbe un passo
avanti rispetto all'attuale configurazione usata dall'OP; che poi ci sia
da fare altro ... beh, questo non credo di averlo mai messo in dubbio,
però, visto il "livello" dei posts, meglio fare un passettino alla
volta, no :) ?