---------------------------------------------------------------------- Date: 24 Aug 1996 06:06:32 -0700 From: johnl@iecc.com (John R Levine) Subject: Re: DNS based proposal for shared tlds >The current proposals swirl around the idea of an ad hoc central >database that is used for coordination between registries. What >follows is an alternate approach that does not use any central >database except for DNS itself. [reasonable proposal omitted] This makes the DNS the CDB. (Does changing one TLA really make people happier?) I suppose that might work, although I'm still worried about race conditions when multiple registries try to grab the same name, and about the procedure for transferring a name from one registry to another. - -- 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: 24 Aug 1996 09:41:24 -0700 From: Michael Dillon Subject: Re: DNS based proposal for shared tlds On Sat, 24 Aug 1996, John R Levine wrote: > >The current proposals swirl around the idea of an ad hoc central > >database that is used for coordination between registries. What > >follows is an alternate approach that does not use any central > >database except for DNS itself. [reasonable proposal omitted] > > This makes the DNS the CDB. This is a positively GROSS idea. Adding kludges to kludges.... It's nice to see that many of the DNS shortcomings are being fixed and it would be good to make use of some of these new features where possible. But the whole CDB concept is more than just an extended DNS. You now the old mantra? DNS was never intended to be a DIRECTORY service? I think this is the fundamental difference with CDB in that the Central DataBase SHOULD be designed to be a directory service. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com ---------------------------------------------------------------------- Date: 24 Aug 1996 11:40:53 -0700 From: Simon Higgs Subject: Re: DNS based proposal for shared tlds At 9:37 AM -0700 8/24/96, Michael Dillon wrote: >> >The current proposals swirl around the idea of an ad hoc central >> >database that is used for coordination between registries. What >> >follows is an alternate approach that does not use any central >> >database except for DNS itself. [reasonable proposal omitted] >> >> This makes the DNS the CDB. > >This is a positively GROSS idea. Adding kludges to kludges.... > Let's add another kludge... ;) >It's nice to see that many of the DNS shortcomings are being fixed and it >would be good to make use of some of these new features where possible. > >But the whole CDB concept is more than just an extended DNS. You now the >old mantra? DNS was never intended to be a DIRECTORY service? I think this >is the fundamental difference with CDB in that the Central DataBase SHOULD >be designed to be a directory service. > What would it take to turn the CDB into *BOTH* DNS and a global whois within the same set of protocols? Is this something DNS-NG will do? I know it would probably increase the load significantly, but it would satisfy several problems. Ignore the user interface, because this could be done just as well as a DNS UDP packet, telnet session, or a www browser function. This would allow DNS' use to be expanded to a semi-intelligent level (useful to agents). whois:// This brings up whois contact info for you. Web version obviously hypertext (I suggest we add a URL to the fields in the contact table): whois://Dillon,Michael Dillon, Mike (MD130) michael@MEMRA.COM C-4 Powerhouse, RR#2 Armstrong BC V0E 1B0 CA +1-604-546-8022 (FAX) +1-604-546-3049 Record last updated on 02-Jul-96. dns:// All nslookups have to do is indicate they're lookups to prevent the excess contact data being returned. Here's one looking for www.memra.com: dns://?www.memra.com memra.com start of authority = mname = okjunc.junction.net, rname = noc.junction.net serial = 807, refresh = 28800, retry = 7200, expire = 604800, minimum = 86400 memra.com name server = okjunc.junction.net memra.com name server = felix.junction.net (felix.junction.net) inet address = 199.166.227.5 (okjunc.junction.net) inet address = 199.166.227.1 And this gets referred to the authorative name server: dns://okjunc.junction.net?www.memra.com www.memra.com inet address = 199.166.227.56 memra.com name server = okjunc.junction.net memra.com name server = felix.junction.net (felix.junction.net) inet address = 199.166.227.5 (okjunc.junction.net) inet address = 199.166.227.1 _____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 ... ---------------------------------------------------------------------- Date: 24 Aug 1996 13:54:08 -0700 From: Kent Crispin Subject: Re: DNS based proposal for shared tlds John R Levine allegedly said: > > >The current proposals swirl around the idea of an ad hoc central > >database that is used for coordination between registries. What > >follows is an alternate approach that does not use any central > >database except for DNS itself. [reasonable proposal omitted] > > This makes the DNS the CDB. (Does changing one TLA really make people > happier?) Well, it does a great deal more than substitute TLAs. The DNS database exists as a "central database" in either proposal -- so in fact the DNS-based proposal has one less database to manage. Plus the resulting structure is intrinsically more distributed, with essentially no extra cost. > I suppose that might work, although I'm still worried about race > conditions when multiple registries try to grab the same name, The addition/update of a RR to the primary nameserver has to be an atomic transaction; that's expressly noted in one of the drafts I referenced : "Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. UPDATE is atomic, i.e., all prerequisites must be satisfied or else no update operations will take place." -- Abstract for "Dynamic Updates in the Domain Name System (DNS UPDATE)", P. Vixie, S. Thomson, Y. Rekhter,, 03/14/1996, at > and about the > procedure for transferring a name from one registry to another. IMPerhapsControversialO, that is an issue between registries and their customers. The customer arranges with their current registry to move to the new registry, and simultaneously arranges with the new registry to take over, and that's it. Should be a simple form, or authenticated email, to do it. - -- 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: 24 Aug 1996 13:58:09 -0700 From: Kent Crispin Subject: Re: DNS based proposal for shared tlds Michael Dillon allegedly said: > > On Sat, 24 Aug 1996, John R Levine wrote: > > > >The current proposals swirl around the idea of an ad hoc central > > >database that is used for coordination between registries. What > > >follows is an alternate approach that does not use any central > > >database except for DNS itself. [reasonable proposal omitted] > > > > This makes the DNS the CDB. > > This is a positively GROSS idea. Adding kludges to kludges.... Perhaps you could be a bit more specific? > It's nice to see that many of the DNS shortcomings are being fixed and it > would be good to make use of some of these new features where possible. > > But the whole CDB concept is more than just an extended DNS. As originally defined, the CDB was the "Coordination Database", and its explicit purpose was to prevent close call name conflicts. It had no other purpose. Then people began to add things... > You now the > old mantra? DNS was never intended to be a DIRECTORY service? I think this > is the fundamental difference with CDB in that the Central DataBase SHOULD > be designed to be a directory service. Why on earth do you thing the CDB should be a Directory Service? - -- 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: 24 Aug 1996 14:11:33 -0700 From: johnl@iecc.com (John R Levine) Subject: Re: DNS based proposal for shared tlds >> >The current proposals swirl around the idea of an ad hoc central >> >database that is used for coordination between registries. What >> >follows is an alternate approach that does not use any central >> >database except for DNS itself. [reasonable proposal omitted] >> >> This makes the DNS the CDB. (Does changing one TLA really make people >> happier?) > >Well, it does a great deal more than substitute TLAs. The DNS >database exists as a "central database" in either proposal -- so in >fact the DNS-based proposal has one less database to manage. Plus >the resulting structure is intrinsically more distributed, with >essentially no extra cost. Huh? More distributed? The primary nameserver acts as the central database, with the secondary nameservers as mirrors. I can't see that this is any more distributed than any other kind of centralized database with mirrors. If we don't use the DNS as the CDB (and I don't think we should, since there's going to be more info in the CDB than needs to be in DNS), and there's a lot of demand to examine the contents of the CDB, it's not hard to put up mirrors for that, too. That part of distributed databases is easy. >> and about the >> procedure for transferring a name from one registry to another. > >IMPerhapsControversialO, that is an issue between registries and their >customers. Of course. I was more concerned about how the DNS/CDB tracks who's responsible for each entry, whether one registry is normally allowed to update another's entry, and how as a software issue the ownership of an entry is transferred from one registry as another. It also occurs to me that there are definitely well-debugged database packages that can handle the CDB, while distributed update of DNS seems to exist as at most a prototype. Since it seems that there's considerable time pressure to get a shared-tld model working soon, I'd rather use known good parts wherever possible. If it turns out in the future that it's possible to merge the CDB into a shared update DNS and there are working shared update DNS servers we can point to, I have no problem with that. - -- 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: 24 Aug 1996 18:28:32 -0700 From: Kent Crispin Subject: Re: DNS based proposal for shared tlds John R Levine allegedly said: [snip] > >> This makes the DNS the CDB. (Does changing one TLA really make people > >> happier?) > > > >Well, it does a great deal more than substitute TLAs. The DNS > >database exists as a "central database" in either proposal -- so in > >fact the DNS-based proposal has one less database to manage. Plus > >the resulting structure is intrinsically more distributed, with > >essentially no extra cost. > > Huh? More distributed? The primary nameserver acts as the central > database, with the secondary nameservers as mirrors. I can't see that this > is any more distributed than any other kind of centralized database with > mirrors. If we don't use the DNS as the CDB (and I don't think we should, > since there's going to be more info in the CDB than needs to be in DNS), This is apparently a misconception you have about the proposal. In fact, there is simply not that much more data in DNS than would have to be there already. It could be as little as three fields -- the IP address of the registry, an authentication key for the registry, and a lifetime. Nothing else. All the rest of the data being bandied in the CDB proposals is in databases at the registry. No whois data at all is in DNS. > and > there's a lot of demand to examine the contents of the CDB, it's not hard to > put up mirrors for that, too. That part of distributed databases is easy. > > >> and about the > >> procedure for transferring a name from one registry to another. > > > >IMPerhapsControversialO, that is an issue between registries and their > >customers. > > Of course. I was more concerned about how the DNS/CDB tracks who's > responsible for each entry, The registry id is with the entry. > whether one registry is normally allowed > to update another's entry, Never. > and how as a software issue the ownership > of an entry is transferred from one registry as another. The controlling registry for the domain sends an authenticated incremental zone transfer that changes the controlling registry id, after communicating with the new registry to ok the transfer. If the customer has a problem with the current registry he can pursue various remedies, up to and including suing his registry. But in practice it should be a simple request to transfer. > It also occurs to me that there are definitely well-debugged database > packages that can handle the CDB, while distributed update of DNS seems to > exist as at most a prototype. Since it seems that there's considerable time > pressure to get a shared-tld model working soon, I'd rather use known good > parts wherever possible. If it turns out in the future that it's possible > to merge the CDB into a shared update DNS and there are working shared > update DNS servers we can point to, I have no problem with that. However, DNS has a *gigantic* advantage over any commercial database - -- it is *designed* to be distributed throughout the net...So, for example, if a remote user accesses something in the xxx.new domain, the DNS records for that domain will be cached locally. Then, for example, if a whois request is made for that domain it will go directly to the registry that has the data, and not have to hit any central server at all. This is what I was getting at when I said that a DNS solution is *intrinsically* more distributed than a commercial database solution. DNS already has a mechanism for local caching, and by having the addresses of the individual registry cached no central access needs to be made at all. - -- 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: 24 Aug 1996 19:07:12 -0700 From: johnl@iecc.com (John R Levine) Subject: Re: DNS based proposal for shared tlds >This is apparently a misconception you have about the proposal. In >fact, there is simply not that much more data in DNS than would have >to be there already. It could be as little as three fields -- the IP >address of the registry, an authentication key for the registry, and a >lifetime. Nothing else. All the rest of the data being bandied in >the CDB proposals is in databases at the registry. No whois data at >all is in DNS. Hold it, red alert, we're back to the million way merge problem. I really think it's critical that the CDB contain enough information to generate the zone file for the domain. If it doesn't, it has to poll every registry every night to collect the data for the zone file, with all the attendant problems of registries that don't answer (what if they don't have a 24/7 connection because they're in a distant corner of the world and can't afford it?), registries that return bad data, etc. The CDB I proposed back when I called it a "lightweight registry" was supposed to have enough info to generate the zone file. That only adds the names and addresses of the domain servers for each domain in the zone, not an enormous amount of extra info. If you want to treat an incrementally updated DNS as the CDB, I still suppose that's possible but I'd be a lot more comfortable with a multi-user database with a track record. I'm still not sure about whether we need a combined whois database or whether rwhois or whois++ is up to the task. - -- 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: 24 Aug 1996 22:11:39 -0700 From: Kent Crispin Subject: Re: DNS based proposal for shared tlds John R Levine allegedly said: > > >This is apparently a misconception you have about the proposal. In > >fact, there is simply not that much more data in DNS than would have > >to be there already. It could be as little as three fields -- the IP > >address of the registry, an authentication key for the registry, and a > >lifetime. Nothing else. All the rest of the data being bandied in > >the CDB proposals is in databases at the registry. No whois data at > >all is in DNS. > > Hold it, red alert, we're back to the million way merge problem. I really > think it's critical that the CDB contain enough information to generate the > zone file for the domain. If it doesn't, it has to poll every registry > every night to collect the data for the zone file, with all the attendant > problems of registries that don't answer (what if they don't have a 24/7 > connection because they're in a distant corner of the world and can't afford > it?), registries that return bad data, etc. It doesn't work that way. There is no zillion-way merge. The total zone file is built in the primary nameserver as the registries do their IXFRs. Here's a more complete example. Two registries, A & B serve the TLD .new, and the primary nameserver, P, holds the current zone file for .new. That zone file contains records for the following subdomains (I don't try to indicate the exact syntax, 'cuz: domain nameservers registry remaining life auth s.new. <15 months> v.new. <12 months> Note that P contains no whois data. Another customer comes to B and wants domain w.new. B does a nslookup, sees that w.new is not in use (this step is not necessary, just a prelimary check). B says "Hmm. w.new is free, so I will reserve it for you". B runs a code that builds minimal information for the new domain, and does an IXFR to P. This succeeds. The zone description at P now contains: domain nameservers registry remaining life auth s.new. <15 months> v.new. <12 months> w.new. <1 day> B proceeds to take down the customers contact, which includes whois data and other data that B needs for business purposes. The whois part is put in a whois database, the rest is stored in a filing cabinet. In the meantime, A gets a customer who also wants w.new. A does an nslookup, but doesn't see anything, because B's IXFR hasn't happened yet. A says "OK", and tries to reserver the name. However, when A's IXFR request arrives, B's entry is already there. A's update can't change the entry, because it would require B's auth to change it. Instead, the IXFR gets an error. A says to the customer, "Sorry, somebody over at "Domains by B" just claimed w. Can I interest you in another name?" B collects the customers credit card information, completes the charge for 5 years of service, and does an IXFR that modifies the record. Now the zone looks like this: domain nameservers registry remaining life auth s.new. <15 months> v.new. <12 months> w.new. <60 months> Two months later B's customer happens to wander by "Domains by A", and discovers that A's rates are half of B's. Customer thinks about it at home that night, and decides to transfer to A -- it will save him money even counting for the transfer fee. Firing up his home computer, he sends an authenticated messages to A and B, with his credit card number to A. He discovers that B doesn't give refunds -- it's in the fine print of his contract, but is so pissed off that he transfers to A anyway. He pays the transfer fee, and the initiation fee to A, and the transfer happens -- B knows A's auth, of course, and sends an update. Things now look like this: domain nameservers registry remaining life auth s.new. <15 months> v.new. <12 months> w.new. <58 months> However, the nice clerk at A notices that the customer came from B, and gives the customer an extra two years: domain nameservers registry remaining life auth s.new. <15 months> v.new. <12 months> w.new. <82 months> Every night P does a full zone transfer to secondary nameservers for the TLD. > The CDB I proposed back when I called it a "lightweight registry" was > supposed to have enough info to generate the zone file. That only adds > the names and addresses of the domain servers for each domain in the zone, > not an enormous amount of extra info. It's not an enormous amount of extra info. I show each record as having the auth for the registry, but of course that's not necessary. Another Resource Record could contain that for each registry. So the only thing you would really need to add would be the registry ID and the remaining life (of course that would be coded as an expiration date, but it is easier to talk about as a lifetime). So this could be reduced to two integers worth of extra data. > If you want to treat an incrementally updated DNS as the CDB, I still > suppose that's possible but I'd be a lot more comfortable with a multi-user > database with a track record. DNS has a pretty long track record. RFC1034 or whatever, by Paul Mockapetris, clearly indicates that it was designed to hold other data, and that it was: The design goals of the DNS influence its structure. They are: - The primary goal is a consistent name space which will be used for referring to resources.... - The sheer size of the database and frequency of updates suggest that it must be maintained in a distributed manner, with local caching to improve performance. Approaches that attempt to collect a consistent copy of the entire database will become more and more expensive and difficult, and hence should be avoided. The same principle holds for the structure of the name space, and in particular mechanisms for creating and deleting names; these should also be distributed. ... - The costs of implementing such a facility dictate that it be generally useful, and not restricted to a single application. We should be able to use names to retrieve host addresses, mailbox data, and other as yet undetermined information. All data associated with a name is tagged with a type, and queries can be limited to a single type. ... 2.3. Assumptions about usage The organization of the domain system derives from some assumptions about the needs and usage patterns of its user community and is designed to avoid many of the the complicated problems found in general purpose database systems. The assumptions are: - The size of the total database will initially be proportional to the number of hosts using the system, but will eventually grow to be proportional to the number of users on those hosts to the number of hosts using the system, but will eventually grow to be proportional to the number of users on those hosts as mailboxes and other information are added to the domain system. ... - -- 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: 24 Aug 1996 22:14:49 -0700 From: Kent Crispin Subject: Re: DNS based proposal for shared tlds Simon Higgs allegedly said: > [speculations about DNS-NG deleted] You probably are not frequently accused of a lack if imagination. - -- 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
