DNS service broken BUG

Today I started ipfire before I startet the internet modem followed by ipfire DNS status broken. I started the modem and the internet came up. I could check then DNS servers availability via the ipfire webinterface and it went just fine, but the service stayed broken. Also there is no routine to reset or restart or rescan the service automatically when the internet comes up (again) and there is no way to restart the service via the webinterface to get the DNS to work. I had to restart the firewall to get internet.

That’s a BUG and not a feature…


… and what are we supposed to do with that description now?

If there are any relevant logs in /var/log/messages, could you please post them here so we at least have a chance to find out what went wrong exactly.

Thanks, and best regards,
Peter MĂĽller

First please let me know if that is supposed to happen because there no routine to update the internet/dns status automatically.

Because this should not needed. If the internet is up again the already running unbound instance can contact the servers without restart and if the red IP has changed the initskripts are runned again reconfigure the running unbound (update-dns-forwarders) git.ipfire.org Git - ipfire-2.x.git/tree - src/initscripts/networking/red.up/

1 Like

Same situation today and no working DNS.

I have the exact same issues with the latest versions, especially since 148.

I also think your issue is related to this topic: DNS issue causing loss of sanity and hair

Propably. I’ve tested it on 3 different systems and 2 different internet modems/routers, also RED in LAN and WLAN and got always the same result -> no domain name resolve. There are also no errors or warnings in any logfile.

I had to restart unbound or the system to get DNS back to work.

Did you wait a bit longer before restarting unbound? I have to wait about 8 minutes until dns resolving is working after red is up again.

I’ve been waiting for more than 30 minutes.

Any news on this? Im struggling with some IPFire installations which are randomly stop working because of this unbound bug. I would really love to have a fix for this…

My cable modem is quite slow to start so normally if it has to be turned off then I wait for it to be fully on line before I start my IPFire system.

To test the timing sequence I shutdown IPFire and turned off the cable modem. Then I booted IPFire. I then had Error messages for the enabled DNS entries and on the Home page it showed Connecting…

Then I turned on the cable modem and waited till it showed the steady green light indicating it was online. I still had Connecting… and this stayed the same for around 30 minutes.

Then on the command line I restarted networking. The home page then changed to Connected and the DNS entries were all shown as OK. DNS all working.

I looked in the RED system logs and found the following:-

13:40:18 dhcpcd[1698] : dhcpcd exited
13:40:18 dhcpcd[1698] : timed out
13:39:48 dhcpcd[1698] : red0: waiting for carrier
13:39:48 dhcpcd[1698] : DUID xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
13:39:48 dhcpcd[1696] : dhcpcd-9.1.2 starting

You can see red0 waiting for the carrier (not present because the cable modem is turned off) and then after 30 seconds dhcpcd times out and exits. So when the cable modem comes on line and the carrier is present it looks like dhcpcd is no longer running and cannot see the presence of the red carrier and request an ip address.

After restarting networking the log showed the following:-

14:09:37 dhcpcd[8686] : red0: adding default route via
14:09:37 dhcpcd[8686] : red0: adding route to
14:09:37 dhcpcd[8686] : red0: leased for 86400 seconds
14:09:32 dhcpcd[8686] : red0: probing address
14:09:32 dhcpcd[8686] : red0: offered from
14:09:30 dhcpcd[8686] : red0: soliciting an IPv6 router
14:09:29 dhcpcd[8686] : red0: soliciting a DHCP lease
14:09:29 dhcpcd[8686] : ipv6_addaddr1: Permission denied
14:09:29 dhcpcd[8686] : red0: adding address xxxx::xxx:xxxx:xxxx:xxxx
14:09:29 dhcpcd[8686] : red0: IAID xx:xx:xx:xx
14:09:29 dhcpcd[8686] : DUID xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
14:09:29 dhcpcd[8684] : dhcpcd-9.1.2 starting

This shows dhcpcd asking for and being given an ip address from red0

I don’t have your periodic DNS service broken problem but I can confirm that if the red carrier is not present within 30 seconds of dhcpcd starting to look for it then it times out and exits.
Rebooting or restarting networking from the command line brings everything back up to normal operation.

This is with a cable router. A cable modem gives you public IP.
Perhaps I find the time/have the opportunity to test your steps with my own installation.
The power outage this afternoon, not planned but by activation of the FI through a clothes iron :wink: , did not show the problem.

Yes, you are right my cable modem is running in router mode for an arcane reason I won’t go into now.

I tried just disconnecting the cable going into the cable router and that left me with Connected showing on the home page but gave a broken DNS status page with Error messages for the enabled servers. I think this does duplicate what Terry was finding. Reconnecting the cable made everything work again. I did not have to reboot or restart networking, so that is not in line with Terry’s input.

The 30 second timeout for dhcpcd is a default setting. I changed it to 0 seconds in dhcpcd.conf which means it will keep checking for ever. I then repeated the IPFire and cable router shutdown and restarted IPFire. The 0 seconds timeout means that IPFire stays looking for a carrier on red0 until it finds one.
I left it like that for 3 minutes and then turned on the cable router. dhcpcd then acquired the carrier on red0 and got to soliciting a DHCP lease but then stuck at that point. Rebooting IPFire then got it back to normal.

I think I am at the end of my knowledge skills with this. I will probably just keep ensuring that the cable router/modem is fully up before starting IPFire.
I have IPFire connected to a UPS so it will be protected from short power outages.

I had similar symptoms, but a different root cause and solution.

DNS didn’t work, and the DNS status showed as “Broken,” but all configs seemed right. It turned out that unbound’s root.key was corrupted, ie., empty.


regenerated the file.

unbound-control start

restarted it.

Hope it helps.