Date: Thu, 15 Jul 1993 13:54:06 +0100 (BST)
From: Martin Hamilton <M.T.Hamilton@lut.ac.uk>
Subject: Re: URNs in the DNS
To: Peter Lister <P.LISTER@mail.cranfield.ac.uk>
In-Reply-To: <9307140959.AA22623@xdm039>
Message-Id: <Pine.3.07.9307151306.B4919-c100000@lust>
Peter said:
> Martin, what you are suggesting (arbitrary text information from the
> DNS) already exists and it's called Hesiod. Whatever happens, please
> can we respect the existing conventions of Hesiod? Use class HS rather
> than IN; and map the information onto the domain so as to avoid clashes
> with other information currently in the DNS/Hesiod.
I think that whether you put the URNs in the HS or IN class
is really just a question of which approach breaks fewer
implementations - the HS class and TXT RR are certainly widely
supported, at least amongst recent O/S releases from most
workstation vendors - though not in the products of a certain
group whose name rhymes with Bun Microsystems... (fixed in
$olaris 2 perhaps? :-) If there's anyone listening who has
resolver/nameserver experience with Macs & PCs, tell us the
gory details!
The organisational structure adopted for this information is
actually quite an issue -- this is why I didn't suggest anything
along the lines of <URN:domain::finger.gnu.urn.ns.your.domain
.here:::>, which is something that I suspect might or might not
follow, depending on the success of this initial effort.
For what it's worth, I prefer the idea of a local administrator
taking responsibility for the URNs in their domain, and using
the regular TTL and caching mechanisms to take care of URN
distribution, rather than some scheme which attempts to make
finger.urn.ns point to the same thing, no matter where you
are. (Isn't CNAME best suited to this sort of thing anyway?)
Consider: foo.bar.lut.ac.uk (put whatever you like in foo.bar
for now) holds pointers to on-line copies of technical reports
produced at Loughborough. Better still, let's say mrrl9337 points
to the "URNs in the DNS" blurb. Now I can give you the semi-
permanent address <URN:domain::mrrl9337.foo.bar.lut.ac.uk:::>
for the document.
So, what I'm suggesting is that you'd *actually* be given a URN
for GNU finger that looked something like <URN:domain::finger.foo
.bar.gnu.ai.mit.edu:::>. How does that sound?
> The MX record has a very useful priority value. I would really like to
> have that in a URL system as well, so that sites explicitly rank
> themselves. In a TXT RR, we have to add a "PRIO=n" field to the text.
> MX records prefer LOWER values, so we'd better stick to that convention
> as well. In the case above, the ac.uk information would tell us that
> there are a few sites of equal priority for GNU software in the UK, and
> there are also other places for UK sites to look elsewhere in the world
> if we can't find what we want in the UK BEFORE trying to search the
> world. This prevents a client which has failed to find a working UK
> site from ranking servers in the US (good connectivity to the UK, and
> to be preferred) equally with (say) Australia or Japan.
I like the prioritising idea, but I'm afraid we come back to the
by-now stale and cheesy debate about the amount of information
necessary to pick up an object - and this is perhaps where the
analogy with MX records breaks down. For sure, it would be nice
to give hints about which URLs you would prefer people to use,
though not necessarily from the point of view of connectivity --
wouldn't the priority field be useful to indicate data quality? :-)
At about this point I guess we slip into circular conversations
about the role of a hypothetical directory service which returns
perhaps URNs (semi-permanent things) and URLs (temporary things) as
the result of searches...
> Congratulations to everyone who read this far. Does this all make
> sense? I heartily applaud the idea of URNs in the DNS, and I hope that
> pointing out problems early will result in a working scheme before long.
As I said in the previous posting, I don't think putting URNs into
the DNS is necessarily The Answer, but it's An Answer, and it might
be quite useful in the short term. In the long term? Well, BIND
is certainly a "moving target"!
See ya,
Martin