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 >
signature.asc
Description: OpenPGP digital signature
