When a query arrives over UDP, and no answer is available in the cache, it may
take a while to obtain an answer. After how long will unbound drop the query
and no longer provide a delayed response?
If the client timeout is shorter than that, unbound will reply to a client port
that is already closed, or in some rare cases already re-assigned to a new UDP
socket making a new request.
I believe I am seeing the latter every few million queries with a sequence
number mismatch for request/reply via UDP to an unbound server listening on
127.0.0.1. My only explanation is that the high query rate (thousands per
second) means that occasionally a new request gets the same port as a recently
abandoned request whose UDP socket was closed. Since I'm burning through
thousands of ports per second, port number re-use within a few seconds of last
use is somewhat likely, and if the nameserver is still willing to send answer
after the client request has timed out, then that would be a way to explain the
occasional sequence number mismatch...
I could tune the nameserver to give up sooner than the clients, or tune the
clients to wait longer than the nameserver's willingness to send delayed
replies. What controls, if any are available to tune the nameserver side?
--
Viktor.
