-> Publish & Subscribe
by Simon Higgs
-> Re: yet more unworkable distributed design
by Michael Dillon
----------------------------------------------------------------------
Date: 21 Aug 1996 07:47:47 -0700
From: perry@piermont.com
Subject: Re: New Non-Shared TLD's Create More Monopolies
Kent Crispin writes:
> > > Nope. I'm suggesting a perl script that runs rwhois, gets the data,
> > > and inserts all of it into a local whois database.
> >
> > Yuck!
>
> You could write it in C++, or perhaps have a CGI interface, if you
> like :-)
The "Yuck!" is because this isn't a robust way to run a database
management system.
Maybe you haven't built systems designed to deal with large numbers of
transactions and work reliably, but those of us who have know that its
fine to hack something together with chewing gum and scotch tape when
you aren't operating on a large scale, but once things get big you are
setting yourself up to have your throat cut from ear to ear.
> > > "Distributed" to me implies "distributed responsibility".
> >
> > You cannot distribute the responsibility to apply the first-come
> > first-served rule.
>
> Of course you can.
Kent, I hate ad hominems. I really do. However, we are starting to
talk technical turkey here.
How many real world transaction systems where significant money was on
the line have you built? Because it sounds to me like the answer is
"none". I built my first accounting system on contract when I was
sixteen, more than a few years ago. I really hate centralized
relational databases. They are ugly things and they are generally
designed by chinese waves of drool bucket brigade members. However,
there are times when the things are indispensable. You cannot build a
real world interactive transaction system without one. I understand
that you have political goals here, and I share them, but there is one
thing you are going to have to get straight: there is no amount of
klugery that is going to make a seventy way commit written in Perl
work, period, and there is no system which is going to operate
properly where you try to reconcile things at the end of the day
because conflicts burn money and cause lawsuits. Everyone else here
seems to have accepted the inevitable -- a small central database. It
doesn't have to be large, it doesn't have to be complicated, and it
can be viewed as a service provider hired on behalf of all the
registries by the International Association of Internet Registries if
you like, but it is going to have to be there.
Quit with the dreams of ten minutes worth of Perl now, because that
isn't going to cut any of it. Maybe a fine front end will be built in
SybPerl with Tk or some such, but the back end of this baby isn't
going to be a bunch of flat files passed around over TCP connections
by Perl scripts. If it is, I bail out, because the InterNIC is better
for the world than that would be.
> > What is this monopolistic abuse problem?
>
> Hypothetical: IANA is charged with running the CDB. 5 years from
> now a contract is let to a company, Network Savants, Inc., to manage
> the CDB. NSI (no relation to the current NSI) decides that a
> subsidiary will go into the registry business...
Big deal. If the CDB is run under a contract that specifies fees, they
can't raise them except as specified. If it is run under a contract
that specifies that the CDB organization can't run a registry, it
can't. If the contract says "thou shalt do nothing with the data other
than hand it daily to the root servers and the whois servers", well,
thats legally binding.
> [argument deleted]
>
> I thought through this stuff a while back in my initial half-baked
> suggestions for a voting protocol with unforgable timestamps. I
> agree that it is simpler to have a centralized interlock mechanism.
> I don't agree that it is the only system that will work -- there are
> tradeoffs, that's all.
Kent, if you can build a functioning 70 way commit mechanism that
actually works in the field over the internet, you'll get a PhD and an
endowed chair in database systems at a computer science department
somewhere within weeks. Its too hard a problem for anyone I know of to
build, but I certainly won't say you shouldn't work on it. However,
are we trying to do way past bleeding edge CS research, or are we
trying to build a functioning registry system?
Perry
----------------------------------------------------------------------
Date: 21 Aug 1996 08:08:02 -0700
From: "Richard J. Sexton"
Subject: Re: yet more unworkable distributed design, was New Non-Shared TLD's Create More Monopolies
>Can we get back to sketching out the CDB protocol now, please?
Yes, and with some sort of authorization scheme so authorized agents
can make changes to it.
Changes should be able to be made, byt the right people, damn quickly.
----------------------------------------------------------------------
Date: 21 Aug 1996 08:36:01 -0700
From: perry@piermont.com
Subject: Re: New Non-Shared TLD's Create More Monopolies
Kent Crispin writes:
> > Thats what public keys are for. If you involve humans,
>
> It is a human who makes the decision to change registries. That
> human contacts the registries involved, and says (via email or over
> the phone, or via a certified letter, or whatever normal business
> practice is) "I want to change".
I think you miss the point.
A public key should be associated with each domain. Then, when you
want to change, you hand a PK signed statement to the new
registry. That way, YOU control the domain, not the registry.
Helps from a liability standpoint, too.
> Interesting comments, but they just don't address the same issue I
> was. I have a domain name registered with registry A. Registry A and
> I get into a dispute, so I want to move my registration to B. Those
> bastards at A constantly screw up my data (that's why I want to
> change). The CDB can have the fanciest authenticated DB protocol
> imaginable, but it simply doesn't matter. The transfer of business
> relationship is between the registries and the customer. This is a
> human transaction that you simply aren't going to automate.
Since public key is used to talk to the CDB, no humans are needed at
the CDB. I'm afraid you have a lack of imagination about what is
possible here.
> Furthermore, if the registries are the authoritative sources for the
> contact information,
I don't understand this "authoritative" buisness. Perhaps you could
explain it to me. If the data is required to be identical at the CDB
and elsewhere, what does "authoritative" mean?
> > The only 'authoritative' information is the information sitting in the
> > DNS, since its the only stuff that matters in the last analysis. You
> > can call anyone's copy of the database 'authoritative' for laughs, but
> > that doesn't matter -- what matters is what gets cut to produce DNS
> > entries.
>
> I'm pretty sure you actually know what authoritative means, but to
> humor you: the authoritative copy of a database is the one whose
> information is considered correct, if there is a discrepancy.
Billing and contact information is used by the registry, not by the
CDB, so that ends up being a matter of registry policy, not a matter
of system design.
HOWEVER, it is likely important that up to date and accurate
information be kept at the CDB in case of a registry vanishing, or in
case the CDB needs to contact the users of a failed registry (to
inform them that they have to switch), to cut the whois database, and
for other similar reasons.
> You argue that it should also be kept at the CDB; I argue that it
> shouldn't,
Why the hell not?
> and that *if* it is, the data at the CDB is just a good-faith copy
> -- the data at A is the master.
"Master" is a matter of opinion. So long as its required to be kept up
to date, I don't care what you call the "master". Call the copy kept
on CP/M formatted 8 inch floppies the "master" for all I care.
> Now, your comment that "authoritative" is really meaningless in the
> context of whois data is quite interesting. I suppose you mean that a
> registry could, for example, put whatever information for contact
> information it wanted in the CDB, and just keep its private records
> for billing purposes.
No. I'm arguing that "authoritative" is meaningless. "Authoritative"
means something in the context of, for instance, DNS records, because
some servers are guaranteed to have the freshest data, and others just
have cache. However, in this context, the data at the CDB should be
kept accurate. Whether the registry keeps a second database, a
different database, or anything else is of no concern. The only
requirement is that the data at the CDB be *accurate*, in case it is
needed.
> I was referring to the fact that the contract (cooperative agreement)
> expires soon, and we would like it to be changed. That is, *contracts
> can change*. We view the possible change in this case in a positive
> light, but contracts can change for the worse, as well.
Contracts can last a long time.
The contract that established the franchise of the Empire City Subway
Company to run all the wiring ducts under New York City was signed in
1883. It is still in force, unchanged, after all these years, even
with the original city organization that signed the contract no longer
in existance. There is no rule that says contracts cannot last 150
years if need be.
> We as technical weenies are really incompetent in the legal arena.
Speak for yourself. I'm not a lawyer, but the elements of contract law
are really easy.
> > Nope, it isn't. Something fucks up your primary DNS entries, you need
> > it fixed NOW. The InterNIC already takes too long on this.
>
> 1) Failure of your primary DNS doesn't constitute a Net Catastrophe.
> 2) Emergency cases are exceptional -- "turnaround time of a week"
> refers, I think fairly obviously, to the average case.
There will be several hundred disasters a day to deal with. The
mechanisms for dealing with them must be smooth and cheap, or they
will drown out all other costs.
What costs money in any situation like this are the exception
cases. That which happens only to one person in 100 happens damn often
when you are running 10,000 new registrations a week.
> > No. You need something to cut the masters that generate the DNS. You
> > also want a central database containing authorization information on
> > who can and can't switch a zone from one registry to another.
>
> OK. That's a record like this
> - the domain nae
> - who can switch a zone, and the location
> of the whois data.
> - for updating DNS
> - for reservations
>
> No other information is necessary.
Sorry, but you need all the information a new registry would require,
and authentication data like public keys. If a registry is destroyed
in a freak accident with all its personel, you need ALL the data the
registry would have had about who owns what.
Perry
----------------------------------------------------------------------
Date: 21 Aug 1996 09:37:27 -0700
From: perry@piermont.com
Subject: Re: yet more unworkable distributed design, was New Non-Shared TLD's Create More Monopolies
"Richard J. Sexton" writes:
> >Can we get back to sketching out the CDB protocol now, please?
>
> Yes, and with some sort of authorization scheme so authorized agents
> can make changes to it.
>
> Changes should be able to be made, byt the right people, damn quickly.
Agreed.
I would suggest that a public/private key pair be associated with each
registry, and with each domain. The holder of the domain key would be
able to do exactly one thing -- sign a request which could be
countersigned by a filing registry requesting that a domain be
switched to that registry. The registry keys would be used for all
other requests, but would only have the ability to modify data
associated with that registry.
An interesting question arises for WHOIS style data, specifically old
style NIC handles. Since a given handle might involve domains for
several registries, the question of who gets to update the handle
information gets hard. Perhaps we should abandon the old style NIC
handles -- thoughts?
Perry
----------------------------------------------------------------------
Date: 21 Aug 1996 09:58:05 -0700
From: Kent Crispin
Subject: Re: New Non-Shared TLD's Create More Monopolies
Perry E. Metzger allegedly said:
> The "Yuck!" is because this isn't a robust way to run a database
> management system.
>
> Maybe you haven't built systems designed to deal with large numbers of
> transactions and work reliably, but those of us who have know that its
> fine to hack something together with chewing gum and scotch tape when
> you aren't operating on a large scale, but once things get big you are
> setting yourself up to have your throat cut from ear to ear.
Hmm. Quite graphic. But you're right, transaction systems are not my
area of expertise.
> > > > "Distributed" to me implies "distributed responsibility".
> > >
> > > You cannot distribute the responsibility to apply the first-come
> > > first-served rule.
> >
> > Of course you can.
>
> Kent, I hate ad hominems. I really do. However, we are starting to
> talk technical turkey here.
Which ad hominem were your referring to? :-)
I know that the obvious algorithms aren't practical for the
application we have in mind. But what Michael said was clearly
false, and I couldn't resist the bait. Sorry.
> How many real world transaction systems where significant money was on
> the line have you built? Because it sounds to me like the answer is
> "none". I built my first accounting system on contract when I was
> sixteen, more than a few years ago. I really hate centralized
> relational databases. They are ugly things and they are generally
> designed by chinese waves of drool bucket brigade members.
[snip]
> Everyone else here
> seems to have accepted the inevitable -- a small central database.
> It doesn't have to be large, it doesn't have to be complicated, and it
> can be viewed as a service provider hired on behalf of all the
> registries by the International Association of Internet Registries if
> you like, but it is going to have to be there.
Even I agreed to that -- as far as I know, what we are discussing is
what "small" means in "small central database". I agree that one is
necessary (in a practical sense) for coordination, at least initially
(I hedge that, because some of the proposed changes to DNS could
actually make it possible to use DNS for coordination purposes). The
question is what else goes in there. You believe the whois data needs
to go there. At this point I don't, for several reasons:
1) I believe that making the database the central master for all whois
data is a much bigger deal than what you make of it. Rwhois is being
developed exactly to get away from a centralized whois database. Why
should we be taking a giant step backward?
2) The registries will have to keep a local database of all contact
information, for billing purposes. In fact, this data is the
authoritative data, not the data that may be at the CDB 10 days later
when the registry gets around to updating it.
3) It hinders the freedom of the registries to control access to the
information. For example, an "anonymous" registry could filter all
contacts through itself.
4) Having a centralized database with all contact information
aggregating data that doesn't need to be aggregated. This is a
privacy concern -- it is one thing to be able to find a particular
indivual contact -- it is quite another to know the name and address
of *every* network manager. Currently the InterNIC resists giving
out its entire database, but if there wasn't a centralized database
the issue wouldn't arise.
5) A general political concern about passing as much authority and
control to the registries as possible.
> Quit with the dreams of ten minutes worth of Perl now, because that
> isn't going to cut any of it.
[big snip]
Damn. I should never have used the "P" word. Really, Perry, don't
fixate on that. Consider "ten minutes worth of Perl" as a flowery way
of saying "easy to implemet".
- --
Kent Crispin "No reason to get excited",
kent@songbird.com,kc@llnl.gov the thief he kindly spoke...
PGP fingerprint: B6 04 CC 30 9E DE CD FE 6A 04 90 BB 26 77 4A 5E
----------------------------------------------------------------------
Date: 21 Aug 1996 11:01:31 -0700
From: perry@piermont.com
Subject: Re: New Non-Shared TLD's Create More Monopolies
Kent Crispin writes:
> 3) It hinders the freedom of the registries to control access to the
> information. For example, an "anonymous" registry could filter all
> contacts through itself.
If you want anonymity, operate your zone through a nominee. I run a
couple of zones for offshore hedge funds -- it would be quite a
challenge to find out who the owners are from the contact info (which
is me or an employee and P.O. Boxes in places like the Bahamas.)
We don't need anonymity via registries, and the mechanism you propose
would be a hinderance.
> 4) Having a centralized database with all contact information
> aggregating data that doesn't need to be aggregated. This is a
> privacy concern -- it is one thing to be able to find a particular
> indivual contact -- it is quite another to know the name and address
> of *every* network manager.
You'll have to live with this sort of thing. If any of the data is
public, it *will* all be collected, eventually. If you need privacy,
as I said, you can get it.
> 5) A general political concern about passing as much authority and
> control to the registries as possible.
I don't see how managing a database gives the CDB power, especially
when it is legally constrained. I mean, how much political power does
the vital records office in your county have? I'd suspect that the
answer is "none". You only get power when you have the power to
control. The CDB doesn't CONTROL the information, it just STORES
it. There is a world of difference. The CDB has *no discretion*.
Perry
----------------------------------------------------------------------
Date: 21 Aug 1996 12:34:32 -0700
From: Michael Dillon
Subject: Re: New Non-Shared TLD's Create More Monopolies
On Wed, 21 Aug 1996, Perry E. Metzger wrote:
> Contracts can last a long time.
So can companies or organizations. Both the Hudson's Bay Company here in
Canada and the Kikkoman Shoyu Company in Japan were formed in the 1600's.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
----------------------------------------------------------------------
Date: 21 Aug 1996 12:42:01 -0700
From: nreadwin@london.micrognosis.com (Neil Readwin)
Subject: Re: yet more unworkable distributed design, was New Non-Shared TLD's Create More Monopolies
Perry E. Metzger writes:
> I would suggest that a public/private key pair be associated with each
> registry, and with each domain.
This sounds nice, but I am not convinced it would work well in
practice. If people can use their ISP as a registry then many of them
will and they will only need their private key when they change ISPs.
We (Micrognosis) do that every few years, which would give us plenty of
time to lose the key.
I suspect we would need a simple operational procedure for bypassing
the strong authentication :-(
> Since a given handle might involve domains for several registries
The handle identifies a person. Several registries may use that handle
to identify a contact for domains that they are responsible for, but
the handle does not point back to them. There is no information pointed
at by the handle that a domain registry should be able to update.
If that is right then a handle could be treated like a domain - you
have a personal key pair and can sign a request to make a new registry
responsible for changes to your handle. Neil.
- --
"So you could say the greatest achievement of the Internet is that it turns
nuclear war into nothing more than a series of routing errors." -- Mark Pesce
----------------------------------------------------------------------
Date: 21 Aug 1996 12:49:31 -0700
From: Michael Dillon
Subject: Re: yet more unworkable distributed design, was New Non-Shared TLD's Create More Monopolies
On Wed, 21 Aug 1996, Perry E. Metzger wrote:
> An interesting question arises for WHOIS style data, specifically old
> style NIC handles. Since a given handle might involve domains for
> several registries, the question of who gets to update the handle
> information gets hard. Perhaps we should abandon the old style NIC
> handles -- thoughts?
The actual domain owner must be authoritative in any changes to their
domain information. Somehow we have to make it easy for the domain owner
to pass that authority on to the registry in any given transaction. Maybe
this will work.
1. Domain owner asks registry to change something
2. Registry issues change transaction to CDB
3. CDB emails domain owner with special key data similar to First Virtual
4. Domain owner replies to CDB including key data to authorize transaction
or
4. Domain owner replies to CDB including key data refusing transaction
or
4. CDB times out transaction and tells registry that no authorization was
received. Registry then has option to renew the transaction with the
same key data if domain owner is just lazy or confused. Yes this can
be time consuming for the registry but that's what they are being
paid for, i.e. servicing the customer.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
----------------------------------------------------------------------
Date: 21 Aug 1996 13:47:18 -0700
From: johnl@iecc.com (John R Levine)
Subject: Re: yet more unworkable distributed design, was New Non-Shared TLD's Create More Monopolies
>> And, of course, it's inconceivable that any registry would ever backdate a
>> registration for a valued customer, even though there's no way anyone outside
>> the registry could ever tell. Naah. It would be wrong.
>
>1) Backdating couldn't happen with the protocols I described -- that
>should be obvious if you think about them for two minutes. The
>timestamp really is unforgable.
Even if the timestamps are impossible to forge, it seems to me that you
could easily use a replay attack. Just use a genuine time stamp from an
hour ago or a day ago or a week ago or, for that matter, a month ago.
("Darn that uucp, kept getting busy signals.")
>2) There is another, similar, method of cheating that no protocol yet
>described, centralized or not, can protect against. That's the
>problem of pre-allocating a name. Nothing we have described prevents
>a registry from assigning 5000 desirable names, setting up
>nameservers for them, and reselling them later.
That's true, and indeed the analogous problem has been a chronic problem in
the 800 arena. I believe that there's a rule in the 800 biz that if you
can't identify a customer who's using a number and you've had it reserved
for more than a few days, you have to give it back. I hope a similar rule
could keep the abuse down.
You also have the problem of registry customers hoarding names, e.g. P&G's
diarrhea.com and the names for sale by some domain name brokers. I don't
see any way to solve that, but I also don't see that whether a domain is
shared or not makes any difference to this problem.
- --
John R. Levine, IECC, POB 640 Trumansburg NY 14886 +1 607 387 6869
johnl@iecc.com "Space aliens are stealing American jobs." - Stanford econ prof
----------------------------------------------------------------------
