-
-
Notifications
You must be signed in to change notification settings - Fork 359
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.
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
Cannot override tcp-upstream and tls-upstream with forward-tcp-upstream and forward-tls-upstream #1128
Comments
The forward-tls-upstream and forward-tcp-upstream only take precedence over the server: setting when they enable the setting. For disabling it it does not override the server setting. If it is needed to have separate options for tls and tcp for particular forward-zone and stub-zone entries, do not use the global server settings but instead configure all of the forward-zone and stub-zone entries individuall with the forward-tls-upstream, forward-tcp-upstream, stub-tls-upstream and stub-tcp-upstream options. That leaves the tcp-upstream and tls-upstream settings at the default no, in the server: section. In the individual stub-zone and forward-zone sections it can then be configured in detail. |
Understood, thanks. It would be nice to add that information to the documentation. |
forward-tcp-upstream and forward-tls-upstream.
The commit adds an explanation for the behaviour to the documentation. Maybe this is more understandable. |
* nlnet/master: (24 commits) Add changelog entry for tag for 1.22.0rc1. - Tag for 1.22.0 release. This did not contain the 1154 fix from 16 oct. The code repository continues with version 1.22.1 in development. - Fix NLnetLabs#1154: Tag Incorrectly Applying for Other Interfaces Using the Same IP. This fix is not for 1.22.0. - Fix for dnstap with dnscrypt and dnstap without dnsoverquic. - Fix for dnsoverquic and dnstap to use the correct dnstap environment. - Fix dnsoverquic to extend the number of streams when one is closed. - Fix to display warning if quic-port is set but dnsoverquic is not enabled when compiled. - Fix contrib/aaaa-filter-iterator.patch for change in call signature for cache_fill_missing. - Fix harden-unverified-glue for AAAA cache_fill_missing lookups. - Fix to disable detection of quic configured ports when quic is not compiled in. - Fix add reallocarray to alloc stats unit test, and disable override of strdup in unbound-host, and the result of config get option is freed properly. - Fix cookie_file test sporadic fails for time change during the test. - Fix for dnstap compile of doqclient with doq disabled. Changelog entry and unit test for fix of NSEC TTL and prefetch ttl. - Fix to limit NSEC TTL for messages from cachedb. Fix to limit the prefetch ttl for messages after a CNAME with short TTL. - Fix to limit NSEC TTL for messages from cachedb. Fix to limit the prefetch ttl for messages after a CNAME with short TTL. Changelog note for NLnetLabs#871 - Merge NLnetLabs#871: DNS over QUIC. This adds `quic-port: 853` and `quic-size: 8m` that enable dnsoverquic, and the counters `num.query.quic` and `mem.quic` in the statistics output. The feature needs to be enabled by compiling with libngtcp2, with `--with-libngtcp2=path` and libngtcp2 needs openssl+quic, pass that with `--with-ssl=path` to compile unbound as well. DNSoverQUIC (NLnetLabs#871) - Fix NLnetLabs#1128: Cannot override tcp-upstream and tls-upstream with forward-tcp-upstream and forward-tls-upstream. - Fix NLnetLabs#1149: unbound-control-setup hangs sometimes depending on the openssl version. - The fix for CVE-2024-8508 was part of 1.21.1, a security point release on 1.21.0. The code repository continues with this fix and the version number 1.22.0. ...
Hello,
I am not sure if this is a bug or intentional, but thought I would report it here anyways.
I currently use unbound with an upstream DoT server. I use
forward-tls-upstream
to ensure that all of the upstream requests use implicitly use TLS (in case of bugs like #676)However, I would also like to use forward-tls-upstream to implicitly set some domains to be resolved via an upstream server over normal DNS over UDP. As such, I have the following configuration:
My expectation is that when
wlan.schiphol.nl
is resolved, the192.168.127.97
server is used via standard DNS over UDP, without encryption. Unfortunately it seems that neitherforward-tls-upstream
norforward-tcp-upstream
(either together or separately) take preference over theserver:
setting.Unbound Version 1.21.0 on FreeBSD13.
The text was updated successfully, but these errors were encountered: