How much time before unbound drops an unanswered UDP query?

[W.C.A. Wijngaards]

Hi Viktor,

On 30/03/18 03:23, Viktor Dukhovni via Unbound-users wrote:
> 
> 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?

There are no options to control this on server side.

There is delay-close where you can configure unbound to keep a port open
a bit longer to catch delayed responses.

Unbound can take many seconds to reply.  If there are a large number of
upstreams to probe.  They all respond very slowly, or are in the process
of timing out.  Then you get something very slow, because, no
information is available sooner.

There is an RFC that recommends you check the id number and query name
of the reply, that would solve your problem here.

Best regards, Wouter

> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20180403/3fdaddf9/attachment.bin>