Newsgroup: it.comp.os.linux.debian
Titolo: dns telecom funzionano solo per alcuni programmi???

Scusate ma questa non mi era mai capitata, quindi chiedo lumi qua.
Ho appena configurato la connessione adsl (telecom) a casa di mia madre, 
con un router d link 2750B.
 
Ecco, se utilizzo il router come nameserver, alcuni programmi risolvono i 
nomi ed altri no
 
 
ne ho provati un po' e...
 
risolvono : chrome, mplayer, ping, pan, dig, nslookup
 
*non* risolvono : iceweasel, icedove, ssh , telnet, apt-get, wget, curl, 
php(file_get_contents), python (urllib), xmms
 
 
 
cosa mi sfugge?
 

 nomi ed altri no
 
e se configuri direttamente i nameserver di telecom dentro
/etc/resolv.conf

 cosa mi sfugge?
 
Che programmi diversi usano metodi diversi per connettersi, alcuni usano
impostazioni diverse, altri passano per un proxy, et cetera.
 
I classici esempi sono dig e nslookup; a volte forniscono risposte diverse
hai notato?
 
 
--- news://
freenews.netfront.net/
 - complaints: 
ne...@netfront.net
 ---

 /etc/resolv.conf
 
Non funziona. Prima perché molte distribuzioni scavalcano questo 
file altre lo ricostruiscono a partire da altri file di configurazione (in
generale non è detto che Debian faccia così). Poi perché, motivo 
più importante, i server DNS di TELECOM sono caccosi quindi il 
problema non si risolve.


 problema non si risolve.
 
 
a me sembra strano una simile degenerazione della struttura
dell'OS.
Una interpretazione alternativa più sensata potrebbe essere
legata al caching del dns che alcuni programmi fanno e mi
sembra che stiano nella lista, caching che serve a velocizzare
la traduzione e che credo possa essere disabilitato.
 
Può esserci anche un malfunzionamento dei server telecom,
in questo caso si possono provare gli affidabili opendns.
     208.67.222.222
     208.67.220.220
La questione dns è particolarmente sensibile alla sicurezza,
meglio evitare roba presa a caso sul web.

 meglio evitare roba presa a caso sul web.
 
Proprio per questo non uso più né OpenDNS né i DNS di Google.
Il discorso è il prezzo che si paga in cambio del servizio. 
Sei disposto a barattare i tuoi dati con una ricerca su internet?


 Sei disposto a barattare i tuoi dati con una ricerca su internet?
 
Tu lo vuoi proprio gratis? Secondo te lo telecom non fa lo stesso
lavoro sui suoi server? Ormai ci dobbiamo rassegnare a questo
andazzo.
 
Il problema più grosso resta comunque le possibilità di phising
totalmente invisibile all'utente che il server dns può rendere
attuabile.
Altro che "raccolta dati a scopo di marketing", questi sono uccelli
per diabetici.

 perché*NON*  fanno caching.
 
Io suppongo non funzionino quelli che fanno caching interno 
all'applicazione. Ice* fanno parte della categoria, gli altri
non so.

 per diabetici.
 
Veramente dal punto di vista della sicurezza Google o OpenDNS non
danno nessun problema; il fatto che mi fa arrabbiare è che se per un 
qualche motivo non riesco a risolvere l'indirizzo si apre una pagina
su un motore di ricerca del cazzo che non c'entra niente, che mi fa 
perdere tempo e da cui è difficile tornare indietro.


 lo fai.
 
AHAHAHAHAH!!!!!!
Forse lato telefonia fissa e` come dici, ma lato telefonia mobile e` 
dall'estate scorsa che c'e` un bellissimo cartello[1] di prezzi tra i vari 
operatori (seriamente, Vodafone non cambia tariffe da Ottobre, e gli altri 
operatori hanno tariffe simili)
 
Enrico
[1] Legalmente approvato, aggiungerei, visto che per la questione del "Per 
Sempre" non rispettato le autorita` si sono limitate a richiedere una 
promessa formale di non rifarlo mai piu`

 se mi ricordo bene... TELECOM Italia. Guarda che combinazione.
 
Probabilmente ci riferiamo a cose diverse. Se il gestore di
un dns server ti manda l'url su un altro server che emula
il sito della tua banca gliela puoi solo "succhiare" con
i sistemi antispoofing.
 
 

Addì  sabato 24 maggio 2014 16:21 Roby Ross scrisse:

Certo tu stai parlano di una cosa che non esiste, impossibile. Tu stai 
facendo il caso di un gestore di rete che fa deliberatamente phishing 
sfruttando i suoi server DNS legali e perfettamente funzionanti. 
Io invece prospettavo il caso che un cracker sfruttasse un DNS di
un terzo per deviare il traffico su un proprio server per scopi propri.
Questa cosa è difficile, improbabile e, nei rari casi in cui si verificata,
era dovuta a grossi errori fatti dall'amministratore del DNS.
Invece il caso fatto da te è pura fantasia, una cosa da romanzo di 
spionaggio. Facendo un caso ipotetico è come se una ditta immaginaria
(chiamiamola "Cina") deviasse il traffico dei propri clienti in modo da 
celare ai propri clienti tutti i prodotti della ditta concorrenza (chiamiamo 
questi prodotti "Fatti di Piazza Tienanmen"). Chiaro il contesto in cui ti 
stai muovendo?
 
PS Ed anche nella mia storiella inventata, i risultati che ho descritto non 
si raggiungono solo alterando il DNS.


 stai muovendo?
 
Non ci vuole granché.
Metti su un server dns, lo pubblicizzi su internet come
funzionante e free. Poi vedi un po' quali banche usano
gli utenti e devii la traduzione dell'url interessato verso
un ip diverso. Da li metti le paginette uguali uguali
al login della banca ed il gioco è fatto.
Probabilmente più complicato se la banca cambia sempre
password attraverso dispositivi ad hoc oppure se
usa spezzoni di una password più grande per evitare di
comunicarla interamente ad ogni login.
E' meglio stare un po' cauti sui dns,
senza prendere roba "anonima" dalla rete.

 senza prendere roba "anonima" dalla rete.
 
Ed è il mio discorso sullì'opportunità di adottare OpenDNS o i DSN di Google. Voglio dire, se vai con una puttana minimo minimo ti metti il
preservativo.


 problema non si risolve.
Tim mi fa questo scherzo, cambia i dns ogni volta.
un metodo per non permetterlo può essere:
 
chattr +i /etc/resolv.conf
 
forza il dns presente in resolv.conf senza possibilità per altri 
programmi di cambiarlo.
Però uso arch non so se ci sono altre distro che bypassano del tutto 
resolv.conf
 
ciao e buon linux

 chattr +i /etc/resolv.conf
 
  È un po' una Porcata®.  Quel file è aggiornato dal client DHCP: è nel
suo file di configurazione (ad es., /etc/dhcp/dhclient.conf per il
client della ISC) che gli si dice di non riconfigurare questo file con i
DNS indicati dal server DHCP del provider.
 
 
  Ciao,
 
 
Alessandro