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

Kevin Darcy <kcd@daimlerchrysler.com> Sat, 07 April 2001 05:19 UTC

Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29419 for <dnsext-archive@lists.ietf.org>; Sat, 7 Apr 2001 01:19:51 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lksf-0009eo-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 22:03:25 -0700
Received: from [216.168.245.71] (helo=h236.s254.netsol.com) by psg.com with esmtp (Exim 3.16 #1) id 14lksZ-0009e6-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 22:03:23 -0700
Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3752jO01632 for namedroppers@ops.ietf.org; Sat, 7 Apr 2001 01:02:45 -0400
Received: from fxshpr06.extra.daimlerchrysler.com ([208.154.80.165] helo=fxshpr06.is.chrysler.com ident=firewall-user) by psg.com with esmtp (Exim 3.16 #1) id 14lhjU-00015I-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 18:41:44 -0700
Received: (from uucp@localhost) by fxshpr06.is.chrysler.com (8.9.0/8.9.0) id VAA23536 for <namedroppers@ops.ietf.org>; Fri, 6 Apr 2001 21:36:44 -0400 (EDT)
Received: from nodnsquery(129.9.202.19) by fwshpr06.is.chrysler.com via smap (V5.5) id xma023528; Fri, 6 Apr 01 21:36:07 -0400
Received: from daimlerchrysler.com (clkcdts1.is.chrysler.com [129.9.209.47]) by odmrspr1-pf0.oddc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id f371f4611969 for <namedroppers@ops.ietf.org>; Fri, 6 Apr 2001 21:41:04 -0400 (EDT)
Message-ID: <3ACE7019.7CFE8F72@daimlerchrysler.com>
Date: Fri, 06 Apr 2001 21:40:41 -0400
From: Kevin Darcy <kcd@daimlerchrysler.com>
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.8 sun4u)
MIME-Version: 1.0
To: namedroppers@ops.ietf.org
Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt))
References: <20010405154908.A92004@open.nlnetlabs.nl> <200104060317.UAA13324@toad.com> <E14lVXT-000Hev-00@rip.psg.com> <3ACE2367.32018AA0@daimlerchrysler.com> <3ACE3E31.1230A53A@ehsco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eric A. Hall wrote:

> > > in general, we discourage storing non-dns data in the dns.
> >
> > What is the definition of "DNS data", actually?
>
> Actually, it's probably a good idea to develop a concept consensus.
>
> My definition is that the DNS is a lookup service similar to ARP. It just
> happens to be distributed across a collection of interconnected partitions
> in a hierarchical structure -- and there's a bunch of referral stuff to
> make sure queries are sent to the right place -- but in the end devices
> just issue targetted lookups for named resources and they expect an
> unambiguous and consistent answer.
>
> In that model, www.ehsco.com., mail.daimlerchrysler.com and ops.ietf.org
> are all peer entries in a massive *FLAT* database (they happen to be
> stored in separate partitions represented by a namespace but the global
> database itself is flat).
>
> Stuff that belongs in DNS is stuff that benefits from being used in a
> non-authenticated, unambiguous, lightweight lookup service which is backed
> by a global hierarchy of independent partitions. Stuff that doesn't belong
> is anything that requires authentication, is ambiguous, can be served by a
> standalone lookup, or consumes more valuable resources than it provides.

This is possibly too narrow a definition. With DNSSEC, authentication of
queries is possible and perhaps even desirable. As for "ambiguous", what
exactly do you mean by that term? It is perfectly normal and acceptable for
different clients to get different answers to the same DNS question
(depending on their source address and/or which DNS server they ask, when
they ask it, etc.). Does that constitute "ambiguity"? As for "consumes more
valuable resources than it provides", we'll wait to see how efficient DNSSEC
proves to be :-)

> MX RRs work okay in that model. SRV RRs work okay (if they are picked up
> and used to refer to richer or low-commodity-value services). Application
> configuration does not belong (local only). User data does not belong
> (requires authentication).
>
> or was your question rhetorical

Would I ask a rhetorical question? :-)

No, actually, it wasn't rhetorical. I'm looking for a *principled* standard
by which to judge what kinds of data should go into DNS and what kinds of
data shouldn't. Seems to me the determinations have been pretty much
_ad_hoc_ thusfar.

I should perhaps point out that I have no vested interest here. I have no
proposals in mind for new resource-record types, or new uses for existing
types, that could reasonably be considered "non-DNS data". I just don't like
arbitrariness or even the appearance of same.

Question: wasn't it the whole *point* of DNSSEC to offer a secure key
repository to applications? It's hard to believe that so much time and effort
would be expended just to secure DNS *itself*...


- Kevin





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