Debian Bug report logs - #310772
bind9: unexpected error @ client.c:1325 stops IPv6 responses

version graph

Package: bind9; Maintainer for bind9 is LaMont Jones <lamont@debian.org>; Source for bind9 is src:bind9.

Reported by: Adam Majer <adamm@zombino.com>

Date: Wed, 25 May 2005 21:18:09 UTC

Severity: important

Tags: ipv6, jessie, pending, sarge, sid, upstream

Found in version 1:9.2.4-1

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#310772; Package bind9. Full text and rfc822 format available.

Acknowledgement sent to Adam Majer <adamm@galacticasoftware.com>:
New Bug report received and forwarded. Copy sent to LaMont Jones <lamont@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Adam Majer <adamm@galacticasoftware.com>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: bind9: unexpected error @ client.c:1325 stops IPv6 responses
Date: Wed, 25 May 2005 15:48:35 -0500
Package: bind9
Version: 1:9.2.4-1
Severity: important

After running on IPv6 for a while, my ppp connected disconnected and the 
reconnected. About 4 minutes following that even, bind9 suddenly stopped
responding to queries on IPv6 sockets. The only syslog entry was,

May 25 02:00:02 polaris named[13232]: client.c:1325: unexpected error:
May 25 02:00:02 polaris named[13232]: failed to get request's destination: failure

In current sid version, 1:9.3.1, the line that would generate this error is 
client.c:1401

- Adam

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages bind9 depends on:
ii  adduser                     3.63         Add and remove users and groups
ii  libc6                       2.3.2.ds1-21 GNU C Library: Shared libraries an
ii  libdns16                    1:9.2.4-1    DNS Shared Library used by BIND
ii  libisc7                     1:9.2.4-1    ISC Shared Library used by BIND
ii  libisccc0                   1:9.2.4-1    Command Channel Library used by BI
ii  libisccfg0                  1:9.2.4-1    Config File Handling Library used 
ii  liblwres1                   1:9.2.4-1    Lightweight Resolver Library used 
ii  libssl0.9.7                 0.9.7e-3     SSL shared libraries
ii  netbase                     4.21         Basic TCP/IP networking system

-- no debconf information



Information forwarded to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#310772; Package bind9. Full text and rfc822 format available.

Acknowledgement sent to Adam Majer <adamm@zombino.com>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>. Full text and rfc822 format available.

Message #10 received at 310772@bugs.debian.org (full text, mbox):

From: Adam Majer <adamm@zombino.com>
To: Debian Bug Tracking System <310772@bugs.debian.org>
Subject: PPP is IPv4 only..
Date: Wed, 22 Jun 2005 11:40:06 -0500
Package: bind9
Followup-For: Bug #310772

Just to followup the previous report, the ppp connection is IPv4 only
yet its disconnection for any significant period of time causes the IPv6
listening bind9 to stop listening on IPv6 socket wit the above
"unexpected error" message.

- Adam


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-k7
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)



Changed Bug submitter from Adam Majer <adamm@galacticasoftware.com> to Adam Majer <adamm@zombino.com>. Request was from Adam Majer <adamm@zombino.com> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#310772; Package bind9. Full text and rfc822 format available.

Acknowledgement sent to Adrian Knoth <adi@drcomp.erfurt.thur.de>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>. Full text and rfc822 format available.

Message #17 received at 310772@bugs.debian.org (full text, mbox):

From: Adrian Knoth <adi@drcomp.erfurt.thur.de>
To: 310772@bugs.debian.org
Subject: Confirmed, same problem here
Date: Sat, 6 May 2006 23:50:12 +0200
Hi,

I'm experiencing the same problems. named stops answering on
the IPv6 socket, but can still responds to queries via IPv4.

The problem is completely new, I've never seen this within
a year on this server, expect once in February. After
migrating the box to another network (with a lot of broadcast
traffic, the old location was pretty isolated), all was fine
for six days and now named fails after a few seconds/minutes.


rndc reload|flush|whatever does not fix the problem.

The box is always connected to the internet, no PPP
or anything like this, so there are no disconnects.


-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Wer nie in Bette Kuchen aß, weiß nicht wie Krümel pieken



Information forwarded to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#310772; Package bind9. Full text and rfc822 format available.

Acknowledgement sent to Pascal Hambourg <pascal.mail@plouf.fr.eu.org>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>. Full text and rfc822 format available.

