# Local DNS not reliable

**URL:** <https://community.ipfire.org/t/local-dns-not-reliable/13942>\
**Category:** Network\
**Created:** [16 April 2025 21:55 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942 "2025-04-16T21:55:29Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![pslpsl](https://community.ipfire.org/user_avatar/community.ipfire.org/pslpsl/32/15261_2.png) [@pslpsl](https://community.ipfire.org/u/pslpsl)\
**Post date:** [16 April 2025 21:55 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/1 "2025-04-16T21:55:30Z")

</div>

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.

```plaintext
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";
}

```

```plaintext
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… ☹

Visible client:

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

```

Invisible client:

```plaintext
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…

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

```

---

<div class="post-metadata">

**Author:** ![nickh](https://community.ipfire.org/user_avatar/community.ipfire.org/nickh/32/9845_2.png) [@nickh](https://community.ipfire.org/u/nickh)\
**Post date:** [17 April 2025 15:24 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/2 "2025-04-17T15:24:29Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![bloater99](https://community.ipfire.org/user_avatar/community.ipfire.org/bloater99/32/15796_2.png) [@bloater99](https://community.ipfire.org/u/bloater99)\
**Post date:** [17 April 2025 16:15 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/3 "2025-04-17T16:15:10Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![nickh](https://community.ipfire.org/user_avatar/community.ipfire.org/nickh/32/9845_2.png) [@nickh](https://community.ipfire.org/u/nickh)\
**Post date:** [17 April 2025 16:41 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/4 "2025-04-17T16:41:59Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![hvacguy](https://community.ipfire.org/user_avatar/community.ipfire.org/hvacguy/32/8576_2.png) [@hvacguy](https://community.ipfire.org/u/hvacguy)\
**Post date:** [18 April 2025 10:07 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/5 "2025-04-18T10:07:54Z")

</div>

> [@pslpsl](#):
>
> My local DHCP server

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

---

<div class="post-metadata">

**Author:** ![pslpsl](https://community.ipfire.org/user_avatar/community.ipfire.org/pslpsl/32/15261_2.png) [@pslpsl](https://community.ipfire.org/u/pslpsl)\
**Post date:** [18 April 2025 14:21 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/6 "2025-04-18T14:21:16Z")

</div>

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

```auto
-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”.

---

<div class="post-metadata">

**Author:** ![loup001](https://community.ipfire.org/user_avatar/community.ipfire.org/loup001/32/16221_2.png) [@loup001](https://community.ipfire.org/u/loup001)\
**Post date:** [18 April 2025 20:37 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/7 "2025-04-18T20:37:40Z")

</div>

@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](https://unix.stackexchange.com/questions/359253/dhclient-not-updating-etc-resolv-conf#359289)

Hope this help

---

<div class="post-metadata">

**Author:** ![hvacguy](https://community.ipfire.org/user_avatar/community.ipfire.org/hvacguy/32/8576_2.png) [@hvacguy](https://community.ipfire.org/u/hvacguy)\
**Post date:** [18 April 2025 20:49 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/8 "2025-04-18T20:49:31Z")

</div>

> [@pslpsl](#):
>
> I have 8 fixed entries

Are they outside of your DHCP dynamic range?

---

<div class="post-metadata">

**Author:** ![pslpsl](https://community.ipfire.org/user_avatar/community.ipfire.org/pslpsl/32/15261_2.png) [@pslpsl](https://community.ipfire.org/u/pslpsl)\
**Post date:** [20 April 2025 12:06 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/9 "2025-04-20T12:06:31Z")

</div>

> [@hvacguy](#):
>
> > [@pslpsl](#):
> >
> > I have 8 fixed entries
> 
> Are they outside of your DHCP dynamic range?

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

---

<div class="post-metadata">

**Author:** ![pslpsl](https://community.ipfire.org/user_avatar/community.ipfire.org/pslpsl/32/15261_2.png) [@pslpsl](https://community.ipfire.org/u/pslpsl)\
**Post date:** [20 April 2025 12:15 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/10 "2025-04-20T12:15:11Z")

</div>

> [@loup001](#):
>
> 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

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.

---

<div class="post-metadata">

**Author:** ![hvacguy](https://community.ipfire.org/user_avatar/community.ipfire.org/hvacguy/32/8576_2.png) [@hvacguy](https://community.ipfire.org/u/hvacguy)\
**Post date:** [20 April 2025 12:38 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/11 "2025-04-20T12:38:53Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![pslpsl](https://community.ipfire.org/user_avatar/community.ipfire.org/pslpsl/32/15261_2.png) [@pslpsl](https://community.ipfire.org/u/pslpsl)\
**Post date:** [20 April 2025 13:18 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/12 "2025-04-20T13:18:12Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![hjkl](https://community.ipfire.org/user_avatar/community.ipfire.org/hjkl/32/8574_2.png) [@hjkl](https://community.ipfire.org/u/hjkl)\
**Post date:** [21 April 2025 07:02 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/14 "2025-04-21T07:02:51Z")

</div>

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

```auto
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:

```auto
./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`

```auto
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:

```auto
 ./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…

---

<div class="post-metadata">

**Author:** ![pscar13](https://community.ipfire.org/user_avatar/community.ipfire.org/pscar13/32/16558_2.png) [@pscar13](https://community.ipfire.org/u/pscar13)\
**Post date:** [21 April 2025 10:12 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/15 "2025-04-21T10:12:35Z")

</div>

> [@pslpsl](#):
>
> 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 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 🤔

---

<div class="post-metadata">

**Author:** ![dr\_techno](https://community.ipfire.org/user_avatar/community.ipfire.org/dr_techno/32/15388_2.png) [@dr\_techno](https://community.ipfire.org/u/dr_techno)\
**Post date:** [21 April 2025 12:29 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/16 "2025-04-21T12:29:26Z")

</div>

> [@pscar13](#):
>
> When an address is dynamically assigned by DHCP, it is not registered in the DNS.

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

```auto
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.

---

<div class="post-metadata">

**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\
**Post date:** [21 April 2025 12:46 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/17 "2025-04-21T12:46:38Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dr\_techno](https://community.ipfire.org/user_avatar/community.ipfire.org/dr_techno/32/15388_2.png) [@dr\_techno](https://community.ipfire.org/u/dr_techno)\
**Post date:** [21 April 2025 12:47 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/18 "2025-04-21T12:47:45Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\
**Post date:** [21 April 2025 12:49 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/19 "2025-04-21T12:49:35Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dr\_techno](https://community.ipfire.org/user_avatar/community.ipfire.org/dr_techno/32/15388_2.png) [@dr\_techno](https://community.ipfire.org/u/dr_techno)\
**Post date:** [21 April 2025 13:04 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/20 "2025-04-21T13:04:21Z")

</div>

> [@dr\_techno](#):
>
> `register-dhcp:yes`

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.

---

<div class="post-metadata">

**Author:** ![pslpsl](https://community.ipfire.org/user_avatar/community.ipfire.org/pslpsl/32/15261_2.png) [@pslpsl](https://community.ipfire.org/u/pslpsl)\
**Post date:** [21 April 2025 14:03 UTC](https://community.ipfire.org/t/local-dns-not-reliable/13942/21 "2025-04-21T14:03:42Z")

</div>

> [@dr\_techno](#):
>
> Nothings broke, but its a security practice not to auto map every dhcp client and only map broadcasting ones.

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…

[Next page](https://community.ipfire.org/t/local-dns-not-reliable/13942.md?page=2)
