[Dna-dev] [tx0@autistici.org: Re: Articolo]

Delete this message

Reply to this message
Author: Tx0
Date:  
Subject: [Dna-dev] [tx0@autistici.org: Re: Articolo]
Finalmente trovo il tempo di girare in lista questa mail :))))
E' una risposta a zt4 che mi chiedeva qualche chiarimento sulla
risoluzione dei nomi e sul meccanismo di registrazione di DNA.

----- Forwarded message from Tx0 <tx0@???> -----

From: Tx0 <tx0@???>
To: zt4 <zt4@???>
Subject: Re: Articolo
Date: Tue, 13 Jul 2004 15:49:56 +0200
Return-Path: <tx0@???>

On Tue, Jul 13, 2004 at 12:46:31PM +0200, zt4 wrote:
> Ciao Tx0,
> ? un piacere risentirti (anzi rileggerti). Ti scrivo in forma "privata" per
> non annoiare la ML e al limite possiamo ripostare.


Piacere di risentire anche te, zt4 :)))

> Ho letto con interesse il tuo articolo e mi ? piaciuto. Proporrei se sei
> d'accordo di dare una svegliata a DNA tentando di buttare gi? un abbozzo di
> comunicazione in multicast per la risoluzione dei domini DNA.


Molto volentieri.

> Ho per? un dubbio (e forse questo andrebbe in ML) :
> il server pippo vuole risolvere pluto.dna e manda una richiesta in multicast
> cosa succede rispondono tutti quelli che l'hanno in cache?
> risponde solo il rigistratario? e se ? gi??


No, c'e' un errore: la risoluzione NON avviene in multicast! Avviene in
unicast con datagram UDP. In altre parole: e' una NORMALISSIMA
risoluzione di nomi DNS.

Questo perche' DNA _deve_ essere compatibile con il DNS tradizionale. Io
per primo NON lo userei se non lo fosse. ;)))

Il Multicast e' pensato esclusivamente per la gestione fra i nodi. Ti
faccio un esempio: abbiamo 3 nodi, D, N, e A ;))))

Una persona decide di registrare un dominio TLD chiamato ".taz".

Chiede a D di effettuare la registrazione (operazione chiamata
"iniezione della query" perche' attraverso un punto della rete la query
verra' poi propagata in tutta la rete multicast dei nodi DNA).

D puo' ovviamente rifiutare (il server e' carico, l'amministratore lo
configura per rifiutare ulteriori accollamenti di zone).

D non rifiuta e manda 1 datagram UDP in Multicast a tutta la rete DNA
per procedere alla registrazione. Il datagram contiene queste
informazioni:

a) Viene registrato il nuovo TLD ".taz"
b) Il primary master per questo TLD e' il nodo D.

N e A possono rispondere si oppure no in base alle informazioni in loro
possesso. Quello che pero' registrano e' che il dominio ".taz" e' su D.

==== e qui finisce la parte di registrazione, supponendo che sia N che A
rispondano positivamente.

Ora diciamo che un soggetto esterno alla rete DNA (cioe' che NON ha nodi
DNA) voglia registrare il dominio di secondo livello "we-are.taz". Fa
prima una query di tipo NS per capire quale server sia master per
".taz". La query puo' essere fatta sia a D, che a N che ad A. La
risposta e' sempre D!

Quindi contatta D e chiede la registrazione di "we-are.taz". D procede
alla registrazione, N ed A non sono minimamente coinvolti nel
procedimento, quindi la rete multicast non viene toccata affatto.
Registrata la zona, viene registrato anche il nome host
"ftp.we-are.taz".

==== Ora diciamo che un client ha bisogno di risolvere il nome DNS
"ftp.we-are.taz". Utilizza come nameserver il nodo A. Quindi manda una
query DNS _standard_ ad A per risolvere "ftp.we-are.taz", nello stesso
modo che userebbe per chiedere "ftp.ibm.com" ok?

La risposta di A e': non so chi sia "ftp.we-are.taz" ma so che D e' il
server della zona ".taz", lui avra' maggiori informazioni. A questo
punto il client (oppure il nodo A stesso, se la query richiede un
approccio ricorsivo, ma e' un dettaglio trascurabile per questo esempio)
il client dicevo manda la _stessa_ query che ha mandato ad A al nodo D.
A quel punto D gli scodella tutte le informazioni del caso, che sono
tenzenzialmente:

  ftp.we-are.taz IN A   1.2.3.4   # indirizzo IP richiesto
  we-are.taz     IN NS  D.dna     # il name server di we-are.taz sono io
  D.dna          IN A   6.5.31.2  # indirizzo IP di D.dna


Come vedi il client NON utilizza il Multicast per la risoluzione.
Nessuno al mondo deciderebbe di cambiare la libreria del resolver per un
nuovo sistema. Per questo dobbiamo essere compatibili con il sistema
attualmente in uso.

> Si potrebbe definire un concetto di prossimit? tra i server?


Questo concetto e' ancor piu' interessante di quanto tu possa pensare
forse. Il server internodo multicast sara' necessariamente obbligato a
parlare un protocollo di routing multicast in quanto sara' costretto a
supportare tunneling unicast per incapsulare traffico multicast laddove
gli apparati non lo ruotino autonomamente (ossia dentro moltissime LAN
e ovunque fuori di una LAN).

> Forse ne abbiamo gi? parlato, ma non so se abbiamo trovato una risposta.
> La mia esperienza con multicast ? solamente in java per un sistema fault
> tollerance, spero torni utile.


Sara' certamente utilissima, sia l'esperienza in Multicast, che io
invece conosco solo su base teorica (RFC ma poche prove pratiche) sia
quella con Java. Piu' varianti del server scriviamo (io programmo al 99%
in perl) piu' abbiamo la garanzia che il protocollo sia ben supportabile
da architetture differenti.

> Inoltre la funzionalit? di forward verrebbe mantenuta solo per le estensioni
> "tradizionali" o verrebbe eliminata?


Non so se la materremo. In effetti non ha particolarmente senso ora che
RNA_named e' in grado di risolvere ricorsivamente le zone tradizionali.
Tuttavia, non prendermi per oro colato :)

> A presto.
> zt4


Felice di averti risentito.

p.s. che dici, la giro in lista questa risposta?
--
TicsO :: www.autistici.org/loa/tx0 :: tx0@???
@ :: 811C F817 587E D5A3 18DA 40F0 CBB0 0665 7109 867E
So stare un minuto senz'aria, non un secondo senza ideE

----- End forwarded message -----

--
TicsO :: www.autistici.org/loa/tx0 :: tx0@???
@ :: 811C F817 587E D5A3 18DA 40F0 CBB0 0665 7109 867E
So stare un minuto senz'aria, non un secondo senza ideE