Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

DoT forward-zone via unbound-control #1034

Closed
jdelker opened this issue Mar 25, 2024 · 3 comments · Fixed by klutchell/unbound-docker#437
Closed

DoT forward-zone via unbound-control #1034

jdelker opened this issue Mar 25, 2024 · 3 comments · Fixed by klutchell/unbound-docker#437

Comments

@jdelker
Copy link

jdelker commented Mar 25, 2024

First off: I can't tell whether the problem described below is a bug, simply not implemented or me being to stupid to do.

My use case: Setting a DoT DNS forwarder via unbound-control.

Defining such forward in the config is fine and works correct as far as I can tell:

forward-zone:
	name: "."
	forward-tls-upstream: yes
	forward-addr: 1.1.1.1@853

Unfortunately, that static config does not suit my particular environment, because I'm operating in changing locations. I need to switch the "." forward zone to different upstream DNS servers (with and without DoT), basically on-the-fly.
Embedded in some "external detection logic", I'm already able to adjust the DNS setup via unbound-control accordingly, but unfortunately not for any DoT forwards. Simply because there seems to be no way to set the forward-tls-upstream option with the forward_add command.

If there is any way to accomplish this with unbound-control please let me know. Otherwise I would kindly request this as a feature.
@wcawijngaards
Copy link
Member

There is a new option for unbound-control, for unbound-control forward_add +t example.com 192.0.2.1@853. That sets it to use tls for the upstream queries. The option is also added for unbound-control stub_add +t example.com 192.0.2.1@853 to set it to use tls for the upstream queries.

jedisct1 added a commit to jedisct1/unbound that referenced this issue Apr 4, 2024
@jedisct1
Merge remote-tracking branch 'nlnet/master'
b337cdb 
* nlnet/master: (24 commits)
  - Fix NLnetLabs#369: dnstap showing extra responses; for client responses   right from the cache when replying with expired data or   prefetching.
  - Fix NLnetLabs#1035: Potential Bug while parsing port from the "stub-host"   string; also affected forward-zones and remote-control host   directives.
  - For NLnetLabs#1040: adjust error text and disallow negative ports in other   parts of cfg_mark_ports.
  Changelog note for NLnetLabs#1040 - Fix NLnetLabs#1040: fix heap-buffer-overflow issue in function cfg_mark_ports   of file util/config_file.c.
  fix heap-buffer-overflow issue in function cfg_mark_ports of file util/config_file.c
  - Fix for crypto related failures to have a better error string.
  - Fix NLnetLabs#1034: DoT forward-zone via unbound-control.
  - Fix that the server does not chown the pidfile.
  - Fix that when the server truncates the pidfile, it does not follow   symbolic links.
  - Fix to add unit test for lruhash space that exercises the routines.
  - Fix comment in lruhash space function.
  - Fix for NLnetLabs#1032, add safeguard to make table space positive.
  - Fix NLnetLabs#1032: The size of subnet_msg_cache calculation mistake cause   memory usage increased beyond expectations.
  - Fix name of unit test for subnet cache response.
  - For NLnetLabs#831: Format text, use exclamation icon and explicit label   names.
  Changelog entry for NLnetLabs#831 - Merge NLnetLabs#831 from Pierre4012: Improve Windows NSIS installer   script (setup.nsi).
  Improve Windows NSIS installer script (setup.nsi) (NLnetLabs#831)
  - Fix localdata and rpz localdata to match CNAME only if no direct   type match is available.
  - Fix rpz so that rpz CNAME can apply after rpz CNAME. And fix that   clientip and nsip can give a CNAME.
  - Fix rpz for qtype CNAME after nameserver trigger.
  ...
@churchofnoise churchofnoise mentioned this issue May 8, 2024
Merged
@Playgirlkaybraz11
Copy link

First off: I can't tell whether the problem described below is a bug, simply not implemented or me being to stupid to do.

My use case: Setting a DoT DNS forwarder via unbound-control.

Defining such forward in the config is fine and works correct as far as I can tell:

  $forward-zone:
	name: "."
	forward-tls-upstream: yes
	forward-addr: 1.1.1.1@853

Unfortunately, that static config does not suit my particular environment, because I'm operating in changing locations. I need to switch the "." forward zone to different upstream DNS servers (with and without DoT), basically on-the-fly. Embedded in some "external detection logic", I'm already able to adjust the DNS setup via unbound-control accordingly, but unfortunately not for any DoT forwards. Simply because there seems to be no way to set the forward-tls-upstream option with the forward_add command.

If there is any way to accomplish this with unbound-control please let me know. Otherwise I would kindly request this as a feature.

First off: I can't tell whether the problem described below is a bug, simply not implemented or me being to stupid to do.

My use case: Setting a DoT DNS forwarder via unbound-control.

Defining such forward in the config is fine and works correct as far as I can tell:

forward-zone:
	name: "."
	forward-tls-upstream: yes
	forward-addr: 1.1.1.1@853

Unfortunately, that static config does not suit my particular environment, because I'm operating in changing locations. I need to switch the "." forward zone to different upstream DNS servers (with and without DoT), basically on-the-fly. Embedded in some "external detection logic", I'm already able to adjust the DNS setup via unbound-control accordingly, but unfortunately not for any DoT forwards. Simply because there seems to be no way to set the forward-tls-upstream option with the forward_add command.

If there is any way to accomplish this with unbound-control please let me know. Otherwise I would kindly request this as a feature.

@Playgirlkaybraz11
Copy link

test/serialization.test.ts #1090 #1090 #1115 #871 #994

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Unbound release 1.20.0
3 participants
@wcawijngaards @jdelker @Playgirlkaybraz11