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

"Bernie Volz (EUD)" <> Mon, 27 August 2001 21:57 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id RAA01892; Mon, 27 Aug 2001 17:57:38 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id RAA06497; Mon, 27 Aug 2001 17:56:52 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id RAA06431 for <>; Mon, 27 Aug 2001 17:56:49 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id RAA01664 for <>; Mon, 27 Aug 2001 17:55:27 -0400 (EDT)
Received: from ( []) by (8.11.3/8.11.3) with ESMTP id f7RLujp13776 for <>; Mon, 27 Aug 2001 16:56:45 -0500 (CDT)
Received: from ( []) by (8.11.3/8.11.3) with SMTP id f7RLujT10327 for <>; Mon, 27 Aug 2001 16:56:45 -0500 (CDT)
Received: FROM BY ; Mon Aug 27 16:56:04 2001 -0500
Received: by with Internet Mail Service (5.5.2653.19) id <P4MP543N>; Mon, 27 Aug 2001 16:56:03 -0500
Message-ID: <>
From: "Bernie Volz (EUD)" <>
To: "'Mark Stapp'" <>,
Subject: RE: [dhcwg] Re: Last call for <draft-ietf-dhc-fqdn-option-02.txt>
Date: Mon, 27 Aug 2001 16:56:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12F43.10076940"
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>

I think in Ted's case the server would not return the same FQDN option if it wasn't
a server. Ted's saying that his client would always send the FQDN with, but that's not necessarily what the server would send back. Hence,
if the server sends back some other domain (such as if he was at an
IETF meeting), his client will go ahead and update the domain anyway.
I think that is OK. The client must just do what the server wants it to do about the
FQDN supplied by the server, it can't say what to do about the FQDN supplied by the

Or, am I wrong about this?

- Bernie

-----Original Message-----
From: Mark Stapp []
Sent: Monday, August 27, 2001 12:56 PM
Subject: [dhcwg] Re: Last call for <draft-ietf-dhc-fqdn-option-02.txt>

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, 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 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, unless it was administered
>by me (I own the 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