Copy Link
Add to Bookmark
Report
BFi numero 13 file 15
================================================================================
---------------------[ BFi13-dev - file 15 - 20/08/2004 ]-----------------------
================================================================================
-[ DiSCLAiMER ]-----------------------------------------------------------------
Tutto il materiale contenuto in BFi ha fini esclusivamente informativi
ed educativi. Gli autori di BFi non si riterranno in alcun modo
responsabili per danni perpetrati a cose o persone causati dall'uso
di codice, programmi, informazioni, tecniche contenuti all'interno
della rivista.
BFi e' libero e autonomo mezzo di espressione; come noi autori siamo
liberi di scrivere BFi, tu sei libero di continuare a leggere oppure
di fermarti qui. Pertanto, se ti ritieni offeso dai temi trattati
e/o dal modo in cui lo sono, * interrompi immediatamente la lettura
e cancella questi file dal tuo computer * . Proseguendo tu, lettore,
ti assumi ogni genere di responsabilita` per l'uso che farai delle
informazioni contenute in BFi.
Si vieta il posting di BFi in newsgroup e la diffusione di *parti*
della rivista: distribuite BFi nella sua forma integrale ed originale.
--------------------------------------------------------------------------------
-[ HACKiNG ]--------------------------------------------------------------------
---[ DNA: D0MAiN NAME ANARCHY ]-------------------------------------------------
-----[ Tx0 <tx0@autistici.org> http://www.autistici.org/DNA/ ]------------------
DNA: Domain Name Anarchy
Tx0 <tx0@autistici.org>
http://www.autistici.org/DNA/
1. Intro
DNA e' un progetto nato per caso.
Ad una assemblea del LOA hacklab di Milano, ormai piu' di tre anni fa, ho
proposto di mettere in piedi un server DNS nostro e attivarci un dominio di
primo livello. Cosi', piu' per il gusto di farlo che per altro. L'idea, per
quanto semplice, aveva entusiasmato molti ed erano partite grandi discussioni
sull'argomento.
Ad essere onesti l'idea non era poi nemmeno particolarmente originale. Agli
hackmeeting e' tradizione che il DNS interno usi un TLD d'invenzione, come .taz
e, a pensarci, persino molte aziende usano TLD non ufficiali sulle reti
interne. Anzi, a dirla tutta, e' proprio il DNS a consentire esplicitamente,
per come e' concepito, questo genere di strutture locali: porzioni di reti che
utilizzano domini non raggiungibili dall'esterno.
Ciononostante, l'idea era piaciuta. Mentre elaboravamo questa possibilita' di
un DNS con un Top Level Domain tutto nostro, la discussione ha cominciato a
lievitare, a prender volume, a trasformarsi fino a diventare una macro idea
molto piu' complessa. E qualcuno l'ha battezzata Domain Name Anarchy.
Allo stato attuale, DNA e' un progetto articolato che ha come obiettivi
principali la registrazione libera di Top Level Domain (libera significa
anonima, dinamica, non subordinata ad autorita' e non semplicemente "gratuita")
e la ridondanza della rete, in modo da non consentire la cessazione di un
servizio o di parte di esso al crollo di un singolo nodo.
2. Invenzione o evoluzione?
Esistono alcuni esempi di esperienze in atto tuttora che ci indicano come DNA
non sia una invenzione ex novo, quanto piuttosto una evoluzione del desiderio
di organizzare un circuito di server DNS alternativo. Perche' il tentativo
riesca e' necessario che DNA analizzi gli errori del passato, facendone
tesoro.
Sulla scena internazionale esistono da tempo soggetti che offrono la
registrazione di domini TLD non ufficiali, ovvero non integrati nella gerarchia
standard dell'albero DNS. Un esempio e' OpenNIC, raggiungibile all'indirizzo:
http://www.opennic.unrated.net/
Queste soluzioni hanno tuttavia l'evidente inconveniente di non essere
risolvibili con un generico server DNS, ma esclusivamente con i server di
quella realta' stessa o eventualmente i server ad essa connessi.
Un primo problema e' la richiesta di intervento umano. Una gerarchia di domini
richiede una manutenzione davvero eccessiva perche' una organizzazione priva di
finanziamenti e con una economia davvero bassa possa accollarsi l'onere di
mantenere manualmente un simile sistema. Dunque: serve automazione, il piu'
possibile.
Abbiamo inoltre un secondo problema: queste soluzioni rischiano un inesorabile
collasso. La necessita' di scegliere quei pochi DNS per risolvere quel dato TLD
comporta un alto rischio di carico nei confronti di pochi server che quindi
tendono all'esaurimento delle risorse, sia in termini di carico CPU che di
banda disponibile.
Altrettanto non si puo' dire dei Root Server ufficiali che sono costruiti su
hardware di grandi prestazioni e opportunamente ridondato e connesso ad
Internet con link di grande capacita'.
Altre soluzioni, decisamente peggiori e prive di compatibilita', invece
richiedono l'installazione, all'interno del browser, di un plug-in che consenta
la risoluzione dei nomi attraverso un differente meccanismo, prima di
utilizzare il DNS standard in caso di fallimento. Questa seconda possibilita'
e' evidentemente inaccettabile, perche' non e' trasparente per l'utente ed e'
limitata ai soli programmi per i quali esistono i plugin appositi, ossia web
browser e niente altro.
Oltre a rischiare gli stessi problemi della soluzione precedente, questa
seconda commette un ulteriore errore: rompe la compatibilita'. Qualsiasi
sistema operativo e' dotato di un resolver DNS (la libreria di funzioni o
l'agente che operano le risoluzioni DNS). Per questo e' imprescindibile che un
nuovo sistema di risoluzioni dei nomi mantenga la compatibilita' con quanto
esistente adesso. Il DNS funziona troppo bene per pretendere di sostituirlo!
3. Punti di forza del DNS
Ma e' davvero cosi' ben fatto questo DNS per non volerlo buttare via?
Possiamo intanto dire che un sistema o protocollo che regga decenni di
attivita' operando initerrottamente, soddisfacendo le esigenze per le quali era
stato creato e ben sopportando l'integrazione di nuove funzionalita' e' gia'
una prima sommaria risposta positiva alla nostra domanda.
Il DNS e' modulare, distribuito, compatto ed efficiente; ha alte performance,
e' semplice da implementare, e' affermato come il sistema di risoluzione di nomi
della rete Internet. E non accenna a demordere.
Il primo documento che stabilisce uno standard per il DNS e' l'RFC-882, insieme
al successivo 883, datati entrambi 1983, ossia vent'anni fa. Successivamente
gli RFC-1034 e 1035, del 1987, rivedono, correggono e integrano i primi due,
sostituendoli. Dall'87 in poi il DNS non e' piu' stato toccato nella sua
essenza. E' stato aggiornato e dotato di nuovi tipi di informazioni
veicolabili, e' stato irrobustito con sistemi crittografici; ma non e' piu'
stato modificato intimamente. Oramai il DNS ha una sua precisa natura.
I pacchetti viaggiano in piccoli datagrammi UDP, organizzati in maniera
compatta, impiegando inoltre un brillante sistema di compressione basato su
puntatori interni al pacchetto. Il TCP viene impiegato solo quando il volume di
informazione e' troppo grande (sopra i 512 byte) per essere efficientemente
trasportato via UDP. Le query sono ben organizzate con codici numerici noti e
c'e' ancora molto spazio per inventare nuove qualita' di informazioni
veicolabili, oltre ai semplici nomi e indirizzi IP.
L'estensibilita' del DNS e' un requisito di design che e' sempre stato
presente. Per darvi un'idea, l'RFC-2539, quindi molto successivo ai precedenti,
propone uno standard per immagazzinare chiavi Diffie-Hellman all'interno di un
database DNS.
4. L'albero delle deleghe
La distribuzione delle zone e' parte integrante della sua forza. L'intero
database mondiale DNS e' organizzato in una struttura ad albero. Il corpo delle
informazioni che lo compongono e' frazionabile naturalmente in zone, ossia in
porzioni che contengono a loro volta sotto porzioni e cosi' via.
Ciascuna di queste zone viene delegata ad un server piu' specializzato che si
occupa di quella zona. La delega avviene attraverso uno speciale "gancio" che
collega una zona alla sua diretta superiore. Questo gancio e' il record
NS, ossia name server. Questi record possono essere usati a piacimento, grazie
alla natura ricorsiva del meccanismo inverso di interrogazione.
Prendiamo ad esempio il dominio www.dominio.com. Il server 1.2.3.4 gestisce il
dominio di primo livello (TLD) ".com". Il server 5.6.7.8 gestisce il dominio
".dominio.com", che e' evidentemente un sottodominio di ".com". Dentro la zona
".com" esiste un gancio che dice "Il nameserver per .dominio.com e' 5.6.7.8".
Quando un client DNS vuole risolvere "www.dominio.com", contatta 1.2.3.4
richiedendo l'indirizzo IP di "www.dominio.com". La risposta di 1.2.3.4 suona
circa come: <<Non so quale sia l'IP di www.dominio.com, ma so che il suo server
DNS e' 5.6.7.8, chiedi a lui.>> Il client contatta a questo punto 5.6.7.8 e
ottiene, si suppone, l'indirizzo IP ricercato, oppure una risposta autoritativa
che lo informa dell'inesistenza dell'etichetta "www" all'interno della zona
".dominio.com".
I vantaggi della distribuzione sono piu' che evidenti. Non ho idea di quanti
gigabyte possa occupare l'intero database DNS accorpato assieme. Quello che e'
sicuramente evidente e' che non solo e' pesante per un unico server un simile
ammontare di dati, ma e' anche ingestibile il suo aggiornamento da parte di una
singola organizzazione. In sintesi: l'authority delega, evitandosi uno sforzo
enorme e garantendo al contempo liberta' di azione ai singoli soggetti
registratari di dominio.
5. Cosa c'e' che non va?
Ci sono alcuni aspetti sopra citati che troppo spesso si danno per assunti e
sui quali invece varrebbe la pena soffermarsi. Ad esempio il concetto di
authority.
Senza voler sconfinare in una discussione filosofica sul concetto di autorita',
vale la pena di notare come questa sia spesso il concetto al quale facciamo
ricorso con maggior immediatezza quando abbiamo bisogno di garantire qualsiasi
cosa, tra cui, ad esempio, un'informazione.
Facciamo un esempio differente dal DNS: la crittografia a chiave pubblica. Io
creo una chiave, quindi la distribuisco. Tu vuoi essere certo che sia mia. Come
fare? Ecco che la societa' (di invenzione, spero) SecureKey si propone come
autorita' garante e, in cambio di denaro, certifica che la
mia chiave e' mia, apponendovi la sua firma. Tu sai gia' che SecureKey e'
davvero SecureKey perche' nel tuo web browser, nel tuo client di posta e anche
dentro il telecomando del cancello di casa c'e' una copia del suo certificato.
E se io non mi fidassi di SecureKey? E se non volessi spendere dei soldi per
certificarmi? E se...? Per fortuna una soluzione c'e': il cosiddetto "web of
trust". Se io e te abbiamo una conoscenza in comune possiamo chiederle di fare
da tramite, firmando le nostre chiavi. Io e te ci fidiamo entrambi di lui.
Sara' lui la nostra garanzia. Ora estendiamo il concetto in maniera
omnidirezionale e avremo un insieme amalgamato in cui ciascuno di noi beneficia
di migliaia di garanti ed e' garante per migliaia di persone. Senza spendere
soldi e senza inviare informazioni personali a soggetti sconosciuti (che ne
sappiamo di SecureKey? Che fa con i nostri dati?), e cosi' via.
L'autorita' e' un concetto pericoloso. Quando non e' controllabile, ossia
praticamente sempre, diviene un nucleo di potere impenetrabile e insensibile
alle esigenze di quella comunita' di individui a beneficio dei quali era stata
creata.
Decidiamo quindi che vogliamo eliminare il concetto di autorita' dal DNS. Come
si fa?
Per quanto sgradevole, l'autorita' e' un bel vantaggio. Quello che dice e'
legge. Sancito. Decretato. Come e' possibile sostituire un sovrano con
un'assemblea popolare, quando il popolo e' di parecchie centinaia di milioni di
utenti sparsi in tutto il mondo e che parlano cento lingue?
Prima di desistere, consideriamo una ipotesi.
5. Panoramica di DNA
DNA e' tre cose insieme. E' un meccanismo. E' un protocollo. E' una
infrastruttura. Il meccanismo descrive il funzionamento della struttura in
maniera astratta. Il protocollo lo implementa. La struttura lo realizza.
La struttura e' formata di nodi paritetici. Ciascun nodo comunica agli altri
delle proposte di registrazione. Ciascuna proposta viene vagliata dagli altri
nodi per la registrazione. Tutto questo avviene attraverso il protocollo. Il
protocollo deve essere parlato in maniera contemporanea da tutti i nodi (dove
"contemporaneo" ha una valenza necessariamente elastica). Le decisioni entrano
in funzione appena registrate. Un nodo si assume l'onere della zona. Altri nodi
la replicano per ridondanza. Tutti i nodi sanno a quali server riferirsi per
una determinata zona TLD.
In pratica il meccanismo di distribuzione sostituisce la delega per i domini di
primo livello, soppiantando i root-server con una rete piu' omogenea di server.
Al di sotto del primo livello, il DNS non muta in alcun modo. I software
tradizionali possono essere impiegati dal secondo livello in poi, esattamente
come e' adesso. La struttura e' in grado di risolvere trasparentemente tutte le
zone DNS standard (.com, .net, .it, ...) in modo da garantire all'utente la
massima compatibilita' con il sistema tradizionale.
L'utente non si accorge di nulla. Gli amministratori di domini di secondo
livello cambiano solo procedura di registrazione. Ma al primo livello e' tutto
differente: qualcosa di completamente nuovo.
6. Meccanismo di registrazione
Il meccanismo di registrazione e' una delle componenti chiave del sistema. Un
nodo deve essere in grado di richiedere una registrazione ad una rete di alcune
(decine, centinaia di) migliaia di nodi. La rete in questione deve quindi
essere in grado di gestire questa richiesta senza alcun intervento arbitrativo
per quanto possibile. Deve inoltre essere in grado di sviluppare tutto il
procedimento quanto piu' possibile. Certamente una cosa complessa.
Il primo punto da affrontare e': come trascrivere la query di registrazione?
Beh, il formato piu' comodo e' probabilmente un pacchetto DNS! La natura delle
informazioni registrabili puo' essere facilmente codificata dentro un simile
pacchetto (record A per indirizzi IP, record NS per indirizzo del server
registrante, record TXT per un indirizzo email di riferimento, e' gia' tutto
predisposto).
Inoltre significa poter beneficiare di librerie di parsing gia' rodate e
consolidate.
Quindi bisogna considerare altre questioni relative alla transazione della
richiesta. Come e' possibile far comunicare efficientemente questa enorme mole
di server come se fossero ad una sorta di meeting permanente? Sono state
valutate alcune possibilita'.
Gli stream unicast sono stati evidentemente esclusi. Non e' concepibile
attendere che il nodo registrante comunichi una richiesta a 10.000 nodi perche'
questa registrazione venga effettivamente convalidata. Intanto per motivi di
tempo e di banda, e poi per una questione pratica: un cosi' grande intervallo
di tempo rischia di portare a collisioni in cui due nodi, registranti la stessa
zona, compiendo il giro degli altri nodi partendo da due host differenti,
portano la rete ad uno stato non consistente. Meta' rete attribuirebbe la zona
ad un nodo, l'altra meta' all'altro. Ingestibile.
Serve la possibilita' di comunicare con tutti i nodi nello stesso istante.
Serve il Multicast.
7. Multicast e tunneling
Multicast e' una modalita' operativa della suite TCP/IP. Utilizzando un
indirizzo IP (da un intervallo di indirizzi riservato dagli RFC a questo scopo)
che non si riferisce ad un singolo host, ma ad un "gruppo sparso" di host, e'
possibile comunicare con tutti questi host contemporaneamente. E' in questo
simile al Broadcast, ma con la differenza che gli host non devono essere tutti
sulla stessa LAN.
Il Multicast funziona solo con UDP (il TCP e' pensato per stream e uno stream
non puo' essere stabilito da uno a molti, occorrono molti stream). Questo per
noi non e' un problema, anzi. Il Multicast consente di far interagire piu' nodi
su Internet anche se questi sono sparsi su piu' reti separate da router. E'
insomma la chiave al nostro problema di comunicazione "atomica", ossia
riducibile ad un tempo zero.
Certamente non da un punto di vista reale: la comunicazione (ed eventuali
contestazioni alla registrazione) comportano secondi, forse anche minuti. Ma
una volta che la registrazione o la contestazione sono state inviate, sono tali
per tutti i nodi della rete DNA, contemporaneamente.
Naturalmente l'impiego del Multicast comporta un aumento della complessita' del
progetto. Anzitutto il Multicast non e' naturalmente instradato su Internet.
Gli apparati sono preconfigurati per filtrare il traffico Multicast in uscita e
alcuni addirittura non supportano il Multicast nel loro kernel o firmware.
Questo puo' dunque richiedere l'impiego di tunnel punto punto che incapsulino
un tratto di rete DNA dentro un percorso unicast.
Questo puo' dunque richiedere che il server DNA gestisca una porta convenzionale
in ascolto per accettare richieste di tunneling da altri host che non sono in
grado di raggiungere il gruppo multicast naturalmente.
Inoltre il Multicast ha il peso aggiuntivo di un sistema piu' complesso di
routing. Il routing unicast e' semplice: un indirizzo IP fa parte di una subnet.
Una subnet e' identificata da una netmask. Dunque: un rotta unicast puo' essere
scritta semplicemente sapendo che una tale sottorete e' al di la' di una
specifica interfaccia, comprendendo con una regola un numero elevato di host.
Nel caso del Multicast occorre aggiornare continuamente (per fortuna attraverso
un protocollo dinamico) le rotte, che per la loro speciale natura sono
contenute in una tabella di routing separata rispetto a quella dell'unicast.
Per far questo si usa una coppia di protocolli.
Il primo, l'IGMP (Internet Group Management Protocol) gestisce l'ingresso e
l'uscita di un nodo da un gruppo Multicast. Il secondo e' un protocollo di
routing e puo' essere scelto fra PIM (sparso o denso), oppure MOSPF, oppure
altri ancora. Questo secondo ha il compito di compilare effettivamente le regole
di routing per la tabella multicast.
L'uso di un protocollo o di un altro potrebbe non riguardarci, se gli apparati
fossero tutti configurati per l'instradamento del traffico multicast. Ma
siccome non possiamo accettare questo assunto, saremo costretti ad implementare
i protocolli di routing all'interno del nodo DNA, o sotto forma di programmi a
contorno, fortunatamente gia' esistenti, oppure come componenti dello stesso
server DNA.
8. Di nuovo sul meccanismo di registrazione
Siamo dunque arrivati a delineare una situazione grosso modo impostata. I nodi
avranno pari possibilita' di registrare le zone. Ci sara' un meccanismo di
arbitraggio automatico delle zone. Il traffico sara' gestito in multicast.
Verifichiamo che questo scenario possa funzionare.
Diciamo che il nodo (A) voglia registrare una zona ".dna". Formatta la query e
la invia al gruppo Multicast. Supponiamo che tutti i server ricevano la query.
Si possono presentare alcuni scenari.
Se la zona non e' stata registrata, nessun host rispondera' negativamente alla
richiesta di registrazione e la zona si potra' considerare confermata.
Probabilmente un tacito assenso puo' essere male interpretato se proprio il nodo
registrante viene temporaneamente disconnesso dalla rete. Forse un assenso di
test da parte di almeno un nodo altro puo' essere auspicabile. Un meccanismo
random di risposta puo' fare al caso nostro nella gestione della scala di
priorita' di invio.
Se invece la zona e' gia' stata registrata, i nodi si predisporranno per una
risposta negativa. Sara' sufficiente una prima risposta per invalidare la
richiesta. Teniamo presente che tutti i nodi dovrebbero conoscere quali zone
TLD sono registrate ed a quali server fanno capo. Dunque si puo' supporre che
un nodo che registri una zona gia' registrata, se in buona fede, sia stato
vittima di una disconnessione dalla rete DNA.
In entrambi i casi il meccanismo di arbitraggio e' piuttosto semplice.
8. Meccanismo di sincronia
Ora consideriamo una ipotesi scartata in precedenza: non tutti i nodi ricevono
una query. Caso piuttosto probabile su una rete di migliaia di nodi.
In questo caso ci basiamo su una considerazione. La distribuzione del database
in ciascun nodo ci garantisce maggior credibilita' mano a mano che le
informazioni si replicano. Se e' probabile che, su una rete di quattro nodi,
tre si coalizzino contro uno per negargli ogni possibilita' di registrazione
(attraverso software manipolato intenzionalmente), e' improbabile che avvenga
una simile cosa su grandi numeri.
Nel caso in cui un nodo avesse perso una richiesta di registrazione, il suo
database locale sarebbe desincronizzato rispetto al quadro complessivo della
rete. A questo scopo dovranno essere implementati dei meccanismi di sincronia.
Plausibilmente un nodo dovra' verificare la sua connettivita' alla rete DNA
periodicamente. Ricevere del traffico su gruppo multicast DNA e' un buon
"heartbeat". In caso di silenzio troppo prolungato (ad esempio dopo un timeout
di dieci minuti) il nodo isolato puo' considerarsi in uno stato "out of sync" e
intraprendere quindi una procedura di sincronizzazione.
I passaggi sarebbero probabilmente i seguenti:
1. tentare una connessione unicast ad un nodo DNA scelto fra una lista di
nodi di emergenza, precedentemente configurata.
2. ottenuto l'aggancio, richiedere una sincronizzazione di tutte le zone
registrate nel frattempo.
3. ottenuta una lista di tutte le registrazioni intercorse, procedere ad una
verifica di tutte, presso i rispettivi server figuranti come registratari.
Nel frattempo, se il link tarda ad attivare, sara' opportuno che il nodo DNA
informi gli amministratori competenti della mancata connessione di rete,
sperando che questa non coinvolga anche le connessioni unicast, ovviamente.
9. Supporto crittografico
L'ultimo elemento necessario a completare il quadro e' un meccanismo di
autenticazione dei nodi.
Il disegno sinora tracciato non contempla il fatto che, quando (A) esegue una
registrazione di una zona, sia realmente (A). Un possibile attacco ad una rete
con database distribuiti e replicati e' ovviamente l'avvelenamento delle
informazioni. Continuare ad eseguire registrazioni a nome di nodi ignari oppure
inesistenti e' un ottimo modo per demolire la consistenza della rete stessa.
Per questo e' previsto che ciascun nodo sia dotato di un certificato
crittografico a chiave pubblica con il quale firmare le informazioni che
vengono introdotte nella rete DNA. Non abbiamo ancora deciso se utilizzare lo
standard OpenPGP oppure l'X.509 o altro ancora.
L'inserimento di un server in rete comporta anche lo scambio di certificati.
Uno dei compiti degli amministratori di sistema sara' quello di firmare
reciprocamente i certificati dei nodi in modo da creare un "web of trust".
10. Il tempo
Un'altra questione da non sottovalutare e' la questione tempo. Finche' una
registrazione viene eseguita presso una autorita', l'ora della registrazione
sara' quella locale dell'autorita' stessa. Ma DNA non prevede autorita'. Come
mettere d'accordo un eterogeneo insieme di nodi?
Non abbiamo ancora una risposta definitiva su questo. Le due
possibilita' piu' probabili sono la consultazione di un time server condiviso
oppure l'inserimento di protocolli di sincronia all'interno dei requisiti di un
nodo DNA. Questo e' decisamente terreno aperto.
9. Attuale implementazione
L'unica implementazione attualmente esistente di DNA si chiama RNA ed e'
scaricabile dal sito all'indirizzo:
http://www.autistici.org/DNA/_download/rna.epl
La release 0.2 e' in sviluppo attivo. Assicuratevi di ottenere l'ultima
sottorelease (indicata dalla sigla wXX, dove XX e' un numero progressivo di due
cifre). E' ancora difettosa anche se cresce piuttosto rapidamente.
Questa implementazione al momento copre soltanto la parte relativa al DNS
server. Contiene un server che si propone come sostituto di BIND per le
operazioni di risposta ai client. Si basa su un server MySQL per
l'immagazzinamento dei dati, sia delle zone che della cache. Risolve
trasparentemente sia zone DNS ufficiali che zone DNA.
Per quanto riguarda l'altra meta', ossia il meccanismo internodo di
registrazione, non esiste ancora alcun software. Il motivo per cui ho scritto
prima possibile il server DNS era proprio per invogliare altri a unirsi al
progetto, presentando una situazione in cui il lavoro piu' noioso era gia' stato
fatto.
Allo stato attuale delle cose e' possibile concentrarsi su aspetti piu'
stimolanti come la registrazione delle zone in multicast piuttosto che dover
lavorare ad un server DNS. Questo infatti e' un'applicazione separata dal
server internodo e puo' dunque essere utilizzata su un nodo DNA affiancandola
ad un server scritto in C, C++, Java o qualsiasi altro.
10. Come unirsi al team di sviluppo
Tutte le informazioni attualmente prodotte su DNA, incluso il software si
trovano sul sito all'indirizzo: http://www.autistici.org/DNA/. Sul sito trovate
anche le informazioni per iscrivervi alla lista di coordinamento degli
sviluppatori. E' presente un'area forum per discutere ogni questione legata al
progetto, assieme ad un'area di sviluppo in cui e' possibile uploadare draft e
documenti con proposte.
Un'area documentazione raccoglie una selezione di RFC sul DNS e sul Multicast
per facilitare lo studio iniziale delle tematiche correlate. Il sito e' in
italiano e inglese. Altre traduzioni sarebbero molto apprezzate.
11. The next step
Interagire con lo sviluppo di DNA e' dunque possibile su numerosi livelli.
E' possibile in fase progettuale: creazione delle meccaniche e dei protocolli.
E' possibile in fase implementativa: la scrittura di una suite DNA. E' possibile
in un'altra fase implementativa: la creazione di nodi su Internet per far
nascere realmente una rete DNA. Ed e' infine possibile partecipando al
betatesting del software esistente.
Le sfide ancora aperte sono dunque tante e molte ancora non sono state incluse
nello sviluppo del progetto. Due per tutte: DNSSEC e IPv6!!!
Ma tutto questo non fa che rendere ancora piu' affascinante un'idea, quella di
ripensare ogni nome della Rete e dunque il suo stesso Nome, in un sogno
gibsoniano che gia' di per se' dipinge scenari travolgenti.
Come si chiamera' la Rete domani?
Riferimenti: http://www.autistici.org/DNA/
dna-dev@autistici.org
================================================================================
------------------------------------[ EOF ]-------------------------------------
================================================================================
