Date: Wed, 23 Feb 1994 21:47:59 +0500
From: dupuy@smarts.com (Alexander Dupuy)
Message-Id: <9402240247.AA28196@brainy.smarts.com>
To: jcurran@nic.near.net, mitra@pandora.sf.ca.us
Subject: Re: URN to URC scenario
John Curran writes:
> Is there a particular reason to jump at the use of DNS as a URN->URL
> resolution mechanism? I have no problem with using DNS to find such
> servers, but think that it's hasty to select DNS as the right mechanism
> for URN->URL mapping until we know what properties the resolution server
> should have.
While there was some discussion of using DNS as a URN->URL resolution
mechanism last year on this list, nobody other than Rob Raisch has mentioned
it recently, and he only said that he had done it, not that it was necessarily
a good approach.
So there appears to be consensus that DNS would only be used to find the
URN->URL servers (URN->URC servers, in Mitra's scenario). This is true for
all the DNS configurations being discussed, whether they use TXT, A, or CNAME
records, a new URN.INT domain or existing DNS domains.
Mitra writes:
> I specifically didnt propose in the scenario using the TXT record or whatever
> in the DNS. The scenario uses DNS for looking up URN->URC servers in the
> manner it has always been used for servers, i.e. a CNAME record, with the
> huge advantage that a simple call to "gethostbyname" will find you
> a server without knowing any of the esoterics of DNS.
A call to "gethostbyname" doesn't find you a URN->URC server, it finds you an
IP address. You still need to know the protocol and port number to set up a
connection. Even if everybody standardizes on whois++/tcp as the protocol, I
would expect that some sites will want to have separate whois++ servers for
White Pages and for URNs listening on different ports, while other sites will
want to have just one whois++ server for both. Depending on a "well-known"
port number will make life difficult for one or the other of these two groups
(depending on whether the well-known port is the same as the one for regular
whois++ service or not).
Using DNS TXT records to store a URL which describes the URN->URC server
allows us to specify different port numbers, and if we want, we can experiment
with other protocols (http is probably the only reasonable alternative). It's
also possible to have multiple TXT records with the same name, to spread the
load of URN->URC lookups across multiple servers - you can't do that with
CNAMEs (it's possible if you use A records, but then you are tying the
multiple servers to specific IP addresses, which is inconvenient if those
addresses ever need to change). This will be very important for scalability.
If we want, we can add precedence information (ala MX records) to TXT records;
this also can't be done with CNAMEs.
As for CNAMEs being easier to support in DNS than TXT records, Martin is wrong
when he says that "it's just a matter of adding one line to the domain" in
either case; CNAMEs are actually more difficult, because they apply to ALL
record types, not just address lookups; it's illegal to have both a CNAME and
other records for a domain name. On the other hand, there's no problem adding
a TXT record for a domain name, even if there are already other records for
the name.
There haven't been any significant DNS implementations in years which don't
support TXT records (TXT records are in the original DNS standard; they aren't
one of those recent additions like RP records). In any case, everyone else
but me seems to feel the DNS records for locating URN->URC servers should be
in some URN.INT domain; I would hope that the DNS administrators for that
domain would be able to configure a TXT record correctly.
I actually suspect that if DNS administrators are really as inept or unhelpful
as everyone seems to think that they are, that having a single URN.INT domain
is probably a worse idea than using existing domains for registering URNs.
Successfully configuring a new delegated subdomain is a lot more complicated
than adding a TXT record, and if the TXT (or CNAME) records for URN->URC
servers are all in one URN.INT zone because nobody can get their DNS
administrators to set up a new DNS zone, the domain servers for URN.INT will
be pretty overworked in five or ten years.
@alex