[Top] [All Lists]

Re: new DNS classes

2017-07-07 13:28:03
You need a better imagination then.   mDNS is a crippled DNS implementation
that was hobbled on purpose.   HS was/is an entirely different addressing
scheme that emerged from project Athena @ MIT.  To the extent that when all
you have been given is the IN class and it's associated rooted hierarchy,
you first,second,&third inclination is to treat EVERYTHING as being easily
integrated into that model.  And the ietf is going to go right along with
you.   After all, when all you have is a hammer, everything looks like a

On Saturday, July 8, 2017, Nico Williams <nico(_at_)cryptonector(_dot_)com> 

On Fri, Jul 07, 2017 at 03:32:21PM +0200, David Cake wrote:
On 5 Jul 2017, at 10:47 am, Randy Bush <randy(_at_)psg(_dot_)com 

i think avoiding icann is a red herring.  if the draft in question had
done a decent job of exploring the taxa of needs for name resolution
outside of the 'normal' topology, we would have the start of a base on
which to discuss this.

If you have a single centralised root for your new class, you will
probably either recreate the problems of ICANN, or create one or more
of the problems that ICANN has very consciously tried to avoid.  If
you have a system of name resolution that avoids the need for a
centralised root, you probably don’t need a new class to implement it.
The few marginal cases that need to interact with the one root but not
be ICANN controlled are why we have the RFC 6761 process.

I agree a taxa of needs that do not fit within those three cases would
have been useful.

Well, there's a) the rooted hierarchy of the public DNS (IN class),
b) mDNS (which isn't really DNS, just a local discovery mechanism based
on the DNS protocol), c) the HS class, which traditionally wasn't used
in a federated manner (but maybe I'm wrong about that), so it doesn't
need a rooted hierarchy, though it also could use one.  (b) and (c) are
niches, with no real place on the open, public Internet.

One could use something like HS as an alternative to LDAP, say, but
recall that the vision of a world of federated and open directories
never materialized NOT because of limitations of DAP/LDAP, but because
of confidentiality/ privacy considerations.  Such a class would really
need to use the same rooted hierarchy, and, really, the same root, as
the public DNS IN class -- i.e., an IN RR type namespace extension
class, so it's best to consider such a class in those terms rather than
as a "directory class".

I am having a very difficult time imagining, say, a peer-to-peer or
web-of-trust DNS (other than mDNS).  Perhaps my imagination fails me.

A rooted hierarchy is and has been incredibly useful, and the simplest
method of providing a consisten Internet to all users.  It seems to me
very unlikely that we'll ever move from that.  At most we may have
alternative roots, but a mostly common set of TLDs (e.g., as happens in
many private (corporate) networks).


DNSOP mailing list
DNSOP(_at_)ietf(_dot_)org <javascript:;>

<Prev in Thread] Current Thread [Next in Thread>