Cyclic delegation flaw turns Technitium DNS into amplifier
TL;DR - Technitium DNS Server < 15.0.0 can be abused for DNS traffic amplification via cyclic name server delegation. If this resolver is reachable from untrusted networks, upgrade to 15.0 now.
What happened
Technitium DNS Server is a self-hosted DNS resolver and authoritative server, commonly deployed as an internal resolver, edge DNS service, or containerised component.
CVE-2026-42255 describes a DNS traffic amplification vulnerability triggered by a cyclic name server delegation loop. An attacker crafts a delegation cycle that causes the server to generate disproportionately large outbound DNS traffic relative to the inbound query - exactly the asymmetry attackers want when building DDoS reflection capacity. The flaw is scored CVSS 3.1 7.2 (High).
| Item | Detail |
|---|---|
| Affected product | Technitium DnsServer |
| Affected versions | < 15.0.0 |
| Patched version | 15.0 |
| Severity | CVSS 3.1 7.2 (High) |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:L |
DNS amplification bugs punch above their weight. A small inbound query becomes a large outbound payload, and that ratio is what attackers shop for when assembling reflection infrastructure.
Who is impacted
- Any deployment running
Technitium DNS Serverversions< 15.0.0. - Highest risk: servers reachable from untrusted networks - public-facing resolvers, authoritative DNS endpoints, or anything exposed to the internet without strict client filtering.
What to do now
- Upgrade to
15.0, which the vendor confirms resolves this issue:"Fixed a DNS amplification vulnerability ... caused by Cyclic Name Server Delegation."
- Inventory every
technitium/dns-serverdeployment across your environment and confirm installed versions - container images and bare-metal installs alike. - If you cannot upgrade immediately:
- Restrict network access to DNS listener endpoints to known-good clients only.
- Verify the instance is not operating as an open resolver - open resolvers are the default target for amplification abuse.
- If you suspect the server has already been abused, pull DNS query logs and compare inbound request volumes against outbound egress. A large response-to-request ratio is the tell.
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.
