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