OPNsense Forum
Archive => 19.7 Legacy Series => Topic started by: Ricardo on August 05, 2019, 03:33:10 pm
-
I found in 19.7 under the Unbound settings that "Custom options" will be deprecated in the future. Can the team share the plans how the not-so-common parameters be still used if "custom options" input box will no longer be available?
-
Maybe include file where you have to put it in via CLI
-
That would be a huge steps backwards. Is there any reason why this is the plan?
-
Because you can put everything in this field, also commands and whatever and you have to trust the application it validates everything correctly.
Why not just put a feature request so you don't have to use this field?
-
I have just opened a feature request for the DNS blacklist case.
Another entry in OPNsense Unbound Custom options, which I have been using for diagnosis, is this one:
log-queries: yes
Could this be achieved currently without using Custom options?
-
I have these:
extended-statistics: yes
log-queries:yes
and I dont think there is any other way in Opnsense to use these special options without the "Custom options" input field.
For the record, this was the reason why I opened this thread:
Custom options
This option will be removed in the future due to being insecure by nature. In the mean time only full administrators are allowed to change this setting.
Enter any additional options you would like to add to the Unbound configuration here.
-
The removal wont happen too soon .. so no panic.
Just add a new FR with these two options as a checkbox, it shouldn't be that hard to implement.
-
What are the reasons for the removal of the custom options? I use the custom options to bulk import host and domain blocking lists as well as import dkim settings. I found it really useful for that. If there is no alternative then i guess i will be moving back to pfsense in the future.
-
What are the reasons for the removal of the custom options? I use the custom options to bulk import host and domain blocking lists as well as import dkim settings. I found it really useful for that. If there is no alternative then i guess i will be moving back to pfsense in the future.
https://github.com/opnsense/core/commit/d62015df1cdb0c0711b488bd66ced631b9a4f37b
There is no date set when to remove this feature .. it can also be in 2021 .. and for every usecase there will be an alternative, trust me :)
-
At least please please put some kind of ETA if the "planned to be deprecated" text is already printed on the setup GUI.
-
Nobody thought about an ETA .. that means, it won't happen in 20.1.
Usually you bring all the stuff in to mitigate this field, then wait for 1 or 2 major upgrades and then remove it after plenty of warnings.
BTW, we are working on a file include .. so you can put everything on the options field, paste in a file and you are done.
-
Hi,
I'm also using the custom options for different purposes, e.g
- DNS Blacklist include
- server
tls-cert-bundle: "/etc/ssl/cert.pem"
forward-zone:
name: "."
forward-tls-upstream: yes
... - server:
#Access control for Internal IPv4/6
access-control-view: 192.168.xx.0/24 lanview
access-control-view: xxxx:xxxx:xxxx:xxxx::/64 lanview
view:
name: "lanview"
local-zone: "xxxxxxxx" transparent
local-data: "xxxxxxxx A xxxxxxxxx"
local-data: "xxxx A xxxxxxxxxx"
This should be covered in the alternative solution too.
br
-
We deprecate the GUI custom advanced fields because of OpenVPN shell injection issues we had reported. The freeform input cannot be validated. We still offer file-based includes everywhere it makes sense.
We deprecate the GUI custom advanced fields because our policy is to make fool-proof and future-safe features.
We deprecate the GUI custom advanced fields because services that don't have them have better UX in general and users are more keen to report and share their use cases which in turn helps shape and introduce new easy to use features.
We deprecate the GUI custom advanced fields without a schedule to raise awareness and to avoid surprises on updates.
Cheers,
Franco
-
Within 19.7.4 there is „support file-based custom-includes“ mentioned as new unbound feature.
I‘m not sure if this is the replacement for „Unbound custom parameter“?
br
-
No, but a hook. I'm building a unbound-plus plugin. First release will offer dnsbl, future versions DoT and options you put in custom field. Just file them as an issue in github
-
Thanks for the information, looking forward for the plugin.
-
No, but a hook. I'm building a unbound-plus plugin. First release will offer dnsbl, future versions DoT and options you put in custom field. Just file them as an issue in github
What about dns over TLS! (DoT)
There is already a Github entrie
https://github.com/opnsense/core/issues/2909 (https://github.com/opnsense/core/issues/2909)
-
It's inside your quote :) "future versions DoT"
-
It's inside your quote :) "future versions DoT"
I know, but what does future mean? 20.1 or later?
I am not a professional, but why is this feature so complicated, if it does nothing else but to set the manual entries via checkbox or dropdown?
Regards rene
-
When times allow it. First we need a release to stable. The bigger it gets the more time it needs to review/release
-
The feature is not complicated. It's inherently unstable with the clusterf***ery that cloud DNS providers are doing at their backend side. If we implement in an easy way we'll have more support to spend time on something that can already be configured manually and will potentially break your Internet. This is a lose-lose from the project's perspective.
Cheers,
Franco
-
I'm using the custom options for a few areas now:
- To provide "split horizon" for different subnets, or for LAN vs. WAN (I could spin up two unbound instances but that's completely off the rails, and if Unbound is my resolver of choice I don't want to be forced to run 2 resolver softwares just to get different views)
- To provide static responses that aren't available in the GUI for certain domains, such as manual dns-sd entries, and <local-zone: "DOMAIN" static> entries.
My Unbound.conf code custom snippets:
log-queries: yes
log-replies: yes
qname-minimisation: yes
# dns-sd manual entries
local-data: "b._dns-sd._udp.MY-FQDN IN PTR MY-FQDN"
local-data: "db._dns-sd._udp.MY-FQDN IN PTR MY-FQDN"
local-data: "r._dns-sd._udp.MY-FQDN IN PTR MY-FQDN"
local-data: "dr._dns-sd._udp.MY-FQDN IN PTR MY-FQDN"
local-data: "lb._dns-sd._udp.MY-FQDN IN PTR MY-FQDN"
local-data: "b._dns-sd._udp.0.0.193.10.in-addr.arpa. IN PTR MY-FQDN"
local-data: "db._dns-sd._udp.0.0.193.10.in-addr.arpa. IN PTR MY-FQDN"
local-data: "r._dns-sd._udp.0.0.193.10.in-addr.arpa. IN PTR MY-FQDN"
local-data: "dr._dns-sd._udp.0.0.193.10.in-addr.arpa. IN PTR MY-FQDN"
local-data: "lb._dns-sd._udp.0.0.193.10.in-addr.arpa. IN PTR MY-FQDN"
# Device #1: various definitions for primary printer
local-data: "MY-PRINTER.MY-FQDN A IP-ADDRESS"
local-data: "_printer._tcp.MY-FQDN PTR _MY-PRINTER._printer._tcp.MY-FQDN."
local-data: "_MY-PRINTER._printer._tcp.MY-FQDN SRV 0 0 631 MY-PRINTER.MY-FQDN."
local-data: "_printer._tcp.MY-FQDN PTR _MY-PRINTER._universal._sub._ipp._tcp.MY-FQDN."
local-data: "_universal._sub._ipp._tcp.MY-FQDN PTR _MY-PRINTER._universal._sub._ipp._tcp.MY-FQDN."
local-data: "_MY-PRINTER._universal._sub._ipp._tcp.MY-FQDN SRV 0 0 631 MY-PRINTER.MY-FQDN."
local-data: "_MY-PRINTER._universal._sub._ipp._tcp.MY-FQDN TXT txtvers=1 qtotal=1 adminurl=https://MY-PRINTER.MY-FQDN ty=MY-PRINTER note=(LOCATION) usb_MFG=HP usb_MDL=MY-PRINTER Scan=T Duplex=T Color=T PaperCustom=T"
local-data: "_printer._tcp.MY-FQDN PTR _MY-PRINTER._pdl-datastream._tcp.MY-FQDN."
local-data: "_pdl-datastream._tcp.MY-FQDN PTR _MY-PRINTER._pdl-datastream._tcp.MY-FQDN."
local-data: "_MY-PRINTER._pdl-datastream._tcp.MY-FQDN SRV 0 0 9100 MY-PRINTER.MY-FQDN."
local-data: "_MY-PRINTER._pdl-datastream._tcp.MY-FQDN TXT txtvers=1 qtotal=1 adminurl=https://MY-PRINTER.MY-FQDN ty=MY-PRINTER note=(LOCATION) usb_MFG=HP usb_MDL=MY-PRINTER Scan=T Duplex=T Color=T PaperCustom=T"
local-data: "_printer._tcp.MY-FQDN PTR _MY-PRINTER._ipp._tcp.MY-FQDN."
local-data: "_ipp._tcp.MY-FQDN PTR _MY-PRINTER._ipp._tcp.MY-FQDN."
local-data: "_MY-PRINTER._ipp._tcp.MY-FQDN SRV 0 0 80 MY-PRINTER.MY-FQDN."
local-data: "_MY-PRINTER._ipp._tcp.MY-FQDN TXT txtvers=1 qtotal=1 adminurl=https://MY-PRINTER.MY-FQDN ty=MY-PRINTER note=(LOCATION) usb_MFG=HP usb_MDL=MY-PRINTER Scan=T Duplex=T Color=T PaperCustom=T"
local-data: "_printer._tcp.MY-FQDN PTR _MY-PRINTER._ipps._tcp.MY-FQDN."
local-data: "_ipps._tcp.MY-FQDN PTR _MY-PRINTER._ipps._tcp.MY-FQDN."
local-data: "_MY-PRINTER._ipps._tcp.MY-FQDN SRV 0 0 443 MY-PRINTER.MY-FQDN."
local-data: "_MY-PRINTER._ipps._tcp.MY-FQDN TXT txtvers=1 qtotal=1 adminurl=https://MY-PRINTER.MY-FQDN ty=MY-PRINTER note=(LOCATION) usb_MFG=HP usb_MDL=MY-PRINTER Scan=T Duplex=T Color=T PaperCustom=T"
# kill list
# for domains where redirect to 127.0.0.1 or other IP is insufficient
local-zone: "DOMAIN" static
local-zone: "DOMAIN" static
# and many others
# split horizon #1
access-control-view: 10.0.0.0/8 FROM-LAN
access-control-view: 0.0.0.0/0 FROM-WAN
access-control: 0.0.0.0/0 deny_non_local
view:
# from lan - can recurse to root servers, can also use global data if nothing found in this section.
# so we actually don't have to put anything much here.
name: "FROM-LAN"
view-first: yes
view:
# from wan - forbidden to recurse, and can't access the data in the global section, or anything not explicitly stated in this view.
# so we only need to put here, what an external WAN query needs to be able to find.
name: "FROM-WAN"
view-first:no
local-zone: "." refuse
local-data: 'FQDN. DNS_RECORD '
local-data: 'FQDN. DNS_RECORD '
local-data: 'FQDN. DNS_RECORD 'There's a big difference between not adding a feature, vs. removing one that's already in use. Maybe stuff like this could be retained with a tunable added "Enable unverifiable config fields", so those who are by now depending on it, dont' worry they'll lose it?
-
Hi Stilez.
See also my posts. I'm also using "View" in unbound. https://github.com/opnsense/plugins/issues/1503#issue-493737939 (https://github.com/opnsense/plugins/issues/1503#issue-493737939)
br