Re: Let's assume DNS is involved

[Walt Howard <howard@eng.utah.edu>]

On Fri, 12 Apr 2002, Jakob Schlyter wrote
> On Tue, 9 Apr 2002, Walt Howard wrote:
> > I would like to see [a reference to] a list of reasons why srv-style
> > names cause unhappiness.  I have subscribed to this list for a while,
> > so a message-id is sufficient.
>
> magic naming, which srv-style names are, isn't that beautiful. I'm
> thinking more into using a combination of NAPTR & APPKEY, almost as in
> draft-daigle-napstr-00.txt, e.g:
>
> host.example.com. NAPTR 1 10 "p" "APPKEY+ipsec" "" ipsec.host.example.com.
> ipsec.host.example.com. APPKEY ...
>
> this would:
>
> a) limit the size of the RR for host.example.com.
> b) remove the magic naming hack

I read the draft-daigle-napstr-00.txt and thought it looked interesting,
so I implemented NAPTR RRs pointing to the SRV RRs in a domain for
which I do the DNS records.  A problem leaped out which I must mention:
this solution does not remove the magic names; instead it moves them
from the record label to the fourth item of RDATA.  The names are still
magic in the sense that the resolving software must have some prior
knowledge of what those names should be in order to find the right one.
Probably some existing list from IANA could be used for this purpose,
but any RFC defining this method must specify where the list  is defined.

RFC 2219 lists a number of magic hostnames.  Some other document makes
the names of the existing TLDs magic.  RFC 2782 makes "_tcp" and "_udp"
magic as subdomains.  I do not advocate the uncontrolled spread of
magic in the DNS, but we are living with a lot already and I do not
observe significant damage from that.  Perhaps I am not observant
enough?  :-)

I agree with Jakob's point that we should try to keep the size of the
RRset associated with a hostname small.  That will almost certainly
require that the rather large APPKEY/CERT RRs be detached from the
host's RRset.  Whether the detaching is best achieved by adding one
or more NAPTR RRs to the host's RRset, or by generating magic names
from the host's FQDN in a well-specified way, or by some other method,
appears to still be open to discussion.

Both the NAPTR method and the magic-name method admit the possibility
of keeping APPKEYs/CERTs in a separate subzone.  Is there anyone who
feels that is either a bad idea or an unimportant goal?
--
Walt Howard
InterNet: whoward@ieee.org
BellNet: +1 801 581 5827