Local DNS not reliable

IPfire core 193 running at “AMD” CPU. I run config “RED+GREEN+BLUE”, DHCP server is active on GREEN and BLUE.

My local DHCP server has about 40 clients. And I found I cannot resolve some of them. I see them in IPfire web interface but I cannot resolve their hostnames or IP address. Only IPv4, I do not use IPv6. Some clients are OK and others are invisible.

I see that entries are several times in file /var/state/dhcp/dhcpd.leases.

Example, host “c4b” works OK but host “mint” is invisible.

lease 192.168.222.236 {
  starts 3 2025/04/16 20:38:39;
  ends 3 2025/04/16 21:38:39;
  cltt 3 2025/04/16 20:38:39;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 00:1e:06:4a:be:ef;
  uid "\001\000\036\006J*\260";
  client-hostname "c4b";
}
lease 192.168.222.236 {
  starts 3 2025/04/16 21:08:39;
  ends 3 2025/04/16 22:08:39;
  cltt 3 2025/04/16 21:08:39;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 00:1e:06:4a:be:ef;
  uid "\001\000\036\006J*\260";
  client-hostname "c4b";
}
lease 192.168.222.121 {
  starts 3 2025/04/16 20:37:51;
  ends 3 2025/04/16 21:37:51;
  cltt 3 2025/04/16 20:37:51;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 00:1a:4d:4f:be:ef;
  client-hostname "mint";
}
lease 192.168.222.121 {
  starts 3 2025/04/16 21:03:54;
  ends 3 2025/04/16 22:03:54;
  cltt 3 2025/04/16 21:03:54;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 00:1a:4d:4f:be:ef;
  client-hostname "mint";
}
lease 192.168.222.121 {
  starts 3 2025/04/16 21:27:03;
  ends 3 2025/04/16 22:27:03;
  cltt 3 2025/04/16 21:27:03;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 00:1a:4d:4f:be:ef;
  client-hostname "mint";
}

I understand this is a tricky issue, I do not see clear difference between visible and invisible clients. They have IP address assigned and they all work. I only cannot resolve them with host command and I have to connect to IPfire gateway to find what IP address they have…

I think this is not new issue. My IPfire was not updated or rebooted for 5 months and when I checked it after my “holiday”, I noticed that local DNS was not working at all, it was running but I was not able to resolve any local client. I updated gateway to the “core 193”, it is up and running for several days and I see signs that something is not working as expected… :frowning:

Visible client:

user@book:~$ host c4b
c4b.home has address 192.168.222.236

Invisible client:

user@book:~$ host mint
Host mint not found: 2(SERVFAIL)

I see 15 “ESP devices” in DHCP server GUI but I can resolve only 13 of them, 2 are invisible.


I cannot see “invisible” clients in file /etc/unbound/dhcp-leases.conf
Timestamp of dhcp-leases.conf is 2025-04-12, this file was not updated for several days. Host “mint” was down until today, that explains why I cannot see it. The same applies two two invisible ESP clients, those were down on 2025-04-12. The issue is that file dhcp-leases.conf is not regularly updated.

ps shows me these processes, maybe they are dead…

root      2309  0.0  0.1   9444  6900 ?        Ss   Apr12   0:27 /usr/sbin/dhcpd -q green0 blue0
root      2317  0.0  0.3 165624 13488 ?        Sl   Apr12   0:04 /usr/bin/python3 /usr/sbin/unbound-dhcp-leases-bridge -d
1 Like

Try updating IPF. There was a big update to the DHCP/DNS integration a few months ago which was aimed to get round this sort of issue.

It looks like he’s already running CU193 based on his first sentence.

2 Likes

My bad. I’d picked up he hadn’t updated for 5 months.

Unfortunately I am not comfortable with some of the approach taken in the unbound integration update so I dropped out and can’t remember the details.

Are you using IPfire’s DHCP server?
Do you have any Client’s with a fixed ip?

I use my IPfire as the only DHCP server. I have 8 fixed entries (like server, printer and several Android devices).

-rw-r--r-- 1 root root 995 Apr 12 02:04 /etc/unbound/hosts.conf

BTW, my IPfire is at version 193, the latest one…


I just wonder, doesn’t you see this issue? Is your file /etc/unbound/dhcp-leases.conf kept updated? I am looking forward for an update like “I have the same issue” or “I can replicate it”.

@pslpsl Hi

I have not an installed mint machine to test for a solution, so maybe this link can provide explanation for a solution..

Mint and other modern distros ship with mdns by default, which wraps the regular public DNS with a local “decentralized” wrapper which enables zeroconf support for your local network. Basically, a local DNS server resolves names in the local network it has discovered, then falls back to the (now proxied) public DNS for public Internet resolution, i.e. for names outside of your local network.

In so many words, your resolv.conf is correct and appropriate for this scenario, and if mdns has problems accessing your ISP’s nameserver, you should look inside its configuration - though of course, if you don’t care about zeroconf support, disabling mdns (and then probably also Avahi) lets you manage resolv.conf in the traditional fashion.

Link from : dhcp - Dhclient not updating /etc/resolv.conf - Unix & Linux Stack Exchange

Hope this help

Are they outside of your DHCP dynamic range?

Static leases in range 2-99, dynamic in 100-250, no overlap..

You assume that “mint” hostname is modern Linux Mint and you are right, that is Linux Mint machine but with an old Linux Mint., 19.3… I should update it to the latest version but I see some bad issues with Intel GPU in the modern Mint/Ubuntu, so I do not hurry with an update…

I assume that ESP devices (ESP32 or ESP8266 chips) know nothing about mdns or zeroconfig, those are just simple IoT devices with limited resources…

DHCP works, all devices get IP address, they can connect to the internet.

Issue is at IPfire gateway, it doesn’t update local DNS entries from DHCP state.

1 Like

Do you have your fixed leases setup in “Edit hosts”
I have multiple names point to 1 IP in some cases.

I just found and started test PC, it runs IPfire 193. Simple configuration, RED+GREEN+BLUE, DHCP client on red, DHCP server on GREEN and BLUE. No fixed DHCP leases, just two clients on BLUE.

I can replicate the issue. Local DNS knows only about hosts those are active when IPfire boots or were active before reboot (and DHCP lease is still active). When I connect new device (Android tablet) to this gateway, it receives IP address and can connect to the internet. It hostname is not added to local DNS, file /etc/unbound/dhcp-leases.conf is not updated.

I noticed other issue. I have connected network cable that was not active to RED port (cable was connected to a switch that was power off). IPfire was not able to fix this situation, once the red network cable was connected to active switch. IPfire has not tried to ask for new IP address, RED was not usable. I fixed this by rebooting IPfire, after reboot IP address was assigned to RED interface and IPfire was able to connect to the internet. This is another serious weakness of current IPfire. And there is no button in “IPfire GUI” to connect/reconnect RED interface. I reported similar issue in the past, and I see it was not fixed.. :frowning:

1 Like

I have wrote this script and save it as resolve_fixed-addresses.sh:

for IPaddress in `cat /etc/dhcp/dhcpd.conf | grep fixed | cut -f2 -d' ' |cut -f1 -d';'`
do
        host $IPaddress
done

Than used it to count how many failures I have:

./resolve_fixed-addresses.sh | wc
     46     230    2896
 ./resolve_fixed-addresses.sh | grep NXDOMAIN | wc
      4      20     223

So PTR resolution returns NXDOMAIN for 4 out of 26 fixed IP addresses. (some fixed lease IP addresses have multiple hosts defined like “TV”, “SonyTV”, “Sony2” )

Now the interesting part: some fixed leases are for devices that were not connected in years to IPFire - like a very old phone that I did not powered up in years.
That old Fixed Address is still resolved as PTR.

In other words, in my box there is no correlation between how old is that entry and how much time passed since the box last saw that device connected and the failure of PTR address resolution.

I hope that my little test helps…

Late edit:
Script resolve_fixed-hosts.sh to resolve fixed hosts from resolve_fixed-hosts.sh

echo
echo "Searching for Hosts inside dhcpd.conf"
echo
domain=`cat /etc/resolv.conf | grep search | cut -f2 -d" "`
echo "Domain is $domain..."
echo
for leasehost in `cat /etc/dhcp/dhcpd.conf | grep 'host fix' | cut -f4 -d' '`
do
        host $leasehost.$domain
done

Then counts:

 ./resolve_fixed-hosts.sh | wc
     27     101     993
./resolve_fixed-hosts.sh | grep NXDOMAIN | wc
      5      25     205

So my machine fails to resolve 5 out of 26 fixed hosts…

1 Like

I successfully reproduced this problem on my test platform.
When an address is dynamically assigned by DHCP, it is not registered in the DNS.

It seems that the cause is the DNS_UPDATE_ENABLED value missing from the /var/ipfire/dhcp/settings file during installation.

Check the Enable DNS update (RFC2136) box, then save.
Uncheck the Enable DNS update (RFC2136) box, then save.

The /etc/unbound/dhcp-leases.conf file will be updated.

This may be a bug :thinking:

2 Likes

That is actually not set, which defaults to assign if client broadcast host name.

Which you could add this to the configuration if you want dns names on all dhcp clients

register-dhcp:yes

in /etc/unbound/unbond.conf

Nothings broke, but its a security practice not to auto map every dhcp client and only map broadcasting ones.

If you want that functionality you turn it on. The only difference is IPFire doesn’t have a web GUI control so you have to edit the file to set it.

But this is the normal default behavior and even other router OS software like pfsense is set like this at default.

I have no idea if that command is beneficial or could cause problems or not but it should be put in

/etc/unbound/local.d/*.conf

where * is a name you choose. The standard unbound.conf imports any local configurations from unbound/local.s/ that end in .conf

If placed in unbound.conf the file will be overwritten when unbound is updated in a Core Update.

I also have just noted that register-dhcp is not listed in the man page for unbound.conf so I would not suggest putting it into unbound.conf or its include files.

If anything, a control needs to be added in the GUI to toggle that functionality like the other router OS like pf sense OPENwrt, and others

Its a standard security practice to map only broadcasting clients.

1 Like

You can always submit a patch for that but first you should check where that option is used as it is not listed in the unbound man page for unbound.conf.

I think they are leaving that undocumented because it has an issue sanitizing the host names, but I’ll look to see since that was about 8 years ago.

But if its not currently in the man page, then there is a problem with it. But I would think someone would have fixed the sanitizing null and invalid characters by now. But of course not everyone’s dhcp lease file is structured the same because it varies depending on the dhcp server used. What they should have done is just be compatible to one type or have versions for the different dhcp servers because they react so differently between them and unbound.

1 Like

In that case there is other issue in IPire. On reboot it registers all active DHCP leases to local DNS… (File /etc/unbound/dhcp-leases.conf is updated on IPfire reboot).

I was using IPcop for several years and that fork of Smoothwall registered local clients to DNS. I am not sure now but I think that the IPfire was the same. Simple home routers (ASUS, TP-Link) propagate local clients to local network too (but it works only when WAN is connected, once WAN is down, they do not serve DNS, and I do not like this “bug”).

If this is a security feature that IPfire do not register new DHCP clients to DNS, I would like to see an option to disable it. DHCP client should not be able to overwrite “fixed” entry in DNS, that could be a problem.

In my network, I have PC “mint” and that is a “troublemaker” because every new Linux Mint PC has name “mint”, it is the default name selected by Linux Mint distribution used when Live Linux Mint is running…


I test with IPfire core 183 and local DNS is updated when new DHCP lease is assigned… That means, core 193 changed that behavior. Design or a bug?? I wrote 193 but I am not sure when this change was applied, I skipped several updates…

1 Like