I want to see an underlying database schema that mates naturally with the UMich LDAP implementation so that it is easy for all registries to supply an LDAP interface to their data in addition to the more traditional Whois stuff. > A design goal I implictly accept for shared tlds is that things should > be as distributed as possible. One way to do this is to have a centralised database that anyone can replicate at will and use to serve local requests when the central nature of the database is not relevant. > A database that is the single, central, authorative repository of all whois > data, and all SLD registrations is over my warning threshold for > abuse potential. It is also a risk for single point of failure. Not if it is replicated. And the easiest way to supply an atomic query/reservation transaction is to have a single central authoritative database to process all of them. Of course you could split things up by TLD and have different central authoritative databases at different sites for different TLD's. But I think we should avoid multi-phase commit stuff with truly distributed databases. There are ways to ensure stability of central databases even in the event of catastrophic failures such as Earthquakes. There are other protocols that have working code for getting two or more master servers to appoint one of their number as *THE* master and for others to take ove if *THE* master becomes incapacitated for some reason. One of them is a LAN time protocol that I've used on SCO UNIX networks but whose name escapes me right now. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com ---------------------------------------------------------------------- Date: 19 Aug 1996 19:21:33 -0700 From: perry@piermont.com Subject: Re: New Non-Shared TLD's Create More Monopolies Kent Crispin writes: > > Of course there is. First of all, "whois" isn't a hierarchical access > > protocol, so all the "whois" databases have to get merged the way > > things work these days. > > This clearly needs to be fixed. I'd say we should try to fix one thing at a time. > > Second of all, the data has to be preserved if > > a registry goes "boom!". > > What happens if the CDB suddenly goes "boom"? Not much likelyhood of that happening -- the organization is likely to have some permanence. (If you are referring to the hardware, I'd say that having a pair of replicated machines at different sites should handle that -- and commercial databases will let you do this.) > > Third, "whois" provides a textual interface, > > not a structured interface suitable for transfering database > > contents. > > A 25 line perl script that takes about 30 minutes to write will > handle this quite easily. Not very well, I'd say. > > I really see no point to registry only local storage of whois type > > information. It makes little sense to me. > > A design goal I implictly accept for shared tlds is that things should > be as distributed as possible. The registries, or the data? There is no need to have different databases in different places, although replicating the databases makes considerable sense. > Any centralized service is a potential monopoly point. Not, as I've said, if its role is tightly constrained, especially by contracts. > If a centralized service is so trivial that there is no way for > money or power to accrue to those who run it, then I grant it's > probably not a significant problem. However, the more complex the > centralized service, and the more things that depend on it, the > greater the risk for abuse. The central service we are talking about is fairly trivial -- it runs a database server, and a fairly simple one at that. > Frankly, I would prefer a solution that does not have a central CDB of > any type. I would trade off a fair amount of short term simplicity, > reliability, and performance to meet that goal, I'm afraid we can't afford to sacrifice reliability -- people need the DNS and the rest to work all the time -- and if the system is so complicated that it won't work at all sacrificing simplicity isn't an option, either. > because I think in the long run it actually is a better model -- > registrations should continue without a hitch if an earthquake sank > IANA and its computers beneath the ocean. You can't avoid some centralization. The root name servers, for instance, are a centralization. Now, the root DNS database is REPLICATED, but it is in a real sense centralized. 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. Perry ---------------------------------------------------------------------- Date: 19 Aug 1996 19:47:22 -0700 From: perry@piermont.com Subject: Re: New Non-Shared TLD's Create More Monopolies Michael Dillon writes: > There are ways to ensure stability of central databases even in the event > of catastrophic failures such as Earthquakes. You can get a lot of milage simply by streaming the transaction logs out to replication sites... Perry ---------------------------------------------------------------------- Date: 19 Aug 1996 19:56:29 -0700 From: Michael Dillon Subject: Re: New Non-Shared TLD's Create More Monopolies On Mon, 19 Aug 1996, Perry E. Metzger wrote: > Michael Dillon writes: > > There are ways to ensure stability of central databases even in the event > > of catastrophic failures such as Earthquakes. > > You can get a lot of milage simply by streaming the transaction logs > out to replication sites... In fact this is precisely how I set up my largest commercial database customer even though the database product that they use supports all kinds of neat distributed database stuff. And it works too because we tried it out with a real live get-the-server-operational-by-tomorrow-morning-or-we-lose-the-company type of failure. That machine just picke the worst time in the whole year to die :-( Anyway, since it happened near the end of the business day (full tape backups are done at night) they would have lost almost a full day's work in addition to the downtime getting a backup server configured and into their offices (now the backup server is up and running 24hrs a day in another room in the same building). But the transaction logs made it a snap to bring the machine up and continue on exactly where everybody left off with the piles of paper on their desks being all that was needed to maintain state information. This last was the biggest benefit of those up to date transaction logs because no matter how much you try to prepare people for a potential disaster they just will not learn and over several months they are lulled into a sense of security and absolute trust in the machine. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com ---------------------------------------------------------------------- Date: 19 Aug 1996 22:00:44 -0700 From: Kent Crispin Subject: Re: New Non-Shared TLD's Create More Monopolies Michael Dillon allegedly said: > > On Mon, 19 Aug 1996, Kent Crispin wrote: > > > > Third, "whois" provides a textual interface, > > > not a structured interface suitable for transfering database > > > contents. > > > > A 25 line perl script that takes about 30 minutes to write will > > handle this quite easily. > > If you are suggesting that we build a pseudo-database interface on top of > a text interface then I strongly disagree. Nope. I'm suggesting a perl script that runs rwhois, gets the data, and inserts all of it into a local whois database. > I would much rather see a > standard underlaying database schema developped and see people encouraged > to use tools like gdbm or Berkeley db at the very least to implement this. > In fact, when you get right down into nitty gritty implementation details > I want to see an underlying database schema that mates naturally with the > UMich LDAP implementation so that it is easy for all registries to supply > an LDAP interface to their data in addition to the more traditional Whois > stuff. That would be nice, but I don't it is necessary for shared-tld to mandate that particular change. The whois format is the current standard, apparently moving to rwhois, and, as Perry says, we should only change one thing at a time. :-) > > A design goal I implictly accept for shared tlds is that things should > > be as distributed as possible. > > One way to do this is to have a centralised database that anyone can > replicate at will and use to serve local requests when the central nature > of the database is not relevant. "Distributed" to me implies "distributed responsibility". > > A database that is the single, central, authorative repository of all whois > > data, and all SLD registrations is over my warning threshold for > > abuse potential. It is also a risk for single point of failure. > > Not if it is replicated. > And the easiest way to supply an atomic > query/reservation transaction is to have a single central authoritative > database to process all of them. Replication has no effect on the problem of monopolistic abuse, if there is a single authoritative source. > Of course you could split things up by > TLD and have different central authoritative databases at different sites > for different TLD's. But I think we should avoid multi-phase commit stuff > with truly distributed databases. > > There are ways to ensure stability of central databases even in the event > of catastrophic failures such as Earthquakes. There are other protocols > that have working code for getting two or more master servers to appoint > one of their number as *THE* master and for others to take ove if *THE* > master becomes incapacitated for some reason. One of them is a LAN time > protocol that I've used on SCO UNIX networks but whose name escapes me > right now. I can accept (though grudgingly) that a centralized database for synchronization is small enough and simple enough that it is unlikely to become a serious problem. However, when this central database also becomes the authoritative repository for all the contact information I begin to worry. This may seem silly to you, but it seems silly to me that we should see threats of lawsuits against the IANA at the merest hint that it might do something unfavorable to particular parties. It seems silly to me that people from a sophisticated country like Canada should be bashing the US because the net infrastructure is centered there. Part of the advantage of moving as much responsibility as possible out to the registries is that they become the primary source of legal liability. And the more a local person can blame their local registry for screwups, the better. As I have said, if efficiency, simplicity, and reliability are our primary goal we might as well stick with trying to make the InterNIC better -- forget shared TLDs altogether. The whole point of shared TLDs is to accomplish what are really social, business, and internet structural goals. They are a means to competition, to diversity, and to dispersing the control of the internet into a wider population. Every bit of centralization works against those goals. Sorry -- sometimes I tend to get a little preachy :-) - -- 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: 19 Aug 1996 22:27:46 -0700 From: Kent Crispin Subject: Re: New Non-Shared TLD's Create More Monopolies Perry E. Metzger allegedly said: > > > Kent Crispin writes: > > > Of course there is. First of all, "whois" isn't a hierarchical access > > > protocol, so all the "whois" databases have to get merged the way > > > things work these days. > > > > This clearly needs to be fixed. > > I'd say we should try to fix one thing at a time. Perhaps rwhois has already fixed this -- haven't had time to explore it, though, so I can't really say. [snip] > > A 25 line perl script that takes about 30 minutes to write will > > handle this quite easily. > > Not very well, I'd say. It doesn't have to be perfect. 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. People will be looking at the data, making changes involving registry addresses and potentially other things. In fact, it would be unwise to spend much time on this part of it without some experience, anyway. > > > I really see no point to registry only local storage of whois type > > > information. It makes little sense to me. > > > > A design goal I implictly accept for shared tlds is that things should > > be as distributed as possible. > > The registries, or the data? There is no need to have different > databases in different places, although replicating the databases > makes considerable sense. 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. > > Any centralized service is a potential monopoly point. > > Not, as I've said, if its role is tightly constrained, especially by > contracts. If the CDB contains all the authoritative data, then it is a very short step to a direct email interface, bypassing registries. Contracts can be developed that will avoid that, you're right. But then, contracts with whom? With the registries? With the IANA? 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? And we are plotting a drastic change in that contract. [snip] > I'm afraid we can't afford to sacrifice reliability -- people need the > DNS and the rest to work all the time -- and if the system is so > complicated that it won't work at all sacrificing simplicity isn't an > option, either. 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. A human enters the contact data -- it will have mistakes, and DNS won't notice them. Years could elapse with an incorrect administrative contact. The accuracy and reliability of registry data has very little to do with the correct, reliable, running of the net. > > > because I think in the long run it actually is a better model -- > > registrations should continue without a hitch if an earthquake sank > > IANA and its computers beneath the ocean. > > You can't avoid some centralization. The root name servers, for > instance, are a centralization. Now, the root DNS database is > REPLICATED, but it is in a real sense centralized. In the absurd philosophical extreme, as Leslie Lamport once said, everything is distributed -- if you get down to the chip level signals take time to propogate. The transfer of zone files takes time, and the replicated databases can be out of sync for significant periods of time. So I would say that in a very real sense, even the root servers are *distributed* -- they just have a crude update mechanism. > 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, 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. - -- 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: 19 Aug 1996 22:40:14 -0700 From: "David R. Conrad" Subject: Re: New Non-Shared TLD's Create More Monopolies Alan, >Now, if several near-simultaneous attempts are made to reserve the name, >only one will succeed, and the losers know that they have lost *before* they >start setting up the nameservers. So the losers have no work that needs to >be undone. Thanks for the clarification. I'm interested in getting up and running as fast and reliably as possible, thus I was assuming that the CDB (which is what I guess we're calling it) would not do any of the checking to see if the nameservers were up. As such, the race condition wouldn't exist. The scenario I envisioned was: 1) person chooses name 2) person goes to registry to request name, providing registration data 3) registry requests name 4) if name exists, goto step 1 5) CDB allocates name with registration data at registry and builds zone file 6) person pays registry 7) person sets up DNS service 8) zone file distributed to appropriate servers Is adding the state, timers, and server complexity valuable enough to warrant the addition of the NS checking code (no opinion, just asking)? Of course, the race condition can also be "avoided" by just saying, "sorry, name taken, remove the gunk from the primaries and secondaries", but I'd agree this would be annoying. Regards, - -drc ---------------------------------------------------------------------- Date: 19 Aug 1996 22:46:36 -0700 From: "David R. Conrad" Subject: Re: New Non-Shared TLD's Create More Monopolies >In other words we define an HTML form that uses POST >transactions and we define the behavior of the backend CGI script that >handles it. There are many places in the world that could concievably want to be registries under this scheme that have no hope of using the WWW (e.g., they're on the end of a UUCP line). Regards, - -drc ---------------------------------------------------------------------- Date: 19 Aug 1996 22:54:22 -0700 From: Michael Dillon Subject: Re: New Non-Shared TLD's Create More Monopolies On Mon, 19 Aug 1996, Kent Crispin wrote: > > If you are suggesting that we build a pseudo-database interface on top of > > a text interface then I strongly disagree. > > Nope. I'm suggesting a perl script that runs rwhois, gets the data, > and inserts all of it into a local whois database. Yuck! > That would be nice, but I don't it is necessary for shared-tld to > mandate that particular change. The whois format is the current > standard, apparently moving to rwhois, and, as Perry says, we should > only change one thing at a time. :-) Who says whois is a "standard"? 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. 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. > > One way to do this is to have a centralised database that anyone can > > replicate at will and use to serve local requests when the central nature > > of the database is not relevant. > > "Distributed" to me implies "distributed responsibility". You cannot distribute the responsibility to apply the first-come first-served rule. > > > abuse potential. It is also a risk for single point of failure. > > > > Not if it is replicated. > > And the easiest way to supply an atomic > > query/reservation transaction is to have a single central authoritative > > database to process all of them. > > Replication has no effect on the problem of monopolistic abuse, if > there is a single authoritative source. What is this monopolistic abuse problem? > I can accept (though grudgingly) that a centralized database for > synchronization is small enough and simple enough that it is unlikely > to become a serious problem. However, when this central database > also becomes the authoritative repository for all the contact > information I begin to worry. Why? If a registry agent wants to maintain their own customer contact database off to the side they are free to do so. > of the advantage of moving as much responsibility as possible out to > the registries is that they become the primary source of legal > liability. And the more a local person can blame their local registry > for screwups, the better. Unfortunately it is simply not possible to distribute a first-come first-served authority in a way that localizes liability. Lets say there are N registries. Then for any new domain you must query and receive a positive response from N/2 + 1 registries in order to make a valid determination of first-come first-served. In fact, this may require querying more than N/2 + 1 registries because some of them may reply in the neagtive and if the number of registries is even there is a seriour problem of deadlock that may need to be resolved. Note that even if you are careful to only allow odd numbers of registries, network problems can cause a working set of registries with an even number of members thus the deadlock problem cannot be easily avoided. In real world situations like boards of directors this is solved by giving one person a tie-breaking vote. However, in regards to domain registries this same solution would result in legal liabilities being focussed on that tie-breaker. Might as well plan for the legal liabilities and have one single central database run by an organization chartered under Swiss law in Geneva that has some level of immunity from prosecution. > As I have said, if efficiency, simplicity, and reliability are our > primary goal we might as well stick with trying to make the InterNIC > better -- forget shared TLDs altogether. You and I have no say whatsoever over the actions of Network Solutions Inc. The only thing we could possibly do would be to have the NSF terminate the coop agreement with NSI and even then a new contractor or new organization would have no model to follow and thus there is no guarantee that they would do a better job than NSI. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com ---------------------------------------------------------------------- Date: 19 Aug 1996 22:55:17 -0700 From: "David R. Conrad" Subject: Re: New Non-Shared TLD's Create More Monopolies >> If the information is available from the registry via a "whois", then >> there is no particular advantage to having it in the CDB. >Of course there is. First of all, "whois" isn't a hierarchical access >protocol, As has been pointed out, see rwhois. Note that rwhois has mechanisms which allow caching of data as well as ways of downloading records, thus the risk of data loss if the registry falls down and goes boom can be alleviated. >Third, "whois" provides a textual interface, >not a structured interface suitable for transfering database contents. No. Both the (freely available) RIPE whois database software and the InterNIC whois database have mechanisms by which structured data (actually, tag/value pairs) can be returned. In the case of RIPE, it is the only way the data can be returned. In the case of InterNIC, "dump full" provides the tag/value pairs. As mentioned, rwhois has somewhat elaborate mechanisms to allow database transfers to occur. Cheers, - -drc ---------------------------------------------------------------------- Date: 19 Aug 1996 23:18:17 -0700 From: Michael Dillon Subject: Re: New Non-Shared TLD's Create More Monopolies On Tue, 20 Aug 1996, David R. Conrad wrote: > >In other words we define an HTML form that uses POST > >transactions and we define the behavior of the backend CGI script that > >handles it. > > There are many places in the world that could concievably want to be > registries under this scheme that have no hope of using the WWW (e.g., > they're on the end of a UUCP line). Once we have defined the fields used for a CGI POST transaction there is no reason why alternative interfaces cannot be devised. Two possible models arise. One is where the TLD registry must supply multiple interfaces including a modern CGI POST interface and an antiquated but universal email form interface. The other model is one where registry agents can further fan out their duties to other subcontracted agents and supply the email interface and UUCP connectivity perhaps. This model does have the desirable attribute that a TLD registry only needs to deal with a small number of regional agents while still allowing for the possibility of domain registry agents in every country and linguistic region of the world. Presumably a registry agent in Mongolia would actually be subcontractor to most or all TLD registries through one or more registry agents. And it is even possible that there are only a few regional registry agents who actually handle all TLD's. But now we are rapidly approaching that twilight zone where it no longer seems to make any business sense to be a TLD registry but makes a lot of sense to be a registry agent. That's presumably why IANA didn't feel it was a good idea to make registries shared from day one. On the other hand the fact that it is not a terribly profitable operation makes it more likely that we will be able to establish a single central international authority that maintains the shared databases for all international TLD's. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com ---------------------------------------------------------------------- Date: 19 Aug 1996 23:38:23 -0700 From: Simon Higgs Subject: Re: New Non-Shared TLD's Create More Monopolies At 9:43 PM -0700 8/19/96, Kent Crispin wrote: >I can accept (though grudgingly) that a centralized database for >synchronization is small enough and simple enough that it is unlikely >to become a serious problem. However, when this central database >also becomes the authoritative repository for all the contact >information I begin to worry. > This is an issue for later on (transaction scalability), but don't forget Bob Frank's FOI request for the InterNIC database. There are numerous third-party uses for the information outside the snail-mail spamming like CRL and others do. Trademark searches are going to be done in any whois created. That includes both the matches for addresses as well as domain and organizational names. Several companies already tie up NSI's whois with bulk searches. Should these searches tie up each registry's whois or be assigned to a mirrored master whois database (or just be downloaded via ftp)? _____S_i_m_o_n___H_i_g_g_s_________________H_i_g_g_s___A_m_e_r_i_c_a_____ ... "I'm fine - it's the others" ......... President/CEO ................ _____e-mail: simon@higgs.com _____________ http://www.higgs.com/ ________ ... http://ds.internic.net/internet-drafts/draft-higgs-tld-cat-02.txt ...
