i consigli di Repubblica.it riguardo ai DNS

[brancalessio]

Trovo però interessante questa cosa di OpenDNS... magari quando sono a casa la provo...

[_NYTRO_]

Però se sai che probabilmente non cambierà. potresti metterlo in /etc/resolv.conf ...
Solo che è scomodo, poi dovresti essere root...

Il file in questione è /etc/hosts !
In teoria, è buona norma specificare in quel file gli indirizzi acceduti più frequentemente. Il sistema, per le sue ricerche, si appoggia prima a questo file e poi ai dns in rete. Quindi la procedura dovrebbe essere più veloce.
Ovviamente non tutti gli indirizzi possono essere trovati in questo modo, ma per alcuni è fattibile e funzionante..
Ciao.

[albatros]

Cito _NYTRO_ :

albatros ha scritto:
Però se sai che probabilmente non cambierà. potresti metterlo in /etc/resolv.conf ...
Solo che è scomodo, poi dovresti essere root...

Il file in questione è /etc/hosts !

Sì, hai ragione!
Volevo dire lui, ma pensavo ai dns e ho scritto resolv.conf...
Grazie mille per la segnalazione, ho corretto anche il post precedente!

[albatros]

Ho guardato un po' e c'è un'estensione di firefox, fasterfox, che, fra i vari meccanismi di velocizzazione del browser, tiene anche una cache dns...
Ci sono anche altre impostazioni che si possono regolare, non ho capito però l'unità di misura per la scadenza della cache quale sia (secondi?).

[a1k]

se proprio si puo' installare un server dns e mettere come dns primario 127.0.0.1 e come secondario un dns vero.

[1pixel]

io uso i dns di OpenDns, mai sentiti?

[targzeta]

Ragazzi, nessun DNS è meglio di quello locale

Codice: Seleziona tutto

man 8 named

Spina

[albatros]

Ragazzi, nessun DNS è meglio di quello locale

Concordo, ma non mi pare una soluzione praticabile per un pc di casa e una connessione a 56K...
Penso solo al traffico per costruire e tenere aggiornato il database, nonché allo spazio da esso occupato...

[targzeta]

Ragazzi, nessun DNS è meglio di quello locale

Concordo, ma non mi pare una soluzione praticabile per un pc di casa e una connessione a 56K...
Penso solo al traffico per costruire e tenere aggiornato il database, nonché allo spazio da esso occupato...

Io ho fatto alcuni test. Innanzitutto da quello che ho capito (ma forse si può settare dal file di configurazione) named non tiene niente sull'HD, fa tutto in RAM, infatti quando lo killi e poi lo riavvii si dimentica tutto.
Ho monitorato la rete, sia quella di loop back (lo), quella in cui ho fatto partire named e sia la eth0, l'interfaccia con cui sono collegato ad internet.
Da quanto ho capito, anche il browser web ha un suo primo livello di cache per gli indirizzi IP, infatti se provi ad aggiornare il sito di Slacky ti accorgi che non fa nuove richieste al DNS. Quindi ho fatto quanto segue, ho lanciato Opera ed ho aperto un numero considerevole di pagine, dal monitoraggio si osservano tutte le richieste DNS. Ho killato Opera e l'ho rilanciata riprendendo la sessione precedente. Senza named, Opera richiedeva la risoluzione di tutti gli indirizzi su l'interfaccia eth0, con named attivo le richieste vengono gestite direttamente dall'interfaccia lo in locale, con una sensibile riduzionde dei tempi di attesa (praticamente nulla).
C'è da dire ovviamente che essendo un programma che lavora praticamente in RAM l'occupazione della memoria potrà essere notevole, io ho 2 GB di RAM e non mi preoccupo, per ora comunque il totale di memoria occupata da named è di 3MB. Sarebbe interessante sapere in media quanto occupa un RR in memoria.

Spina

[elettronicha]

Ecco un'opinione circa i presunti problemi ai DNS.

[albatros]

