DHCPINFORM: global option overrides scope?

[Kees Leune]

We are currently moving some of our DNS infrastructure, and we would like
to test it in one scope before we deploy globally and I am running in to a
somewhat unusual problem. Running ISC DHCP on Ubuntu 12.04 LTS, it seems
that whenever a client is sending a DHCPINFORM, the DHCP daemon responds
with options that are set globally, rather than the options set in the
appropriate scope.

The DHCP configuration file:

--- begin config file ---
ddns-update-style none;

option domain-name "test.internal";
option domain-name-servers 10.80.1.2, 10.80.2.3;

default-lease-time 86400;
max-lease-time 86400;

authoritative;

log-facility local7;

subnet 10.80.0.0 netmask 255.255.0.0 {
    pool {
        range 10.80.10.0 10.80.11.255;
        option subnet-mask 255.255.0.0;
        option routers 10.80.1.1;
        option domain-name-servers 10.3.12.100, 10.3.12.121;
    }
}
--- end config file ---

When a client on the 10.80.0.0/16 subnet does a normal
release/discover/offer/request/ack, it is given the correct nameserver info
(10.3.12.100 and 10.3.12.121). However, when that same client does an
inform/ack, he is given nameservers 10.80.1.2 and 10.80.2.3. In my
understanding, scope should always override global, but that doesn't seem
to be the case here.

We have a workaround, which is not defining any global DNS servers and
specifying the correct ones for each scope, but after having spent a few
days on troubleshooting the issue, I want to find out WHY this is
happening. Are we missing something obvious (or even something obscure?)

Interesting side-note: After finding 48 offending packets in a packet trace
of over 1 million, I am now at a point where I can fairly confidently state
that the only time my clients are sending DHCPINFORM is when they are
actively running a Windows Update cycle on Windows 7, or if after having
applied updates, they have not yet rebooted. While that gives us an
interesting metric as to who has not yet rebooted after applying updates,
it is not what I'm looking for at this time ;-)

I look forward to any responses,

-Kees

*Dr. Kees Leune*
Information Security Officer
Adelphi University
Garden City, NY
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20130221/8744baef/attachment.html>