Bind 9.2.5 and IPv6 fails with client.c:1325: unexpected error: failed to get request's destination: failure
Pascal Hambourg
pascal.mail at plouf.fr.eu.org
Wed Jan 17 00:47:07 UTC 2007
Hello,
Roland Dirlewanger a écrit :
>
> I have a very strange problem with a Bind server version 9.2.5 on Fedora
> Core 3.
>
> Named listen to one IPv4 address and any IPv6 address. The configuration
> has been running for many months. No changes where made recently to the
> configuration except for adding or removing slave zones.
>
> The symptom is that the server does not answer request to the IPv6
> address + port UDP 53. It still answers requests to the UDP and TCP port
> 53 using IPv4 and to the TCP port 53 using IPv6. Using dig on the
> server, or on any server on the same LAN, leads to the following behavior :
> - dig ns some.domain @IPv4-address : works fine
> - dig +vc ns some.domain @IPv4-address : works fine
> - dig +vc ns some.domain @IPv6-address: works fine
> - dig ns some.domain @IPv6-address: works once or twice immediately
> after restarting named, fails afterwards
>
> The logs show the following message :
> Jan 16 23:34:25 named[32125]: failed to get request's destination: failure
> Jan 16 23:34:27 named[32125]: client.c:1325: unexpected error:
I think I experienced a similar problem with BIND 9.2.4 on Debian Sarge.
It seems to be triggered when the IPv6 UDP socket receives an IPv4
request, which can occur in the following conditions :
- IPv6 sockets allow IPv4 communications (default on Linux),
- and a UDP request is received on an IPv4 address for which named has
no listening UDP socket.
The result is the IPv6 UDP socket receives the IPv4 request and hangs.
Cf. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310772 for more
info. I also included a workaround based on changing the defaut
behaviour of accepting IPv4 communication on IPv6 sockets.
HTH.
More information about the bind-users
mailing list