RE: Something better than DNS?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: Patrick Vande Walle [mailto:patrick@xxxxxxxxxxxxxx] 

> From
> http://www.cs.cornell.edu/people/egs/beehive/codons-sigcomm04/
node15.html
> 
> "CoDoNS enables multiple namespace operators to manage the 
> same part of the name hierarchy [...] Ideally, competing 
> operators would preserve a single consistent namespace by 
> issuing names out of a common, shared pool. In the presence 
> of conflicting or inconsistent records, clients simply pick 
> the records signed by an operator they trust, similar to the 
> way they pick between separate sets of root servers today. 
> Essentially, nameowners have the ability to choose the 
> namespace operator that will endorse their records based on 
> price, service and functionality."

Beware academic speculation, it has a tendency to obsess on the exact wrong thing.

For years extreemly intellignt people that many of us know quite well worked away on cryptographic voting protocols that are designed to provide perfect secrecy. The realization that auditability was the central criteria in a voting system only came in the fall of 2000. 

[That is not to say that commerce does not have similar issues but the falure modes are different.]


The issue for DNS users is that core DNS has to be there with at least five nines reliability. No part of the Internet can exceed the reliability of core DNS, if core DNS is down everything is.

Without reading the paper the abstract alone gives the game away 'issuing names out of a common pool'. Who manages the central pool? What we end up with here is nothing more than a recapitulation of the current situation except that the registry function has been distributed across the registrars.

I don't think that you will find many registrars that actually want to be in the capital intensive business of operating  a registry, or a registry that wants to be in the customer support intensive business of operating a retail registrar.

Even if you did the cost of achieving current levels of reliability would be considerably higher.

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]