Unbound behaviour changes (wrong) when domain-insecure is set for a stub zone with multiple stub-addr(s)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Unbound - Caching DNS Resolver |
Unknown
|
Unknown
|
|||
unbound (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Trusty |
Won't Fix
|
Undecided
|
Unassigned | ||
Xenial |
Won't Fix
|
Undecided
|
Unassigned | ||
Bionic |
Won't Fix
|
Undecided
|
Unassigned |
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://
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:/
With regards,
Richard Arends
Changed in unbound (Ubuntu): | |
status: | New → Confirmed |
importance: | Undecided → Medium |
Changed in unbound (Ubuntu Bionic): | |
status: | Incomplete → Won't Fix |
This was fixed yesterday upstream and is not yet released anywhere.
For confidence in the change I'd prefer to wait for it to be released - not that they find issues in the fix.
The actual change is small and seems backportable even to trusty, but I had no time to check the context.
Debian currently is ~2 months behind the last upstream release, given the cadence of upstream releases this will be released ~mid december.
We can't really wait until March to pick it, but should wait for the upstream release.
Until then we can try in a ppa if it actually is backportable and there Richard can check if the backport works.