Error while Enabling DNS Resolver

crimper

I have been using the PfSense Plus 26.03 with AdGuard as my external DNS forwarder for a while.

I tried to Enable DNS Resolver today and received the following error message;

The following input errors were detected:

The generated config file cannot be parsed by unbound. Please correct the following errors:
/var/unbound/test/root.key: No such file or directory
[1778142869] unbound-checkconf[33661:0] fatal error: auto-trust-anchor-file: "/var/unbound/test/root.key" does not exist in chrootdir /var/unbound

I'm not able to find the root.key file in both the /var/unbound and /var/unbount/test folders.

Anybody else encountering this issue? I wonder if this is a problem with my configuration or a system error.

Thank you.

Gertjan

@crimper said in Error while Enabling DNS Resolver:

I'm not able to find the root.key file in both the /var/unbound and /var/unbount/test folders.

It's there where it should be.
This file has its own story.
When pfSense starts unbound, it creates an "unbound.conf" with the settings found in the GUI.
The root.key file is part of the DNSDEC signing structure and a fresh copy is retrieved from a remote location. See here for details.
Your issue is : the "unbound-anchor" executable couldn’t retrieve the file.

Open the console or SSH, option 8 and try things out yourself :

26.03-RELEASE][root@pfSense.bhf.tld]/root: unbound-anchor -a /root/root.key
[26.03-RELEASE][root@pfSense.bhf.tld]/root: ls -al root.key
-rw-r--r--  1 root wheel 1250 May  7 11:48 root.key
[26.03-RELEASE][root@pfSense.bhf.tld]/root: cat root.key
; autotrust trust anchor file
;;id: . 1
;;last_queried: 1778147296 ;;Thu May  7 11:48:16 2026
;;last_success: 1778147296 ;;Thu May  7 11:48:16 2026
;;next_probe_time: 1778188199 ;;Thu May  7 23:09:59 2026
;;query_failed: 0
;;query_interval: 43200
;;retry_time: 8640
.       86400   IN      DNSKEY  257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b} ;;state=2 [  VALID  ] ;;count=0 ;;lastchange=1778147285 ;;Thu May  7 11:48:05 2026
.       86400   IN      DNSKEY  257 3 8 AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jBosZBU5eeHspaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vrhbu6irwCzVBApESjbUdpWWmEnhathWu1jo+siFUiRAAxm9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7CPqpdVwuMoTvoB+ZOT4YeGyxMvHmbrxlFzGOHOijtzN+u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxPvYLw4z9mR7K2vaF18UYH9Z9GNUUeayffKC73PYc= ;{id = 38696 (ksk), size = 2048b} ;;state=2 [  VALID  ] ;;count=0 ;;lastchange=1778147285 ;;Thu May  7 11:48:05 2026

First command : I executed unbound-anchor and asked it to place the file here /root/root.key
An then I listed that file. The date+time stamp shows it was downloaded seconds ago.
Then I showed the file.

Detail : unbound-anchor can't use 'unbound' as a DNS source. unbound-anchor is executed before unbound itself is set up and run. unbound itself needs this file to run - at least, the pfSense way of doing things implies the presence of this file.

About the /var/unbound/test/ folder :
Before unbound is actually started, a test setup is build in "/var/unbound/test/" with all the needed files. Then unbound is started (chrooted) in "/var/unbound/test/". If it started up just fine, it's taken down, the files are placed (one level up) in /var/bound/ and this time its started for real.

Of course, the short answer would do fine here : You've broken DNS.
Extra info : imho, "unbound-anchor" can't go 'outside' (== to the Internet) to get the file 'root.key' - it failed, so the test failed.

More info : if unbound itself isn't running, local (pfSense) DNS can't work.
I'm not sure what DNS server unbound-anchor uses to resolve the hostname used to find the needed file.
~~Don't let this stop you. unbound-anchor from NLLabs is open source, so very readable.~~ edit forget it. It's rocket science again. unbound-anchor if you're interested.

The NLLabs unbound-anchor doc (see above) tells me that this content is downloaded :
https://data.iana.org/root-anchors/root-anchors.xml
which is very important : it's the current trusted root of DNSSEC.
( and yes, it will even download this file if you've decided to not use DNSSEC)

crimper

Thanks for the heads-up. I have created the root.key file and placed it in /var/unbound. The same error show up whenever I tried to save the configuration in Services-DNS Resolver-General Settings.

I'll try to dig down the rabbit hole to see how the files are created and the sequence of events.

tinfoilmatt

The root.key file may or may not need to be owned by user unbound and group unbound. At least that's how it looks on my system:

-rw-r--r--   1 unbound unbound  1.2K MONTH  DAY 00:00 root.key

crimper

Ah.... Simple solution. Turn off RAM Disk. Reboot. Save Unbound settings. Turn on RAM Disk again. Reboot. Yey!

Thanks for the help.

Gertjan

@crimper said in Error while Enabling DNS Resolver:

Turn off RAM Disk. Reboot. Save Unbound settings. Turn on RAM Disk again. Reboot. Yey!

Hummm. unbound_anchor, the program that creates the 'root.key', doesn't care if the file is stored on bare metal spinning disks, an SSD type of storage or that the disk image is in RAM.
What can makes a difference : RAM disks are always to small.
Still, this root.key file is what ? 2 K max in size.

Is pfBlockerng used ? If so, if the pfBLocker files are also thrown into the /var/unbound/ and in /var/unbound/test/ for the test phase, then space can go down fast very temporary, the time /var/unbound/test/ exists (it's deleted after the test run, which is the reason we never see it when browsing the pfSense file system).
If pfBlockerng also uses the ancient 'unbound mode' and not 'Python mode', pfBlocker related files can be pretty big, like many Megas or more. These Mega size files would exist in /var/unbound/ and for a short time in /var/unbound/test/
and now I'm not surprised that the RAM disk said : "no go", and this would fail the unbound test drive, unbound won't start, /test/ gets deleted (now space is ok again) and unbound still won't get started.

Me thinking out loud here of course. I can't really test this as my RAM is way to small- just 4 G. And I've enough SSD space so I stay away from RAM drives.

edit : and for what it's worth : it could be a temporary glitch like "https://data.iana.org/" not avaible for a moment, so unbound_anchor can't do it's work, and it fails ... etc.

crimper

@Gertjan Now that DNS Resolver is Enabled and working, the only root.key file is found in /usr/local/etc/unbound. It's not found in /var/unfound.

I was reminded that /var is one of the temp folders created by RAM disk while going through the config. Maybe the root.key in /var/unbound/ and /test was created and overwritten somehow during the enabling process. Or some other perfectly logical explanation

Gertjan

@crimper said in Error while Enabling DNS Resolver:

Now that DNS Resolver is Enabled and working, the only root.key file is found in /usr/local/etc/unbound. It's not found in /var/unfound.

/usr/local/etc/unbound is the default 'unbound' package /etc/ location.
It's not used by pfSense, it doesn't add use or modify files in that place.

My files over there :

Look at the date of these two files that came along with the unbound package : 3 February 2026, the date I upgraded to my latest pfSense version.

pfSense - GUI or something else - can't and won't do anything with the location /usr/local/etc/unbound. Not that I know of.

SteveITS

@crimper unbound runs under chroot as I recall so that’s probably the correct path from unbound’s point of view. Also not all of /var is using tmpfs/RAM disk as I recall…run a “df -h”.

We use RAM disks as much as possible but I don’t recall ever disabling DNS Resolver. I wonder if that’s a bug between that and enabling the RAM disk, and after enabling DNS the file is there to be copied in at boot, or something.