Newsgroup: it.comp.os.linux.sys
Titolo: Configurazione di named - connessione Albacom.

Ciao a tutti.
Da un po' di tempo ho configurato il mio DNS e mi sembra che funzioni
abbastanza bene.
Ci sono alcuni siti che non riesco a raggiungere. Non so se dipende dal mio
DNS o da quello del provider, o da altri motivi.
La risoluzione degli indirizzi per la mia LAN č corretta e funziona bene.
Secondo voi č corretto quanto ho scritto in named.conf?
options {
        directory "/var/named";
        allow-transfer {
            127.0.0.1;
 
192.168.1.0/24
;
        };
        allow-query {
            127.0.0.1;
 
192.168.1.0/24
;
        };
        forwarders {
#           212.41.208.6;       # Server di Galactica
#           212.41.208.7;       # Server di Galactica
#           195.110.128.1;      # Server di Mc-Link
            212.17.192.56;      # Server di Albacom
            212.17.192.216;
        };
};
Grazie per le vostre risposte.
Giulio

 };
Ma hai fatto un bel "dig >/var/named/root.hints" per creare la tabella dei
DNS di root invece di usare quelli di altri provider italiani ? :P
Oz
-- 
------
O-Zone ! (C) 2004
http://myphotos.zerozone.it
 << MyPHOTOS GPL Photo Blog ! Join now !

 Oz
Io ho un named.hints anche più pienotto di quello che ottengo con dig...
Quindi i forwarders li posso levare? Scusa la mia ignoranza ma ho fatto come
sta scritto nel DNS-Howto... probabilmente interpretando male...
Grazie
Giulio

 sta scritto nel DNS-Howto... probabilmente interpretando male...
Basta quello che ti ritorna "dig". E togli i forwarders che fanno solo
perdere tempo...


 perdere tempo...
beh...
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
An NT server can be run by an idiot, and usually is.

 beh...
Ciao
potresti essere meno "sintetico"... Ogni info aggiuntiva mi sarebbe utile.
Grazie.
Giulio

 perdere tempo...
Non direi, a meno che non facciano schifo i dns del provider...
bye G.L.
-- 
- Renaissance, aka Gian Luca Sole -
Cit. « E' assolutamente evidente che l'arte del cinema
  si ispira alla vita, mentre la vita si ispira alla TV »
                                         (Woody Allen)

 utile.  Grazie.
