[dhcwg] Re: Last Call: DHCP Domain Search Option to Proposed Standard

Thomas Narten <narten@raleigh.ibm.com> Fri, 28 September 2001 18:39 UTC

Received: from optimus.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22079; Fri, 28 Sep 2001 14:39:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16121; Fri, 28 Sep 2001 14:37:50 -0400 (EDT)
Received: from ietf.org (odin []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16093 for <dhcwg@optimus.ietf.org>; Fri, 28 Sep 2001 14:37:49 -0400 (EDT)
Received: from extmail01m.raleigh.ibm.com (extmail01.raleigh.ibm.com []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22042 for <dhcwg@ietf.org>; Fri, 28 Sep 2001 14:37:43 -0400 (EDT)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com []) by extmail01m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id OAA30550; Fri, 28 Sep 2001 14:37:16 -0400
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com []) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with ESMTP id OAA27040; Fri, 28 Sep 2001 14:37:15 -0400
Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id OAA25641; Fri, 28 Sep 2001 14:34:51 -0400
Message-Id: <200109281834.OAA25641@rotala.raleigh.ibm.com>
To: Keith Moore <moore@cs.utk.edu>
cc: dhcwg@ietf.org
In-Reply-To: Message of "Thu, 27 Sep 2001 15:32:42 EDT." <200109271932.PAA20346@astro.cs.utk.edu>
Date: Fri, 28 Sep 2001 14:34:51 -0400
From: Thomas Narten <narten@raleigh.ibm.com>
Subject: [dhcwg] Re: Last Call: DHCP Domain Search Option to Proposed Standard
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

Keith Moore <moore@cs.utk.edu> writes:

(in a message sent to the iesg)

> The problem I have with this option is that it invites implementors
> and network administrators to presume that a host's domain should be 
> tied to a host's location in the network - when these are intentionally, 
> and by design, entirely separate.  For instance, a mobile computer user 
> who wishes DNS lookups to be performed relative to a particular domain 
> should not have this choice overridden by each POP to which he connects.

> (The fact that protocol designers often try to use DNS lookups as a 
> means to discover topologically close services does not change this.
> There is an inherent conflict between using DNS as a way to discover
> services relative to a domain and using it as a way to discover
> services relative to a network location, but the intent of DNS 
> clearly favors the former.)

> Host DHCP implementations therefore should not blindly accept Domain 
> Search information from a DHCP server.  Local configuration of any 
> DNS information (including not just search domains, but also DNS servers) 
> should override anything supplied by DHCP.

> Keith

I am sympathetic with your general point. I'll also note that this
arguably applies to a number of other existing DHCP options. I don't
believe right off that this point is explicitely addressed in the
other cases either.

There is a general issue of when should (and shouldn't) a DHCP-learned
option override a manually configured one. My guess is that
DHCP-learned options generally do not override manually configured
ones. But I suspect that this is all considered implementation
specific. Can other DHC WG members comment? What do existing RFCs say
about this point?

Finally, what do you propose? I.e., "send text" :-) Would it suffice
to add some language stating that in the case of this option, it
should not override a manually configured search list?


dhcwg mailing list