# unbound configuration / DNSSEC



## hruodr (Apr 17, 2019)

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:


```
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?


----------



## SirDice (Apr 18, 2019)

Is security/ca_root_nss installed? This package contains the trusted internet root CA servers.


----------



## hruodr (Apr 18, 2019)

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?


----------



## Hiroo Ono (Apr 18, 2019)

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?

```
Obtaining a trust anchor:.
Starting unbound.
```


----------



## hruodr (Apr 18, 2019)

It is unbound from base.



Hiroo Ono said:


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



I get:


```
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`.


----------



## hukadan (Apr 18, 2019)

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.


----------



## hruodr (Apr 18, 2019)

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`:


```
; <<>> 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`:


```
; <<>> 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`

```
;; 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`


```
;; 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.
```


----------



## hukadan (Apr 18, 2019)

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...


----------



## hukadan (Apr 18, 2019)

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 ?


----------



## hruodr (Apr 18, 2019)

Time is right, `drill -k` gives the same error. Also if I use 8.8.8.8 as DNS server. Thanks anyway.


----------



## hruodr (Apr 18, 2019)

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?


----------



## hukadan (Apr 18, 2019)

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.


hruodr said:


> From where comes it? Can be changed?


See local-unbound-anchor(8).


----------



## hruodr (Apr 18, 2019)

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.


----------

