[Ninux-Calabria] DNS distribuito e sicuro

[Giuseppe De Marco]

Il 9 gennaio 2015 18:12, Stefano De Carlo <stefanauss a gmail.com> ha scritto:
> Il 30/12/2014 21:58, Giuseppe De Marco ha scritto:
>> https://github.com/mwarning/KadNode
>>
>> Ragazzi occupa poco, già disponibile su openmWRT, autorevolezza p2p
>> basata su chiave asincrona, buon debug - a naso pare la buona scelta.
>>
>> Testiamolo e stabilizziamolo, potrebbe essere la soluzione definitiva
>> e non centralizzata in assoluto.
>> Di certo non stà nell'841 se in questo c'è anche il tunnel ma ognuno
>> può eseguirlo sul proprio pc quando lo accende e iniziare ad
>> annunciarsi e scovarci con il DHT...insomma, funziona come il torrent
>> ma risolve nomi.
>
> Me lo sono guardato un po' con calma. È un tool carino, non lo conoscevo.
>
> Il fatto è che non è un DNS distribuito e non è sicuro, di conseguenza non rappresenta l'architettura di cui Ninux ha bisogno come punto d'arrivo.
>
> Quello che KadNode distribuisce è il database delle associazioni nome => risoluzione. Che è certamente una ottima cosa.
> Ma KadNone *esplicitamente* non fa/vuole fare nulla per distribuire il processo di verifica dell'identità e della legittimità della entry DNS.
> Quella rimane PtP. Cioè: è il singolo nodo che deve aggiungere e verificare una a una le entità delle quali si fida. È evidente che una cosa del genere non può scalare.
> Questa verifica PtP è il tipico meccanismo del Dynamic DNS, ed infatti l'autore dice esplicitamente che KadNode è una soluzione decentalizzata a questo genere di problematica.
> In sostanza, chiunque può annunciare identificatori duplicati (che non risolvono finché non verifichi manualmente) e l'identificatore è valido fintanto che resti online. È un niet per un'architettura DNS, ma accettabile per una DynDNS.
> L'uso del dht poi rende i tempi di lookup impossibili da portare giù nell'ordine di grandezza del tipico DNS.
>
> Credo che attualmente la migliore prospettiva di architettura completamente decentralizzata e retro-compatibile con i tool DNS classici siano quelle blockchain-based come NameCoin e dotp2p.
> Va analizzata bene perché i risvolti sono tanti.
>
> Certamente distribuire e decentralizzare il DNS rispetto al SPOF attualmente in NinuCS è da fare.
> Possiamo farlo per gradi:
> - altri DNS anycast in giro per la rete
> - meccanismo di rimozione da HNA quando si perde la possibilità di fare forwarding
> - zone-delegation ai dnsmasq di NinucsWrt
> - estensioni sicure come DNSSEC o DNSCrypt.
> - quanto sopra ci da il tempo di analizzare pregi e difetti delle soluzioni distribuite partendo da una base operativa.
>
> Vi passo un paio di link che ho accumulato nel tempo (KadNode ultima aggiunta).
>
> NameCoin <http://namecoin.info/>- Open source decentralized key/value registration and transfer system
> DotP2P <http://dotp2p.io>- Open Source decentralized blockchain domain name system
> KadNode <https://github.com/mwarning/KadNode>- DynDNSusing DHT
> DNSCrypt <http://dnscrypt.org/>
> gitzone <https://github.com/dyne/gitzone>- Administering DNSzones using git
> nsupdate.info <https://github.com/nsupdate-info/nsupdate.info>- FOSS DynDNS
> OLSRD namservice plugin
> Decentralized DNS Overview <https://wiki.projectmeshnet.org/DNS>@ meshwiki
>
>
>> come dominio usiamo .nnx ?
>
> No, in Calabria usiamo
> * .cs
> * .cal
> * .calabria
> * .ninux
>
> Non usiamo .nnx perché, in previsione di un collegamento con altre isole, ci sarebbe un conflitto tra root server.
> A Cosenza, per adesso, solo .cs.


Zio proto mi ha messo in contatto con moritz che è l'autore e abbiamo
fatto alcuni tests che l'hanno portato ad alcuni commits.

Personalmente non lo trovo prestante e non mi sta stupendo sebbene
l'autenticazione con chiave rsa è possibile ma non è fortissimo sul
piano security. Ho fatto le immagini che ha usato anche moritz,
abbiamo parlato un pò delle prestazioni che sono un tantino deludenti,
sul pnp siamo in forse.

Secondo me quello che ci serve è semplicemente olsrd 0.7.4 o maggiore,
perchè in questa versione grazie al plugin nameservice possiamo
annunciare hostnames. Alla stessa maniera possiamo usare il dnsmasq
affinchè adoperi l'export del file hosts di olsrd nameservice ( così
come testato con spax ).

Gli autori di olsrd sono stati disponibili e mi hanno detto che la ver
0.6.x non garantisce funzionamento ( infatti nada ) e sto aspettando
10 minuti di tregua per compilare olsrd 0.7 su openWRT.

per me olsrd nameservice al momento è il non plus ultra, sebbene gli
hosts che desideriamo risolvere in rete richiedano una configurazione
costante.

kadnode testato col peerfile è ancora più lento