Presumo fosse una considerazione su "i forwarders non servono".  Detta
cosi`, senza sapere nemmeno che tipo di abbonamento hai e l'efficienza
dei dns del tuo provider, pare una stronzata :-)
-- 
Vuoi fare colpo su di lei con me?
Fai colpo su di lei con me! Fai colpo su di lei con me!
[Dr. Gonzo : Paura e delirio a Las Vegas]

 beh...
A parte il discorso delle prestazioni sul quale non so pronunciarmi, vorrei
aggiungere al discorso una mia esperienza.
Ho configurato alcuni DNS senza mai usare forwarders e non ho mai avuto
problemi fino a quando, pochi giorni fa, sono capitato da un cliente che ha
fastweb (adsl con ip statico).
Ebbene sono stato costretto a impostare come forwarder di fastweb altrimenti
il mio DNS risolveva soltanto parzialmente.
Ad esempio risolveva correttamente .com ma non risolveva  .it
Al momento ho potuto fare soltanto una breve indagine e ho constatato, per
esempio che
# ping 
e.root-servers.net
PING 
e.root-servers.net
 (192.203.230.10): 56 data bytes
--- 
e.root-servers.net
 ping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss
mentre invece
# ping 
a.root-servers.net
PING 
a.root-servers.net
 (198.41.0.4): 56 data bytes
64 bytes from 
198.41.0.4
: icmp_seq=0 ttl=238 time=120.4 ms
64 bytes from 
198.41.0.4
: icmp_seq=1 ttl=238 time=119.4 ms
64 bytes from 
198.41.0.4
: icmp_seq=2 ttl=238 time=119.1 ms
So che fastweb fa cose strane con la sua rete per cui non ho dato per
scontata una mia cappellata e per il momento ho lasciato le cose come
stanno.
Che ne pensate, errore mio o paciughi fastweb ?
-- 
Stefano L.

L'utilizzo di forwarders e' necessario (a mio modesto avviso) solo in 
casi molto particolari.
Ad esempio un dns aziendale che utilizzi delle zone interne a uso 
privato e che debba necessariamente risolvere anche nomi di dominio 
pubblici, non avendo la possibilita' di accedere direttamente in internet.
Tipicamente server con ip privato che non partecipano ad un Nat su ip 
pubblico.
In tal caso per poter risolvere i nomi privati + pubblici si configurano 
i forwarders sul dns privato in modo da delegare la risoluzione di nomi 
di dominio pubblici a dns che possano svolgere tale compito.
L'utilizzo di forwarders su dns che accedano direttamente o 
indirettamente (tramite nat) a Internet provoca problemi solo in un caso.
Cioe' quello in cui il provider restituisca risoluzioni referral e non 
autoritative: questo avviene se cerchiamo di utilizzare il dns del 
provider X collegandoci al provider Y .
E comunque dipende da X.
Esempio di risoluzione referral:
  $ dig 
www.bluray.it
 @
195.130.224.18
; <<>> DiG 9.2.0 <<>> 
www.bluray.it
 @
195.130.224.18
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19170
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 10
;; QUESTION SECTION:
;
www.bluray.it
. 
		IN	A
;; AUTHORITY SECTION:
it. 
		170207	IN	NS	
SERVER2.INFN.it
.
it. 
		170207	IN	NS	
NAMESERVER.CNR.it
.
it. 
		170207	IN	NS	
NS.RIPE.NET
.
it. 
		170207	IN	NS	
DNS.NIC.it
.
it. 
		170207	IN	NS	
IT2.MIX-IT.NET
.
it. 
		170207	IN	NS	
DNS2.IT.NET
.
it. 
		170207	IN	NS	
DNS2.IUNET.it
.
it. 
		170207	IN	NS	
AUTH2.DNS.COGENTCO.COM
.
;; ADDITIONAL SECTION:
NS.RIPE.NET
. 
	20944	IN	A	193.0.0.193
NS.RIPE.NET
. 
	21649	IN	AAAA	2001:610:240:0:53::193
DNS.NIC.it
. 
	21092	IN	A	193.205.245.5
DNS.NIC.it
. 
	45265	IN	AAAA	2001:760:600:1::5
IT2.MIX-IT.NET
. 
	84923	IN	A	217.29.76.4
DNS2.IT.NET
. 
	79873	IN	A	151.1.2.1
DNS2.IUNET.it
. 
	22260	IN	A	192.106.1.31
AUTH2.DNS.COGENTCO.COM
. 
29547 
IN 
A 
66.28.0.30
SERVER2.INFN.it
. 
367878 
IN 
A 
131.154.1.3
NAMESERVER.CNR.it
. 
22386 
IN 
A 
194.119.192.34
;; Query time: 174 msec
;; SERVER: 195.130.224.18#53(195.130.224.18)
;; WHEN: Thu Mar  4 09:51:15 2004
;; MSG SIZE  rcvd: 426
Cioe' anziche' restiuire direttamente l'indirizzo IP restituiscono i 
riferimenti ai dns del quel dominio.
Se invece il risultato e' :
$ dig 
www.bluray.it
 @
212.17.192.56
; <<>> DiG 9.2.0 <<>> 
www.bluray.it
 @
212.17.192.56
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31574
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;
www.bluray.it
. 
		IN	A
;; ANSWER SECTION:
www.bluray.it
. 
	85774	IN	CNAME	
webtu01.bluray.it
.
webtu01.bluray.it
. 
85774 
IN 
A 
62.101.65.179
;; AUTHORITY SECTION:
bluray.it
. 
	85774	IN	NS	
polifemo-ichi.bluray.it
.
bluray.it
. 
	85774	IN	NS	
ulisse-ichi.bluray.it
.
;; ADDITIONAL SECTION:
polifemo-ichi.bluray.it
. 85774	IN	A	62.101.65.177
ulisse-ichi.bluray.it
. 
85774 
IN 
A 
62.101.65.178
;; Query time: 33 msec
;; SERVER: 212.17.192.56#53(212.17.192.56)
;; WHEN: Thu Mar  4 10:00:10 2004
;; MSG SIZE  rcvd: 155
Abbiamo tre cose :
1) una risoluzione autoritativa : nome di dominio -> IP
2) il dns del provider funziona perfettamente
3) fare ping non serve ad una mazza ( i provider utilizzano dei firewall 
che solitamente non fanno passare nenche l'aria, eccetto i protocolli 
strettamente utili alla erogazione del servizio). Sarebbe piu' utile un 
traceroute almeno per stabilire se il pacchetto non vada a quel paese...
Ciao e spero di aver chiarito alcuni dubbi.

 molto particolari.
Sul necessario possiamo anche essere d'accordo, sulla prestazione è altro
discorso...
Se il forwarder è prestante e pesantemente utilizzato, trovi una grossa
cache che ti risolve in una query quello che altrimanti richiedeva una
escalation di 3/4 senza...
per cui, appunto, dipende dal forwarder...
-- 
wash the blood from your hands
bury your secrets in the sand
and forget

 dei dns del tuo provider, pare una stronzata :-)
Ok
Abbonamento Albacom Alb@speed con CDN 64k e Ip statico pubblico (32).
il risultato di alcuni traceroute lo inserisco, anche per far notare che
Tiscali nonostante il traceroute non buono sul web lo vedo, McLink pure...
albacom.it
 no!
root@server2:~# traceroute 
www.albacom.it
traceroute to 
www.albacom.it
 (212.17.194.147), 30 hops max, 38 byte packets
 1  
h213-213-77-97.albacom.net
 (213.213.77.97)  3.687 ms  1.672 ms  1.520 ms
 2  213.255.62.85 (213.255.62.85)  44.132 ms  54.566 ms  195.811 ms
 3  
ac1-G1-0.RM2.albacom.net
 (213.255.9.69)  94.224 ms  41.937 ms  42.632 ms
 4  * * *
 5  * * *
 6  * * *
 7  * * *
..........
30  * * *
root@server2:~# traceroute 
www.mclink.it
traceroute to 
www.mclink.it
 (195.110.128.8), 30 hops max, 38 byte packets
 1  
h213-213-77-97.albacom.net
 (213.213.77.97)  3.670 ms  1.614 ms  1.531 ms
 2  213.255.62.85 (213.255.62.85)  38.410 ms  45.350 ms  42.599 ms
 3  
tr1-G7-0.RM2.albacom.net
 (213.255.9.65)  41.978 ms  41.958 ms  42.545 ms
 4  
prs-b1-pos5-1.telia.net
 (213.248.70.241)  68.404 ms  67.699 ms  67.950
ms
 5  
prs-bb1-pos0-3-0.telia.net
 (213.248.70.1)  67.845 ms  94.952 ms  129.257
ms
 6  
mno-b1-pos0-2.telia.net
 (213.248.65.166)  94.641 ms  84.856 ms  85.128
ms
 7  
wind-01672-mno-vcn-i1.c.telia.net
 (213.248.103.38)  100.133 ms  100.193
ms  100.929 ms
 8  
rmas-t01-rmid-i01-po01.wind.it
 (212.245.229.6)  84.914 ms  83.970 ms
87.890 ms
 9  
mica-t01-rmas-to1-po01.wind.it
 (151.6.3.2)  110.134 ms  111.150 ms
116.128 ms
10  151.6.2.58 (151.6.2.58)  89.856 ms  84.616 ms  84.735 ms
11  151.6.33.252 (151.6.33.252)  85.449 ms  86.055 ms  84.981 ms
12  
s5-0-1.fineco-gw1.iunet.it
 (151.5.129.6)  94.709 ms  96.007 ms
151.5.129.18 (151.5.129.18)  95.712 ms
13  
net128-076.mclink.it
 (195.110.128.76)  95.813 ms  94.918 ms  93.642 ms
root@server2:~# traceroute 
www.tiscali.it
traceroute to 
www.tiscali.it
 (195.130.227.63), 30 hops max, 38 byte packets
 1  
h213-213-77-97.albacom.net
 (213.213.77.97)  3.652 ms  1.635 ms  1.567 ms
 2  213.255.62.85 (213.255.62.85)  44.711 ms  42.979 ms  42.166 ms
 3  
tr1-G7-0.RM2.albacom.net
 (213.255.9.65)  42.378 ms  42.587 ms  41.970 ms
 4  
prs-b1-pos5-1.telia.net
 (213.248.70.241)  68.301 ms  68.081 ms  67.882
ms
 5  
prs-bb1-pos0-3-0.telia.net
 (213.248.70.1)  68.472 ms  68.436 ms  67.957
ms
 6  
prs-b3-pos5-0.telia.net
 (213.248.65.62)  68.928 ms  68.576 ms  69.299 ms
 7  
Tiscali-3257.tlh.giga.parix.net
 (198.32.247.78)  69.016 ms  69.243 ms
69.017 ms
 8  
pos-2-0.cag21.ip.tiscali.net
 (213.200.82.42)  93.137 ms  93.746 ms
93.819 ms
 9  213.205.6.6 (213.205.6.6)  93.617 ms  93.537 ms  93.551 ms
10  * * *
..........................
30  * * *
Si puň stabilire piů o meno dove sia il problema? Da me o da loro?
Grazie
Giulio

 per cui, appunto, dipende dal forwarder...
Infatti.


 pubblico.
E vabbe', allora...        :-)
Non e' opportuno che ti lanci cosi'... mica e' questo il caso del nostro 
amico e albacom.   ;-)
[SNIP]


 # ping 
a.root-servers.net
Non far constatazioni  in base agli effetti di  un ping.  Una macchina
puo` rispondere come non rispondere all' icmp echo request.  Anzi, per
quanto riguarda i DNS, nella  mia piccola esperienza ti posso dire che
capita piu` spesso che non rispondano.


 
albacom.it
 no!
Non  puoi  concludere molto  con  un  traceroute.   Non significa  che
``vedi'' mclink e non ``vedi'' albacom.  Semplicemente o da un gateway
in poi  non vengono  piu` routati i  tuoi pacchettini udp  oppure quei
gateway che vedi come * non  mandano gli icmp type 11.  Non vedo quale
sia il tuo problema.


 capita piu` spesso che non rispondano.
Per amore di brevita' mi sono spiegato male.
L'esempio del ping seriva solo per illustrare il fatto che il server
_da quella_ adsl fastweb il server 
e.root-servers.net
 (192.203.230.10)
sembra completamente irraggiungibile.
Infatti da altre linee non fastweb il server risconde allegramente
al ping.
Ma non e' tutto, _da quella_ linea fastweb il server in oggetto non risponde
nemmeno al dig
# dig @
192.203.230.10
 
e.root-servers.net
; <<>> DiG 9.2.1 <<>> @
192.203.230.10
 
e.root-servers.net
;; global options:  printcmd
;; connection timed out; no servers could be reached
Infine un traceroute al'indirizzo risponde soltanto con una lunga,
malinconica serie di asterischi.
Appena adesso ho provato tutti i DNS della lista
F.ROOT-SERVERS.NET
.     3600000 IN      A       192.5.5.241
B.ROOT-SERVERS.NET
.     3600000 IN      A       192.228.79.201
J.ROOT-SERVERS.NET
.     3600000 IN      A       192.58.128.30
K.ROOT-SERVERS.NET
.     3600000 IN      A       193.0.14.129
L.ROOT-SERVERS.NET
.     3600000 IN      A       198.32.64.12
M.ROOT-SERVERS.NET
.     3600000 IN      A       202.12.27.33
I.ROOT-SERVERS.NET
.     3600000 IN      A       192.36.148.17
E.ROOT-SERVERS.NET
.     3600000 IN      A       192.203.230.10
D.ROOT-SERVERS.NET
.     3600000 IN      A       128.8.10.90
A.ROOT-SERVERS.NET
.     3600000 IN      A       198.41.0.4
H.ROOT-SERVERS.NET
.     3600000 IN      A       128.63.2.53
C.ROOT-SERVERS.NET
.     3600000 IN      A       192.33.4.12
G.ROOT-SERVERS.NET
.     3600000 IN      A       192.112.36.4
Guarda caso tutti quelli il cui indirizzo inizia per 192 non rispondono
al dig.
Mi viene il dubbio che fastweb consideri privata tutta la 192.x.y.z
-- 
Stefano L.

 Mi viene il dubbio che fastweb consideri privata tutta la 192.x.y.z
A quanto mi dicono, hanno uno strano concetto delle classi private...    ;-)


 sia il tuo problema.
Il problema è semplice: Non vedo quei siti.
In particolare non vedo 
www.albacom.it
 (io ho abbonamento albacom e su quel
sito ci sono ovviamente i servizi assistenza ed altro), il sito della TNT
Traco, per curiosità ho trovato che non vedo neanche
www.punto-informatico.it
Tutto qui. E chissà quanti altri siti non vedo.
Ciao
Giulio

 Tutto qui. E chissà quanti altri siti non vedo.
Premetto che non ho seguito il 3ad e non so se sia gia' stato discusso o
meno, ma sei sicuro che sia un problema di dns e non sia la solita cosa
dell'ecn??? prova a dare un occhio a 
www.volareweb.org
 e dimmi se lo
vedi o meno.
Spero di non aver detto panzane, dato che non ho proprio seguito il
tread.
ciao
Banana

 o meno.
mi aggrego sull'ipotesi ecn.. la lista di siti affetti corrisponde alla
casistica...


 dell'ecn??? prova a dare un occhio a 
www.volareweb.org
 e dimmi se lo
seeeehhh...  .org, volevo dire 
www.volareweb.com
, non org.
ahh il venerdi' mattina....
ciauz!
Banana

 Mi viene il dubbio che fastweb consideri privata tutta la 192.x.y.z
Non ci posso credere, questa pare _veramente_ grossa.  


 Banana
Ciao
G

 Banana
Ciao
G

 
mo' prova a fare un
echo 0 > /proc/sys/net/ipv4/tcp_ecn
e riprova..


 e riprova..
Fatto.
Non è cambiato nulla.
Giulio

 e riprova..
Dunque... mi era venuto un dubbio. Ho trovato cosa è l'ECN.
Ho trovato che va abilitato/disabilitato nel kernel.
Io ce l'ho abilitato. Ho provato a fare echo 0>/proc..../tcp_ecn ma non
cambia niente, vale sempre 1.
E non riesco a navigare su quei siti...
Nel kernel deve essere abilitato o disabilitato?
Ciao
Giulio

 Giulio
hmmm... 'spe...
vediamo di spiegare, sennň si ingenera la confusione :-)
ecn č una feature del tcp -recente-.
Alcuni firewall/router cannano e droppano i pacchetti tcp che lo usano.
Esempio naturale se il client che ha il browser tenta di raggiungere
direttamente un server che ha davanti un coso cosě, la connessione non si
stabilisce..
Oppure se i client non lo hanno ma si appoggiano a un proxy che lo ha.
Poesse?!?


 disabilitato? Ciao
se vuoi raggiungere quei siti, devi disabilitarlo.
se è compilato nel kernel, di default è abilitato.
ergo, o ricompili un kernel senza, oppure lo disabiliti durante lo
startup...


 E poi rimane li appeso... :-(((
scommetto che ultimamente ti sei compilato un kernel....
sysctl -w net.ipv4.tcp_ecn=0
----------------------------------------------------------------------------
------
Ebbene il mio problema è opposto, cioè tcp_ecn=1
ma il risultato è lo stesso...
Giulio
P.S.
Sto commettendo qualche errore concettuale?

 startup...
Sto provando a ricompilare il kernel, perché se anche faccio
echo 0>/proc/sys/net/ipv4/tcp_ecn
il suo valore mi viene sempre visualizzato come 1.
G

 Sto commettendo qualche errore concettuale?
di per sè non mi pare, ma il valore di ecn *deve* cambiare, altrimenti
canni qualcosa...
da root:
zaza:~# cat /proc/sys/net/ipv4/tcp_ecn
1
zaza:~# echo 0 > /proc/sys/net/ipv4/tcp_ecn
zaza:~# cat /proc/sys/net/ipv4/tcp_ecn
0
se fai questo e il risultato è diverso, allora passiamo al woodoo...


 il suo valore mi viene sempre visualizzato come 1.
AFAIK _deve_ permetterti di modificare il suo valore.
giusto per fare un po' di chiarezza:
L'ecn e' una funzione nuova, che fa incazzare alcuni routers che, non
conoscendola, scartano il pacchetto per una serie di motivi.
Il tuo linux imposta l'ecn ad ogni pacchetto che passa per le sue
grinfie, tu devi dirgli di non farlo.
per fare questo devi impostare a zero l'ecn, cosi:
echo 0 > /proc/sys/net/ipv4/tcp_ecn
ovviamente da root, altrimenti riceverai un bel 
bash: /proc/sys/net/ipv4/tcp_ecn: Permission denied
Ovviamente se fai un reboot torna di nuovo ad 1.
Ergo devi piazzare echo 0 > /proc/... ecc in uno script che viene
eseguito all'avvio. A te la scelta di quale script  in funzione della
distribuzione e delle tue preferenze.
ciao
Banana

 se fai questo e il risultato è diverso, allora passiamo al woodoo...
 'spe che lo rimando, che mi dimentico che pan fa 'sti giochi idioti...
zaza:~# cat /proc/sys/net/ipv4/tcp_ecn
1
echo 0 > /proc/sys/net/ipv4/tcp_ecn
zaza:~# cat /proc/sys/net/ipv4/tcp_ecn
0
-- 


 E nella mia poca esperienza, e' quasi sempre conveniente.
potrei essere d'accordo con te sul fatto della convenienza legata alla 
cache.
Pero' preferisco utilizzare server in configurazione "da manuale".
A casa ad esempio ho impostato il mio dns senza forwarders e funziona 
alla grande.
Del resto il traffico dns e' irrisorio.
Ciao

 0
Se lo faccio a mano non funziona.
l'ho messo in rc.firewall ed ha funzionato.
Ora vedo il sito.
Grande! (sei tu!)
Grazieeeee!
Giulio

 echo 0 > /proc/sys/net/ipv4/tcp_ecn


 per cui, appunto, dipende dal forwarder...
</paste>


</paste>
Piccola aggiunta: e dai client della tua rete.
10 != 100 != 300 (mantenendo la stessa banda).
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
No space left in message for a signature.

 Non ci posso credere, questa pare _veramente_ grossa.
E in effetti sarebbe stata troppo grossa, la questione era piu' semplice.
Oggi sono andato sul posto e' ho indagato.
Ho attaccato un portatile direttamente al router e il problema rimaneva,
allora ho chiamato l'assistenza Fastweb e spiegato la questione, mi hanno
detto gli pareva strano, comunque controllavano subito..................si
in effetti collegandosi al router notavano anche loro il problema.
Allora gli ho chiesto se per caso avevano configurato la netmask lato LAN
come 255.0.0.0 e la risposta e' stata *si* ..............
No comment !
-- 
Stefano L.

 come 255.0.0.0 e la risposta e' stata *si* ..............
Non preoccuparti: l'ultima volta che ci ho guardato, fastweb utilizzava
come indirizzi di rete privata, alcune classi che IANA non ha assegnato
(ma che assegnera` prima o poi). Suppongo perche` subnettare fosse
troppo difficile.
Vedrai come si divertono tutti quando vengono assegnate tali classi.
(questo succede facilmente quando il grosso degli investimenti va in
commerciali, anziche` in tecnici).
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Lusers: can't live with them, don't get paid without them.