-> DNS based proposal for shared tlds
by Kent Crispin
----------------------------------------------------------------------
Date: 23 Aug 1996 07:19:39 -0700
From: "Richard J. Sexton"
Subject: Re: Modelling the Process
At 10:50 PM 8/22/96 EDT, David Collier Brown wrote:
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80,
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x60, 0x04, 0xb0, 0x31, 0x30, 0x06, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x60, 0x8c, 0xbb,
> 0x31, 0x30, 0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xf0,
0x27, 0x19, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0xf0, 0x47, 0x31, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1f};
----------------------------------------------------------------------
Date: 23 Aug 1996 17:33:58 -0700
From: Martin Hamilton
Subject: Re: New Non-Shared TLD's Create More Monopolies
John R Levine writes:
| Similarly, there needs to be enough info to generate the WHOIS file, but
| again that's not a huge amount of info, just name and address of domain
| holder (who as Perry notes may be a nominee) and some contact people. We
| all need to dig into RWHOIS and whois++ to see how well either or both make
| distributed whois maintenance possible.
FWIW: You might want to grab a copy of Bunyip's "Digger" WHOIS++ server
from . Our
implementation isn't really meant for high volume stuff, and is still
alpha quality, so you probably wouldn't want to use that... :-)
Martin
----------------------------------------------------------------------
Date: 23 Aug 1996 20:30:36 -0700
From: Michael Dillon
Subject: Re: TLD WAR
On Fri, 23 Aug 1996, Bob Allisat wrote:
> These boys have chosen war
> over compromise and confrontation
> over co-operation. Let the
> TLD WAR begin.
Oh yeah?
> Let's fuck IANA,
> the NSI and Internic but good.
How?
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
----------------------------------------------------------------------
Date: 23 Aug 1996 23:32:47 -0700
From: Kent Crispin
Subject: DNS based proposal for shared tlds
The IANA non-announcement is creating a small firestorm of
controversy over on the newdom list, so it seems like shared-tld
needs a little push...
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. It turns out that there are several
current proposals for extensions to DNS that would allow it to
essentially take the place of the CDB in an efficient manner:
Introduction
This is an outline for a proposal for implementing shared TLDs through
the DNS system. It has the following characteristics:
1) performs extremely well
2) allows completely distributed registries
3) requires no central database
4) does not require massive changes to any current protocols, but
rather relies on minor changes to proposals already in process, namely
incremental zone transfer, rhwois, and dnssec (secure DNS).
5) adds no new technical duties to IANA
6) fits very naturally into the DNS model
(Caveat: I am certainly not an expert in DNS internals, so I may not
be aware of some limitations of the proposals in the drafts. But they
look pretty good to me.)
The primary DNS servers for the shared domains and the nameservers for
the registries would need to support the proposed DNS protocols, and
perhaps some additional protocol mechanism. However, no nameservers
in the field would have to change.
Background
The set of IETF drafts that are proposing changes to DNS that
effectively include, I believe, all the functionality that we have
described as necessary for the CDB. In particular, the drafts are:
"Domain Name System Security Extensions", D. Eastlake, C. Kaufman,
08/02/1996.
"Mapping Autonomous Systems Number into the Domain Name System", D.
Eastlake, 12/27/1995
"Secure Domain Name System Dynamic Update", D. Eastlake, 02/22/1996.
"Incremental Zone Transfer in DNS", M. Ohta, 06/06/1996.
"A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)",
P. Vixie, 06/04/1996.
"Dynamic Updates in the Domain Name System (DNS UPDATE)", P. Vixie,
S. Thomson, Y. Rekhter,, 03/14/1996.
"Scheduled Expiration of DNS Resource Records", M. Patton,
02/21/1996.
"Deferred Dynamic Updates in the Domain Name System (DNS DEFUPD)", P.
Vixie, 05/23/1996.
Outline
IANA licenses shared registries for a TLD. Among other things, a
license grants to each of the registries a copy of a secret key that
allows them to do incremental zone transfers to the primary DNS server
for the TLD. (I don't discuss any other aspects of the license, and
just concentrate on the technical details.)
The relationship between the "nameservers" at the registries and the
primary nameserver for the TLD is a peculiar one. In fact the
"registry nameservers" that do the IXFRs might actually be attenuated
stubs that *only* do IXFRs.
The basic operations for supporting shared TLDs were RESERVE,
CONFIRM, LOOKUP, and DELETE.
A RESERVE is done by adding a Resource Record to the zone that
marks the new domain as belonging to the registry, with a pointer back
to the registry (IP address would probably be sufficient), an attached
timeout, and possibly authentication information. If the domain is
already present, of course, the reservation fails. The mechanism for
doing the reservation is an authenticated incremental zone transfer.
If the timeout expires the reservation is deleted automatically.
Which RRs to use to contain this data is an issue. Perhaps a new one
would need to be defined. Once again, however, since only the
registries and the primary nameservers involved in the reservation
scheme, the nameservers in the field will not be impacted.
A CONFIRM is done by updating the domain with a longer timeout (1 year
or more), and adding NS records for the domains nameserver. After the
timeout expires the domain is eligible to be deleted from the primary
nameserver. It is the responsibility of the end customer and the
registry to renew the name.
A LOOKUP is just a standard DNS query.
A DELETE is implementd through another authenticated IXFR request.
The whois data is maintained at the registry. Because the primary
nameserver has resource records that point back to the controlling
registry for each, the whois data is easily accessible, and a
slightly enhanced whois server would easily be able to do the
indirection to the registry for the data. This whois server could
reside anywhere -- it just needs to know to look at the nameserver
for the source of the whois data.
The case of registry failure is handled by requiring registries to
backup and escrow their databases at a different site.
That's about all there is to 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
