[Bug 1472510] Re: Unbound returns SERVFAIL for specific query on dual stacked machine

Patrik Lundin patrik.lundin at su.se
Thu Jul 16 11:10:52 UTC 2015


Attached is a debdiff for trusty which is based on the wily patch.

** Attachment removed: "unbound_1.4.22-1ubuntu4.14.04.2.patch"
   https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/1472510/+attachment/4426181/+files/unbound_1.4.22-1ubuntu4.14.04.2.patch

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1472510

Title:
  Unbound returns SERVFAIL for specific query on dual stacked machine

Status in unbound package in Ubuntu:
  Fix Committed
Status in unbound source package in Trusty:
  Triaged

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/unbound/root.key a.root-servers.net
  ===

  * IPv6-only (works):
  ===
  unbound-host -6 -f /var/lib/unbound/root.key a.root-servers.net
  ===

  * Both (fails):
  ===
  unbound-host -f /var/lib/unbound/root.key a.root-servers.net
  ===

  [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/unbound/root.key a.root-servers.net
  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/unbound/root.key a.root-servers.net
  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/unbound/root.key a.root-servers.net
  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/unbound/root.key a.root-servers.net
  [...]
  [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://www.unbound.net/download.html) I noticed 1.5.0 had increased
  the MAX_SENT_COUNT definition from 16 to 32.

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/1472510/+subscriptions



More information about the Ubuntu-sponsors mailing list