Re: [dhcwg] Revision of DHCPv6 DNS configuration options

Robert Elz <kre@munnari.OZ.AU> Mon, 03 March 2003 04:13 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25888; Sun, 2 Mar 2003 23:13:25 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h234N6p27432; Sun, 2 Mar 2003 23:23:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h234LGp27369 for <dhcwg@optimus.ietf.org>; Sun, 2 Mar 2003 23:21:16 -0500
Received: from ratree.psu.ac.th (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25841 for <dhcwg@ietf.org>; Sun, 2 Mar 2003 23:10:56 -0500 (EST)
Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h234BjO09192; Mon, 3 Mar 2003 11:11:46 +0700 (ICT)
Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h234BUo26091; Mon, 3 Mar 2003 11:11:30 +0700 (ICT)
From: Robert Elz <kre@munnari.OZ.AU>
To: Jun Xie <junxie@cisco.com>
cc: Ted Lemon <Ted.Lemon@nominum.com>, dhcwg@ietf.org, Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] Revision of DHCPv6 DNS configuration options
In-Reply-To: <4.3.2.7.2.20030301111923.00ae1360@mira-sjcm-2.cisco.com>
References: <4.3.2.7.2.20030301111923.00ae1360@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030228202840.00b00300@mira-sjcm-2.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 03 Mar 2003 11:11:30 +0700
Message-ID: <26089.1046664690@munnari.OZ.AU>
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>

    Date:        Sat, 01 Mar 2003 11:29:34 -0800
    From:        Jun Xie <junxie@cisco.com>
    Message-ID:  <4.3.2.7.2.20030301111923.00ae1360@mira-sjcm-2.cisco.com>

  | Nothing prevents a stub resolver from sending further queries to the server
  | referred by an iterative server,

No, but the point of the option is (or should be) to provide the addresses
of "things" for which that will not be required - that is, things which will
do recursive resolution for the (stub) resolver.

If the stub resolver is able to do iterative resolution, then all it needs
is a list of the root servers, and I really don't believe this option should
be used for that - and it should be made clear that that isn't what should
be sent in this option.

It is truly unfortunate that the DNS has never created a name for this
"thing" which has stuck - "DNS server" was used originally, but many,
rightly I feel, object to that one as being too vague - a DNS server isn't
required to do recursive resolution, here we want a thing which will do
recursive resolution (at least for the clients being instructed to use it)
and so calling it a "DNS Server" isn't really the best idea.

Calling it a "resolver" is no better however, the resolver is the thing
that is going to be using this information really, and while a recursive
server can be thought of as a resolver, which gets its query passed to
it using DNS protocols, rather than the more usual function calls, it
is still a stretch on most people's interpretation of the term - that is,
using it suggests to people something other than what is intended.

I'd suggest using some label that is neither of those - and since the DNS
community has failed to produce a name for this thing, I see no reason for
this WG to not just go ahead and pick a suitable name, and define it.
With any luck, it can then transfer itself into the DNS lexicon, and
the whole DNS community will be grateful (trying to continually find some
good term which will unambiguously describe the thing that is of interest
here is a recurring nightmare - and has caused misunderstandings quite
often in the DNS world).

I have no particular suggestion to offer (if I had a really good one,
then perhaps everyone would be using it by now), but something along
the lines of "DNS cache server" or "DNS caching resolver" or perhaps
just "DNS cache".   What is clear however, is that whatever name is
used (including DNS server and DNS resolver) its function needs to be
clearly spelled out in this doc - either this will be a new term, or
the re-use of an ambiguous one, and so this doc cannot simply rely upon
saying "The address of a DNS XXX goes here" and just assume that what
a "DNS XXX" is will be clear to everyone (and once more for emphasis,
this applies whatever is substituted for XXX).

kre

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg