Revert unbound to 18.7.7 - not possible?

[newsense]

Monit might be able to help, however that doesn't change the fact that whatever changes were introduced in 18.7.10 in either Unbound or HBSD keep on lingering and causing it to crash. I couldn't touch any of the PRD systems to enable the swap and provide better info for lattera to look into...


Interestingly, there's one system that's not affected among many others, and I just noticed Suricata was not ON there. I'm trying now on an APU that crashes heavily to see if there are any changes.

[chemlud]

You also run the LibreSSL flavour and try to do DNS over TLS? I thought I'm the only one! :-D

I had a quick look at Monit yesterday, but it's anyrhing but straight forward how to use this beast. I would have to figure out the path to the .pid file for unbound as well as the correct command to restart unbound. And test this and and and... No time for this currently...

[newsense]

Kinda hard seing the value of 'dumping half of the old/buggy/unused for decades OpenSSL code in the first 30 days of forking it' ;-)

So yeah, I'm pushing for it everywhere and worked just fine until 18.7.10. I have a higher degree of confidence the OpenBSD people are more concerned and focused on secure coding principles and a good track record in that regard than pretty much anyone else playing with forks.

[chemlud]

I would really love to learn where in the Bermuda triangle of BSD - LibreSSL - unbound the error sits. Or if it is a "misconfig" in the DNS servers SSL/TLS unbound is contacting....

[newsense]

Arguably out of it. It dies on the hands of HBSD apparently. Otherwise Unbound thrives on DoT/Doh on 1.8.3 using pfSense which lacks the HBSD hardening. It would be extremely doubtful that any major workarounds that aren't public have been done in pfS in that regard.

[chemlud]

But pfSense is not LibreSSL, or? For me unbound has been stable with OpenSLL and DNS over TLS in the past...

[newsense]

That's correct.

My point however, although arguably incomplete, was that the issues were present on both OpenSSL and LibreSSL,  with no indication whatsoever about an SSL issue when crashing.

The only issue I saw on OpenSSL/pfSense regarding Unbound was shortly after 1.1.1.1 launched and lasted less than 24h and was dealt with server side by Cloudflare. Basically quad1 would fail to connect while quad9 would be just fine.

At the same time OPNsense/LibreSSL/Unbound were working just fine on both DoT services.

[chemlud]

But now I only can stay at 19.1.1 with LibreSSL and unbound with DNToverTLS or switch to OpenSSL for updating. I'm a little lost at the moment...

[miroco]

@chemlud

I've experienced your exact predicament and I took the "Stubby" rout after the 19.1 release following the "directnupe" guide. As far as I can tell it's working very well. I'm on 19.1.2 LibreSSL flavour.

https://forum.opnsense.org/index.php?topic=10062.0

miroco

[chemlud]

I have no GetDNS and no Stubby installed, so you mean I should install Stubby? :)

[miroco]

It's working for me. These following notes are an extract of the "directnupe" guide. They helped me get a better overview of the process. However I do strongly advise you to read up on his guide prior to making the installation/configuration.

miroco


GetDNS and Stubby

# pkg add https://pkg.opnsense.org/FreeBSD:11:amd64/19.1/MINT/19.1.2/LibreSSL/All/libidn-1.34_1.txz
# pkg add https://pkg.opnsense.org/FreeBSD:11:amd64/19.1/MINT/19.1.2/LibreSSL/All/libuv-1.26.0.txz
# pkg add https://pkg.opnsense.org/FreeBSD:11:amd64/19.1/MINT/19.1.2/LibreSSL/All/libev-4.24,1.txz
# pkg add https://pkg.opnsense.org/FreeBSD:11:amd64/19.1/MINT/19.1.2/LibreSSL/All/getdns-1.5.1.txz

# su -m unbound -c /usr/local/sbin/unbound-anchor

# mv /usr/local/etc/rc.d/stubby /usr/local/etc/rc.d/stubby.sh

Make it executable - I run two commands - it works for me:
# chmod 744 /usr/local/etc/rc.d/stubby.sh
# chmod a+x /usr/local/etc/rc.d/stubby.sh

Yes must enable Stubby Daemon in the file -  open file by: nano /usr/local/etc/rc.d/stubby.sh
go to line 27  -

: ${stubby_enable="NO"}  change the setting to  : ${stubby_enable="YES"}

That is all you have to do to this file. It comes pre-configured. Save and exit.

Now you must configure Stubby to resolve DNS OVER TLS - nano /usr/local/etc/stubby/stubby.yml

resolution_type: GETDNS_RESOLUTION_STUB

dns_transport_list:
  - GETDNS_TRANSPORT_TLS

tls_authentication: GETDNS_AUTHENTICATION_REQUIRED

tls_query_padding_blocksize: 128

edns_client_subnet_private : 1

round_robin_upstreams: 1

idle_timeout: 60000 # keep-alive for 1 min, for better performance

listen_addresses:
  - 127.0.0.1@8053   ## Stubby / Unbound ## Default Address/Port

https://raw.githubusercontent.com/getdnsapi/stubby/develop/stubby.yml.example

