Different DNS server response for dhcpdiscover than for dhcpinform

[Glenn Satchell]

This is from RFC 2131

3.4 Obtaining parameters with externally configured network address

    If a client has obtained a network address through some other means
    (e.g., manual configuration), it may use a DHCPINFORM request message
    to obtain other local configuration parameters.  Servers receiving a
    DHCPINFORM message construct a DHCPACK message with any local
    configuration parameters appropriate for the client without:
    allocating a new address, checking for an existing binding, filling
    in 'yiaddr' or including lease time parameters.  The servers SHOULD
    unicast the DHCPACK reply to the address given in the 'ciaddr' field
    of the DHCPINFORM message.

    The server SHOULD check the network address in a DHCPINFORM message
    for consistency, but MUST NOT check for an existing lease.  The
    server forms a DHCPACK message containing the configuration
    parameters for the requesting client and sends the DHCPACK message
    directly to the client.

As I understand it the DHCPINFORM packets lack certain information which 
is needed to determine pool membership. In particular, because the 
server does not look up any existing lease, it is not able to see what 
information may or may not have been sent previously. So it's not a bug 
as such, more a design limitation of the protocol.

RFC2131 is a detailed documentation of a complex protocol. Well worth a 
read to get a full background on the how dhcp is meant to work.

regards,
-glenn

On 04/16/10 09:10, Michael Robbert wrote:
> So, in order to work around this apparent bug I decided to move the "option domain-name-servers" out of the global section of the config and only configure it in each pool. Now DHCPINFORM requests from clients don't result in them changing their DNS server config because they don't get a DNS server answer. I'm hoping, and it appears to be true, that the clients don't ever decide to blank out the DNS servers because the DHCP server doesn't give them an answer.
> I would still be curious to know if it is intentional behavior or a bug that DHCPINFORM requests don't appear to result in the parsing of options defined in the pools?
>
> Thanks,
> Mike Robbert
>
> On Apr 12, 2010, at 5:46 PM, Michael Robbert wrote:
>
>> We are currently running ISC DHCP 3.1.3b1 and have been running the same basic config for many years now, but recently we've had some clients that appear to behave differently and I think that I've tracked it down to what appears to be a known bug in the way the server responds to DHCPINFORM packets. There have been list discussions about this in the past and a workaround for one users situation was posted, but our situation is a little different and I'd like to know if this bug is supposed to be fixed or if anybody can suggest a different config that will work for us.
>> Our setup is that we send most of our clients to our two main DNS servers, but on a few subnets if the client MAC address is not registered with us (unknown to DHCP) we want to send them to a registration portal page so we give them a different DNS server that will direct them to our "captive portal". The problem is that we've found some clients appear to be occasionally sending DHCPINFORM packets at some point and are getting the public DNS servers so they are not getting redirected. Here is what I think are the relevant parts of our config:
>>
>> option domain-name "Mines.EDU";
>> option domain-name-servers magma.Mines.EDU, ns1.Mines.EDU;
>> default-lease-time 7200;
>> max-lease-time 21600;
>> option broadcast-address 255.255.255.255;
>>
>> authoritative;
>>
>> #Main Campus subnet
>> subnet 138.67.0.0 netmask 255.255.192.0 {
>>         option broadcast-address 138.67.63.255;
>>         option subnet-mask 255.255.192.0;
>>         #known clients
>>         pool {
>>                 failover peer "magma-massive";
>>                 deny dynamic bootp clients;
>>                 range 138.67.20.10 138.67.20.250;
>>                 range 138.67.11.10 138.67.11.250;
>>                 option routers 138.67.1.1;
>>                 deny unknown clients;
>>         }
>>         #unknown clients
>>         pool {
>>                 failover peer "magma-massive";
>>                 deny dynamic bootp clients;
>>                 range 138.67.13.10 138.67.13.240;
>>                 range 138.67.10.10 138.67.10.240;
>>                 option domain-name-servers slag.Mines.EDU;
>>                 option routers 138.67.1.63;
>>                 allow unknown clients;
>>                 deny known clients;
>>         }
>> }
>>
>> ...
>> Many other subnets
>> ...
>> include "/home/dhcpd/dhcp.registered";
>>
>> Thanks in advance for any help!
>>
>> Mike Robbert