Different DNS server response for dhcpdiscover than for dhcpinform

Fri Apr 16 18:27:06 UTC 2010

Of course some sites could be depending on DHCPINFORM doing
what it is specified to do.  Two design-table questions come to mind:

(1) Should there be a message similar to DHCPINFORM but which
returns the options associated with the existing lease?
(2) Are there so many cases of wrongly-implemented and misused
DHCPINFORMs that its spec should be modified to match
what is done in (some) practice, even if incompatible with the
currently-specified behavior?  I.e., is it worth changing DHCP in
a non-upwardly-compatible manner?

An underlying question is whether there is any
real use for DHCPINFORM as it is currently defined.

John

On Apr 16, 2010, at 9:50 AM, Randall C Grimshaw wrote:

> It would be good for someone to bring this to the RFC design table  
> because it makes it very unreliable to configure different settings.  
> Because info requests only deliver the global values, over-riding  
> more localized administrator settings based on the client behavior  
> in making the info requests.
>
> Randy
>
> -----Original Message-----
> From: dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org [mailto:dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org 
> ] On Behalf Of Glenn Satchell
> Sent: Thursday, April 15, 2010 8:55 PM
> To: Users of ISC DHCP
> Subject: Re: Different DNS server response for dhcpdiscover than for  
> dhcpinform
>
>
> 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
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users