IPFire 2.29 - Core Update 203 released

[ms (Michael Tremer)]

Finally, IPFire 2.29 - Core Update 203 has been released, migrating our DNS system to Knot Resolver:

IPFire 2.29 - Core Update 203

[porkyle (mapi)]

My update went otherwise without issues except hostnames from DHCP leases don’t resolve.

After adding hostname to Hosts and rebooting client it resolved again.

This was on Linux client, I haven’t test Windows yet.

Great news is that DNS resolving feels now faster and memory usage dropped over 50%.

[ms (Michael Tremer)]

@porkyle

My update went otherwise without issues except hostnames from DHCP leases don’t resolve.

Yes, this can happen as the database has to be built first. After all leases have been renewed they should all resolve. In the default configuration this should not take longer than 60 minutes.

@porkyle

Great news is that DNS resolving feels now faster and memory usage dropped over 50%.

This is what I wanted to hear

[mfischer (fischerm42)]

Same here. Its frustrating. What shall I do now - with 16GB RAM!?

About 12 GB are now useless…

[pscar13]

@porkyle

My update went otherwise without issues except hostnames from DHCP leases don’t resolve.

A DHCP configuration issue was identified during testing; neither the upgrade nor the restore process (CU203) correctly migrates the dhcp.conf file.

CU203 Test : dhcp entries not resolving

Hi Phil. I had this same issue but I resolved it by disabling Green and Blue DHCP (untick both) then press save. Then re-enabling both (or whichever needed) Can you test this and report back with the results? Thanks, A G

[porkyle (mapi)]

Maybe I should have been more specific. I’ve set fixed leases and used remark to set them hostnames. Now it ignores that set hostname completely and uses hostname configured in client or if client itself don’t have set hostname it doesn’t get any hostname from DHCP server.

I guess we have to use Edit Hosts feature now since that seems to do same job?

[ms (Michael Tremer)]

@pscar13

A DHCP configuration issue was identified during testing; neither the upgrade nor the restore process (CU203) correctly migrates the dhcp.conf file.

And what is being incorrectly migrated about it?

[ag (Adam Gibbons)]

Hi all.

Core Update 203 is showing much lower memory usage.

Even with IPS enabled with many rules, multiple IP blocklists and DNS firewall with ads, malware and phishing lists enabled memory usage is only 2.88G.

And it has remained stable for almost 12 days now.

Great work everyone involved.

Thanks,
A G

[porkyle (mapi)]

My denon AVR is getting wrong hostname. In AVR config it’s Denon AVR-2300W.

DHCP lease conf it’s just denon

DHCP log from IPFire

21:44:27	dhcpd:	execute_statement argv[4] = DOMAINNAME=localdomain
21:44:27	dhcpd:	execute_statement argv[3] = HOSTNAME=0123456789
21:44:27	dhcpd:	execute_statement argv[2] = ADDRESS=192.168.13.110
21:44:27	dhcpd:	execute_statement argv[1] = commit
21:44:27	dhcpd:	execute_statement argv[0] = /usr/sbin/dhcp-lease

So something is not working as expected. It should be either Denon or Denon AVR-X2300W. After chagning friendly name to Denon in AVR settings hostname is still wrong and nslookup or ping only works on 0123456789 hostname.

I had to add hostname Denon from Edit Hosts WebGUI page and only after that hostname Denon resolved to correct address. DHCP server log still shows device mac as hostname.

With unbound I could use DHCP lease remarks to give hostnames even for clients that did’t get IP from DHCP(manually configured). It was useful in case client for some reason reseted and went back to automatic IP mode so IP and hostname would always be same. I use this kind of setups for NASes and WIFI AP:s

Not really issue since I can use Edit Hosts now for same result but maybe wiki page should be upgrade if this is intended behaviour?

[pscar13]

That is what I tried to describe in this post:

CU 203 Test : DNS does not update DHCP leases

I have a laptop that I use via Wi-Fi when mobile and via a wired connection at my desk. The PC’s Windows hostname is “matebook”. With CU202, the local Unbound DNS uses the REMARK field defined on the dhcp.cgi page for fixed leases. The wired address is 192.168.20.49 with the name “huaweimb”. The Wi-Fi address is 192.168.20.47 with the name “huaweimbW”. When I query the DNS PS C:\Users\phili> nslookup huaweimb Server: ipfire.pshome Address: 192.168.20.1 Name: huaweimb.pshome Address:…

But no one understood.

CU203 changed the rules for local DNS management.

The REMARK field for fixed leases is now ignored by the local DNS.

[ms (Michael Tremer)]

@pscar13

But no one understood.

This seems to be a very common thing with your posts. I would recommend you work on it so that people are actually able to understand or otherwise people will be talking to themselves in a thread.

@pscar13

The REMARK field for fixed leases is now ignored.

It is not ignored. It says what it is doing on the tin which is storing a comment about an entry. The client sends their hostname which is what will be put into DNS.

@pscar13

I explained it here

Here is a comparison of the /var/ipfire/dhcp.conf files: 1 - Version OK after reloading dhcp.cgi page 2 - Version KO after CU202 → CU203 upgrade 3 - Version KO after restoring CU202 backup onto CU203 [Capture d’écran 2026-07-10 170958]

Once again, I would recommend to report any bugs to the bugtracker. A picture is not a bug report.

[porkyle (mapi)]

@ms

It is not ignored. It says what it is doing on the tin which is storing a comment about an entry. The client sends their hostname which is what will be put into DNS.

Wiki page is now confusing, if IPFire’s DNS doesn’t use remark field anymore to set hostname entry.

Note! The IPFire’s DNS server automatically adds the first word in the remark field as a host name entry for the IP address configured in this section.

Should that note be removed now or is it even possible to do that with Knot Resolver in future update?

If intention is to have only one page to configure Hosts (Edit Hosts) that’s fine by me. I just have to move rest of my hostnames to there now. I have some fixed DHCP clients that don’t have any hostname or they have hard remember non descriptive names and it’s not possible change them from device itself. Don’t remember why I started using DHCP remarks for them but I’ve been using them over decade now.

[pslpsl (Petr Slansky)]

I confirm that memory usage is significantly better with C203 but I see much higher use of CPU in C203…

[bbitsch (Bernhard Bitsch)]

The implementation of sending local DHCP informations to DNS, formerly know as unbound-dhcp-leases-bridge, isn’t fully complete yet.
I’ll send a report to bugzilla with recommended corrections today or tomorrow, when I have a clean solution.
For the time being, the admin can do this manually, by editing hosts. This should be equivalent.

[bbitsch (Bernhard Bitsch)]

The bug was refused.
Reason:

• REMARK is just a remark, not more.
• Clients MUST send their hostname

I have some device in my local network, which do not send a host name. This isn’t nice, but conforms to the DHCP RFCs.
For handling these devices there are several ways:

1. Forcing the device to send a host name, either by configuration or bug report to the vendor
2. Including the device to the hosts WUI
3. Managing knot’s name DB from a shell
4. Adding a host name field to the dhcp WUI

Topic 1. is difficult, if not ineffective.
Topic 3. is mentioned in some posts, may be a solution for advanced users but breaks the ‘configure by WUI’ philosophy of IPFire.

[pscar13]

Thanks for trying
So, there’s no way to roll back.
That makes managing IoT devices difficult.
I’ve reverted to CU202 while waiting for a solution and for knot-resolver and DNS firewall to stabilize.
The memory issue doesn’t affect me, I use URL filter with Toulouse List and it’s Ok.

[cbrown (Charles Brown)]

I believe the fixed lease Remark feature is mentioned in the wiki.