tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

IPv6 UDP getting stuck



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


Home | Main Index | Thread Index | Old Index