Bind 9.2.5 and IPv6 fails with client.c:1325: unexpected error: failed to get request's destination: failure

[Mark Andrews]

> 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.

	BIND 9.3/9.4 set the IPV6_V6ONLY option on IPv6 sockets
	if the kernel supports it.

	Upgrade.

	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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org