================================================================================ ---------------------[ 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 http://www.autistici.org/DNA/ ]------------------ DNA: Domain Name Anarchy Tx0 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: <> 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 ]------------------------------------- ================================================================================