Hi Adam,
Thank you very much for testing. It is good to hear that the test
package solves your issue.
The patch that was in the test package was in the upstream release
9.16.2, so when you built 9.16.10, the patch would have been present and
hence compiling from upstream doesn't present the
Hi Matthew
I can confirm that this package did indeed fix the issue. The current
packaged version still presented the problem so it looks like you patch
fixed it.
I would be interested to know why compiling from upstream doesn't
present the issue however.
Thanks
--
You received this bug
Hi Adam,
I think I have found the issue that you are experiencing. I don't have a
way to reproduce just yet, but I have built a test package for you to
try.
I came across the following upstream bug:
https://gitlab.isc.org/isc-projects/bind9/-/issues/1700
The users mention that tcp connections
** Also affects: bind9 (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: bind9 (Ubuntu Focal)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Yeah testing should be no problem. I will get a server ready.
It may take me some time to get this done however.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1909950
Title:
TCP connections never
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: bind9 (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1909950
Title:
TCP
** Changed in: bind9 (Ubuntu)
Status: Confirmed => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1909950
Title:
TCP connections never close
To manage notifications about this bug go to:
Hello,
A another user has reported a very similar issue. They operate bind9
resolvers in both recursive and authoritative configurations, and
occasionally, their servers will stop responding to TCP requests.
UDP still operates as normal, but TCP connections will time out.
named is still
** Changed in: bind9 (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1909950
Title:
TCP connections never close
To manage notifications about this bug go
Sure thing:
Upstream Build: BIND 9.16.10
Debian Distro Build: 9.11.5
I have since migrated all the affected machines to KNOT-Resolver but I
have kept one off our network with Bind9 still running if you need any
extra info.
Thanks
--
You received this bug notification because you are a member
Hi Adam,
Could you please let us know the upstream version you compiled and
reported as working and the Debian version you found working? I had a
look at the upstream commit and bug history but couldn't spot an obvious
change regarding the handling of the tcp timeouts, at least past-9.16.1
(there
Yes that exactly, essentially we found that we had the connections set
to 1000 and one client opened a few connections but they never closed,
they then opened more and more naturally.
In the end one client had over 900 connections. Once we hit 1000 we ran
a quick dig against the server and it
Interesting, as Lucas said I'd not have seen any config/patch that would
intend to change any of that.
As for testing could we tap on your experience please?
As I understand you limit the number of connections (and we could use an even
lower number).
So would you think if we default deploy a
Thanks for the update.
Config files are attached. You will note that the only override we we
for TCP clients is the amount that are allowed to connect as the default
is very low for an ISP DNS server.
However we are relying on the default tcp-timeout values. I will note
that since we removed the
Thanks for taking the time to file this bug and try to make Ubuntu
better.
I suppose you are talking about 'tcp-initial-timeout' config option
which the upstream default is 30 seconds (300 * 100 milliseconds). Am I
right? Or are mentioning something else?
FWIW I got this info from upstream doc:
15 matches
Mail list logo
