Message-Id: <9307140959.AA22623@xdm039>
To: uri@com.bunyip
Subject: Re: URNs in the DNS
In-Reply-To: Your message of "Tue, 13 Jul 93 18:49:59 BST." <9307131750.AA15198@xdm001>
Date: Wed, 14 Jul 93 10:58:59 BST
From: "Peter Lister, Cranfield Computer Centre" <P.LISTER@mail.cranfield.ac.uk>
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.
> So, if <URN:domain::finger.foobar.lut.ac.uk:::> were to be used as a
> identifier for the latest version of the GNU Finger program, the placement of
> the following entries in the DNS for the domain finger.foobar.lut.ac.uk
>
> finger TXT "URL=ftp://sunsite.unc.edu/pub/gnu/.cap/finger-1.37.tar.gz"
> finger TXT "URL=ftp://theta.iis.u-tokyo.ac.jp/pub1/GNU/finger-1.37.tar.gz"
> finger TXT "URL=ftp://utsun.s.u-tokyo.ac.jp/ftpsync/prep/finger-1.37.tar.gz"
In Hesiod, a normal mapping is finger.urn.ns.foobar.lut.ac.uk in class
HS. 'ns' separates the Hesiod info from the rest of the DNS, and 'urn'
makes it clears that we are looking for a urn, not (for instance) a
user by that name. Braindead nameds don't understand class HS, and will
explode if exposed to it. However, as you've already noted, some don't
understand type TXT either, so many people will probably need to mend
their nameds anyway. A plus is the code for Hesiod is already written,
and in use at various sites. No wheels to reinvent. (Have a look at
ccprl.passwd.ns.cranfield.ac.uk (class=HS, type=TXT)).
There are more serious problems of scale with Hesiod, since Hesiod is
best at providing most of it's information to the local site, or to
remote sites which specifically know where to ask. As described, the
URN is stored relative to the local domain name, i.e.
finger.urn.ns.lut.ac.uk is NOT the same as
finger.urn.ns.cranfield.ac.uk. Is this A Good Thing or A Bad Thing? I
think (on the whole) Good, in that local preferences can be imposed on
the "best" URL to pick, However, the "U" stands for "Universal", and
there is much of scope for confusion. It is reasonable to expect that
finger.urn.ns.cranfield.ac.uk is guaranteed to get me the same program
as finger.urn.ns.lut.ac.uk or finger.urn.ns.athena.mit.edu, though
hopefully, my "local" version results in a url which points to an ftp
site in London, not Cambridge, MA. However, this implies that EVERY
domain in the world needs to know about EVERY URN in the world, which
duplication results in a vast inflation of information and (inevitably)
results in chaos, since no-one would ever be up to date. It rather
defeats the point of the DNS.
The URN in the example domain above is simply "finger", the rest
(urn.ns.lut.ac.uk) is stuff for the DNS/Hesiod. In practise, URNs
contain more information than this, including the naming authority. As
I see it, what's required is a convention to search for the naming
authority, then ask a site which has information about the publisher
for the nearest local site which can serve the information we want.
So - using GNU finger as an example - I ask the local DNS who has GNU
info, and it starts off at cranfield.ac.uk, then ac.uk, uk and '.'. It
should find that cranfield.ac.uk has a few gnu sources (but not
finger), and then that src.doc.ic.ac.uk actually has finger and other
GNU stuff for ac.uk sites. If src.doc.ic.ac.uk is unavailable, then
lets try uk and '.' (the root), which tells us about GNU sites worldwide.
In effect, the behaviour is similar to the existing NS record; which
has the effect of passing on the enquiry elsewhere. The difference is
that the NS record assumes that all servers are equally valid, whereas
the best local server for a URL differs depending on where the client happens to be.
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.
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.
Peter Lister p.lister@cranfield.ac.uk
Computer Centre,
Cranfield Institute of Technology, Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL UK Fax: +44 234 750875