Date: Tue, 14 Dec 1993 22:54:59 +0500
From: dupuy@smarts.com (Alexander Dupuy)
Message-Id: <9312150354.AA05849@brainy.smarts.com>
To: uri@bunyip.com
Subject: DNS lookups for URLs (was: URN functionality from URLs)
First, apologies for the multiple copies of my original mail message. There's
a mailing list loop somewhere in Sweden - I hope it will be fixed before we
all get N copies of this message as well. Funny, how mailing loops always
strike just when a discussion gets going.
[A preemptive aside - If the extra copies drive you to unsubscribe, please
don't send your request to the mailing list, but to uri-request@bunyip.com (we
all knew that, I'm sure, but I've seen too many good mailing lists sink under
a looping barrage of unsubscribe requests).]
In <199312142059.PAA03573@wilma.cs.utk.edu> Keith Moore <moore@cs.utk.edu> says:
> Not everyone thinks this [DNS search paths] is a nice feature. Some people
> would even call it broken. Domain names (like URLs) are supposed to be
> absolute.
In <9312142028.AA21530@rodan.UU.NET> stripes@uunet.uu.net (Josh Osborne) agrees:
> I don't think you really want to use search paths that way. (Why? I don't
> know, it just seems unclean). If just want caching, just use a caching
> nameserver. (or for more aggressive caching be an unoffical secondary for
> the domain...) No problem there.
The purpose of putting in local DNS IX records for STANF URLs in other domains
is to provide caches for the files (objects) referenced by the URLs, not
caches for the IX records themselves (in that case, a caching nameserver would
be better). This sort of local cache for common references (RFCs,
dictionaries, etc.) will be very important, and is one of the reasons for
URNs, which are supposed to be location-independent.
Terry's original post on STANFs described how a local organization might set
up client configuration files that translated STANF URLs into local references
to nodes under an NNA/ (nonlocal naming authority) branch of the local URL
tree. I was simply suggesting that DNS search paths could be used to achieve
the same effect for all clients within a domain. If you don't want to do this
to your domain, well, you don't have to.
Now, as for whether DNS search paths are nice, well, look at RFC 1535 to see
how search paths (as implemented by all but the most recent BIND releases)
have a major problem (hint: what happens when you create an edu.com domain?).
Nonetheless, sometimes things which aren't nice are still useful.
In the same message, stripes@uunet.uu.net (Josh Osborne) asks, regarding my
comment about avoiding complexity in IX record "editing rules":
> More difficult for who/what? To enter? For the nameserver to track?
> To apply?
More difficult for the person setting it up to get right. Regular expressions
are extremely powerful, but the number of people who can get a non-trivial sed
script right the first time can probably be counted on one hand. Since the
underlying access method presumably provides some ability to reconfigure the
namespace (even FTP can be configured a bit with symbolic links), we should
encourage people to use those (presumably easier to set up) mechanisms
instead. Getting things right the first time around is especially important
if the names processed by this system are supposed to be "cast in stone", and
not changed because there was a bug in a editing rule that was fixed.
Now, after defending my proposed use of DNS, I'll play devil's advocate, and
make a point that seems to me to be more damning than the issue of DNS search
paths. That's the "WKS syndrome". For those of you who don't remember, the
original DNS RFCs defined a record type called WKS (well-known service) which
was supposed to list all the major TCP/IP services provided by each host (like
SMTP, FTP, etc.). How many WKS records have you seen recently? Of the four
experimental RR types defined in RFC-1035, the IBM AIX sendmail is the only
mailer I know that uses them (and it only uses MB and MG) although most
nameservers can support all four.
There are five additional RFCs (1101, 1183, 1348, 1383, 1464) defining 7
additional DNS RR types (AFSDB, RP, X25, ISDN, RT, NSAP, NSAP-PTR), two
additional uses for PTR records and two additional uses for TXT records. Of
these, only RP and network name PTR records are used by more than a tiny
fraction of domains, and I would estimate that they are used by far less than
10%. The only AFSDB records I could find were at transarc.com (even
andrew.cmu.edu didn't have any).
So it seems unlikely that a new DNS record type would be adopted by any
significant fraction of domains anytime soon. One approach to this problem
would be to use TXT records, which have the advantage that they are supported
by a significant fraction of DNS servers (though probably still not most of
them). But even in this case, it isn't clear that people will actually go to
the trouble of setting up this information on a wide enough scale for it to be
useful.
So although I feel that using DNS is the more elegant approach, I'm not yet
convinced that it is a good idea to tie URNs into a naming system that has a
lot of administrative inertia.
@alex