Subject: dhcp-dns-10: how does server tell client "no dynamic dns updates"?

From: Irwin Tillman <[email-masked]>
Date: Thu, 2 Sep 1999 09:53:58 -0400 (EDT)

With regard to dhcp-dns-10, what is the correct behavior in the following
scenario:

  The IP addresses being served by the DHCP server (even those
  it will allocate dynamically) are already registered in DNS (both
  A records and PTR records), and the DHCP server knows this.
  (E.g. even the addresses that will be allocated dynamically by the
  server have been registered perhaps according to some local
  naming convention, such as "dynamic-23.my-company.com.")  

  A client issues a DHCPDISCOVER or DHCPREQUEST containing the Client FQDN
  option, and the server responds with a DHCPOFFER or DHCPACK.

  Regardless of the state of the 'S' flag in the option sent by
  the client, the server wants to communicate to the client: "Your
  FQDN is 'X'. I don't want you to attempt to update the A record for 'X'.
  I will not attempt to update the A record for 'X' nor the PTR record for
  the IP address I am offering or assigning to you.  DNS already
  contains a correct A record and PTR record for the lease I am
  offering or assigning to you."

At first I thought the server could do this by sending a Client FQDN
option that contained the 'X' in the domain field (encoded as per the 'E'
flag in the client's request), and setting both the 'S' and 'O' flags.
(I got that idea from the language in section 3.2, paragraph 2, last
sentence.) And the RCODE1 and RCODE2 fields would be set to 0 (???).

While it sounds to me that this ensures the client will not
attempt to perform a dynamic DNS update, it also seems to
me from section 3.3 that by setting the 'S' and 'O' flags, the server
may have just promised to attempt to perform the dynamic DNS update, and
also to return meaningful RCODE1 and RCODE2 values.  But in this scenario,
the server knows it's not going to attempt any dynamic DNS update,
and has no return codes from DNS to provide to the client.  

What should the server return to the client in this scenario?
(Or does the draft leave this undefined?)

/ist