-
Notifications
You must be signed in to change notification settings - Fork 906
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dnsdist "stuck" after a few empty IXFRs if config has setMaxTCPClientThreads #12099
Comments
That sounds bad. I don't immediately understand what is happening because even if dnsdist was expecting more data on the IXFR TCP connections, it should only add the corresponding file descriptors to the watch list and go on with its life, so something weird is happening. |
My suspicion is that dnsdist indeed does go on with its life in a sense, and that the "stuckness" is a result of it having exhausted all available TCP connections in the backend with these already finished IXFRs (which are seemingly not recognized as such). |
So what is happening is that the server is replying with a single Now, the question is whether the authoritative server responding with a single |
It is valid, but why it is described in the "Brief description of the protocol" section of the RFC and not at all in the "Response Format" is a mystery to me. Oh well.
|
Ok, so basically if the IXFR query's requested SOA.SERIAL >= the SOA.SERIAL in the first record in the response, then we're done? |
Looks that way, yes. But I'm afraid it means we cannot distinguish such a short IXFR response from the start of a normal AXFR response without parsing the SOA in the query. |
Short description
Dnsdist gets "stuck" after completing a number of "empty IXFRs" (ie IXFR for current SOA.SERIAL) if the config has eg
setMaxTCPClientThreads(20)
.IXFRs that has changes (ie IXFR for past SOA.SERIAL) or AXFR does not seem to trigger this problem.
Environment
Steps to reproduce
Prereq: ensure you have an IXFR-capable nameserver. I validated the problem primarily with ixfrdist, but pdns-auth likely also works for the actual breaking case (IXFR for current SOA.SERIAL), although I think it will "unstick" dnsdist by closing connections after a while.
Install dnsdist, configure it like so:
Expected behaviour
All rounds should complete
Actual behaviour
Every single time the loop gets stuck after some number of rounds as dnsdist stops responding to TCP queries (in my tests it seemed to be after round 10, but idk if that is reliably so).
(Also compare what happens with
IXFR=1
(previous serial),AXFR
, or withoutsetMaxTCPClientThreads
in dnsdist.conf; none of those variations of the above scenario results in the same breakage.)Other information
At the point when dnsdist is "stuck" it has a bunch of connections remaining open to the backend (as observable in eg
netstat -an
).Possibly the issue is something along the lines that dnsdist doesn't close connections after completing the empty IXFR, and then is stuck after having exhausted all TCP connections to the backend.
For me personally, the immediate problem has been solved by simply removing
setMaxTCPClientThreads
from dnsdist.conf; the meaning of that directive has changed quite radically since the time I added it to the config anyway, and it isn't really of interest to me anymore after having read documentation for current dnsdist.However, the above behavior seems to indicate that something is wrong in the IXFR handling, which may still manifest in some other way, or at the very least for others who do want to use
setMaxTCPClientThreads
.The text was updated successfully, but these errors were encountered: