Unbound cannot start in 2.2 RELEASE

kdillen

Sollution is simple. During the upgrade your root.key file got corrupt. If you open it you will get binary content instead of text. Work around is simple: remove the file and recreate it with the correct content.

reqlez

okay i found stuff here: https://www.unbound.net/documentation/howto_anchor.html

Maybe i will use the util to recreate it i guess …

reqlez

okay for anybody experiencing the same issue, this is how i solved it:

went into the diagnostics _> command menu and typed in line by line:

rm /var/unbound/root.key

unbound-anchor -a /var/unbound/root.key

chown unbound /var/unbound/root.key

After that, unbound stars fine now :)

One thing i don't know, does that unbound-anchor generate the right key file to use ? or did pfsense have a custom file that is more updated ?

kdillen

I copied the root.key file from another pfsense firewall still running 2.1.5 and unbound. I just did the unbound-anchor command as you provided but to a temporary file. Both files are identically so the file created with the command is the latest version.

reqlez

@kdillen:

I copied the root.key file from another pfsense firewall still running 2.1.5 and unbound. I just did the unbound-anchor command as you provided but to a temporary file. Both files are identically so the file created with the command is the latest version.

thanks for confirming that !

doktornotor

There's really no need to copy anything from anywhere. It gets downloaded from root servers when you start unbound, kindly read /etc/inc/unbound.inc

kejianshi

The only thing odd I've noticed with unbound is that if I try to use Drill without putting a DNS server in system > general, drill reports nothing.

$ drill google.com
Error: error sending query: No (valid) nameservers defined in the resolver

But then if I put 8.8.8.8 in the server list:

$ drill google.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 24628
;; flags: qr rd ra ; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; google.com. IN A

;; ANSWER SECTION:
google.com. 131 IN A 74.125.22.100
google.com. 131 IN A 74.125.22.138
google.com. 131 IN A 74.125.22.101
google.com. 131 IN A 74.125.22.139
google.com. 131 IN A 74.125.22.113
google.com. 131 IN A 74.125.22.102

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 20 msec
;; SERVER: 8.8.8.8
;; WHEN: Mon Jan 26 12:12:03 2015
;; MSG SIZE rcvd: 124

So - A little bit of strange behavior and not sure why.
Without the 8.8.8.8 in the server list, all is fine EXCEPT things like drill from command prompt.

Any clues?

doktornotor

I guess you should uncheck the "Do not use the DNS Forwarder as a DNS server for the firewall" in System - General. (Should see 127.0.0.1 in System Information - DNS Server(s) dashboard).

kejianshi

That is checked and all is fine and working for all clients and also for pfsense update status.

Just not for drill. No idea why.
I put my LAN IP in the server list just to see what would happen and all is well.

I wouldn't mind having 8.8.8.8/8.8.4.4 in the list as long as I can be 100% sure its never going to be used by LAN clients for DNS resolution.

doktornotor

Yes. You should UNcheck that.

kejianshi

I just did as you suggested and its working fine with that being unchecked as you suggest and nothing entered into the IP list.

The only reason I ever did check that block is because just yesterday update status wouldn't work unless I checked it but today seems it is working.

Maybe I just needed to wait a bit? No idea.

Ohhhhh well - Its working now. Good enough for me.

Which button do you prefer I press? [applaud] or [smite]?

Looks like you are trying to break the record for most helpful person with most smites. haha.

doktornotor

@kejianshi:

The only reason I ever did check that block is because just yesterday update status wouldn't work unless I checked it but today seems it is working.

The updates/packages site seems to randomly become unresponsive without any good reason. (Not really any pattern but it happens much more frequently on boxes with IPv6 connectivity.)

@kejianshi:

Which button do you prefer I press? [applaud] or [smite]?
Looks like you are trying to break the record for most helpful person with most smites.

LOLz… Press whatever you want. This karma thing should be nuked from the forum.

johnpoz

^ I have been clicking applaud on dok whenever I remember.. Trying to get him into the positive range where he should be ;)

Seems he ticked off someone with more desire to keep sending him down, where my buddy only did about 20 before got bored..

reqlez

@johnpoz:

^ I have been clicking applaud on dok whenever I remember.. Trying to get him into the positive range where he should be ;)

Seems he ticked off someone with more desire to keep sending him down, where my buddy only did about 20 before got bored..

I should probably smite him for highjacking my thread ! lol ( j/k ).

By the way, the reason i had to recreate that key file is because unbound would not recreate it during bootup or startup. I didn't copy it form anywhere, I just used the unbound utility that seeds that file form somewhere.

luckman212

@reqlez:

okay for anybody experiencing the same issue, this is how i solved it:

rm /var/unbound/root.key
unbound-anchor -a /var/unbound/root.key
chown unbound /var/unbound/root.key

Was having a heck of a time on my 2.2.2 install with the same issue. Thanks for your help - fix worked for me! I wonder why this file gets corrupt? I was messing around with captive portal, it happened after that… not sure if that's related or coincidental.

Amiga500

I recently moved, and when I re-connected my device unbound wouldn't start.
Before I performed the required steps to recreate the root.key file, I looked at it with "cat /var/unbound/root.key"
I was surprised to find this…

# The format of this file is documented in the dhcpd.leases(5) manual page.
# This lease file was written by isc-dhcp-4.2.6

lease 10.0.2.135 {
  starts 0 2015/05/24 21:24:57;
  ends 0 2015/05/24 21:47:05;
  tstp 0 2015/05/24 21:47:05;
  cltt 0 2015/05/24 21:24:57;
  binding state free;
  hardware ethernet 00:0c:29:x:x:x;
}
lease 10.0.2.136 {
  starts 1 2015/05/25 17:26:23;
  ends 1 2015/05/25 19:26:23;
  tstp 1 2015/05/25 19:26:23;
  cltt 1 2015/05/25 17:26:23;
  binding state free;
  hardware ethernet e4:ce:8f:x:x:x;
  uid "\001\344\316\217*\311\226";
}
lease 10.0.2.134 {
  starts 1 2015/05/25 17:50:13;
  ends 2 2015/05/26 17:50:13;
  tstp 2 2015/05/26 17:50:13;
  cltt 1 2015/05/25 17:50:13;
  binding state free; ....

After recreating the root.key file it looks completely different…

; autotrust trust anchor file
;;id: . 1
;;last_queried: 1434226551 ;;Sat Jun 13 16:15:51 2015
;;last_success: 1434226551 ;;Sat Jun 13 16:15:51 2015
;;next_probe_time: 1434266973 ;;Sun Jun 14 03:29:33 2015
;;query_failed: 0
;;query_interval: 43200
;;retry_time: 8640
.	172800	IN	DNSKEY	257 3 8 ...

Is another process writing to this file and breaking unbound?

cmb

@beetlejelly:

Is another process writing to this file and breaking unbound?

No, that's typical of what happens when a file isn't fsynced and you lose power shortly after writing it. Should be worked around now, and reported upstream to be fixed in Unbound.
https://redmine.pfsense.org/issues/5334