IPv6 UDP getting stuck

["Kimmo Suominen" <kim%netbsd.org@localhost>]

Hi all,

It looks like something can get stuck in the (UDP) receive queue:

grendel:~# netstat -anf inet6 | awk '$2 != 0 {print}'
Active Internet6 connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        
(state)
udp6    3268      0  *.53                   *.*

Whatever it is that gets stuck in the queue never seems to drain. I 
thought
it could be fragments (although didn’t check how the queue is 
counted), but
reassembly should time out eventually.

There are no IPv4 sockets for "*.53" as named expects to receive all 
traffic
over the IPv6 sockets disabling IPV6_V6ONLY. Since IPv4 traffic works, 
this
would appear to be the case.

The issue manifests itself as UDP queries not being answered over IPv6 
but
TCP connections working normally over IPv6 (separate socket). Both UDP 
and
TCP keep working over IPv4, which seems surprising given the shared 
socket.

On a secondary name server you can see messages like these in the logs:

named[27979]: zone example.com/IN: refresh: retry limit for master 
2001:db8::53#53 exceeded (source ::#0)
named[27979]: transfer of ‘example.com/IN' from 2001:db8::53#53: 
Transfer status: up to date

Twice so far (and not in the last 4-6 weeks anymore for some reason) 
named
has become completely unresponsive on the network. Unfortunately I had 
not
looked at the receive (or transmit) queues back then, but instead just
restarted named to resume normal operation.

I'm running NetBSD 8.0 with its bundled BIND:

# named -V
BIND 9.10.5-P1 (Extended Support Version) <id:34fd9c6>
running on NetBSD amd64 8.0 NetBSD 8.0 (GENERIC) #0: Tue Jul 17 14:59:51 
UTC 2018  
mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC
built by make with defaults
compiled by GCC 5.5.0
compiled with OpenSSL version: OpenSSL 1.0.2k  26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k  26 Jan 2017

The issue surfaced after enabling DNSSEC on all zones, in case it proves
relevant. Apart from the increased response size, it doesn’t seem 
relevant
to me, given that IPv4 UDP keeps working when IPv6 UDP doesn’t.

Kind regards,
+ Kimmo