[dns-operations] Blockchains, shared management, and zone CRUD (was NeoDNS : A new DNS like the one we know)

[Shane Kerr]

David,

At 2016-08-29 11:08:58 -0700
David Conrad <drc at virtualized.org> wrote:

> > In the case of the root, I do see a big benefit, if you consider=C2=A0
> > getting rid of ICANN's role in maintaining the root zone a benefit.=C2=A0=  
> 
> 
> I'm curious: how does waving the magic =22blockchain=22 wand around addre=
> ss two non-cooperating entities wanting the same name in a =22fair=22 man=
> ner=3F

I haven't thought too deeply about this, but I have given it some
consideration. Just to be clear, I don't actually think that it is
possible that any of the domains that might use algorithms to manage
the zones will actually do it, so it's just a fun (for me) thought
experiment.

Blockchains & shared management
-------------------------------
I was exposed to the blockchain idea from Bitcoin, like I guess a lot
of people. When applying the idea of a blockchain to names, I think we
need to be able to jettison some of the baggage that comes from that
particular experiment. We're not Libertarians trying to free ourselves
from the shackles of an evil oppressive monetary system captured by
fundamentally corrupt and flawed governments. (Well... at least I'm
not.) :)

When thinking about how a blockchain might be used in the DNS, I tend
to think that it should only be be applied to management within a given
domain. The current delegation mechanism model is fine, and any given
zone can use whatever way it wants to update itself.

Probably we really don't care too much about blockchains, but more
about the idea of shared management of a zone, instead of centralized
management of a zone. Blockchains are a way of enabling this, but not
the only way of course.

Shared CRUD
------------
Within a domain, we have the basic database Create, Read, Update, and
Delete operations, a.k.a. CRUD. We need an algorithm to implement each
of these in a shared system.

Read: Actually we don't really need to worry about Read, since we
assume that the DNS protocol itself is used to read the zone data.

Update: In the simplest case an Update can be updated by keeping the
public key that "owns" a domain name in the blockchain, and then the
holder of the private key can make changes to it. There will be details
will need to be agreed on, such as what limits (if any) there are on
TTL for the RRset of the name and so on. Also there should probably be
some way of recovery, in case the private key is lost (thanks to
Stephane Bortzmeyer for pointing this requirement out over lunch or
beer at some point). For example, one could agree that authorization by
X% of the other private keys could allow a new public key to be added
to a domain name. There may also be additional authorization required
in some cases, or other ways to override authorization.

Delete: This could be authorized exactly the same as Update (perhaps
one of the cases where additional authorization was desired, such as
confirming the action after N hours). For garbage collection purposes,
you probably want names to auto-Delete if the holder of the owner does
not confirm periodically.

Create: This is of course the tricky operation. :) However, I don't
think it is as intractable as implied. The exact details will depend on
the particular zone, but lets consider two cases: root and COM.

In the case of the root zone, one could imagine a few possible
approaches. My assumption is that we have holders of existing domains,
and that they all continue to get some say in what new names are added.

One approach would be that each current domain holder would be given
the right to create a certain amount of zones per period of time -
perhaps one per year. This would create an exponentially growing number
of zones in the root, although one could do something to limit that.
The order of selection could be picked randomly (which is itself a fun
problem, but merely hard not impossible).

Alternately one could have all of the current domain holders agree
every period of time (year, week, whatever) to create Y domains and
then do a lottery to assign them. Each domain holder could get a number
of tickets and use them itself or give or sell them.

If you wanted to preserve some of the special features of the naming
system you could give the ISO authority for ccTLD creation & removal,
and require NTIA authorization at least until November. ;) Any
stakeholder could be given some sort of authorization for new zone
creation, really.

In the case of COM you really just want a way to make it expensive for
domain holders... but not *too* expensive. Money kind of works today,
but not perfectly - otherwise domain squatting would not be a thing.
This is actually something that Bitcoin deals with - although as a
sort-of environmentalist I really don't like the idea of trading CPU
cycles for domains. But one could imagine designing a system where you
traded something like DNS query capacity for domains (this might have
the nice benefit of making it directly beneficial for domainers to
invest in the DNS infrastructure... but of course there are likely
negative unintended consequences). A lottery system might work too.

No Next Steps
-------------
I don't really think there is much point in pursuing this sort of
technology, although it might be fun just to play with.

Cheers,

--
Shane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160830/5f382c7f/attachment.sig>