Bind 9.2.5 and IPv6 fails with client.c:1325: unexpected error: failed to get request's destination: failure
Mark_Andrews at isc.org
Wed Jan 17 01:48:07 UTC 2007
> 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: failed to get request's destination: failure
> > Jan 16 23:34:27 named: 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.
BIND 9.3/9.4 set the IPV6_V6ONLY option on IPv6 sockets
if the kernel supports it.
Note: there is nothing that precludes a stack from returning
packet info for mapped packets. One could argue that for
consistancy sake it should do just that.
Note: as noted in the above bug report that socket binding
in Linux is broken. The BSD socket api allows for more
specific binding regardless of the binding order.
::1#53 is more specific than ::#53 (allowed)
127.0.0.1#53 is more specific than 0.0.0.0#53 (allowed)
0.0.0.0#53 is more specific than ::#53 (order dependent unless
IPV6_V6ONLY is set).
127.0.0.1#53 is more specific than ::#53
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the bind-users