DHCP server serving out incorrect DNS for scope

[Randall C Grimshaw]

David:
   In the language of RFC-2131 PLEASE continue to pursue the IETF DHC WG on this issue. It seems entirely un-intended that the server provide the wrong information on an inform. It seems that the clients MUST use this data and it MUST be correct. Regarding your suggestion... I am strongly discouraged (ie. MUST NOT) from modifying your code. It MUST work according to the principle of least surprise. Thank you. <grin> 
Randy

________________________________

From: dhcp-users-bounce at isc.org on behalf of David W. Hankins
Sent: Fri 8/29/2008 6:04 PM
To: dhcp-users at isc.org
Subject: Re: DHCP server serving out incorrect DNS for scope



On Fri, Aug 29, 2008 at 11:18:59AM -0700, Bracey, John wrote:
> Frame 9 - the client issues a DHCPINFORM, requesting further info from
> the server.

That's the trouble.  Usually after Offer you Request.  Sounds like the
client is doing DNA...so the OS level DHCP is done at OFFER time,
happy on its old lease (actualy very polite of it from my point of
view, OFFER is free, REQUEST needs an fsync...nice of it to patiently
wait for renewal time), and some "application" level DHCP is doing
these informs (but the OS level still seems to update its cache when
replies come in).

Depending on the type of client, the DHCPINFORM might be trying to
locate WPAD configuration (MSFT).  You can get it to stop informing
at all by forcing option 252 (with a bogus empty value "\n\000") into
the replies.  There are maybe some other unrelated good reasons to
do that...but I'm wandering a bit here.

Anyway.

> Frame 10 - the server then replies to the INFORM request with an ACK,
> which includes the WRONG DNS settings:

This is by design.  You've scoped the nameserver settings into the
pool.  RFC2131 has a strange MUST NOT in it, namely, that on
DHPCINFORM we MUST NOT locate any existing bindings for the client.

So we are not allowed to find the lease, so we are not able to find
the pool, so we are not able to find this configured option.

Try moving the options into the subnet scope.

> Any insight would be greatly appreciated.

I've written a draft (and just poked the IETF DHC WG about it last
week) seeking to clarify some of these inform problems.  This is one
of them, but I still have more text to write on this subject.  There's
no config that will do it, but it's a pretty small matter to put the
client's lease lookup into the dhcpinform() function and include it in
the execute_statements_in_scope() call (which sources config), if you
really have a need for that.

--
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?  https://secure.isc.org/store/t-shirt/
--
David W. Hankins        "If you don't do it right the first time,
Software Engineer                    you'll just have to do it again."
Internet Systems Consortium, Inc.               -- Jack T. Hankins



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20080829/59981940/attachment.html>