DNSSEC Enabled, but not configured correctly

[zxuilnie]

Hi, I have previously setup a recursive Unbound DNS server before without issue, however I am new to OPNsense/BSD environments in general so apologies if I am carrying over some of my Linux assumptions with me.

I just setup a new OPNsense 23.1.7_3 box to play around with, am using it as my primary router to force me to learn, everything has been fine and setup without issue, Recursive Unbound (bar DNSSEC), multiple LANs, firewall rules, wireguard, all fine.

DNSSEC is enabled, however it doesn't seem properly configured as is.

What I expect, and what I got from my previous Unbound server in the past:

Code: [Select]

$ dig opnsense.org +dnssec @1.1.1.1
; <<>> DiG 9.18.14 <<>> opnsense.org +dnssec @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57543
;; flags: qr rd ra [b]ad[/b]; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;opnsense.org. IN A

;; ANSWER SECTION:
opnsense.org. 900 IN A 178.162.131.118
opnsense.org. 900 IN RRSIG A 8 2 900 20230630180002 20230401180002 49569 opnsense.org. I2tN3SBesNTUpeFvF001L91c4PQ6BMY5jCvHppUHsN4VDEigvq2EzZEe WKmkwHjOzZoAmlfPoOwp9JUOuKbOhjENfF7VzOMYa4VDurQxiIo7YJ+S 7nI/kphezmLy30PsRtTLFolzwasY8hHj+Fwk/rXwk+P1yQzf2YzRrwEO 6CE=

;; Query time: 24 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Wed May 10 23:47:21 IST 2023
;; MSG SIZE  rcvd: 229
Noting the ad flag indicating DNSSEC setup successfully.

Versus what I am getting now on OPNsense:

Code: [Select]

$ dig opnsense.org +dnssec
; <<>> DiG 9.18.14 <<>> opnsense.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60896
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;opnsense.org. IN A

;; ANSWER SECTION:
opnsense.org. 779 IN A 178.162.131.118

;; Query time: 1 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed May 10 23:49:22 IST 2023
;; MSG SIZE  rcvd: 57
Looking into this further, delv is giving me the below error;

Code: [Select]

$ delv opnsense.org
;; broken trust chain resolving 'opnsense.org/A/IN': 127.0.0.53#53
;; resolution failed: broken trust chain
This leads me to believe it may be an issue with the root trust anchor file (which was a 'root.key' file that needs to be regularly updated).
In my previous setup on Debian I just needed to add the following line to unbound.conf;

Code: [Select]

auto-trust-anchor-file: "/var/lib/unbound/root.key"And Unbound would keep it updated with a unbound-anchor program.

I have upped the log verbosity and still don't seem to be seeing anything in the logs with more specifics.

Any advise on where to begin with troubleshooting/trying to fix, would appreciate it. Looking into manually editing an unbound.conf file brought up references to editing via a "GUI custom box" which I couldn't find, and reference to editing an .xml file. Or generally advise on whether I should be manually editing the conf files or not. As I could find no reference to the anchor file in the GUI.

Or if anyone happens to have already come across this and knows what's needed to correct.

Many thanks.

EDIT: I should clarify, I haven't modified any of the settings under Unbound / General or Advanced, except for 'Log Level Verbosity' and Host Overrides - which is working correctly.

[cookiemonster]

Can you see if you have the root.key file in /usr/local/etc/unbound/
I would have thought the enabling DNSSEC in the UI would have triggered the fetch of it & keep updated but I do not know if that's the case. You might want to wait for a better answer.
I use a different method and is disabled in the UI. In other words I have this managed by other means so I never had to expect this to be as it should be.
To solve it you might have to manually do the unbound-anchor routines. That might have been what I had to use but I can't remember. It is a good question though if enabling DNSSEC in the UI is expected to do it for the user.

[zxuilnie]

Thank you for your response.

No, no root.key in that folder, only has two files; unbound.conf and unbound.conf.sample
They are both exactly the same, all the potential variables are commented out.

I did find the folder; '/var/unbound/'
Which does contain 'root.key', modified date is today, and has an unbound.conf which contains; 'auto-trust-anchor-file: /var/unbound/root.key'

Odd, I was hoping it would be missing that or be old, so that it would be a clear fix.

Code: [Select]

zxuilnie@opnsense:~ % unbound-anchor -a /var/unbound/root.key -l
. IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
The root key appears to be up to date, hash matches IANA

[cookiemonster]

OK, so there's where the UI places it.
I can see the same results from a client or opnsense directly but I recall now that I had this query myself when setting up my DoT setup. I never find a way to test it from the command lines in my chain of services but then external tests confirmed I was using dnssec. In my case I had to settle because I'm using getdns/stubby and that little utility lacks proper logging. Since external tests (like this one https://wander.science/projects/dns/dnssec-resolver-test/) were OK, I left it at that.
I mean we can use dig and other utilities but why results differ from external tests is unknown by me.