On Wed, 28 Aug 2013 10:43:24 -0400 Jerry Leichter <leich...@lrw.com> wrote: > On Aug 28, 2013, at 8:34 AM, Perry E. Metzger wrote: > > > On Tue, 27 Aug 2013 23:39:51 -0400 Jerry Leichter > > <leich...@lrw.com> wrote: > >> It's not as if this isn't a design we have that we know works: > >> DNS. > Read what I said: There's a *design* that works. > > I never suggested *using DNS* - either its current physical > instantiation, or even necessarily the raw code. In fact, I > pointed out some of the very problems you mention. > > What defines the DNS model - and is in contrast to the DHT model - > is: > > - Two basic classes of participants, those that track potentially > large amounts of data and respond to queries and those that simply > cache for local use; > - Caching of responses for authoritative-holder-limited amounts of > time to avoid re-querying; > - A hierarchical namespace and a corresponding hierarchy of caches. > > DNS and DNSSEC as implemented assume a single hierarchy, and they > map the hierarchy to authority. These features are undesirable and > should be avoided.
I'm unsure how to use a DNS-like model when there is no real linkage between hierarchy in the names used and the storage location of particular mappings. In particular, if I have names like f...@example.com, and I want just anyone to be able to enroll at any time without administrator input, and I don't want state authorities to be able to shut down or alter the contents of the system, I don't see how to accomplish all my goals with something DNS-like. That said, if you have a concrete proposal, I would of course find it interesting to hear about. -- Perry E. Metzger pe...@piermont.com _______________________________________________ The cryptography mailing list firstname.lastname@example.org http://www.metzdowd.com/mailman/listinfo/cryptography