On 17 June 1996, I wrote the following message, detailing the basic
mechanics of a system that would permit a realistically swift resolution of
DNS name requests, allow the load to be spread across several servers and
suppliers, and that was not dependent on a centralised server/service.

Just for amusement, I present it again in the current context. All I would
add is that email is just an obvious and extremely easy "transport layer",
but there are clearly plenty of alternatives.

   --- cut here ---
Here's a radical thought (well, maybe. Maybe it's crap.):

A set of servers are set up by interested parties. Each server consists of:
 - one web server and software able to receive a DNS proposal
 - suitable mail processing filters
 - a person (or people) deemed responsible and able to administer domain policy

People wanting a domain name can submit a proposal to any of these servers
(the "receiving server"); the receiving server RANDOMLY selects a server,
possibly itself, from those it knows about and forwards the request. This
step ensures a reasonably even distribution of the load and prevents any one
server gaining too much "power", although there might be something to the
idea of weighting the selection towards those servers with more capacity
(human or CPU).

The selected server is now the "primary server", first among equals. It
immediately emails an ACK to the receiving server. If the receiving server
doesn't get the ACK within an hour or so, it selects another primary server
and the process starts over. I know there's the potential for a race
condition here, but we can work that out :-)

The primary server performs whatever automatic checks can be performed and
automatically handles all the obvious rejections, returning the reasons to
the proposer and discarding the proposal.

If a proposal survives the automatic checks it is emailed to the primary
server owner, who can do one of five things:
 1 ignore it. It will be emailed to all other server owners 24 hours later.
 2 refuse it. It will be emailed to all other server owners immediately.
 3 accept it. Automatic inclusion into the DNS follows. Other owners advised.
 4 reject it. Email sent to the proposer with reasons. Other owners advised.
 5 demand a vote of the other server owners. Proposer emailed, advising delay.

In case 1 or 2, any server owner can do nothing, or respond with any of the
last three options, except that responses are "sat on" for 24 hours (the
"response period") in case a rejection or call for votes arrives from
another server owner. If acceptances AND rejections are received, or if any
server owner calls for a vote, option 5 is automatically and immediately
invoked and the first voting period begins.

To vote, server owners simply email their vote, yea or nay, to the primary
server. The mechanics of this need to be worked out, but an automated vote
should be moderately simple to arrange - it seems to me that a majority of
received votes should be all that's needed to accept a proposal. 

Rejections and acceptances received during the initial response period count
as a vote during the first voting period unless overridden by another vote
from the same source, so server owners who responded within the response
period don't have to waste time repeating themselves.

In the event of a tie, the vote (if any) of the primary server owner is
automatically duplicated to resolve the issue. If the primary server owner
has not voted and a tie exists after 24 hours, or if NO votes are received
within 24 hours of the call for votes, all server owners are reminded by
email and a second 24 hour voting period begins. Votes (if any) from the
response period and first voting period are again carried forward.

If the second voting period also elapses with no acceptance or rejection,
the proposal is accepted automatically, as clearly no server owners care one
way or the other. If the second voting period is a tie, the proposal is
rejected.

Maximum time to resolution of a proposal - 4 days. No individual machine is
necessary for this arrangement to work.

Some notes on this lot: Firstly, a lot of the grunt work has already been
done via the automation that (for example) kre's scripts impose. Much of the
policy has already been written.

Secondly, there is no doubt that this relies on a bunch of people
consistently applying policy and doing so with good will. The idea behind
advising all server owners of rejection reasons is that application of
policy will be reinforced and shared, to prevent too much divergence. The
ability to demand a vote will also help "train" new server owners :-) The
random selection business reduces the impact of different approaches. In the
end, there still has to be a root site for each domain - the root site can
simply refuse change requests from un-anointed servers, so the peers in this
arrangement can always oust a maverick server owner by conferring with the
administrator of the root machine.

Security is an obvious issue - PGP springs to mind as a possible solution.
Also, there will always be exceptions that can't be sorted out via the
above. In that case, the server owners get together and thrash out a
decision. Such occasions will be rare.

All this is off the top of my head. Re-reading it, it looks a bit clumsy,
but it does seem to have the advantage of allowing the load to be shared
between two or three peers or spread thinly amongst many volunteers, though
I guess there's a point of diminishing returns. It also means that the
system doesn't depend on one person or machine for processing and it makes
sure that proposals don't get lost.

Most importantly, it can be built on the skills and experience of existing
volunteers!

What it does NOT do is address the legal issues that have been raised. There
is no reason why joining this happy band of volunteeers could not be
accompanied by appropriate legal activity, however.

The above assumes that server owners can decide reasonably swiftly whether
to accept or reject a proposal. If ACNs must be traced or other
time-consuming external checks performed, the above timings will need
adjusting. Such checks are about the only good reason I can see for
centralising the process.

   --- end cut ---

Regards, K.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer: kauer§pcug.org.au                    +61-6-2494627 (bh)
           http://www.pcug.org.au/~kauer/       +61-6-2486607 (ah)

Join the Internet Society of Australia! http://www.isoc-au.org.au