Unbound returns SERVFAIL for specific query on dual stacked machine
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
unbound (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Trusty |
Fix Released
|
Medium
|
Unassigned | ||
Vivid |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
* Unbound is not able to look up certain hostnames in the default configuration when running on a dual stacked (IPv4 and IPv6) host.
* The impact of this on users is that it can lead to a nasty surprise when a currently IPv4-only host gets IPv6 connectivity.
[Test Case]
* On a machine that is currently dual stacked, you can verify the problem with unbound-host. Forcing it to IPv4- and IPv6 only should work, while allowing both will fail.
* IPv4-only (works):
===
unbound-host -4 -f /var/lib/
===
* IPv6-only (works):
===
unbound-host -6 -f /var/lib/
===
* Both (fails):
===
unbound-host -f /var/lib/
===
[Regression Potential]
* I am not aware of any regression risks. Looking at the upstream tree I am not able to identify any diffs surrounding r3127 that seem relevant to this bump.
[Other Info]
* See attachement for debdiff against wily.
[Original Description]
Hello,
I noticed a problem on one of my dual stacked (IPv4 and IPv6) Trusty Tahr machines running unbound.
The problem initially was that i failed running dig +trace against it, where it would hang when looking up the root servers.
I could verify the problem using unbound-host:
===
# unbound-host -f /var/lib/
Host a.root-servers.net not found: 2(SERVFAIL).
Host a.root-servers.net not found: 2(SERVFAIL).
Host a.root-servers.net not found: 2(SERVFAIL).
===
The most interesting part was that when forcing either IPv4 or IPv6, it worked:
===
# unbound-host -4 -f /var/lib/
a.root-servers.net has address 198.41.0.4
a.root-servers.net has IPv6 address 2001:503:ba3e::2:30
# unbound-host -6 -f /var/lib/
a.root-servers.net has address 198.41.0.4
a.root-servers.net has IPv6 address 2001:503:ba3e::2:30
===
Looking at the debug-output i noticed several occurences of the following messages:
===
# unbound-host -d -d -f /var/lib/
[...]
[1436342178] libunbound[14283:0] debug: request has exceeded the maximum number of sends with 17
[1436342178] libunbound[14283:0] debug: return error response SERVFAIL
[...]
===
Comparing this against the changelog of unbound (https:/
Attached is a diff which backports this change, which solved my problem.
The most annoying thing about this problem is that I can not recreate it on another host which is both the same Ubuntu version and dual stacked.
summary: |
- Unbound returns SERVFAIL for specific query on specific dual stacked - machine + Unbound returns SERVFAIL for specific query on dual stacked machine |
Changed in unbound (Ubuntu): | |
status: | Confirmed → Triaged |
importance: | Undecided → Medium |
Changed in unbound (Ubuntu Trusty): | |
status: | New → Triaged |
importance: | Undecided → Medium |
description: | updated |
Cancel that last part about not being able to recreate it on another machine for now. The other machine did not have proper IPv6 routing, making it IPv4 only in reality.