[dhcwg] Re: Last call for <draft-ietf-dhc-fqdn-option-02.txt>

Mark Stapp <mjs@cisco.com> Mon, 27 August 2001 16:57 UTC

Received: from optimus.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24544; Mon, 27 Aug 2001 12:57:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26824; Mon, 27 Aug 2001 12:56:42 -0400 (EDT)
Received: from ietf.org (odin []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26796 for <dhcwg@ns.ietf.org>; Mon, 27 Aug 2001 12:56:40 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24365 for <dhcwg@ietf.org>; Mon, 27 Aug 2001 12:55:20 -0400 (EDT)
Received: from mjs-nt.cisco.com ([]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA18601; Mon, 27 Aug 2001 12:56:08 -0400 (EDT)
Message-Id: <>
X-Sender: mjs@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 27 Aug 2001 12:56:07 -0400
To: mellon@nominum.com
From: Mark Stapp <mjs@cisco.com>
Cc: dhcwg@ietf.org
In-Reply-To: <200108271452.f7REqUi00426@grosse.bisbee.fugue.com>
References: <Message from Mark Stapp <mjs@cisco.com> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [dhcwg] Re: Last call for <draft-ietf-dhc-fqdn-option-02.txt>
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

I agree with you about the purpose of the bit, but I'm a little confused by 
your last paragraph. Do you mean that even if the server was configured by 
you, and it asked your client not to update grosse.fugue.com, you'd like 
your client to update that zone anyway? I guess I don't see the point of 
that: if the dns and dhcp share administration, the 'don't update' bit 
tells the client that the administrators don't want the client to do the 
update for the fqdn in the option. If you get to ignore that bit, why don't 
the win2k clients get to ignore it too, and fire updates into your zone?

-- Mark

At 10:52 AM 8/27/01 -0400, Ted Lemon wrote:

> > >If when you say, "If a client ... wants to be responsible for updating
> > >... then the client MUST ..." you're not talking about my machine as the
> > >"client", but specifically only the DHCP code on the machine, then the
> > >"if" clause is trivially false. My DHCP code only ever sends and receives
> > >DHCP packets. Any code on my machine that sends and receives DNS Update
> > >packets is by definition DNS Update code, not DHCP code.
> >
> > The DHCP client and server are exchanging information about the local
> > administrative domain, the one where the host is booting. If your DHCP
> > client wanted to maintain the name in the fqdn option, a name in a local
> > zone, it would have to comply with this requirement. Since it doesn't, it
> > doesn't.
>My client _always_ sends grosse.fugue.com in the FQDN option.  I
>thought that was how the FQDN option was supposed to be used.  It also
>always updates my DNS server.  It would be wrong for the DHCP server
>to tell me not to update grosse.fugue.com, unless it was administered
>by me (I own the fugue.com domain).  However, it's quite possible that
>it might do this anyway.  It could do this because it can't be
>configured to selectively permit or deny updates based on whether or
>not the client sent an FQDN, and the administrator wants to prevent
>the latter case (Microsoft Win2k clients will otherwise attempt to do
>the update in the local domain, causing errors to be logged by the
>local name server).   It might also be the case that the server
>administrator is not willing to let you set up a working PTR/A pair,
>and is trying to signify that by saying you shouldn't do an update.
>I don't think I am out of conformance with the spec if I ignore the
>no-client-update bit in the FQDN option - if I am, then you should
>probably change the relevant MUST to a SHOULD.   I have a feeling that
>that would address Stuart's objections... :'}
>                                _MelloN_

dhcwg mailing list