← Back to team overview

group.of.nepali.translators team mailing list archive

[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