Message #22 received at 310772@bugs.debian.org (full text, mbox):

From: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
To: 310772@bugs.debian.org
Subject: Re: bind9: unexpected error @ client.c:1325 stops IPv6 responses
Date: Sat, 09 Sep 2006 04:55:16 +0200
Debian Release : 3.1 (sarge)
Architecture: i386
Kernel : custom 2.4.33.3
Package: bind9
Version: 1:9.2.4-1

I just started to experienced the same problem after upgrading from 
woody (oldstable) to sarge (stable). After some testing, I believe I 
found out in which situation it happens, and a possible workaround to 
avoid it.

Background :
On a default Linux system with dual stack IPv4+IPv6, an IPv6 TCP or UDP 
socket listening on any address, which is the kind of IPv6 socket bind9 
uses, can also receive IPv4 packets by using the IPv4-mapped address 
(::ffff:a.b.c.d) translation mechanism when there is no IPv4 socket 
listening on the same port. When you launch bind9 with the following 
options :

    listen-on { any; };
    listen-on-v6 { any; }; // listen

bind9 opens the following sockets on port 53 :

zenith:~# netstat -nltu
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address       Foreign Address      State
tcp6       0      0 :::53               :::*                 LISTEN
udp        0      0 10.0.0.1:53         0.0.0.0:*
udp        0      0 192.168.0.1:53      0.0.0.0:*
udp        0      0 127.0.0.1:53        0.0.0.0:*
udp6       0      0 :::53               :::*

For TCP, a single IPv6 socket receives all IPv4 and IPv6 traffic, 
because it is created first and bind9 fails to create the IPv4 sockets. 
In UDP, bind9 opens a separate IPv4 socket for each local interface IPv4 
address and a single IPv6 socket.

Now, here is what I observed :

- When you do a TCP query either on IPv4 or IPv6, it goes to the TCPv6 
socket and everything goes fine.
- When you do a UDP query on IPv6, it goes to the UDPv6 socket and 
everything goes fine too.
- When you do a UDP query to an IPv4 address on which bind9 is 
listening, it goes to that UDPv4 socket and everything goes fine too.
- But when you do a UDP query to an IPv4 address on which bind9 is NOT 
listening, it goes to the UDPv6 socket and "blocks" it. This is what 
triggers the following message you saw in syslog :

 named[11577]: client.c:1325: unexpected error:
 named[11577]: failed to get request's destination: failure

From this point it looks like stops reading packets on the UDPv6 socket 
and they get stuck in the receive queue :

zenith:~# netstat -nltu
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address       Foreign Address      State
tcp6       0      0 :::53               :::*                 LISTEN
udp        0      0 10.0.0.1:53         0.0.0.0:*
udp        0      0 192.168.0.1:53      0.0.0.0:*
udp        0      0 127.0.0.1:53        0.0.0.0:*
udp6    4328      0 :::53               :::*

I have absolutely no clue about why this is happening. It didn't happen 
in the bind9 version included in woody.

The fourth situation can happen when bind9 does not listen on a given 
local IPv4 address but receives a UDP query on that address. It's easy 
to reproduce by doing a query to any loopack address other than 
127.0.0.1, for example 127.1.2.3. Or when a PPP link goes down and bind9 
re-scans the interfaces before the link goes up again :

- PPP interface goes down ;
- bind9 scans the interfaces and stops listening on the PPP IPv4 
address, there is no more UDPv4 socket for that address ;
- PPP interface goes up again ;
- if a UDP query to the PPP address is received before bind9 rescans the 
interfaces, the packet goes to the UDPv6 socket as there is no UDPv4 
socket for that address -> bug.

To restore the UDP operation on IPv6, you can either stop and restart 
bind9, or disable the listen-on-v6 option in named.conf, run "rndc 
reconfig" to close the blocked IPv6 socket, re-enable the listen-on-v6 
option and re-run "rndc reconfig" to reopen a new socket.

The workaround I found is to set the kernel parameter 
/proc/sys/net/ipv6/bindv6only to 1. This can be automated at system 
startup by adding the following line to /etc/sysctl.conf :

net/ipv6/bindv6only=1

This restricts the use of IPv6 sockets to IPv6 communication only and 
prevents the use of the IPv4-mapped translation mechanism, so the UDPv6 
socket receives only "pure" IPv6 queries. A positive side effect is that 
bind9 (and other services such as sshd) is able to open separate IPv4 
and IPv6 sockets for TCP communications, so for IPv4 queries you will 
see in the logs the usual IPv4 addresses in dotted-quad format instead 
of ugly IPv4-mapped IPv6 addresses. However I don't know whether there 
are any negative side effets to this setting. Any feedback is welcome.

