Memory Leak

[mbah-dukun]

memory goes up to max after upgrade to new version,

[ShreyasZare]

Thanks for the feedback. Have you tried restarting the DNS server to see if that helps? Do you see any errors being logged in the Logs > View Logs section?

Please share more info about your deployment like a screenshot of the dashboard to help understand the setup better.

[mbah-dukun]

Thanks for the feedback. Have you tried restarting the DNS server to see if that helps? Do you see any errors being logged in the Logs > View Logs section?

Please share more info about your deployment like a screenshot of the dashboard to help understand the setup better.

I've restarted several times today, and it did help. But since this is the production DNS for the recursor, I rolled back to the previous version.

[ShreyasZare]

I've restarted several times today, and it did help. But since this is the production DNS for the recursor, I rolled back to the previous version.

You need to provide some info for understanding the issue better. This issue is not observed otherwise in any deployments that I have.

If your server has high traffic and you are using the dashboard stats frequently then it will use more memory. The stats module is very old and was not designed for high loads. You can use the "Enable In-Memory Stats" option in Settings > Logging section to stop stats collection such that only last hour data is available on the dashboard. This reduces memory usage significantly.

[mbah-dukun]

I've restarted several times today, and it did help. But since this is the production DNS for the recursor, I rolled back to the previous version.

You need to provide some info for understanding the issue better. This issue is not observed otherwise in any deployments that I have.

If your server has high traffic and you are using the dashboard stats frequently then it will use more memory. The stats module is very old and was not designed for high loads. You can use the "Enable In-Memory Stats" option in Settings > Logging section to stop stats collection such that only last hour data is available on the dashboard. This reduces memory usage significantly.

Yes, I have quite a bit of traffic, around 500 qps at peak, but I split it using multiple forwarders underneath to keep the load down. I'm using Docker to deploy Technitium on it. I'll try deploying a new instance to test if I'm experiencing the same issue.

Note: I'm also using SQLite to display query logs to determine if DNS flooding is occurring on my internal network.

[ShreyasZare]

Thanks for the details.

Yes, I have quite a bit of traffic, around 500 qps at peak, but I split it using multiple forwarders underneath to keep the load down. I'm using Docker to deploy Technitium on it. I'll try deploying a new instance to test if I'm experiencing the same issue.

500qps is not that large to affect the stats module. It would consume some memory but not so much that you observed.

Note: I'm also using SQLite to display query logs to determine if DNS flooding is occurring on my internal network.

I think the issue could be due to use of Query Logs (Sqlite) app. The db can keep indexed data in memory. I would suggest that you disable the app, restart once and see if that make any difference. You can try using the alternate app that uses mysql backend where you install mysql on a different server.

[GJRodenburg]

Running into the same issue. But not using sqlite or any other apps. Upgraded from 14.x to 15.3 and have, since then, had the machines crash due to out of memory. Have added limits to the docker compose (should've had 'm in place before, but alas), and reverted back to 15.2.

Note: No issues whatsoever on 14. and two hard crashes of both the instances in two days on 15.3.

Sadly, I have no docker logs to share.

[jaxmann-GoBrolly]

I had same issue. Here is a summary of what I found:

Subject: Possible Memory Leak / OOM Issue in Technitium DNS Server 15.3

Summary

After upgrading our Technitium DNS cluster from 15.2.0 to 15.3, all cluster members began experiencing excessive memory consumption resulting in Linux OOM kills, cluster instability, failed node notifications, and intermittent DNS operation failures.

Downgrading all affected nodes back to 15.2.0 immediately resolved the issue.

Environment

• Technitium DNS Server clustered deployment
• Previous version: 15.2.0
• Problematic version: 15.3
• OS: Debian Linux
• Memory per node: ~24 GB RAM
• Swap: None
• Multi-node cluster with secondary nodes and zone transfers

Symptoms Observed After Upgrading to 15.3

Cluster communication became unstable. Cluster nodes would randomly report connectivity failures such as:

Error! Connection refused (dns07-02.lan:53443)

The failures were not isolated to a single node and appeared to move between cluster members.

Server logs showed repeated notification and communication failures:

DNS Server failed to notify Secondary node
System.Threading.Tasks.TaskCanceledException
HttpClient.Timeout of 30 seconds elapsing

and

DNS Server failed to notify name server
DnsClient failed to resolve request
request timed out

Systemd logs showed the service being terminated due to memory exhaustion:

dns.service: Failed with result 'oom-kill'

and

Consumed 23.2G memory peak

Kernel OOM Logs

Multiple nodes recorded repeated OOM kills of the Technitium dotnet process.

Example:

[Tue Jul  7 06:18:01 2026] Out of memory: Killed process 730 (dotnet) total-vm:55699460kB, anon-rss:24295792kB
[Tue Jul  7 06:24:22 2026] Out of memory: Killed process 909 (dotnet) total-vm:55922840kB, anon-rss:24304520kB
[Tue Jul  7 06:39:29 2026] Out of memory: Killed process 1065 (dotnet) total-vm:56251516kB, anon-rss:24300864kB
[Tue Jul  7 06:40:13 2026] Out of memory: Killed process 1290 (dotnet) total-vm:56242536kB, anon-rss:24305636kB

The process consistently grew until it consumed approximately 23–24 GB of RAM and was then terminated by the Linux OOM killer.

Impact

Whenever the OOM event occurred:

• Technitium DNS process was terminated
• Cluster port 53443 stopped listening
• Other cluster members reported "Connection refused"
• Cluster synchronization failed
• DNS NOTIFY operations failed
• Zone transfers were disrupted
• systemd restarted the service

This caused intermittent cluster instability and DNS-related errors.

Rollback Test

To test whether the issue was related to 15.3, the node was downgraded to 15.2.0 using:

wget https://download.technitium.com/archive/15.2.0/DnsServerPortable.tar.gz
sudo tar -zxf DnsServerPortable.tar.gz -C /opt/technitium/dns
sudo systemctl restart dns.service

Verification of installed binaries showed 15.2.0:

grep -a "15." /opt/technitium/dns/DnsServerApp.deps.json

Output included:

DnsServerApp/15.2
DnsServer 15.2.0
DnsServerCore 15.2.0.0

The core assemblies on disk all matched the 15.2 release date (May 9, 2026).

Results After Downgrading

Immediately after downgrading:

• OOM kills stopped
• Memory consumption returned to normal
• Cluster communication stabilized
• Connection refused errors disappeared
• Secondary notifications succeeded
• Zone transfers resumed normal operation

Conclusion

There appears to be a regression in Technitium DNS Server 15.3 that causes excessive memory consumption in our Debian clustered environment. The dotnet process grows to approximately 23–24 GB RSS before being terminated by the Linux OOM killer.

Rolling back to 15.2.0 completely resolved the issue on all affected nodes.

I can provide additional logs if needed.

[Apachez-]

How quickly does this runaway happen?

Any way to provoke it like if you would loop a dig query for localhost or such using udp vs tcp from the client?

I have 15.3 running as container since +54 hours (since last restart/reboot) being a resursor/cache for a few local clients towards internet.

From within the container:

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.5  0.8 9576300 277964 pts/0  Ssl+ Jul07  18:44 /usr/bin/dotnet /opt/technitium/dns/DnsServerApp.dll /etc/dns

Container configured for 1GB of RAM.

Output of podman stats:

ID            NAME        CPU %       MEM USAGE / LIMIT  MEM %       NET IO      BLOCK IO    PIDS        CPU TIME       AVG CPU %
83f2eacf781b  dns         0.86%       169.7MB / 1.074GB  15.81%      0B / 0B     0B / 0B     33          18m49.831674s  0.57%

[jaxmann-GoBrolly]

Almost immediately. I didn't notice it until the following morning. My cluster of 6 servers in 3 different locations average 600k - 700k queries per day.

[nlt6444]

I am experiencing similar issues on 15.3 docker install as well. Memory utilization is 100%. If it helps, I am experiencing the issue when updating my blocklists. The workaround I have been using is deleting all the files in /blocklists. Once I delete them and do not click the update now button, the server runs smoothly until another blocklist update is triggered. Unfortunately, I have not been able to locate any errors in the logs. Is there a debug mode I can enable?

[ShreyasZare]

@nlt6444 Block lists are fully loaded into memory. The update process will load newly downloaded lists too in memory thus consuming twice the memory before it replaces the old block lists data. A millions blocked domain names take roughly 300MB of memory. You need to see how many domain names are being loaded in total by the block lists and allocate sufficient memory. You can find out the blocked list domain count on the dashboard above top clients table.

[mbah-dukun]

I am still monitoring the memory condition for version 15.4, for now there is no memory spike problem like before.

[amatomasaki]

@jaxmann-GoBrolly same here, downgraded to 15.2 and its just working wondrously. i dunno why.
@mbah-dukun , let me know how it goes on the docker side.

[ShreyasZare]

Anyone who still sees this issue, do upgrade to latest and observe. Also observe if the memory usage goes down later.

[jaxmann-GoBrolly]

I have upgraded one of my nodes and everything appears to be working the way it should be. Going to let it run for a while before upgrading any of the other nodes.