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.
- Re: Signature at parent (draft-ietf-dnsop-parent-… Ted Lindgreen
- Re: Signature at parent (draft-ietf-dnsop-parent-… Olaf Kolkman
- Re: Signature at parent (draft-ietf-dnsop-parent-… Roy Arends
- Re: Signature at parent (draft-ietf-dnsop-parent-… Miek Gieben
- Re: Signature at parent (draft-ietf-dnsop-parent-… Edward Lewis
- Re: Signature at parent (draft-ietf-dnsop-parent-… Edward Lewis
- Re: Signature at parent (draft-ietf-dnsop-parent-… Edward Lewis
- Re: Signature at parent (draft-ietf-dnsop-parent-… John Gilmore
- Re: Signature at parent (draft-ietf-dnsop-parent-… Olaf Kolkman
- Re: Signature at parent (draft-ietf-dnsop-parent-… Brian Wellington
- Re: Signature at parent (draft-ietf-dnsop-parent-… Ted Lindgreen
- Re: DNS vs. non-DNS Data (was Re: Signature at pa… Kevin Darcy
- Re: Signature at parent (draft-ietf-dnsop-parent-… Ted Lindgreen
- Re: DNS vs. non-DNS Data (was Re: Signature at pa… Eric A. Hall
- Re: Signature at parent (draft-ietf-dnsop-parent-… Dan Massey
- DNS vs. non-DNS Data (was Re: Signature at parent… Kevin Darcy
- Re: Signature at parent (draft-ietf-dnsop-parent-… Randy Bush
- Re: Signature at parent (draft-ietf-dnsop-parent-… Ted Lindgreen
- Re: Signature at parent (draft-ietf-dnsop-parent-… Peter Koch
- Re: DNS vs. non-DNS Data (was Re: Signature at pa… Eric A. Hall
- Re: Signature at parent (draft-ietf-dnsop-parent-… Brian Wellington
- Re: Signature at parent (draft-ietf-dnsop-parent-… Edward Lewis
- Re: Signature at parent (draft-ietf-dnsop-parent-… Edward Lewis