> > also becomes the authoritative repository for all the contact > > information I begin to worry. > > I don't understand this worry. It doesn't prevent you from storing the > data elsewhere, nor does it give the central DB any advantage if it is > under a contractual obligation about what it can and can't do. > > The central DB is NOT some mammoth organization. Its maybe Bill > Manning's summer intern and a couple of donated machines sitting in a > couple of machine rooms across the country from each other. Relax. In 15 days I will be drifting down the Colorado River with gorgeous multicolored sandstone cliffs rising on either side, leaving civilization at about 4 knots (the average current speed). All this stuff will be far, far away. Anticipation is occupying about half my brain. Believe me, Perry, I am not experiencing a great deal of tension. :-) - -- 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: 20 Aug 1996 12:34:09 -0700 From: Kent Crispin Subject: Re: New Non-Shared TLD's Create More Monopolies Perry E. Metzger allegedly said: General comment: in what follows you persistently interpreted my comments to mean something different than I intended. I will try to be clearer in the future. > Kent Crispin writes: [snip] > > The only time this kind of interface would be used is when a user > > changes registries. That is going to involve a certain amount of > > human interaction and checking no matter what -- you wouldn't want > > me calling up your registry and switching your domain to a registry > > in Timbuktu. > > 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". Sometime in the future you may be able to assume that anyone you do business has a public key, but that day is not now, and it won't be universal for many years. > the process > will be *less* reliable, especially if the way you get contact > information is over unauthenticated "whois" queries augmented by perl > scripts. I don't want any humans involved in the central DB at all, if > possible. The CDB gets called when one of the registries notices that > there is a technical problem, or when someone wants to become a > registry. Humans cost money, introduce error, and make you a better > target for lawsuits. 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. Furthermore, if the registries are the authoritative sources for the contact information, the only change the CDB sees is a change in the registry id associated with the name. We haven't addressed the details of how to authenticate such a transfer -- it is not a big deal, I'm sure. > > Most important is the distribution of the *authority* for the data. > > The registries should have (IMHO) the authoritative data for their > > customers. The distributed character of the data follows from this > > principle. > > 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. For example: Suppose Mr Xmith gets domain x.com, through registry A. Mr Xmith is administrative, technical, and billing contact, at a particular address. All this information is kept at A. You argue that it should also be kept at the CDB; I argue that it shouldn't, and that *if* it is, the data at the CDB is just a good-faith copy -- the data at A is the master. If the CDB says that it Mr Smith is the contact person, it is registry A's data that is correct, not the CDB - -- the name is Xmith, not Smith. 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. For example, every domain registered by Kent's Registry has "Bozo The Clown" as the contact in the CDB. If there is no requirement that a registry keep meaningful whois data at the CDB (a requirement backed, say, by a registry's license to be a registry for a particular TLD), then I guess I really don't care. > > Contracts can be developed that will avoid that, you're right. > > > > But then, contracts with whom? With the registries? With the IANA? > > Presumably both and more. > > > I can certainly see how contracts could be devised that would work > > for a while. But NSI has a contract with NFS, does it not? > > A cooperative agreement, and nothing in it forbids the current behavior. I wasn't referring to the current behavior. 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. We as technical weenies are really incompetent in the legal arena. We can pontificate about things we believe to be the case, but it's really all air. I, therefore, would rather build technical solutions that don't require a legal component to maintain a desired condition. > > People need DNS to be reliable, but it is designed to work very well > > with non instant updates. And the reliability constraints on > > registries are of a totally different magnitude. A turnaround time of > > a week is more than adequate. > > 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. Getting a domain name registered in a week is perfectly adequate for any reasonable business purpose. In fact, of course, any scheme we have discussed can do far better than this on average. But there isn't any business necessity driving it. > > > There is no reason not to have the CDB placed on a replicated database > > > system such that even if one of the cities with one of the CDB > > > machines was nuked the whole thing didn't continue just fine, but > > > there is good reason not to operate without a centralized database. > > > > Hmm. Your last clause means "there is good reason to operate a > > centralized database". The only good reason I've seen so far is to > > support a reservation protocol on names, > > 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. > Let me be blunt. Words fail me, Perry :-) > I wouldn't run a company DNS with 500 entries without > a real DBMS any longer. I certainly am not going to support some ad > hoc crap to run the global DNS. We want a real DBMS. Its cheap, its > efficient, and I don't see why we shouldn't take advantage of the > technology. It is very different to run a pair of machines sitting in > closets than it is to run an InterNIC. We aren't talking a big > operation. I will not, however, support running stuff with perl > scripts, masking tape and chewing gum, either. That takes more work, > not less, and its more dangerous, not less dangerous. OK. I really don't care that much about the technology. - -- 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: 20 Aug 1996 13:34:05 -0700 From: Kent Crispin Subject: Re: Centralized or decentralized Whois server ? Christian Huitema allegedly said: > > The whois service is very important -- how could we run any registration > service if we did not have a way to find out precisely who registered > what? > Thus, I certainly understand why we should make sure that the information > is available, and remains available even if one registry vanishes in a > puff of smoke. > > Archiving everything in one mammoth database is one way to solve the > problem. However, that solution has drawbacks. It creates a central focal > point, which is arguably suboptimal in terms of performances, reliability > and also distribution of control. However, there are alternatives, notably > if we were to promote the "whois++" solution. Its use of centroids enables > "navigation without hierarchy", so that requests will be automatically > directed to whatever server holds the information. > > Then, we would have to solve the puff of smoke problem. What about an > escrow database ? Perhaps run by the IANA? Sounds reasonable. > > -- > Christian Huitema > - -- 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: 20 Aug 1996 13:49:08 -0700 From: Kent Crispin Subject: Re: New Non-Shared TLD's Create More Monopolies John R Levine allegedly said: > [snip] > >Hmm. Your last clause means "there is good reason to operate a > >centralized database". The only good reason I've seen so far is to > >support a reservation protocol on names, and for that you only need > >the names. And even there, the "lazy propagation" character of DNS > >makes me think that locking methods using DNS itself might be sufficient. > > Sigh. You'd almost think there wasn't a long exchange of messages on this > topic only a week ago. The other reason to have a CDB is to force the data > to be syntactically correct and consistent. (It may not all be semantically > correct, but at least it'll be in one place so that corrections can be > applied.) The only alternative I've seen proposed is some sort of big daily > merge of all the registries' separate data, and I think at the time we agreed > that it was unlikely that you'd be able to merge several hundred or thousand > sets of data without running into some consistency errors, requiring in > effect some central authority to sort it out anyway. We are now, I think, talking about the whois data, and whether it should be maintained in a central database. From what I have read so far on the rwhois project, it is widely recognized that keeping that data centralized is in fact already too unwieldy. Apparently (I say apparently 'cuz I haven't had time to read all the RFC) rwhois is similar in structure to DNS -- a hierarchical distributed database. As in DNS, you *never* do a colossal merge of the entire database. As in DNS you depend on the individual sites to maintain their own database. After all, there isn't a central location that makes sure that all the DNS database files are syntactically correct, and DNS seems to work. - -- 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: 20 Aug 1996 18:31:27 -0700 From: Michael Dillon Subject: Re: New Non-Shared TLD's Create More Monopolies On Tue, 20 Aug 1996, Perry E. Metzger wrote: > > People need DNS to be reliable, but it is designed to work very well > > with non instant updates. And the reliability constraints on > > registries are of a totally different magnitude. A turnaround time of > > a week is more than adequate. > > Nope, it isn't. Something fucks up your primary DNS entries, you need > it fixed NOW. The InterNIC already takes too long on this. Does the DNS protocol support a primary server telling all its secondaries that a portion of a zone is incorrect and just correcting that portion? If so we could probably automate this whole corrections business. > Let me be blunt. I wouldn't run a company DNS with 500 entries without > a real DBMS any longer. I certainly am not going to support some ad > hoc crap to run the global DNS. We want a real DBMS. Its cheap, its > efficient, and I don't see why we shouldn't take advantage of the > technology. It also only needs to run one one single server if all iTLD's are shared and coordinated by the same central body like IANA. From the outside looking in it appears that the brunt of the Internic's problems are due to them not having installed a commercial database server to handle their core functions. It sure looks like they are trying to run it with perl scripts and chewing gum although I overheard one of them talking about certain information being in an MS Access database. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com ---------------------------------------------------------------------- Date: 20 Aug 1996 18:35:58 -0700 From: Michael Dillon Subject: Re: New Non-Shared TLD's Create More Monopolies On Tue, 20 Aug 1996, Kent Crispin wrote: > > And who says that it is moving to rwhois? > > One thing I know for sure is that Netscape and just about every other OS > > and Internet tools vendor is adding support for LDAP queries into their > > products so when that is available, LDAP will be far more standard than > > rwhois. > > See RFC1714. I believe you mean "more widespread", not "more standard". Yeah, widespread is more important than standard. > > Not that I have anything against rwhois, just that the writing is > > on the wall and we should encourage people to build a rational > > architecture that will work with the directory service that 95% of the > > Internet community will be using a year from now. > > Perhaps we should specify NT as the OS, as well? No way. NT is a niche OS that has the smallest installed base of any server OS in existence. Use the proper tool for the job which would be either a SUN Solaris box or a pentium running SCO Openserver 5 > > You cannot distribute the responsibility to apply the first-come > > first-served rule. > > Of course you can. No you can't! Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com ---------------------------------------------------------------------- Date: 20 Aug 1996 18:39:37 -0700 From: Michael Dillon Subject: Re: Centralized or decentralized Whois server ? On Tue, 20 Aug 1996, Christian Huitema wrote: > and also distribution of control. However, there are alternatives, notably > if we were to promote the "whois++" solution. Its use of centroids enables > "navigation without hierarchy", so that requests will be automatically > directed to whatever server holds the information. > > Then, we would have to solve the puff of smoke problem. What about an > escrow database ? What about a replicated copy of the central server database that resides on a separate machine and is used to serve public requests via FTP, LDAP, CGI, whois++, rwhois, whois, telnet, email, carrier pigeon, etc. Any interested party can just FTP a local copy of the whole darn thing periodically to run their own local queries. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com ---------------------------------------------------------------------- Date: 20 Aug 1996 20:00:08 -0700 From: Kent Crispin Subject: Re: New Non-Shared TLD's Create More Monopolies Michael Dillon allegedly said: > > On Tue, 20 Aug 1996, Kent Crispin wrote: > > > > And who says that it is moving to rwhois? > > > One thing I know for sure is that Netscape and just about every other OS > > > and Internet tools vendor is adding support for LDAP queries into their > > > products so when that is available, LDAP will be far more standard than > > > rwhois. > > > > See RFC1714. I believe you mean "more widespread", not "more standard". > > Yeah, widespread is more important than standard. > > > > Not that I have anything against rwhois, just that the writing is > > > on the wall and we should encourage people to build a rational > > > architecture that will work with the directory service that 95% of the > > > Internet community will be using a year from now. > > > > Perhaps we should specify NT as the OS, as well? > > No way. NT is a niche OS that has the smallest installed base of any > server OS in existence. I bet it has more than UNICOS. Want to bet about $100000? > Use the proper tool for the job which would be > either a SUN Solaris box or a pentium running SCO Openserver 5. But it has a huge marketing force behind it. Just like LDAP. > > > You cannot distribute the responsibility to apply the first-come > > > first-served rule. > > > > Of course you can. > > No you can't! Oboy, a challenge! Let's see. An algorithm...I've got two minutes... Here we go: In a recent article in CACM, Dorothy Denning and some others presented a method of using GPS signals to generate an unforgable time and place stamp -- turns out that the jitter used in the "selective availability" garbage is pretty darn random, and a record of signals from a set of satellites uniquely identify a time an a place. Furthermore, there is a method by which a set of signals from a particular satellite can be verified. The time is accurate to less than a second, as I recall, and the place is accurate to less than 100 meters. I'll get the reference if you like... So, whenever a registry selects a name it binds it with one of these absolutely unique time/place stamps, using the registry's private key. It propogates it to all cohort registry as time permits. Even if all the other registries have already accepted a competing registries name, the time stamp is proof of prior claim, the competing name is removed, and the earlier one gets the name. There. That works. No single registry has an authority. Another method would be by distributing a tamper-proof clock that generates a signed time-stamp. The "tamper-proof" part is an engineering issue - -- like making smart cards tamper-proof -- but certainly doable. Another method would be to define "first come" as the first one to get a digitally signed acceptance from a majority of other registries. If there is tie then a coin is flipped -- there are algorithms for fair coin flips over a phone -- there are algorithms for playing poker over the phone. All these schemes would work in principal. The voting scheme is actually fairly trivial to do -- it's just not efficient. - -- 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: 20 Aug 1996 20:17:28 -0700 From: johnl@iecc.com (John R Levine) Subject: Re: yet more unworkable distributed design, was New Non-Shared TLD's Create More Monopolies >So, whenever a registry selects a name it binds it with one of these >absolutely unique time/place stamps, using the registry's private key. Wow, three hours ago people were worried that we had to support registries connected by sporadic UUCP connections, now we're going to require that every registry has to have a realtime GPS receiver with suitable dejitterizing software. 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. Can we get back to sketching out the CDB protocol now, please? - -- 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 ---------------------------------------------------------------------- Date: 20 Aug 1996 20:24:26 -0700 From: Michael Dillon Subject: Re: New Non-Shared TLD's Create More Monopolies On Tue, 20 Aug 1996, Kent Crispin wrote: > database. After all, there isn't a central location that makes sure > that all the DNS database files are syntactically correct, and DNS > seems to work. Every domain in DNS has a single central authoritative primary nameserver. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com ---------------------------------------------------------------------- Date: 20 Aug 1996 20:32:17 -0700 From: Keith Winstein Subject: Re: New Non-Shared TLD's Create More Monopolies On Tue, 20 Aug 1996, Michael Dillon wrote: > Does the DNS protocol support a primary server telling all its secondaries > that a portion of a zone is incorrect and just correcting that portion? If > so we could probably automate this whole corrections business. I'm going to be unsubscribing from these lists soon, but let me just comment that "primary" and "secondary" are terms specific to BIND, and really have nothing to do with DNS. In other words, with modified BINDs, you could enhance zone transfers to do whatever you want, without screwing up DNS. Keith ---------------------------------------------------------------------- Date: 20 Aug 1996 22:40:42 -0700 From: Kent Crispin Subject: Re: yet more unworkable distributed design, was New Non-Shared TLD's Create More Monopolies John R Levine allegedly said: > > >So, whenever a registry selects a name it binds it with one of these > >absolutely unique time/place stamps, using the registry's private key. > > Wow, three hours ago people were worried that we had to support registries > connected by sporadic UUCP connections, now we're going to require that every > registry has to have a realtime GPS receiver with suitable dejitterizing > software. Lighten up, John -- I wasn't suggesting those as serious solutions to our problem -- I was just responding to Michael's claim that "it couldn't be done." > 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. 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. - -- 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: 20 Aug 1996 22:44:50 -0700 From: Kent Crispin Subject: Re: New Non-Shared TLD's Create More Monopolies Michael Dillon allegedly said: > > On Tue, 20 Aug 1996, Kent Crispin wrote: > > > database. After all, there isn't a central location that makes sure > > that all the DNS database files are syntactically correct, and DNS > > seems to work. > > Every domain in DNS has a single central authoritative primary nameserver. Oh Jeez. Songbird has a "single central authoritative primary nameserver" -- I'm looking at it right now. Nobody from IANA or the InterNIC or anywhere else came around to check on the syntax of my database. Somehow DNS continues to function. - -- 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: 20 Aug 1996 23:00:45 -0700 From: Kent Crispin Subject: Re: New Non-Shared TLD's Create More Monopolies Keith Winstein allegedly said: > > On Tue, 20 Aug 1996, Michael Dillon wrote: > > > Does the DNS protocol support a primary server telling all its secondaries > > that a portion of a zone is incorrect and just correcting that portion? If > > so we could probably automate this whole corrections business. > > I'm going to be unsubscribing from these lists soon, but let me just > comment that "primary" and "secondary" are terms specific to BIND, and > really have nothing to do with DNS. In other words, with modified BINDs, > you could enhance zone transfers to do whatever you want, without > screwing up DNS. There is a lot of work going on in DNS as we speak that could have a great deal of relevance to this. From the ietf drafts index: "Incremental Zone Transfer in DNS", M. Ohta, 06/06/1996. (17076 bytes) "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", P. Vixie, 06/04/1996. (16178 bytes) "Dynamic Updates in the Domain Name System (DNS UPDATE)", P. Vixie, S. Thomson, Y. Rekhter,, 03/14/1996. (58122 bytes) "Scheduled Expiration of DNS Resource Records", M. Patton, 02/21/1996. (13335 bytes) "Deferred Dynamic Updates in the Domain Name System (DNS DEFUPD)", P. Vixie, 05/23/1996. (16187 bytes) - -- 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
