DNS-over-TLS in unbound ?

[chemlud]

Hi!

I read in the release notes for 21.1

"As we continue to deprecate custom configuration inputs for a number of reasons, Dnsmasq has been switched to a pluggable file-based approach[1] with Unbound to follow in the upcoming 21.7 series."

If no custom config is possible in the GUI, will OPNsense support DNS-over-TLS via GUI (as pfsense does for some time now) from 21.7 on?

Many thanks in advance!

[franco]

doc/20.1/20.1.5:o plugins: os-unbound-plus 1.1

As plugin since 20.1.5.

doc/20.7/20.7.r1:o unbound: integrate functionality formerly known as "unbound-plus" plugin

As core feature since 20.7.

Still, the rework past 21.7 will continue to allow custom configuration, but not from the GUI.


Cheers,
Franco

[chemlud]

Let's see, I have here:

Code: [Select]

server: tls-cert-bundle: "/etc/ssl/cert.pem"
do-tcp: yes
do-ip6: no
qname-minimisation: yes
qname-minimisation-strict: yes
harden-below-nxdomain: yes

forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 5.1.66.255@853#dot.ffmuc.net
forward-addr: 185.95.218.42@853#dns.digitale-gesellschaft.ch
forward-addr: 5.9.164.112@853#dns3.digitalcourage.de

How to do this without the custom options field (via GUI, as other modifications will not be in the config.xml, right?)

[Fright]

@franco
speaking of "pluggable file-based approach"
please clarify
This deliberately does not make any mention in the GUI that the plugin can use (or is already using) additional configuration pluggable file(s)?
I will explain: if the plugin is used for a long time or the administrator changes, it may take a long time to understand that the plugin actually uses a configuration that the administrator does not see in the GUI
(I already forgot several times that I use additional directives in nginх through hooks  )

@chemlud
so you use DoT forwardes only?
have you tried using "DNS over TLS Servers" in Miscellaneous?

[chemlud]

@chemlud
so you use DoT forwardes only?
have you tried using "DNS over TLS Servers" in Miscellaneous?

I know that there's a field in "Misc", but no domain names added and no option to use the rest of the config I use now, or?

[franco]

It should probably be improved. The original work was done by Michael as the plugin.

> This deliberately does not make any mention in the GUI that the plugin can use (or is already using) additional configuration pluggable file(s)?

It doesn't really matter. A plugin or core component should present the configuration options to the user that it renders in pluggable subsystems as any other component would.

If someone drops a file into somewhere manually has the responsibility for the file and any problems caused by it.


Cheers,
Franco

[chemlud]

It should probably be improved. The original work was done by Michael as the plugin.
...
Cheers,
Franco

Definitely, I guess, DNS-over-TLS should be a standard for security/privacy-aware users. Would love to see some more check boxes in the unbound GUI... :-)

[Fright]

@chemlud
sorry, I thought you were asking about DoT.
This is how dot.conf in /var/unbound/etc looks if i specify servers from your config in the "Miscellaneous" GUI:

Code: [Select]

server:
  tls-cert-bundle: /etc/ssl/cert.pem
forward-zone:
  name: "."
  forward-tls-upstream: yes
  forward-addr: 5.1.66.255@853
  forward-addr: 185.95.218.42@853
  forward-addr: 5.9.164.112@853



[franco]

I added a note with your configuration to the ticket https://github.com/opnsense/core/issues/4327


Thanks,
Franco

[chemlud]

Very nice! I promise to send some € on completition :-D

...still have some 50 bucks lying around for those coloured firewall rule headlines nobody wanted to implement... ;-)

[Fright]

If someone drops a file into somewhere manually has the responsibility for the file and any problems caused by it.

I'm sorry, perhaps I put it is not clear. I'm talking about the fact that imho it would be convenient in some way to indicate in the GUI the fact that parameters are used that are not displayed in the GUI

[franco]

...still have some 50 bucks lying around for those coloured firewall rule headlines nobody wanted to implement... ;-)

Take a look at the new categories in 21.1 first.... a lot of work went into this luckily sponsored by a larger company so it could be pushed through.

I'm sorry, perhaps I put it is not clear. I'm talking about the fact that imho it would be convenient in some way to indicate in the GUI the fact that parameters are used that are not displayed in the GUI

I think we talk about the same. The plugin or consumer component is responsible for that to show what it drops in, not the provider component.

In fact DoT already plugs into Unbound as it started as a plugin unbound-plus detachted from core. You configure the servers there and the GUI will tell you what it writes.. well rather "translates" for Unbound to understand.



Cheers,
Franco

[Fright]

I think we talk about the same. The plugin or consumer component is responsible for that to show what it drops in, not the provider component.

Ah! thanks. yes, of course not a provider itself, i was talking about extending the plugins gui to store information about custom .conf-s there (like nginx hooks)
so, if I understand you correctly,  it is assumed that the plugin should display all the necessary parameters in GUI?
it means that I just did not quite understand the "pluggable file-based approach" idea itself correctly

If someone drops a file into somewhere manually has the responsibility for the file and any problems caused by it

understood thanks!
@chemlud
sorry for using your topic for my question )

[franco]

Ah! thanks. yes, of course not a provider itself, i was talking about extending the plugins gui to store information about custom .conf-s there (like nginx hooks)

Well yes, but not the raw contents... we want structured data which we can verify and include in a meaningful way stored in config.xml

One of the drivers of no-custom-config is that people won't share their use case, thus no contributions and everyone trying to figure the same thing out for themselves. That's not how communities share and grow knowledge.

so, if I understand you correctly,  it is assumed that the plugin should display all the necessary parameters in GUI?
it means that I just did not quite understand the "pluggable file-based approach" idea itself correctly

Yes that is true. I admit the "pluggable file-based approach" phrasing is a somewhat convoluted since the top half is missing even though that is what the current rework of Dnsmasq does underneath: create an include directory for user-configurable files to be included automatically.


Cheers,
Franco

[Fright]

yes, I really thought the idea is what you are talking about _plus_ the ability for "advanced users" to create additional conf-files and drop them into the inc\hook-dirs (for complex or slow-maintained plugins, rare options\directives etc.) without the risk of being overwritten during updates. and without validating / storing unpredictable data in the config.
that's why strange ideas appeared )
Thanks for the clarification!