DHCP server does not update DNS
Richard Allen
ra at ra.is
Tue Dec 20 19:45:01 UTC 2011
On 12/20/2011 07:23 PM, Simon Hobson wrote:
> Richard Allen wrote:
>
>> subnet 172.23.100.0 netmask 255.255.252.0 {
>> ddns-domainname "censored.com";
>> option domain-name "censored.com";
>> option domain-name-servers 172.29.100.96, 172.29.100.97;
>> authoritative;
>> ddns-update-style interim;
>> ddns-updates on;
>> deny client-updates;
>> option routers 172.23.100.254;
>> option subnet-mask 255.255.252.0;
>> option broadcast-address 172.23.103.255;
>> option time-offset 0;
>> option ntp-servers 172.29.100.96, 172.29.100.97;
>> option netbios-name-servers 172.23.100.60, 172.23.100.61;
>> one-lease-per-client on;
>> option ip-forwarding off;
>> default-lease-time 14400;
>> max-lease-time 14401;
>> next-server 172.23.100.37;
>> filename "\\OSChooser\\i386\\startrom.com";
>> pool {
>> failover peer "dhcp-failover";
>> range 172.23.101.1 172.23.101.250;
>> host censored1 {
>> hardware ethernet 18:a9:05:fc:6b:88;
>> fixed-address censored1.censored.com;
>> max-lease-time 28800;
>> option host-name "censored1.censored.com";
>> }
>> host censored2 {
>> hardware ethernet 18:a9:05:fc:6b:87;
>> fixed-address censored2.censored.com;
>> max-lease-time 28800;
>> option host-name "censored2.censored.com";
>> }
>> }
>> zone censored.com. {
>> primary 172.29.100.96;
>> }
>> zone 100.23.172.in-addr.arpa. {
>> primary 172.29.100.96;
>> }
>> if exists vendor-encapsulated-options {
>> ddns-updates off;
>> option vendor-encapsulated-options 3a:02:00:19:ff;
>> }
>> }
>
> OK, several things here.
> Move your host statements outside of the subnet. Host statements are
> global in scope but can still inherit options from where they are defined.
> Thus you can get strange problems where a host is in a different subnet
> but gets (almost certainly incorrect) options from the subnet where it's
> host statement is nested. There are very, very few cases where that sort
> of thing is actually desirable, so the simplest rule of thumb is to
> *never* nest host statements inside a subnet.
Ok. I'll move the hosts out of the subnet declarations. They all are in
the correct subnets, but I love rules of thumb :)
> I'd also suggest moving your zone declarations to the global scope. In
> fact, if the DNS server(s) listed in your DHCP server's resolver config
> return the right SOA record, then they can be omitted altogether. Ie,
> without zone statements, the DHCP server will query for the SOA records of
> the zone it wishes to update, and get the master server from that.
Yes. The nameservers in resolv.conf are my two boxes and they do have the
proper SOA entries so I guess the zone statements are redundant, but I'll
move them to the global scope
> Also, you've duplicated several statements between global and subnet
> scope. It's not wrong, but my preference is to remove all redundancy - if
> you ever want to change something, it's easy to miss an instance if you
> duplicate it many times in the config.
Yes, those duplications where on purpose. I was not sure the global's where
actually working so I tried putting them into each subnet scope just to see
if that actually changed anything (it did not). I'll get rid of the dup's.
>
>
>> Multiple other subnets follow, all identical
>
> See above about host statements !
>
>
>> Everything seems to be working just right except for the fact that the dhcp
>> server seems to have stopped registering anything into DNS.
>> I tried doing "ipconfig /release" and "ipconfig /renew" on a windows box and
>> that did not get the machine registered.
>>
>> Logs show some strange behavior. Here are the logs from when I did the
>> release and renew on the windows client:
>>
>> Dec 20 14:44:03 wanda dhcpd: DHCPRELEASE from 00:0f:fe:80:50:3e via
>> 172.23.200.2: unknown network segment
>> Dec 20 14:44:03 wanda dhcpd: DHCPRELEASE of 172.23.101.114 from
>> 00:0f:fe:80:50:3e (censored5) via eth0 (found)
>> Dec 20 14:44:03 wanda dhcpd: DHCPRELEASE of 172.23.101.114 from
>> 00:0f:fe:80:50:3e (censored5) via 172.23.100.252 (found)
>
> Your network config doesn't match what you told us and the DHCP server !
>
> The server has received the release message via three routes (in order) :
>
> Via a relay agent giving it's address as 172.23.200.2. The DHCP server
> doesn't know about this network segment, hence why it complains.
>
> Directly via a local interface - the client is attached to the same
> network (broadcast domain) as the server. At least I think that's the
> case, it may be a unicast packet (which could be routed from another
> network), but then I wouldn't expect to see the other two release packets.
>
> Via another relay agent giving it's address as 172.23.100.252. In this
> case, the relay agent is on the same network (broadcast domain) as the
> client and server. This is itself isn't "wrong", but it can cause some odd
> effects.
>
> Or, I could be wrong about this, are there any intervening
> routers/switches configured to do anything with DHCP packets ?
The two servers are on their own dedicated vlan and there are no dhcp
clients on that network. All other networks that have DHCP clients get
their dhcp info via Cisco routers/switches "helper" functions. I'll send
this to the Networking dept. and ask them to explain why this gets delivered
3 times.
However, All normal dhcp traffic is not duplicated like this. Here is an
example of the current activity in the logs:
Dec 20 19:38:39 wanda dhcpd: DHCPREQUEST for 172.23.113.169 from
00:15:60:9a:6e:cf (censored6) via 172.23.113.254
Dec 20 19:38:39 wanda dhcpd: DHCPACK on 172.23.113.169 to 00:15:60:9a:6e:cf
(censored6) via 172.23.113.254
Dec 20 19:38:42 wanda dhcpd: DHCPREQUEST for 172.23.113.173 from
00:15:60:9a:6e:a7 (censored7) via 172.23.113.254
Dec 20 19:38:42 wanda dhcpd: DHCPACK on 172.23.113.173 to 00:15:60:9a:6e:a7
(censored7) via 172.23.113.254
Dec 20 19:38:47 wanda dhcpd: DHCPREQUEST for 172.23.107.82 from
d4:85:64:a0:2b:34 (censored8) via 172.23.107.254
Dec 20 19:38:47 wanda dhcpd: DHCPACK on 172.23.107.82 to d4:85:64:a0:2b:34
(censored8) via 172.23.107.254
Dec 20 19:38:51 wanda dhcpd: DHCPINFORM from 172.23.107.82 via 172.23.107.254
Dec 20 19:38:51 wanda dhcpd: DHCPACK to 172.23.107.82 (d4:85:64:a0:2b:34)
via eth0
Dec 20 19:38:56 wanda named[31310]: client 172.23.101.171#64357: update
'censored.com/IN' denied
Then I see things like:
Dec 20 19:38:28 wanda dhcpd: DHCPDISCOVER from 52:54:00:e2:fc:a7 via
172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPOFFER on 172.23.101.155 to
52:54:00:e2:fc:a7 via 172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPDISCOVER from 52:54:00:e2:fc:a7 via
172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPOFFER on 172.23.101.155 to
52:54:00:e2:fc:a7 via 172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPDISCOVER from 52:54:00:e2:fc:a7 via
172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPOFFER on 172.23.101.155 to
52:54:00:e2:fc:a7 via 172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPDISCOVER from 52:54:00:e2:fc:a7 via
172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPOFFER on 172.23.101.155 to
52:54:00:e2:fc:a7 via 172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPDISCOVER from 52:54:00:e2:fc:a7 via
172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPOFFER on 172.23.101.155 to
52:54:00:e2:fc:a7 via 172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPDISCOVER from 52:54:00:e2:fc:a7 via
172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPOFFER on 172.23.101.155 to
52:54:00:e2:fc:a7 via 172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPDISCOVER from 52:54:00:e2:fc:a7 via
172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPOFFER on 172.23.101.155 to
52:54:00:e2:fc:a7 via 172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPDISCOVER from 52:54:00:e2:fc:a7 via
172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPOFFER on 172.23.101.155 to
52:54:00:e2:fc:a7 via 172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPDISCOVER from 52:54:00:e2:fc:a7 via
172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPOFFER on 172.23.101.155 to
52:54:00:e2:fc:a7 via 172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPDISCOVER from 52:54:00:e2:fc:a7 via
172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPOFFER on 172.23.101.155 to
52:54:00:e2:fc:a7 via 172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPDISCOVER from 52:54:00:e2:fc:a7 via
172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPOFFER on 172.23.101.155 to
52:54:00:e2:fc:a7 via 172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPDISCOVER from 52:54:00:e2:fc:a7 via
172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPOFFER on 172.23.101.155 to
52:54:00:e2:fc:a7 via 172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPDISCOVER from 52:54:00:e2:fc:a7 via
172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPOFFER on 172.23.101.155 to
52:54:00:e2:fc:a7 via 172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPDISCOVER from 52:54:00:e2:fc:a7 via
172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPOFFER on 172.23.101.155 to
52:54:00:e2:fc:a7 via 172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPDISCOVER from 52:54:00:e2:fc:a7 via
172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPOFFER on 172.23.101.155 to
52:54:00:e2:fc:a7 via 172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPDISCOVER from 52:54:00:e2:fc:a7 via
172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPOFFER on 172.23.101.155 to
52:54:00:e2:fc:a7 via 172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPDISCOVER from 52:54:00:e2:fc:a7 via
172.23.100.254
Dec 20 19:38:28 wanda dhcpd: DHCPOFFER on 172.23.101.155 to
52:54:00:e2:fc:a7 via 172.23.100.254
Looks like we have other networking issues as well...
>> Dec 20 14:44:19 wanda dhcpd: DHCPDISCOVER from 00:0f:fe:80:50:3e via
>> 172.23.100.254
>> Dec 20 14:44:20 wanda dhcpd: DHCPOFFER on 172.23.101.114 to
>> 00:0f:fe:80:50:3e (censored5) via 172.23.100.254
>> Dec 20 14:44:20 wanda dhcpd: DHCPREQUEST for 172.23.101.114 (172.29.100.96)
>> from 00:0f:fe:80:50:3e (censored5) via 172.23.100.254
>> Dec 20 14:44:20 wanda dhcpd: DHCPACK on 172.23.101.114 to 00:0f:fe:80:50:3e
>> (censored5) via 172.23.100.254
>> Dec 20 14:44:22 wanda named[2897]: client 172.23.101.114#10410: update
>> 'censored.com/IN' denied
>>
>> Only the client itself tried to register to dns (inspite of the deny
>> client-updates directive)
>
> You'd want to check in the packets and see what the two ends sent. Also, I
> notice that there aren't duplicates this time - so what happened to the
> direct packet and other relay agent ?
That's a good question and I do not have an answer for it. But I will give
the networking boys a swift kick in the pants.
But still... when a client get's an IP should any of the above prevent the
dhcp server from registering the client into DNS?
--
Rikki. -- RHCE, RHCX, HP-UX Certified Administrator.
-- Solaris 7 Certified Systems and Network Administrator.
Bell Labs Unix -- Reach out and grep someone.
Those who do not understand Unix are condemned to reinvent it, poorly.
More information about the dhcp-users
mailing list