Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt))

Robert Elz <kre@munnari.OZ.AU> Sun, 08 April 2001 19:24 UTC

Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11972 for <dnsext-archive@lists.ietf.org>; Sun, 8 Apr 2001 15:24:04 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mKMz-000FPN-00 for namedroppers-data@psg.com; Sun, 08 Apr 2001 11:57:05 -0700
Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mKMy-000FP9-00 for namedroppers@ops.ietf.org; Sun, 08 Apr 2001 11:57:04 -0700
Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f38Im3U01740 for namedroppers@ops.ietf.org; Sun, 8 Apr 2001 14:48:03 -0400 (EDT)
Received: from munnari.oz.au ([128.250.1.21]) by psg.com with smtp (Exim 3.16 #1) id 14mEiJ-0005jJ-00 for namedroppers@ops.ietf.org; Sun, 08 Apr 2001 05:54:43 -0700
Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id MA15731; Sun, 8 Apr 2001 22:54:37 +1000 (from kre@munnari.OZ.AU)
From: Robert Elz <kre@munnari.OZ.AU>
To: "Eric A. Hall" <ehall@ehsco.com>
Cc: namedroppers@ops.ietf.org
Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt))
In-Reply-To: Your message of "Sat, 07 Apr 2001 19:03:43 MST." <3ACFC6FF.42237B18@ehsco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 08 Apr 2001 22:54:36 +1000
Message-Id: <26300.986734476@mundamutti.cs.mu.OZ.AU>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

    Date:        Sat, 07 Apr 2001 19:03:43 -0700
    From:        "Eric A. Hall" <ehall@ehsco.com>
    Message-ID:  <3ACFC6FF.42237B18@ehsco.com>

  | I'm sure you didn't mean the example I'm about to give but I am taking the
  | bait anyway. :)

It is actually not a bad example to analyse.

  | The problem with being too liberal wrt DNS data is that it dillutes the
  | effectiveness of the lookup service.

Not necessarily.

  | If for example under the "anything goes" principle somebody defines the
  | dreaded My-MP3-Files RR which returns records for every MP3 cataloged on a
  | specific server, it is possible for thousands of RRs to be returned.

Yes, and for that reason (the RRset would not be expected to fit in any
rational packet), that wouldn't be a sane thing to store, technically.

  | However, those answers will also get returned whenever the associated
  | domain name is queried with a qtype=*

Yes, though qtype=* (ANY) as a reason for dropping something doesn't
concern me greatly - if there was no better reason not to do it, I'd
hesitate to refuse on those grounds alone.

  | Ergo, everytime sendmail tries to enumerate the RRs for a destination
  | domain name, it would get overloaded with My-MP3-Files RRs, which would
  | either dillute or completely destroy the usability of DNS for simple
  | lookup functions.

I won't debate whether the way sendmail chooses its lookups is sane or not,
it certainly isn't required that it operate that way.   But anyone who chose
to load up thousands of RR's at the kind of domain label that would be used
for other purposes (like mail) would deserve to have all kinds of things
start failing.   Inventing a new name for such things (say mp3.my.dom.ain)
is not difficult to achieve (assuming it was rational to use the DNS for
a purpose like this - which it isn't).

  | That's maybe an exaggeration, but maybe it isn't, and really it will all
  | depend on how liberal the line is drawn. I advocate hard-liner positioning
  | in this matter. Heck it might even be worth a policy thing, no RRs get
  | approved without passing through DNSEXT first.

I think we already have that policy - the philosphical question being asked
is when and why should new RR records get approved by DNSEXT, and when should
they be rejected.

Eg: if you were to take music (mp3s or anything else), it (just might possibly
be reasonable to encode the aritsi/title (or just title) (of is music
has anything equivalent to an ISBN, perhaps that identifier) as a domain name,
and then define a few RR's to allow a server for that particular music to be
located (then again, perhaps SRV is already that).

kre



to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.