# Re: new port for DNS

Alexander Dupuy (dupuy@smarts.com)
Wed, 21 Jun 1995 18:45:52 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Paul Hoffman: "Re: new port for DNS"
- Previous message: Michael Mealling: "Re: new port for DNS"
- Maybe in reply to: Michael Shapiro: "new port for DNS"
- Next in thread: Paul Hoffman: "Re: new port for DNS"

    Date: Wed, 21 Jun 1995 18:45:52 -0400

    From: dupuy@smarts.com (Alexander Dupuy)

    Message-Id: <9506212245.AA28021@just.smarts.com>

    To: Michael.Mealling@oit.gatech.edu

    Subject: Re: new port for DNS

I wrote:
>>All of the DNS-based URN proposals now on the table use DNS merely to locate a
>>URN resolver; the final step is done using another protocol (e.g. HTTP).
>>Therefore, you only need an in with the system admins if you want your URNs to
>>use funky names based on OIDs or the like. Ordinary people can just run a URN
>>resolver on their home machine, and use the DNS name of that machine in their
>>URNs.

Michael Mealling replied:
> But using the DNS name of their machine in the URN is not persistant. If
> we do that we might as well be using URLs. DNS hostnames as persistant names
> has already been shown to be non-presistant beyond the very top levels.
>
> Its not the ones that can hire the sysadmins that concern me. Its documents
> generated by regular people that are valuable to historians that people
> like the library community want to preserve in some way. The names
> need to be able to support that in a way that doesn't invalidate the
> name.

This is a good point in favor of a separate URN top-level domain, which I have
previously felt to be unnecessary. Actually, after seeing this argument, I
would now favor a separate URN top-level domain to be used for locating all
URN resolvers, in order to keep the regular DNS names (which do tend to change
over time) out of URNs.

I also wrote:
>>3. Users behind firewalls that want to resolve URNs will be screwed until such
>>time as firewalls provide proxy service for the URN-DNS port. Given the
>>increasing popularity of firewalls, not just at commercial sites, but even
>>Universities (e.g. Brown) this seems like a significant barrier to the
>>acceptance of URNs. If users behind firewalls can use URLs, but can't resolve
>>URNs, I think URNs will go nowhere fast.

Michael Mealling replied:
> This is one of the more valid points you have. This point alone could
> be a show stopper. Would an alternative based on named being modified to
> allow a port argument to an NS record be acceptable?

This has serious problems in terms of deployment. If it only required
modifying the nameservers which would serve URN domains, it wouldn't be a big
problem (we may need a new version of named that understands URN RRs in any
case). [If we use DNS TXT records to indicate the location of URN resolvers,
as was suggested by myself, and others, well over a year ago, we don't even
need modifications to named.]

But since the iterative chaining through NS records is usually done by the DNS
server which the client resolver contacts, all the installed DNS servers which
serve clients (as opposed to just serving other servers) would need to be
updated. This is impractical (especially now that Microsoft is developing
their own DNS server which is not based on BIND). In addition, it might
require that the client contact a DNS server on or outside the firewall;
otherwise the DNS server might not be able to resolve via alternate ports.

On balance, I think that the best solution is a separate top-level URN domain
using the existing DNS ports and protocols, with subdomains of URN based on
long-lived identifiers (OIDs or whatever).

This architecture allows several levels of URN allocation, suitable for
publishers ranging from individuals to organizations like LoC:

0. Authors can publish documents through electronic publishers (at level 3 or
5) by sending them a document and having them make it available through
their own URN and URL services. This is roughly the equivalent of the
"vanity press". The URLs and URNs would be assigned by the publisher and
sent to the author. An annual fee might be associated with the maintenance
of the URL. Ideally, the URN would be maintained "forever". No ongoing
computer access is required of the author. Initial access might just be
conversion of the document into electronic form.

1. Authors can publish documents on a one-off basis by sending an electronic
publisher (at any level from 2 to 5) a valid URL and having the publisher
allocate a single URN which will be mapped to that URL by the publisher's
own URN service. This is roughly the equivalent of getting a LoC number
for a self-published document. A fee might be charged initially, and each
time the URN->URL mapping needed to be updated. Again, ideally, the URN
would be maintained "forever". The author must have sufficient ongoing
computer access (files on FTP or HTTP server) to keep the URLs valid.

2. Authors can publish series by sending an electronic publishing authority
(at level 4 or 5) the URL (address, port, resolution protocol) of a URN->URL
resolver service and having the authority allocate a URN namespace for them
and register the URN resolver for this namespace in their URN DNS zone.
This is the equivalent of getting an ISBN publisher number. A fee might be
charged initially, and each time the location(s) of the URN->URL resolvers
in the DNS information needed to be updated. The author must have
sufficient ongoing computer access to run a URN->URL resolver - this
doesn't require special privileges on the machine. The author need not
actually have resources to serve the URL, if the only URNs published are
for existing URLs provided by others.

3. This is just a combination of levels 1 and 2, where the author provides
both URN and URL resolution.

4. Authors who publish sufficiently large numbers of documents that they wish
to split their URN namespaces among several URN->URL resolvers can do so by
getting an electronic publishing authority (at level 4 or 5) to both
allocate a URN namespace to them, and delegate the corresponding DNS domain
for that namespace. If we grandfather in things like ISBNs, authors with
ISBN publisher numbers might only need the DNS domain delegation. A fee
might be charged initially; once the domain has been delegated, all updates
(including the locations of the DNS servers for the delegated domain) are
managed by the author, so no recurring fees would be necessary. The author
must have sufficient ongoing computer access to run a DNS server and
URN->URL resolver - this will typically require special privileges on the
machine which runs the DNS server.

5. This is just a combination of levels 1 and 4, where the author provides
both URN and URL resolution.

@alex

    --
    inet: dupuy@smarts.com
    Member of the League for Programming Freedom -- write to lpf@uunet.uu.net
    GCS d?@ H s++: !g p? !au a w v US+++$ C++$ P+ 3 L E++ N+(!N) K- W M V- po- Y+
         t+ !5 j R G? tv-- b++ !D B- e>* u+(**)@ h--- f+ r++ n+ y+*

- Next message: Paul Hoffman: "Re: new port for DNS"
- Previous message: Michael Mealling: "Re: new port for DNS"
- Maybe in reply to: Michael Shapiro: "new port for DNS"
- Next in thread: Paul Hoffman: "Re: new port for DNS"