DHCP hosts not reliably propagated to DNS

Indeed,
Explanation was posted in the bug 12694 – DHCP hosts not reliably propagated to DNS (ipfire.org)

FYI: for those using my 3 line script to reset dhcp and unbound, add a sleep 3 before unbound. Ipfire needs time to breathe and without the sleep 3, it may throw some errors in /var/log/messages.

/etc/init.d/dhcp stop
/etc/init.d/dhcp start
sleep 3
/etc/init.d/unbound restart

There is a fix available for testing.

  • unbound-dhcp-leases-bridge has received improvements to reliably propagate DHCP hosts to the DNS. Thanks go to Anthony Heading for his work on that front.

Please see:
IPFire 2.27 - Core Update 167 is available for testing

testing feedback is always highly appreciated!

3 Likes

cu 167 Testing … feedback

A few tests indicate that the fix is working (thank you Anthony).

  • when a new laptop comes in, it can be pinged by name
  • when the laptop leaves and dhcp lease expires, the record in DNS is removed.

Paul

2 Likes

Follow up question: I start the dhcp-leases-bridge with -d -vv
/usr/bin/python3 /usr/sbin/unbound-dhcp-leases-bridge -d -vv

The text “Wakeup of main loop” shows in /var/log/messages at uneven times, sometimes 30s, other times 18s, or 1m 30s. There does not seem to be a pattern. Here’s some log …

Apr 12 05:46:44 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:47:50 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:48:14 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:48:32 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:50:02 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:50:20 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:51:51 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:53:21 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:54:21 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:55:03 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:55:09 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:55:51 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:55:57 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:56:02 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:57:32 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:58:14 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:58:20 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:58:50 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:00:14 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:00:32 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:00:38 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:00:43 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:01:25 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:01:31 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:01:37 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:03:13 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:03:31 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:03:49 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:05:19 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:06:20 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:06:26 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:06:32 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:06:50 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:06:56 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:07:02 zotac dhcp[16447]: Wakeup of main loop

Hi Paul,
Could you please add your feedback into the bug report.

it must be 10+ characters … done.

Yes, the DHCP → DNS propagation in core 167 update seems to do the right thing now. This is an intermittent problem though, so it probably needs a bit longer before we declare victory, but the early indications are good. Thanks!

1 Like

Jeff, by “this” you mean the “Wakeup of main loop”, right?

Yes, the timing is a bit of concern since the Dev wrote it should happen every 6 seconds.

No, I meant that the original reported problem, where the daemon would sometimes fail to propagate new DHCP clients to DNS, seems to be fixed.

I haven’t run the daemon with debug logging so I’m not clear on your follow-up question. Given that it’s using inotify to look for changes though, I’d be surprised if the wakeups were at regular intervals.

I’m currently running IPFire a few versions below the most current release.

Does the above mentioned fix mean that I do not have to add a Host entry for each of the DHCP leases anymore?

Can those DNS entries be used in SARG reports, too, instead of IP addresses? Currently I’ve changed a param in SARG config to get resolved IP addresses.

Which DNS name will be used if each DHCP now gets properly propagated?

When a new laptop joins the network, DHCP assigns (10.0.0.36, e6500) and sends that pair to unbound. That means, immediately, you can ping e6500 Up to cu166 this functionality was not working.

When the laptop leaves the network && its lease expires, the pair (10.0.0.36, e6500) is removed from unbound. Up to cu166, unbound kept that pair forever.

1 Like

And the device name e6500 is configured directly on that device and not in DCHP on IPFire, correct?

Correct, it’s a laptop running Mint with hostname e6500. When it joined the network, DHCP via DHCPREQUEST picked up that name, assigned an ip, recorded mac. And DHCP acknowledged that info with DHCPACK. Last step, it tells unbound to add a record so that it can be pinged by name. This last step works on 167-Testing. From another laptop with hostname dennis …

Apr 20 13:09:11 ipfire dhcpd: DHCPREQUEST for 10.0.0.30 from 24:77:03:d8:96:38 (dennis) via green0
Apr 20 13:09:11 ipfire dhcpd: DHCPACK on 10.0.0.30 to 24:77:03:d8:96:38 (dennis) via green0
1 Like

Please see:

This works very well for me! Any add to my small network causes DNS to update. I can ping new machines (by name) instantly.

Thank you to Anthony & Michael and many others!

1 Like

I agree with Jon … but I found a little snag (which is not related to the solution, I think)

A raspberrypi enters the network for the first time

Ipfire DHCP assigns (10.0.0.50, raspberrypi)

I ssh to user@raspberrypi, change hostname to pi3b, reboot.

Ipfire DHCP shows (10.0.0.50, pi3b)

but, unbound keeps the old name

dig @10.0.0.1 -x 10.0.0.50 shows both hostnames

;; ANSWER SECTION:
50.0.0.10.in-addr.arpa. 60 IN PTR raspberrypi.lan.
50.0.0.10.in-addr.arpa. 60 IN PTR pi3b.lan.

After a few hours, that clears up and only pi3b is on unbound.

maybe that is how long it takes for the first lease to timeout? (wild guess on my part)

What is the Default lease time (mins) and the Max lease time (mins) set to on the DHCP Configuration page?

It took a few hours not 10 or 20 min. I have 10/20 (which is short, I know). Default is 60/120.

1 Like

I tried the same with a Mac mini. It fails in a similar (but different) way. I only see one DNS name.

I only see the old name with dig:

iMac:~ jon$ dig @192.168.65.1 -x 192.168.65.177

; <<>> DiG 9.10.6 <<>> @192.168.65.1 -x 192.168.65.177
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54140
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;177.65.168.192.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
177.65.168.192.in-addr.arpa. 60	IN	PTR	MM4.localdomain.

;; Query time: 52 msec
;; SERVER: 192.168.65.1#53(192.168.65.1)
;; WHEN: Fri Apr 29 14:15:53 CDT 2022
;; MSG SIZE  rcvd: 85

I can see the new name on the DHCP Configuration WebGUI (at https://ipfire.localdomain:444/cgi-bin/dhcp.cgi).

But the new name does not propagate to DNS.

EDIT: Here is the dhcp lease file:

[root@ipfire ~] # cat /var/state/dhcp/dhcpd.leases | grep -B12 MM4
lease 192.168.65.177 {
  starts 5 2022/04/29 18:24:41;
  ends 5 2022/04/29 20:24:41;
  cltt 5 2022/04/29 18:24:41;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 21:c2:e3:04:55:06;
  uid "\001(\317\351\014P\013";
  set noname = "dhcp-192-168-65-177";
  set ClientIP = "192.168.65.177";
  set ClientDHCID = "21:c2:e3:04:55:06";
  set ClientName = "MM4update";
  client-hostname "MM4update";
[root@ipfire ~] # 

EDIT2: Here is the unbound file:

[root@ipfire ~] # cat /etc/unbound/dhcp-leases.conf | grep MM4
local-data: "MM4.localdomain 60 IN A 192.168.65.177"
local-data: "177.65.168.192.in-addr.arpa 60 IN PTR MM4.localdomain"
[root@ipfire ~] #

Not surprising that it would work this way. Usually the client needs to send a DHCP release in order for the server to drop the lease. At one time you could do this with dhclient -r, but it would certainly depend on the client OS.

IOW, when you change the name of the server the DHCP server just sees a new client, and has to keep around the lease for the old one until it times out.