What does “unbound-control status” says? I got the same fatal error as you, but this command told me more details about the reason.
It says:
[1582708533] unbound-control[24939:0] error: connect: Connection refused for 123
unbound is stopped
O.K., that looks like another problem. Sorry, but i can’t help with this.
Thanks anyway for your help - much appreciated.
It has something to do with the restore of the Version-139 backup file onto the newly installed Version-141 system.
In the meantime I have set up another unit with version 141 from scratch without restoring anything and, voilà, DNS is working as it should.
For the moment I will just stay on Version 139, if I have to recreate everything (especially all VPN) manually, that would be a big chore.
Thank you again and kind regards
Christoph
1 Like
Just to conclude, finally I figured out the problem - it is the backup and restore process.
Originally, I did a backup of version 139, then a clean install of version 141 and restored the backup. This does not work, there is a problem somewere if you do this.
You first have to do just the update from 139 to 141. If you want the new disk layout, now do the fresh install and then restore the 141-backup. Now everything work great!
2 Likes
Hi,
I just upgraded my test machine from core 138 to core 141.
Unbound simply does not solve any request.
Ex1 - boot error - can’t solve the NTP servers to perform clock update at boot:
Setting time on boot…
Error resolving 0.ipfire.pool.ntp.org: Name or service not known (-2)
Error resolving 1.ipfire.pool.ntp.org: Name or service not known (-2) [ OK ]
At command prompt NTP servers are not resolved by unbound
[root@black-x86-64 ~]# nslookup google.com
Server: 127.0.0.1
Address: 127.0.0.1#53** server can’t find google.com: SERVFAIL
[root@black-x86-64 ~]# nslookup 0.ipfire.pool.ntp.org
Server: 127.0.0.1
Address: 127.0.0.1#53** server can’t find 0.ipfire.pool.ntp.org: SERVFAIL
Then logs show that unbound is unable to resolve any request from clients in the network:
Mar 15 13:37:59 black-x86-64 unbound: [18575:1] info: generate keytag query _ta-4a5c-4f66. NULL IN
Mar 15 13:38:00 black-x86-64 unbound: [18575:1] info: validation failure dns.msftncsi.com. A IN
Mar 15 13:38:00 black-x86-64 unbound: [18575:0] info: validation failure www.msftncsi.com. A IN
Mar 15 13:38:00 black-x86-64 ntpd[17974]: new interface(s) found: waking up resolver
Mar 15 13:38:00 black-x86-64 unbound: [18575:1] info: validation failure client.wns.windows.com. A IN
Mar 15 13:38:00 black-x86-64 unbound: [18575:1] info: validation failure ipv6.msftncsi.com. A IN
Mar 15 13:38:00 black-x86-64 unbound: [18575:1] info: validation failure skydrive.wns.windows.com. A IN
Mar 15 13:38:03 black-x86-64 unbound: [18575:0] info: validation failure win8.ipv6.microsoft.com. A IN
Mar 15 13:38:03 black-x86-64 unbound: [18575:1] info: validation failure www.microsoft.com. A IN
Mar 15 13:38:03 black-x86-64 unbound: [18575:1] info: validation failure www.facebook.com. A IN
Mar 15 13:38:04 black-x86-64 unbound: [18575:1] info: validation failure fgd1.fortigate.com. A IN
Mar 15 13:38:04 black-x86-64 unbound: [18575:1] info: validation failure www.bing.com. A IN
Mar 15 13:38:05 black-x86-64 unbound: [18575:1] info: validation failure www.google.com. A IN
Mar 15 13:38:36 black-x86-64 unbound: [18575:1] info: validation failure dns.msftncsi.com. A IN
Mar 15 13:38:49 black-x86-64 unbound: [18575:1] info: validation failure client.wns.windows.com. A IN
Unbound process exist:
[root@black-x86-64 ~]# /etc/init.d/unbound status
unbound is running with Process ID(s) 15195.
dns.cgi also shows it OK:
Unbound-contol also shows it OK:
I restarted unbound, this did not fixed above.
[root@black-x86-64 ~]# unbound-control status
version: 1.9.6
verbosity: 1
threads: 2
modules: 2 [ validator iterator ]
uptime: 1258 seconds
options: reuseport control
unbound (pid 18575) is running…
Any idea how to solve it?
PS: I had in core 12x the DNS server setup manually and then moved red0 to DHCP. This is why in dns.cgi there are listed 2 pairs of DNS servers: one coming from DHCP red0 and one that I had them statically added in the past. These values are in /etc/ppp/resolv.conf and seems to be copied in /etc/unbound/forward.conf
The “ISP assigned servers” are taken from DHCP or PPP. You can disable it with the checkbox below.
in your screenshot they are listed but not used. This convert of the settings looks ok.
Strange is that the cgi shows working. Because this test use unbound to resolve “ping.ipfire.org”
Do you run suricata? I had serious problems with unbound and suricata in core141. (The should fixed in core142).
1 Like
Yes, I use Suricata…with both ET & Talos sources (merged) and all possible rules active…
Ok, I will wait for 142…my production IPFire is core 139…
Which by the way! still needs unbound restart to make it work (there was a fix from core 138 to 139 to make unbound to work, but for my machine I still need to restart unbound).
So many things failed because unbound does not work: pakfire not working, DNS Blocking script, …talos and ET downloads fail,…etc
@arne_f Arne,
DNS Resolution crash with Norton DNS 199.85.127.30 and 199.85.126.30
But works fine with Cloudflare…
Seems that Norton DNS service does not work with new unbound (it worked fine for the past couple of years)
H&M
Late edit: seems init.d/unbound script has some issues
/etc/init.d/unbound test-name-server 199.85.127.30
199.85.127.30 is validating
/etc/init.d/unbound: line 453: [ off: command not found
199.85.127.30 supports TCP fallback
EDNS buffer size for 199.85.127.30: 4096
It’s a known bug: git.ipfire.org Git - ipfire-2.x.git/commit
But the whole function is removed with core141.
Arne,
I am at: Core-Update-Level: 145
I ran into this trying to find an answer for pretty much the same screenshot issue as posted above for DNS servers showing OK, but with a Broken Status. rDNS does not work. I think it may boil down to a DNSSEC issue, but thought I would get your option. I considered a double PAT situation as IPFire is sitting behind an ISP modem/router but the firewall component is disabled at the ISP equipment. I even tried enabling a status passthrough on TCP connections for a static/dynamic IP I assigned to IPFire for the MAC of the Red Interface. I figured heck, whats the point… Might as well assign it statically so its not a guessing game.
In any event, I have a Green to Red Rule to allow free passage of traffic for 53 TCP/UDP, although i use UDP for DNS. Thought I would allow it in case I need to test TCP.
DHCP on Green is pointing intentionally at 8.8.8.8 and 8.8.4.4 although if I can get it working, I would rather point DHCP at Green Interface of IPFire and let it handle DNS for me. Note… I have checked box for ISP assigned, saved, and checked with still the same issue.
The darn weird thing, is that with my IPFire Red address in passthrough mode at the ISP modem/router I thought I would test unbound as well, since some of the folks up top here had some messages.
Here is a running shell line by line so you can see what I did when I threw the second leg of my network edge in transparent passthrough. I thought below that its strange that is saying its “Broke” but not 1 single message in my testing below saying its really broke. The message saying it can’t get ports is because I tried to start unbound -dd before stopping the service, but that piece I just stopped unbound and then tried again manually on cli… Still… No real error.
[root@ipfire ~]# unbound-control status
version: 1.10.1
verbosity: 1
threads: 1
modules: 2 [ validator iterator ]
uptime: 343085 seconds
options: reuseport control
unbound (pid 3310) is running…
[root@ipfire ~]# cd /etc/unbound/local.d/
[root@ipfire local.d]# ls
[root@ipfire local.d]# unbound -dd
Jun 27 20:40:53 unbound[7736:0] error: can’t bind socket: Address already in use for 127.0.0.1 port 8953
Jun 27 20:40:53 unbound[7736:0] error: cannot open control interface 127.0.0.1 8953
Jun 27 20:40:53 unbound[7736:0] fatal error: could not open ports
[root@ipfire local.d]# unbound-control stop
ok
[root@ipfire local.d]# unbound -dd
Jun 27 20:41:12 unbound[7787:0] notice: init module 0: validator
Jun 27 20:41:12 unbound[7787:0] notice: init module 1: iterator
Jun 27 20:41:12 unbound[7787:0] info: start of service (unbound 1.10.1).
^CJun 27 20:42:41 unbound[7787:0] info: service stopped (unbound 1.10.1).
Jun 27 20:42:41 unbound[7787:0] info: server stats for thread 0: 3 queries, 3 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Jun 27 20:42:41 unbound[7787:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0
[root@ipfire local.d]# unbound-control start
[root@ipfire local.d]# unbound-control status
version: 1.10.1
verbosity: 1
threads: 1
modules: 2 [ validator iterator ]
uptime: 5 seconds
options: reuseport control
unbound (pid 8051) is running…
[root@ipfire local.d]#
I had the same problem behind ISP router.
Had to fall back to standard DNS udp.
TLS did not work
Hi Shaun,
I am using standard UDP DNS port 53, have firewall ports open, and even added host names in the IPFire config. I am not using TLS.
But you are using Safe Search.
Don’t know, if this matters. But it is worth a try.
Hi Bernhard,
Safe mode was an accident. Glad you pointed that out. I was up late last night testing and left it on by mistake.
Eric
have you enables IPS / Suricata? on some systems/isp there is a problem that IPS blocks DNS connections from unbound.
If not try unbound-anchor to update the root key.
Arne, question…
Will the unbound-anchor help bind DNSSEC so that my DNS requests are secured? I know it sounds like a noob question, but still have a few problems. While I can get DNS resolve on A records, none are DNSSEC responses. Would this help to regenerate the root certificate and key?
This is the key that fixed my network/domain name system problem of Status: Broken, when all the status’ were “OK” for the nameservers . My problem is the same, but different direction.
Unbound was not running (“ps ax | grep unbound”). I ran the
unbound -dd
on the ipfire command line. This showed me an error in the local-data at line 31 and unbound exited again.
Jul 08 18:51:13 unbound[10559:0] error: error parsing local-data at 31 ‘Roku Express.xx.yy.com 60 IN A 192.168.1.82’: Syntax error, could not parse the RR’s type
Jul 08 18:51:13 unbound[10559:0] error: Bad local-data RR Roku Express.xx.yy.com 60 IN A 192.168.1.82
Jul 08 18:51:13 unbound[10559:0] fatal error: Could not set up local zones
That looked similar to the “network/Edit Hosts” menu of current hosts. At first I did not see the error. Now I see it all the time. NO Spaces are allowed in URLs. So shortening the “Roku Express” to “RokuExpress” in hosts, retrying “unbound -dd” on the command line worked.
Checking the Status in network/Domain Name System, reveals “Working”.
Your mileage may vary (YMMV). Why? because of flakey configurations that are not checked at menu entry time. The DNS/unbound is still a work in progress, but much much much better than before. Thanks to the developers.
2 Likes
The hostname check will be corrected with one of the next core updates.
The problem is known. But if you don’t use unallowed characters in hostnames/URLs there is no problem.
1 Like
Did anyone ever find solution to this? I have same problem. Seems lik ever sense ipfire updated everything is unstable at best. Feel more like floating this thing down the river :{
1 Like