upstream_recursive_servers:
# IPV4 Servers
# The getdnsapi.net Server
  - address_data: 185.49.141.37
    tls_port: 853
    tls_auth_name: "getdnsapi.net"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
# The Fondation RESTENA Server
  - address_data: 158.64.1.29
    tls_auth_name: "kaitain.restena.lu"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 7ftvIkA+UeN/ktVkovd/7rPZ6mbkhVI7/8HnFJIiLa4=
### Test servers ###
## Surfnet/Sinodun Servers
  - address_data: 145.100.185.17
    tls_port: 853
    tls_auth_name: "dnsovertls2.sinodun.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: NAXBESvpjZMnPWQcrxa2KFIkHV/pDEIjRkA3hLWogSg=
# The securedns.eu Server
  - address_data: 146.185.167.43
    tls_auth_name: "dot.securedns.eu"
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g=
# The dns.cmrg.net Server
  - address_data: 199.58.81.218
    tls_port: 443
    tls_auth_name: "dns.cmrg.net"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo=
# DNSPRIVACY.at Primary DNS TLS Server
  - address_data: 94.130.110.185
    tls_port: 853
    tls_auth_name: "ns1.dnsprivacy.at"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: vqVQ9TcoR9RDY3TpO0MTXw1YQLjF44zdN3/4PkLwtEY=
# DNSPRIVACY.at Secondary DNS TLS Server
  - address_data: 94.130.110.178
    tls_port: 853
    tls_auth_name: "ns2.dnsprivacy.at"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: s5Em89o0kigwfBF1gcXWd8zlATSWVXsJ6ecZfmBDTKg=
# The dns.neutopia.org Server
  - address_data: 89.234.186.112
    tls_port: 443
    tls_auth_name: "dns.neutopia.org"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI=
### Anycast services ###
#Tenta ICANN DNS TLS Primary Server
  - address_data: 99.192.182.200
    tls_auth_name: "iana.tenta.io"
    tls_port: 853
    tls_pubkey_pinset:
      - digest: "sha256"
        value: nPzhfahBmQOFKbShlLBymTqPtZY31bPpKFnh0A86ys0=

## End of Sample File  /

Save and Exit


In order to have Opnsense use default start up script (  /usr/local/etc/rc.d/stubby.sh ) at boot time,
you will have to create a boot time start up script for it in /etc/rc.conf.d/. Not to prolong this - do the following :
# nano /etc/rc.conf.d/stubby   -   in the new file enter the following two lines:

stubby_enable="YES" 
stubby_bootup_run="/usr/local/etc/rc.d/stubby.sh"

Save and exit

Then make the file executable - once again - works for me:

# chmod 744 /etc/rc.conf.d/stubby
# chmod a+x /etc/rc.conf.d/stubby

----

Now you must configure your  Unbound DNS Server to use Stubby for DNS Over TLS.

UNBOUND GENERAL SETTINGS
Network Interfaces =   WAN LAN ( all of your LAN interfaces if you have more than one )
And You Must Select  Localhost - repeat -  You Must Select  Localhost!

Under Custom options enter the following :

server:
do-not-query-localhost: no
forward-zone:
name: "." # Allow all DNS queries
forward-addr:127.0.0.1@8053

## END OF ENTRY

Outgoing Network Interfaces  =  Localhost

Make Sure to NOT CHECK - DO NOT CHECK -  the box for DNS Query Forwarding.

Save and Apply Settings

Next -Under System > Settings  > General Settings

Set the first DNS Server to 127.0.0.1   with no gateway selected  /   
Make sure that DNS server option:

A - Allow DNS server list to be overridden by DHCP/PPP on WAN -  Is Not I repeat - Is Not Checked !

and DNS server option

B -  Do not use the DNS Forwarder/Resolver as a DNS server for the firewall Is Not  - I repeat - Is Not Checked !

I now only run  127.0.0.1  ( Localhost ) configured as the only DNS SERVER on my WAN interface.
If others were added to WAN, when I ran dig or drill commands /etc/resolv.conf allowed those addresses to be queried.
I  only want to use Stubby yml Name Servers for DNS TLS , so this was the determinative factor in my reasoning and decision.

[franco]

Someone finally notified Unbound after a bit of prodding ;)

https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4232

[newsense]

Interesting, thanks for that.

Since Unbound kept on dying with what appeared to be an HBSD related error message I thought the proper chain would have required a bottom up approach and not the other way around.

Whenever a patch is available please let us know so we can work this issue out both here and upstream in that bug report - if needed.

[chemlud]

Nice to hear that things move forward, but as I wrote a above I fear this will end in an Bermuda triangle between (H)BSD, LibreSSL and unbound. Hoping for the best... The solution with stubby is not something to implement in 5 min, this might be beyond my pay grade. :-(

[miroco]

How and for what reasons your OPNsense box is deployed, dictates your freedom of action of cause. In my case, I'm the only user.

I started with a fresh backup of the configuration file. With it you can always return to the previous known good state. However, it will take longer than 5 min. Don't let anyone rush you.

Useful tools:
Putty
WinSCP
Notepad++


Then you can ask your boss for a raise :-)


miroco