DHCP server does not update DNS

Richard Allen ra at ra.is
Wed Dec 21 16:57:55 UTC 2011


Hello all and thanks for your responses.

I've implemented all the suggestions I've received to date in the dhcp
config and we also located the network issue witch turned out to be a rogue
dhcp relay on a multi homed Linux box.   After killing that dhcrelay process
(and making sure it wont start again) things look better.  We did the same
ipconfig /release and /renew test:

Dec 21 16:02:24 wanda dhcpd: DHCPRELEASE of 172.23.101.114 from
00:0f:fe:80:50:3e (censored5) via eth0 (found)

Dec 21 16:02:54 wanda dhcpd: DHCPDISCOVER from 00:0f:fe:80:50:3e via
172.23.100.254
Dec 21 16:02:55 wanda dhcpd: DHCPOFFER on 172.23.101.114 to
00:0f:fe:80:50:3e (censored5) via 172.23.100.254
Dec 21 16:02:55 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 21 16:02:55 wanda dhcpd: DHCPACK on 172.23.101.114 to 00:0f:fe:80:50:3e
(censored5) via 172.23.100.254
Dec 21 16:02:57 wanda named[31310]: client 172.23.101.114#19576: update
'censored.com/IN' denied

Now 172.23.100.254 is the proper relay agent it should be using when
traversing broadcast domains.
There was however no attempt made to register this into DNS.

If Im not mistaken the hostname that is in the logs in parenthesis
(censored5 in these logs) is the hostname supplied by the client and it is
what sould be added to DNS into censored.com and then it's revers map (the
PTR record). 

there is nothing in DNS for this machine:

[root at wanda dhcp]# dig @localhost censored.com axfr | grep censored5
[root at wanda dhcp]#

Now the leases file has:

lease 172.23.101.114 {
  starts 3 2011/12/21 16:17:55;
  ends 3 2011/12/21 20:17:55;
  tstp 3 2011/12/21 22:17:55;
  tsfp 3 2011/12/21 22:17:55;
  atsfp 3 2011/12/21 22:17:55;
  cltt 3 2011/12/21 16:17:55;
  binding state active;
  next binding state expired;
  hardware ethernet 00:0f:fe:80:50:3e;
  uid "\001\000\017\376\200P>";
  client-hostname "censored5";
}


The clients are WIndows 7 and Windows XP machines in a standard WIndows AD
domain.




On 12/21/2011 01:37 PM, Glenn Satchell wrote:
> What is the last lease file entry for one of the clients not in DNS?
>
> The server needs to be able to construct a hostname for the client - if
> the client doesn't supply one then you may want to make one up. In the
> past there have been many examples on this list using pick-first-value()
> for example. If there is no value for a client hostname, then no DNS
> update will be done.
>
> The interim DNS scheme does not try to repeat the DNS update, once it has
> succeeded. SO if you manually remove the DNS entry for the client it will
> not automatically put it back there. It records a successful dns update in
> the lease entry.
>
> There is a section on the Interim DNS Update scheme in the dhcpd.conf man
> page.
>
> regards,
> -glenn
>
> On 12/21/11 18:46, Simon Hobson wrote:
>> Richard Allen wrote:
>>
>>> > 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
>>
>> Bear in mind that these are renewals, and should be unicast to the
>> server by the client - ie the client sends an IP packet addressed
>> directly to the server. The fact that these still are tagged as "via
>> ..." indicates that your switches and/or routers are doing DHCP snooping
>> and modifying the packets anyway. That is quite common.
>> Without the snooping, you could expect (IIRC) the request to come in
>> "via eth0" as in the middle example you quoted.
>>
>>> 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
>>> <snip>
>>> 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...
>>
>> That may well be a client issue. I recall there have been queries from
>> time to time about how to debug this. It could be that the client
>> doesn't get the offer, or it could be that the client doesn't like the
>> offer (doesn't meet it's minimum requirements*), or it could be that the
>> client is broken.
>>
>> * I once had a printer that refused to take an address via DHCP. I
>> manually configured it, and then by chance some time later found out it
>> would only accept a lease with a minimum of two years length !
>>
>>> >> 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.
>>
>> You should be able to do that on your server (I assume you manage that).
>> Just use [tcpdump | ethereal | other favourite tool] to sniff packets on
>> the interface. The biggest problem will be getting a capture filter to
>> give you the packets you need - if it's a busy server then capturing all
>> DHCP packets will leave you with a large haystack to search through.
>>
>>> But still... when a client get's an IP should any of the above prevent
>>> the
>>> dhcp server from registering the client into DNS?
>>
>> There's an option where the client tells the DCHP server that it's going
>> to do it's own DNS registration. If that is set, then the DHCP server
>> won't attempt the forward update - but it should still (IIRC) attempt
>> the reverse PTR update.
>>
>>
>> Chris Buxton wrote:
>>
>>> > Dec 20 19:38:56 wanda named[31310]: client 172.23.101.171#64357: update
>>>> 'censored.com/IN' denied
>>>
>>> That right there could be your problem.
>>
>> Yes, that was mentioned in the original post. I suspect Richard may have
>> more than one problem here, but in his config he has "deny
>> client-updates" - but clients are still attempting their own updates,
>> and the server isn't.
>>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users


-- 
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