Custom options in unbound (dns resolver) cause syntax error
-
Hi All,
PFSense 2.8.1 CE here.
I came across a frustrating problem with unbound custom options, in that it doesn't work, at least with some directives. In my case I am trying to use the private-domain directive to allow a specific domain to resolve to a private IP address, and yes, I'm fully aware of why this is normally blocked, thank you for your attention to this matter.

So here is what I am trying to put into custom options:
private-domain: "some-domain.com"Unfortunately this results in a syntax error and refusal to apply the configuration. In digging into this further at the command line the issue seems to be related to WHERE in unbound.conf the custom options are being inserted...
By default they appear here near the bottom:
# Access lists include: /var/unbound/test/access_lists.conf # Static host entries include: /var/unbound/test/host_entries.conf # dhcp lease entries include: /var/unbound/test/dhcpleases_entries.conf # OpenVPN client entries include: /var/unbound/test/openvpn.*.conf # Domain overrides include: /var/unbound/test/domainoverrides.conf # Unbound custom options private-domain: "some-domain.com" ### # Remote Control Config ### include: /var/unbound/test/remotecontrol.confThis gives the following error if I manually validate the configuration:
/var/unbound/test: unbound-checkconf -f unbound.conf unbound.conf:105: error: syntax error read unbound.conf failed: 1 errors in configuration fileThis is the same error I see in the GUI.
However if I simply move the custom section ahead of the domain overrides include, it works:
# Access lists include: /var/unbound/test/access_lists.conf # Static host entries include: /var/unbound/test/host_entries.conf # dhcp lease entries include: /var/unbound/test/dhcpleases_entries.conf # OpenVPN client entries include: /var/unbound/test/openvpn.*.conf # Unbound custom options private-domain: "some-domain.com" # Domain overrides include: /var/unbound/test/domainoverrides.conf ### # Remote Control Config ### include: /var/unbound/test/remotecontrol.confunbound-checkconf -f unbound.conf unbound-checkconf: no errors in unbound.confI don't know if all unbound directives cause errors in the usual location of the custom options as I have never used it before, however the few directives that I've tried all cause errors when used via the custom options box but work if moved above domain overrides.
It's unclear to me whether this is only a problem with the unbound-checkconf validator, or whether unbound really is fussy about what order certain kinds of directives must appear in the config file.
Anyone have any insights here ? I'm not intimately familiar with unbound and haven't seen anything in the documentation to suggest that certain orders of directives are required, which would be problematic for any kind of custom options box that inserts options in only one location.
-
@DBMandrake do you have server: at the top?
https://docs.netgate.com/pfsense/en/latest/services/dns/resolver-config.html

I have a private-domain setup, I have no issues. But I have server: at the top of the options

-
@johnpoz Ah, thank you so much - that's clever...
I assume that tells unbind to consider the following commands to be part of the server: section at the top of the configuration file, even though it is later in the file...
That works on my test system, however when I went to the real system to apply it I realised PFBlocker has already put this in the custom options: (my test system doesn't have pfblocker)
server:include: /var/unbound/pfb_dnsbl.*confI've added my original line under that because server: is already included here, and it works, however my concern is, under what conditions does PFBlocker edit the custom options field of unbound ?
Will it overwrite my change later or only if I uninstall and re-install PFBlocker ?
It seems a little bit kludgy that the PFBlocker package directly modifies the user-visible custom options field of another package (potentially mingling with the users custom options) rather than having its own dedicated include section in unbound.conf to provide a clean separation...
But in any case this workaround seems to work - I'll just have to make a note to check it is still there if I ever have to do a reinstall again in case installing the pfblocker package overwrites it.
-
@DBMandrake said in Custom options in unbound (dns resolver) cause syntax error:
conditions does PFBlocker edit the custom options field of unbound ?
Not sure, I don't use pfblocker in that way. I only use it to create aliases I use in my rules. But I would think it would only ever edit its own line. But your question is if you turn that feature off in pfblocker will it remove the server: portion and break your other options?
You could prob toggle dnsbl in pfblocker and see. You might also want to look to what mode you have it set too, I believe the python mode changes that and might not use the custom option

Unbound Python Mode: This mode is only available for pfSense version 2.4.5 and above. This mode will utilize the python integration of Unbound for DNSBL. This mode will allow logging of DNS Replies, and more advanced DNSBL Blocking features. This mode requires substantially less memoryWhile I am a huge fan of pfblocker - I just don't use that feature, so not sure. I only use it to maintain aliases - which it does a fantastic job at, that I use in my rules. So I don't have dnsbl enabled.
-
@johnpoz Good point, maybe I should add my own server: line as well, as long as it doesn't hurt, as removing PFBLocker in the future could remove that entire line and then break the functionality of my line relying on the server: directive even if it doesn't remove my custom line.
I don't use the firewall side of PFBlocker, I use only the DNS side to enable DNS based Safesearch as this is MUCH easier than creating (and maintaining) dozens of Safesearch DNS overrides manually...
-
@DBMandrake said in Custom options in unbound (dns resolver) cause syntax error:
I realised PFBlocker has already put this in the custom options: (my test system doesn't have pfblocker)
Something that isn't installed can't modify your unbound configuration ;)
But : if it was installed (way in) in the past, and DNSBL was used, it (pfBlocker) will add that "server:include: /var/unbound/pfb_dnsbl.*conf".
It could be true that, when pfBlockerng was removed, this line persists.
Unbound won't 'break' when it tries to read in a file during process start that doesn't exist anymore.@DBMandrake said in Custom options in unbound (dns resolver) cause syntax error:
... provide a clean separation
as already mentioned above : the solution was found a couple of years ago : pfBlockerng now has 'Python mode' which doesn't need any 'unbound' configuration file modifications.
Hummmm. maybe not entirely true : this :

will get set.
@DBMandrake said in Custom options in unbound (dns resolver) cause syntax error:
removing PFBLocker in the future could remove that entire line and then break t
Add you line's) like this :
server:include: /var/unbound/pfb_dnsbl.*conf
server:do-ipv6: no
server:ede: yes
server:private-domain: "some-domain.com"
etc. -
@Gertjan include wouldn't be part of it - unless you were loading a file.
-
@Gertjan said in Custom options in unbound (dns resolver) cause syntax error:
Something that isn't installed can't modify your unbound configuration ;)
But : if it was installed (way in) in the past, and DNSBL was used, it (pfBlocker) will add that "server:include: /var/unbound/pfb_dnsbl.*conf".
It could be true that, when pfBlockerng was removed, this line persists.
Unbound won't 'break' when it tries to read in a file during process start that doesn't exist anymore.I meant that my test system that I was doing initial testing on of unbound configuration changes does not have PFBlocker but the live system that the fix needed to go on after testing does have PFBlocker installed and in use, sorry if that wasn't clear.
-
@johnpoz said in Custom options in unbound (dns resolver) cause syntax error:
include wouldn't be part of it
Oops.
I corrected my post.