Bug? INFORM and REQUEST getting ACK'ed with different DNS server lists (3.0.4, 3.1.1, 3.1.2)

[Axel Beckert]

Hi,

On Tue, Feb 03, 2009 at 10:23:48AM -0800, David W. Hankins wrote:
> On Tue, Feb 03, 2009 at 06:35:58PM +0100, Axel Beckert wrote:
> > As far as I understand DHCP there should be no difference in any of
> > the server lists equal if the query was a DHCP REQUEST or a DHCP
> > INFORM packet.
> 
> There is a strange MUST in RFC 2131 that says a DHCP server "MUST
> NOT check for an existing lease" when processing a DHCPINFORM.  My
> interpretation is that we can't source the client's dynamic lease,

All the machines in this group have static IP addresses assigned to
them by the DHCP servers. Here's the full example entry for the host I
did the tests with:

  host acromantula {
    hardware ethernet 00:1c:c0:3f:af:3f;
    fixed-address 192.33.97.124;
  }

> and therefore can't pull any information from lease binding scopes
> or the pool it belongs to.  We can't source fixed-address host
> records ("static leases" are still leases).

Ah, I see.

> So, yes, DHCPREQUEST and DHCPINFORM results start looking different.

I feared something like that. That's the reason for the question mark
in the subject... :-/

> I would have to say that it is completely strange that the protocol
> would make such a demand, and I am not suggesting you are wrong for
> complaining.

Thanks! :-)

> It's just that we're looking at a bug in the protocol's
> documentation, which the software is correctly implementing.
> 
> I've written a draft that, among other problems with DHCPINFORM,
> seeks a standard statement that the intention is not to inspect
> nor extend "lease times" (said another way, DHCPINFORM stands outside
> of the client's state engine), not to limit the extent to which the
> server can select and manufacture configuration appropriate to that
> node.
> 
> It's been accepted as a WG item, and I need to get some time to
> attend to its needs.

I guess, the list will get notice if there are any news regarding
thins.

> So, there is progress, if it has been a long time coming.
> 
> We'll have to see what happens as it progresses towards RFC.

Thanks for the quick and informative reply!

> If you're looking at Windows boxes, the reason they are DHCPINFORMing
> may be because 'Windows Industry Updater' wants to find a WPAD option.

Hmmm, we have the DNS-part of WPAD implemented. Works fine so far.

> It is kind of a security risk to let it try, so you are actually in
> a better position if you give a WPAD 'poison pill' at DHCPREQUEST
> time.
> 
>   http://www.mercenary.net/blog/index.php?/archives/42-HOWTO-WPAD.html

I see, there's a WPAD part before DNS. Will try that. Thanks for this
hint. It hopefully solves our problems here, too.

> No DHCPINFORM, no fallbacks to DNS queries to find WPAD, no problems.

I hope, it's as easy as it sounds. :-)

Thanks again for the fast and helpful reply.

		Kind regards, Axel Beckert
-- 
Axel Beckert <beckert at phys.ethz.ch>       support: +41 44 633 26 68
IT Services Group, HPT D 17                 voice: +41 44 633 41 89
Departement of Physics, ETH Zurich
CH-8093 Zurich, Switzerland		   http://nic.phys.ethz.ch/