Rispondo a Spina:
interessante...
Pensavo ad un dns vero e proprio, con un db esteso da costruire prima di usarlo e permanente (o salvabile sull'hd), non ad un dns che popola il suo db piano piano via via che si usa, anche perché se ad ogni avvio lo devi popolare ed hai difficoltà a interpellare i dns già attivi il problema oggetto di questo thread non lo risolvi subito...
Tanto più che una cache dei dns la tiene già anche il browser (non so di quanto sia, con l'estensione fasterfox citata più sopra nel mio caso è di 512 indirizzi)...
Il vantaggio è che in caso di crash del browser non devi ricostruirla e non hai problemi nel terminare e riavviare successivamente l'applicazione, risparmiando ram se il browser non ti serve (i 3mb di named sono pochi in confronto alla ram occupata da un browser).
E' un tema da approfondire e valutare meglio...

[masalapianta]

Rispondo a Spina:
interessante...
Pensavo ad un dns vero e proprio, con un db esteso da costruire prima di usarlo e permanente (o salvabile sull'hd), non ad un dns che popola il suo db piano piano via via che si usa, anche perché se ad ogni avvio lo devi popolare ed hai difficoltà a interpellare i dns già attivi il problema oggetto di questo thread non lo risolvi subito...
Tanto più che una cache dei dns la tiene già anche il browser (non so di quanto sia, con l'estensione fasterfox citata più sopra nel mio caso è di 512 indirizzi)...
Il vantaggio è che in caso di crash del browser non devi ricostruirla e non hai problemi nel terminare e riavviare successivamente l'applicazione, risparmiando ram se il browser non ti serve (i 3mb di named sono pochi in confronto alla ram occupata da un browser).
E' un tema da approfondire e valutare meglio...

facciamo un po di chiarezza:
dns e' un database gerarchico _distribuito_ che associa nomi di dominio ad ip (ma non solo);
se effettivamente fosse un db non distribuito ma ognuno avesse una replica di tutte le zone esistenti non avrebbe senso usarlo (basterebbe utilizzare un /etc/hosts) e soprattutto uno non potrebbe piu' essere autoritativo per un proprio dominio perche' la zona relativa a quel dominio sarebbe replicata in ogni dove e quindi difficile da aggiornare su ogni dns server esistente; la suddetta struttura gerarchica e' ad albero (esattamente come un fs *nix, un albero ldap, ecc...), alla radice dell'albero ci sono i root dns, che indicano quali name server sono autoritativi per i vari domini di primo livello (.com, .net, .it, ecc..), questi name server autoritativi per i primo livello indicano a loro volta quali sono i name server autoritativi per i domini di secondo livello, ecc.. (in tal senso il dns e' distribuito); facciamo un esempio:

se volessi risolvere http://www.slacky.it cosa dovrei fare? non conosco a priori quale sia il name server autoritativo per http://www.slacky.it, quindi devo partire ad interrogare il database dns dalla radice, procediamo dunque a interrogare un root dns:

burp:~# dig @a.root-servers.net -t any it

; <<>> DiG 9.2.4 <<>> @a.root-servers.net -t any it
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8332
;; flags: qr rd; QUERY: 1, ANSWER: 7, AUTHORITY: 7, ADDITIONAL: 10

;; QUESTION SECTION:
;it. IN ANY

;; ANSWER SECTION:
it. 172800 IN NS NAMESERVER.CNR.it.
it. 172800 IN NS DNS.NIC.it.
it. 172800 IN NS M.DNS.it.
it. 172800 IN NS NS-IT.RIPE.NET.
it. 172800 IN NS J.DNS.it.
it. 172800 IN NS S.DNS.it.
it. 172800 IN NS R.DNS.it.

;; AUTHORITY SECTION:
it. 172800 IN NS NAMESERVER.CNR.it.
it. 172800 IN NS DNS.NIC.it.
it. 172800 IN NS M.DNS.it.
it. 172800 IN NS NS-IT.RIPE.NET.
it. 172800 IN NS J.DNS.it.
it. 172800 IN NS S.DNS.it.
it. 172800 IN NS R.DNS.it.

;; ADDITIONAL SECTION:
NAMESERVER.CNR.it. 172800 IN A 194.119.192.34
DNS.NIC.it. 172800 IN AAAA 2001:760:4000:1f5::5
DNS.NIC.it. 172800 IN A 193.205.245.5
M.DNS.it. 172800 IN A 217.29.76.4
NS-IT.RIPE.NET. 172800 IN AAAA 2001:610:240:0:53:cc:12:109
NS-IT.RIPE.NET. 172800 IN A 193.0.12.109
J.DNS.it. 172800 IN A 202.11.16.57
S.DNS.it. 172800 IN A 194.146.106.30
R.DNS.it. 172800 IN AAAA 2001:760:ffff:ffff::ca
R.DNS.it. 172800 IN A 193.206.141.46

;; Query time: 238 msec
;; SERVER: 198.41.0.4#53(a.root-servers.net)
;; WHEN: Thu Dec 14 11:21:24 2006
;; messaggio SIZE rcvd: 461

che ho fatto? ho chiesto a a.root-servers.net (uno dei root dns) di passarmi le informazioni relative alla zona it, di tutte le informazioni fornite a noi interessa quella relativa a quali sono i dns autoritativi per tale dominio, quindi "AUTHORITY SECTION", sotto la quale troviamo diversi name server, ne scelgo uno a caso (dns.nic.it) e procedo a interrogarlo per la zona slacky.it

burp:~# dig @DNS.NIC.it -t any slacky.it

; <<>> DiG 9.2.4 <<>> @DNS.NIC.it -t any slacky.it
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57450
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;slacky.it. IN ANY

;; AUTHORITY SECTION:
slacky.it. 86400 IN NS dns.technorail.com.
slacky.it. 86400 IN NS dns2.technorail.com.

;; Query time: 91 msec
;; SERVER: 193.205.245.5#53(DNS.NIC.it)
;; WHEN: Thu Dec 14 11:21:49 2006
;; messaggio SIZE rcvd: 78

anche qui ci interessa la parte relativa a quali sono i dns autoritativi per slacky.it, dei due ritornati ne scelgo uno e proseguo interrogandolo circa il dominio di terzo livello http://www.slacky.it

burp:~# dig @dns.technorail.com -t any http://www.slacky.it

; <<>> DiG 9.2.4 <<>> @dns.technorail.com -t any http://www.slacky.it
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24585
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.slacky.it. IN ANY

;; ANSWER SECTION:
http://www.slacky.it. 86400 IN A 62.149.140.61

;; AUTHORITY SECTION:
slacky.it. 86400 IN NS dns.technorail.com.
slacky.it. 86400 IN NS dns2.technorail.com.

;; ADDITIONAL SECTION:
dns.technorail.com. 86400 IN A 62.149.128.2
dns2.technorail.com. 86400 IN A 62.149.132.2

;; Query time: 470 msec
;; SERVER: 62.149.128.2#53(dns.technorail.com)
;; WHEN: Thu Dec 14 11:22:12 2006
;; messaggio SIZE rcvd: 130

burp:~#

il dns autoritativo per slacky.it e' autoritativo anche per http://www.slacky.it e quindi ci ritorna un bel A record che ci risolve http://www.slacky.it in un bel indirizzo ip.
Adesso dovrebbe esserti chiaro perche' la frase "Pensavo ad un dns vero e proprio, con un db esteso da costruire prima di usarlo e permanente (o salvabile sull'hd), non ad un dns che popola il suo db piano piano via via che si usa" non ha molto senso e soprattutto cosa si intende quando si dice che il dns e' un db distribuito.
Certo se tu hai un dns autoritativo per decine di migliaia di zone, cominci a dover gestire localmente un db abbastanza corposo, ma se non sei autoritativo per alcuna zona (come avviene normalmente per un'utenza casalinga che si limita a dover risolvere i nomi per i propri client interni (e non deve rispondere a query dall'esterno per domini gestiti localmente), non devi avere alcun db in locale, ti limiterai (non tu in prima persona come ho fatto io con dig, ma ci pensera' il tuo name server in maniera trasparente alle applicazioni), di volta in volta, a risolvere i nomi partendo dalla radice della gerarchia dns e risalendo fino al dominio cercato (a meno che la zona cercata non sia gia in cache ovviamente)

[albatros]

Perfetto!
Grazie mille, masalapianta, adesso ho le idee molto più chiare...
Da ignorante pensavo (erroneamente, ma non mi sono mai preoccupato di approfondire l'argomento) che ciascun root dns registrasse un più ampio numero di domini, non limitati ad un solo top level domain (es. che un root dns potesse direttamente fornire informazioni per tutti i domini europei, uno per tutti quelli del nord america, eccetera, dando ovviamente solo agli appositi enti preposti (es.nic per l'italia) la facoltà di assegnare delle sottoreti ip a un dato provider e la registrazione dei nomi).
Pensavo che poi gli altri dns fossero dei mirror dei root aggiornati regolarmente e frequentemente, per cui interpretavo la gerarchia solo in senso di punto di riferimento per tutti gli altri della loro zona di competenza...
Da qui l'idea, alla luce dei tuoi chiarimenti in realtà assolutamente sbagliata, ma coerente con il quadro delle mie credenze, che un "vero" dns dovesse contenere una gran mole di dati e che dovesse essere capace di sostenere un grande traffico, dovendo tener conto di tutti i cambiamenti su una vasta area...
E' chiaro che un simile schema da me immaginato sarebbe assai più pesante, difficile da gestire e oneroso dello schema applicato in realtà, con il solo vantaggio, reso inutile dalle altre inefficienze, di fornire risposte più veloci per risolvere l'ip di un server in germania o in svezia...
L'idea mi era venuta perché i server whois comprendono zone più grandi (vedi ripe, apnic o arin), anche se il servizio è diverso, pensavo che anche i root dns si occupassero di zone così grandi...
In ogni caso non avevo compreso come funziona il sistema gerarchico e distribuito...

Ti ringrazio di nuovo per la gentile e chiara risposta.
Ciao

[masalapianta]

Ti ringrazio di nuovo per la gentile e chiara risposta.
Ciao

figurati, condivido volentieri le poche cose che so con chi vuol imparare dei concetti invece che delle procedure.

[targzeta]

facciamo un po di chiarezza:

Quello che spieghi nel tuo post è un esempio di richiesta DNS iterativa da parte del nameserver (dato che alla fine spieghi che l'operazione che hai fatto tu viene effettuata dal mio nameserver in maniera trasparente), il che, come ben sai non è mai quello che accade.
Il problema è: A vuole conoscere l'IP di B di cui però conosce solo l'hostname.
Quello che succede è un pò una catena di Sant'Antonio, in cui chi non sa risolvere il nome lo chiede ad un altro. L'host A per definizione non conosce l'hostname di B quindi lo chiede al suo local name server (/etc/resolv.conf), se il local name server sa risolvere l'indirizzo, glielo fornisce immediatamente, altrimenti lo chiede al root name server. A questo punto, se il root name server sa risolvere l'indirizzo IP lo ritorna al local name server di A il quale lo ritorna ad A, altrimenti LUI stesso lo chiede ad un server di nomi assoluti per B (l'authoritative server name) il quale per definizione sa risolvere l'IP di B. Quindi l'authoritative name server lo ritorna al root server name, il quale lo ritorna al local name server, il quale lo ritorna ad A. Il gioco è fatto .
Quello che indicavi tu, come ho già detto è un modo iterativo di interrogare il DNS (quindi il database distribuito).
Se vogliamo essere chiari bisogna dire che tutti e due questi scenari sono accettabili. Ma di solito viene fatto in maniera ibrida. Mi spiego, l'esempio che ho fatto io implica che tra A e B ci sono solo tre server (local, root e authoritative), in generale però ci sono altri server intermedi situati tra il root name server e l'authoritative name server. Che succede allora, tutte le interrogazioni seguono la nostra catena di Sant'Antonio come ho spiegato io, solo che tra i local name server e il root name server c'è una interrogazione iterativa. Ovvero il local name server chiede al root name server il quale però, non sapendo risolvere l'IP gli ritorna solo l'IP di un server intermedio a cui poi il local name server si deve rivolgere. Questa chiamata iterativa, che di solito avviene solo a questo livello viene fatta per risparmiare al root name server l'onere di inviare richieste, dato che il root name server è quello a cui tutti i local name server si rivolgono.
Tutte le chiamate però tra i vari server intermedi sino all'authoritative name server sono effettuate in maniera ricorsiva (catena di sant'Antonio).

Si vede facilmente che per risolvere un indirizzo IP ci vogliono almeno 6 messaggi, tre di andata e tre di ritorno, se poi contiamo che ci sono altri server intermedi il numero dei messaggi cresce. Come si può ovviare allora? Si fa in modo che ci siano dei livelli di cache più o meno vicini all'host. In pratica se tu richiedi la risoluzione di un indirzzo al tuo local name server quello, una volta che l'ha scoperto se lo salva in memoria, così, se glielo richiedi di nuovo fra tre minuti lui furbissimo te lo ridà in due secondi senza interrogare nessun altro (quindi non ingarbugliando la rete).
Questo è il motivo per cui l'articolo che si citava all'inzio è una boiata.

Ovviamente come giustamente si è detto ci sono degli host che cambiano indirizzi, per ovviare a questo problema si fa in modo che le cache vengano invalidate dopo un periodo di tempo che puuò essere più o meno lungo.

Quello che cercavo di fare io era di far partire un server DNS locale in modo da monitorare il risparmio che effettivamente ottengo nell'eliminare gli invii al mio DNS locale. Ovviamente il tempo di risposta è nullo se ho un DNS locale che effettua la cache di tutti gli indirizzi che richiedo IO abitualmente.

Spero di non avervi annoiato con questo lungo post. Ci tenevo a spiegare la cosa per bene perchè ho visto che il livello del thread si stava alzando, e da quello che ha spiegato masalapianta non mi sembrava chiarissimo il modo in cui vengono gestiti i DNS. Infatti, a parte le interrogazioni che continuava a fare indicando hostname invece che IP, invalidando quindi le chiamate precedenti , si limitava a spiegare uno scenario, che se vero, era meglio far eseguire direttamente agli host invece che ai local server name. Mi spiego, se tutto fosse iterativo è inutile far faticare i local name server, si fa prima a far fare tutto agli host. Della serie. l'host chiede al local name server, il quale gli da l'indirizzo del root name server, a questo punto l'host chiede al root che gli da l'indirizzo di un server intermedio. Quindi l'host chiede al server intermedio etc..etc..

Spina

P.S. Tutto sarebbe stato più chiaro con un disegnino ma....