<HTML dir=ltr><HEAD><TITLE>Re: DHCP server serving out incorrect DNS for scope</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.6001.18099" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText9832 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>David:</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2> In the language of RFC-2131 PLEASE continue to pursue the <FONT face="Times New Roman">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> </FONT></FONT></DIV></DIV>
<DIV dir=ltr>Randy</DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> dhcp-users-bounce@isc.org on behalf of David W. Hankins<BR><B>Sent:</B> Fri 8/29/2008 6:04 PM<BR><B>To:</B> dhcp-users@isc.org<BR><B>Subject:</B> Re: DHCP server serving out incorrect DNS for scope<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>On Fri, Aug 29, 2008 at 11:18:59AM -0700, Bracey, John wrote:<BR>> Frame 9 - the client issues a DHCPINFORM, requesting further info from<BR>> the server.<BR><BR>That's the trouble. Usually after Offer you Request. Sounds like the<BR>client is doing DNA...so the OS level DHCP is done at OFFER time,<BR>happy on its old lease (actualy very polite of it from my point of<BR>view, OFFER is free, REQUEST needs an fsync...nice of it to patiently<BR>wait for renewal time), and some "application" level DHCP is doing<BR>these informs (but the OS level still seems to update its cache when<BR>replies come in).<BR><BR>Depending on the type of client, the DHCPINFORM might be trying to<BR>locate WPAD configuration (MSFT). You can get it to stop informing<BR>at all by forcing option 252 (with a bogus empty value "\n\000") into<BR>the replies. There are maybe some other unrelated good reasons to<BR>do that...but I'm wandering a bit here.<BR><BR>Anyway.<BR><BR>> Frame 10 - the server then replies to the INFORM request with an ACK,<BR>> which includes the WRONG DNS settings:<BR><BR>This is by design. You've scoped the nameserver settings into the<BR>pool. RFC2131 has a strange MUST NOT in it, namely, that on<BR>DHPCINFORM we MUST NOT locate any existing bindings for the client.<BR><BR>So we are not allowed to find the lease, so we are not able to find<BR>the pool, so we are not able to find this configured option.<BR><BR>Try moving the options into the subnet scope.<BR><BR>> Any insight would be greatly appreciated.<BR><BR>I've written a draft (and just poked the IETF DHC WG about it last<BR>week) seeking to clarify some of these inform problems. This is one<BR>of them, but I still have more text to write on this subject. There's<BR>no config that will do it, but it's a pretty small matter to put the<BR>client's lease lookup into the dhcpinform() function and include it in<BR>the execute_statements_in_scope() call (which sources config), if you<BR>really have a need for that.<BR><BR>--<BR>Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.<BR>Why settle for the lesser evil? <A href="https://secure.isc.org/store/t-shirt/">https://secure.isc.org/store/t-shirt/</A><BR>--<BR>David W. Hankins "If you don't do it right the first time,<BR>Software Engineer you'll just have to do it again."<BR>Internet Systems Consortium, Inc. -- Jack T. Hankins<BR><BR></FONT></P></DIV></BODY></HTML>