group.of.nepali.translators team mailing list archive
-
group.of.nepali.translators team
-
Mailing list archive
-
Message #25773
[Bug 1732150] Re: Unbound behaviour changes (wrong) when domain-insecure is set for a stub zone with multiple stub-addr(s)
FYI - final upstream fix was
https://github.com/NLnetLabs/unbound/commit/52aeaf4924ec3f6689e6aafedbe41473d2bda992
Which in the meantime was released in version 1.7 and later:
$ git tag --contains 52aeaf4924ec3f6689e6aafedbe41473d2bda992 | head -n 2
release-1.7.0@4583
release-1.7.0rc1
Thereby Cosmic is already fixed.
In fact we covred steps 1-3 of my comment #4.
That said I have had a unbound SRU planned anyway.
Lets fix this for T/X/B - especially as we already know it works back to Trusty as-is.
I realized that you could help a lot by providing a bit more detailed steps to reproduce the error.
I've added the rest of the SRU Template, but would ask you to provide steps to reproduce here.
>From your upstream bug report I can derive it would need setting up multiple DNS servers, then unbound with domain-insecure.
Whatever you can add to make this testable for someone that will evaluate the SRU later on will help.
Note: also killing other EOL tasks.
** Description changed:
+ [Impact]
+
+ * DNSSEC setup with domain-insecure set fail to work.
+ The lookup will process all available servers leading to a very long
+ lookup time.
+
+ * Backport upstream fix to stop checking for further trust points in that
+ case.
+
+ [Test Case]
+
+ * TBD: Waiting for the bug reporter to provide the initial steps that we
+ migth refine
+
+ [Regression Potential]
+
+ * The change will make it stop iterating for further DNSSEC records in
+ certain configuration cases (domain-insecure). But this is just what
+ the respective configuration is meant to do (see
+ http://manpages.ubuntu.com/manpages/bionic/man5/unbound.conf.5.html)
+ So it should speed up certain cases were so far it still iterated
+ through servers, but giving that up early is just what it shoudl be per
+ config.
+ I can think of a slight behavior change due to being faster now, but
+ the end result should not change due to this. With that background I
+ could think of two regressions:
+ a) the faster lookup makes automation wonder
+ b) there would be a condition we (and upstream) missed which would
+ change the actual lookup return
+ Given that the code was not reverted upstream for quite a while I'd
+ think the latter is only theoretical, and the former should be of low
+ risk.
+
+ [Other Info]
+
+ * n/a
+
+
+ ---
+
Unbound contains a bug when domain-insecure is set for a (stub) zone.
This bug is fixed, see https://www.nlnetlabs.nl/bugs-
script/show_bug.cgi?id=2882. Can you please backport this to the Trusty
package?
With regards,
Richard Arends
** No longer affects: unbound (Ubuntu Zesty)
** No longer affects: unbound (Ubuntu Artful)
** Changed in: unbound (Ubuntu)
Status: Triaged => Fix Released
** Changed in: unbound (Ubuntu Trusty)
Status: New => Triaged
** Changed in: unbound (Ubuntu Xenial)
Status: New => Triaged
** Changed in: unbound (Ubuntu Bionic)
Status: New => Triaged
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1732150
Title:
Unbound behaviour changes (wrong) when domain-insecure is set for a
stub zone with multiple stub-addr(s)
Status in Unbound - Caching DNS Resolver:
Unknown
Status in unbound package in Ubuntu:
Fix Released
Status in unbound source package in Trusty:
Triaged
Status in unbound source package in Xenial:
Triaged
Status in unbound source package in Bionic:
Triaged
Bug description:
[Impact]
* DNSSEC setup with domain-insecure set fail to work.
The lookup will process all available servers leading to a very long
lookup time.
* Backport upstream fix to stop checking for further trust points in that
case.
[Test Case]
* TBD: Waiting for the bug reporter to provide the initial steps that we
migth refine
[Regression Potential]
* The change will make it stop iterating for further DNSSEC records in
certain configuration cases (domain-insecure). But this is just what
the respective configuration is meant to do (see
http://manpages.ubuntu.com/manpages/bionic/man5/unbound.conf.5.html)
So it should speed up certain cases were so far it still iterated
through servers, but giving that up early is just what it shoudl be per
config.
I can think of a slight behavior change due to being faster now, but
the end result should not change due to this. With that background I
could think of two regressions:
a) the faster lookup makes automation wonder
b) there would be a condition we (and upstream) missed which would
change the actual lookup return
Given that the code was not reverted upstream for quite a while I'd
think the latter is only theoretical, and the former should be of low
risk.
[Other Info]
* n/a
---
Unbound contains a bug when domain-insecure is set for a (stub) zone.
This bug is fixed, see https://www.nlnetlabs.nl/bugs-
script/show_bug.cgi?id=2882. Can you please backport this to the
Trusty package?
With regards,
Richard Arends
To manage notifications about this bug go to:
https://bugs.launchpad.net/unbound/+bug/1732150/+subscriptions