unbound configuration / DNSSEC

According to /usr/local/share/doc/freebsd/handbook/network-dns.html one must test, for configuring unbound, that the forwarder (eg. 192.168.1.1) supports DNSSEC with: drill -S freebsd.org @192.168.1.1

Well, in one computer this same command success, in other fails with last line:

Code:
No trusted keys found in tree: first error was: No DNSSEC public key(s)
;; Chase failed.

And in this case unbound does not work unless I add to unbound.conf the line: val-permissive-mode: yes

On what depends that DNSSEC work? Do I need to add somewhere a public key from somewhere?
 
Yes, but the problem persists. The forwarder is a DNS server in the home router, Perhaps do not support DNSSEC and do not have a public key, but why in my other installation works with the same unbound.conf?
 
Is it unbound in the base or one from ports?
Does /var/unbound/root.key (for local-unbound) or /usr/local/etc/unbound/root.key (for unbound from ports) exists in both case?
Normally, (local-)unbound-anchor gets the trusted anchor in the rc.d script.
When you do service unbound restart, is there any messages between the two lines?
Code:
Obtaining a trust anchor:.
Starting unbound.
 
It is unbound from base.

When you do service unbound restart, is there any messages between the two lines?

I get:

Code:
unbound does not exist in /etc/rc.d ...

And with service local_unbound restart I do not get that lines.

But I think the cause of problem is not unbound: it happens with drill -S freebsd.org @192.168.1.1.
 
Could you show us the records you get from the two machines (the one that works and the one that does not)? I don't know about drill, but using dig (available in dns/bind-tools) it would be dig @192.168.1.1 freebsd.org +dnssec.

-- Edit --
Beside, you could use "external" DNS that support DNSSEC instead of your home router.
 
If that helps, here the results of dig @192.168.178.1 freebsd.org +dnssec and drill -S FreeBSD.org @192.168.178.1 in both machines. machine1 succes, machine2 failure.

-----------------------

Machine 1, dig @192.168.178.1 freebsd.org +dnssec:

Code:
; <<>> DiG 9.11.6 <<>> @192.168.178.1 freebsd.org +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31802
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
freebsd.org.            3583    IN      A       96.47.72.84
freebsd.org.            3583    IN      RRSIG   A 8 2 3600 20190422044130 20190407192107 27850 freebsd.org. YN2+7xImnsI64KLtFy+Jemai20teubtGJTW2K2ruZYjWvS7Xvx5LU0zL nP+YJRxdV5ptx8fvW3eOZ7nuTzebU4H6Z9mYghdh6PEldr0UnQ5P0x56 NPjwoqqT9v8lZYNRQwWVAqk+1fnMghCACcjsePinDhX7q/quC5pQKTIM MjTH5RomUYaACOfXhxmWJ3s04ro/CjGWflOGZ9A5Ay8Qx/XbEvfESajC Xi+JwLV62Tr5QG7ycDViPA97vy/8VKKMZZN7cnVkOA1Gzi64P2mBtOVt rfURNSa15Om9yu33f7paNnbNXZHJwNydhIlvQFrIkLNjawnDDHMMQiFC 8xSb+w==

;; Query time: 2 msec
--More--(89%)...skipping...

; <<>> DiG 9.11.6 <<>> @192.168.178.1 freebsd.org +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31802
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
freebsd.org.            3583    IN      A       96.47.72.84
freebsd.org.            3583    IN      RRSIG   A 8 2 3600 20190422044130 20190407192107 27850 freebsd.org. YN2+7xImnsI64KLtFy+Jemai20teubtGJTW2K2ruZYjWvS7Xvx5LU0zL nP+YJRxdV5ptx8fvW3eOZ7nuTzebU4H6Z9mYghdh6PEldr0UnQ5P0x56 NPjwoqqT9v8lZYNRQwWVAqk+1fnMghCACcjsePinDhX7q/quC5pQKTIM MjTH5RomUYaACOfXhxmWJ3s04ro/CjGWflOGZ9A5Ay8Qx/XbEvfESajC Xi+JwLV62Tr5QG7ycDViPA97vy/8VKKMZZN7cnVkOA1Gzi64P2mBtOVt rfURNSa15Om9yu33f7paNnbNXZHJwNydhIlvQFrIkLNjawnDDHMMQiFC 8xSb+w==

;; Query time: 2 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Thu Apr 18 12:54:09 UTC 2019
;; MSG SIZE  rcvd: 355

Machine 2, dig @192.168.178.1 freebsd.org +dnssec:

Code:
; <<>> DiG 9.12.4 <<>> @192.168.178.1 freebsd.org +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27655
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
freebsd.org.            2682    IN      A       96.47.72.84
freebsd.org.            2682    IN      RRSIG   A 8 2 3600 20190422044130 20190407192107 27850 freebsd.org. YN2+7xImnsI64KLtFy+Jemai20teubtGJTW2K2ruZYjWvS7Xvx5LU0zL nP+YJRxdV5ptx8fvW3eOZ7nuTzebU4H6Z9mYghdh6PEldr0UnQ5P0x56 NPjwoqqT9v8lZYNRQwWVAqk+1fnMghCACcjsePinDhX7q/quC5pQKTIM MjTH5RomUYaACOfXhxmWJ3s04ro/CjGWflOGZ9A5Ay8Qx/XbEvfESajC Xi+JwLV62Tr5QG7ycDViPA97vy/8VKKMZZN7cnVkOA1Gzi64P2mBtOVt rfURNSa15Om9yu33f7paNnbNXZHJwNydhIlvQFrIkLNjawnDDHMMQiFC 8xSb+w==

;; Query time: 2 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Thu Apr 18 13:11:44 UTC 2019
;; MSG SIZE  rcvd: 355

Machine 1, drill -S FreeBSD.org @192.168.178.1 > tmp-drill1
Code:
;; Number of trusted keys: 1
;; Chasing: freebsd.org. A


DNSSEC Trust tree:
FreeBSD.org. (A)
|---freebsd.org. (DNSKEY keytag: 27850 alg: 8 flags: 256)
    |---freebsd.org. (DNSKEY keytag: 60160 alg: 8 flags: 257)
    |---freebsd.org. (DS keytag: 60160 digest type: 2)
        |---org. (DNSKEY keytag: 9062 alg: 7 flags: 256)
            |---org. (DNSKEY keytag: 9795 alg: 7 flags: 257)
            |---org. (DNSKEY keytag: 17883 alg: 7 flags: 257)
            |---org. (DS keytag: 9795 digest type: 1)
            |   |---. (DNSKEY keytag: 25266 alg: 8 flags: 256)
            |       |---. (DNSKEY keytag: 20326 alg: 8 flags: 257)
            |---org. (DS keytag: 9795 digest type: 2)
                |---. (DNSKEY keytag: 25266 alg: 8 flags: 256)
                    |---. (DNSKEY keytag: 20326 alg: 8 flags: 257)
;; Chase successful

Machine 2, drill -S FreeBSD.org @192.168.178.1 > tmp-drill1

Code:
;; Number of trusted keys: 1
;; Chasing: freebsd.org. A


DNSSEC Trust tree:
FreeBSD.org. (A)
|---freebsd.org. (DNSKEY keytag: 27850 alg: 8 flags: 256)
    |---freebsd.org. (DNSKEY keytag: 60160 alg: 8 flags: 257)
    |---freebsd.org. (DS keytag: 60160 digest type: 2)
        |---org. (DNSKEY keytag: 9062 alg: 7 flags: 256)
            |---org. (DNSKEY keytag: 9795 alg: 7 flags: 257)
            |---org. (DNSKEY keytag: 17883 alg: 7 flags: 257)
            |---org. (DS keytag: 9795 digest type: 1)
            |   |---. (DNSKEY keytag: 25266 alg: 8 flags: 256)
            |       |---. (DNSKEY keytag: 20326 alg: 8 flags: 257)
            |---org. (DS keytag: 9795 digest type: 2)
                |---. (DNSKEY keytag: 25266 alg: 8 flags: 256)
                    |---. (DNSKEY keytag: 20326 alg: 8 flags: 257)
No trusted keys found in tree: first error was: No DNSSEC public key(s)
;; Chase failed.
 
The response of you home server looks fine. Is the time set correctly on the second machine ?

-- Edit --
Well, reading again I think the error message would be different in case of wrong time setting...
 
Just a last idea : could you try drill -k /etc/unbound/root.key -S FreeBSD.org @192.168.178.1 on the non-working machine ?
 
Time is right, drill -k gives the same error. Also if I use 8.8.8.8 as DNS server. Thanks anyway.
 
Both commands give /usr/bin/drill.

May be the file /etc/unbound/root.key? From where comes it? From what it depends? Can be changed?
 
Well, with no -k option, the man page says it will use /etc/unbound/root.key if it "exists and contains a valid DNSKEY or DS record". So without the -k option, I would expect a non valid root.key file to be ignored while with forcing the -k option, I would expect drill to through a different error. Hence my suggestion. I am at work so I cannot check at the moment if this is true.
From where comes it? Can be changed?
See local-unbound-anchor(8).
 
local-unbound-anchor(8) is not in any of my machines.

I stoped unbound, deleted /etc/resolv.conf, /var/unbound/forward.conf and /var/unbound/root.key and run local-unbound-setup. Now I have a working recursive resolver.

The original problem is not solved and seems to be generated by this intelligent local-unbound-setup. It folows Windows philosophy: an intelligent program decides for the stupid user, but it is not so intelligent and causes troubles.

If you have network configured, it takes forwarders from /etc/resolv.conf, otherwise takes them from /var/unbound/forward.conf, and if it finds nothing, it is a recursive resolver.
 
Back
Top