Sorry for being so long.



Information forwarded to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#310772; Package bind9. Full text and rfc822 format available.

Acknowledgement sent to Mark Andrews <Mark_Andrews@isc.org>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>. Full text and rfc822 format available.

Message #27 received at 310772@bugs.debian.org (full text, mbox):

From: Mark Andrews <Mark_Andrews@isc.org>
To: 310772@bugs.debian.org
Subject: Re: bind9: unexpected error @ client.c:1325 stops IPv6 responses
Date: Mon, 26 Feb 2007 12:03:13 +1100
2143.   [bug]           We failed to restart the IPv6 client when the
                        kernel failed to return the destination the
                        packet was sent to. [RT #16613]
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: Mark_Andrews@isc.org



Tags added: sarge Request was from LaMont Jones <lamont@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: sid Request was from LaMont Jones <lamont@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: upstream Request was from LaMont Jones <lamont@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: pending Request was from LaMont Jones <lamont@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#310772; Package bind9. Full text and rfc822 format available.

Acknowledgement sent to Brian Ristuccia <brian@ristuccia.com>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.

Your message did not contain a Subject field. They are recommended and useful because the title of a Bug is determined using this field. Please remember to include a Subject field in your messages in future.

Full text and rfc822 format available.


Message #40 received at 310772@bugs.debian.org (full text, mbox):

From: Brian Ristuccia <brian@ristuccia.com>
To: 310772@bugs.debian.org
Date: Mon, 21 Jan 2008 10:59:27 -0500
Also broken in the 1:9.3.4-2etch1 version in etch.

In my configuration, I see the problem on several interfaces relatively
quickly after named starts running. This bug makes named mostly unusable. 

-- 
Brian Ristuccia
brian@ristuccia.com




Information forwarded to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#310772; Package bind9. Full text and rfc822 format available.

Acknowledgement sent to brian@ristuccia.com:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>. Full text and rfc822 format available.

Message #45 received at 310772@bugs.debian.org (full text, mbox):

From: "Brian Ristuccia" <brian@ristuccia.com>
To: "Pascal Hambourg" <pascal.mail@plouf.fr.eu.org>, 310772@bugs.debian.org, 205926@bugs.debian.org
Subject: Re: Bug#310772: bind9: unexpected error @ client.c:1325 stops IPv6responses
Date: Tue, 22 Jan 2008 11:34:14 +0000
Whoops. I had meant to add this to bug#205926 (bind9 named stops receiving on some interfaces). My setup works equally poorly if IPv6 is disabled...

------Original Message------
From: Pascal Hambourg
To: Brian Ristuccia
Sent: Jan 22, 2008 4:39 AM
Subject: Re: Bug#310772: bind9: unexpected error @ client.c:1325 stops IPv6responses

Hello,

Brian Ristuccia wrote :
> Also broken in the 1:9.3.4-2etch1 version in etch.
> 
> In my configuration, I see the problem on several interfaces relatively
> quickly after named starts running. This bug makes named mostly unusable. 

I haven't upgraded my system to etch yet, so thanks for the feedback.

Depending on your system setup, networking environment and operational 
requirements, there may be some possible workarounds mitigating the bug. 
On my system, bind9 works fine with with the kernel parameter bindv6only 
set to 1.








Added tag(s) ipv6. Request was from Simon Paillard <simon.paillard@resel.enst-bretagne.fr> to control@bugs.debian.org. (Sat, 16 Jan 2010 19:48:31 GMT) Full text and rfc822 format available.

Severity set to 'serious' from 'important' Request was from Clint Adams <schizo@debian.org> to control@bugs.debian.org. (Tue, 23 Mar 2010 01:04:13 GMT) Full text and rfc822 format available.

Severity set to 'important' from 'serious' Request was from Gerfried Fuchs <rhonda@deb.at> to control@bugs.debian.org. (Tue, 23 Mar 2010 08:31:16 GMT) Full text and rfc822 format available.

Added tag(s) jessie. Request was from Julien Cristau <jcristau@debian.org> to control@bugs.debian.org. (Thu, 18 Apr 2013 17:38:06 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 06:36:37 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.