DragonFlyBSD

BIND is queuing socket operations (read/write), marking them as queued, but then
not filtering ready events (from kqueue/poll/select) that would result in a
second queued operation and then asserting when they catch it just prior to
queueing (in dispatch_recv() in this case, but it is also possible for it to
happen in dispatch_send()). Raising the number of FD events,
ISC_SOCKET_MAXEVENTS may work around this in our kevent case.

A possible fix might be to change the INSIST's in dispatch_send/recv() to if
(sock->pending_recv) return;, but I have not tested this.

There is an underlying bug here and we should re-file this upstream.

I might have been wrong here, BIND does "unwatch" the descriptor for the read or
write case after queuing the read or write event. So it looks like it is
possible we are returning events from kevent(2) previously passed in with an
EV_DELETE flag. Will investigate further.