BoronDNS - News

BoronGun 0.9 preview: scriptable attack profiles

2026-06-15T00:00:00+00:00

BoronGun exists so you find your DNS server's breaking point before an attacker does. 0.9 makes the load profiles themselves a lot more expressive.

What's landing</h2>

Weighted query mixes — define what fraction of traffic is A, AAAA, ANY, or garbage qtypes, instead of a flat round-robin.</li>
Scriptable profiles — a small Lua surface for generating query names and timing dynamically, instead of replaying a static wordlist.</li>

Per-worker pacing — smooth a target QPS across workers instead of bursting, useful for testing RRL tuning rather than just raw capacity.</li> </ul>
Example profile</h2>
profile.qtypes = { A = 0.6, AAAA = 0.25, ANY = 0.05, NXDOMAIN = 0.10 } profile.qname = function(i) return "load-" .. (i % 50000) .. ".bench.test." end</code></pre>Availability</h2> 0.9 is in internal testing now. See BoronGun</a> for the current stable docs, and watch this feed for the release announcement.

BoronDNS 1.0.0-beta.1 released 2026-06-13T00:00:00+00:00 We're happy to announce the first public beta of BoronDNS. What's in beta.1</h2> Zone transfers — AXFR and IXFR, with incremental diff tracking</li> Zone Transfer over TLS (XoT, RFC 9103) — encrypted transfers end-to-end</li> DNS cookies (RFC 9018) — stateless client verification</li> Response Rate Limiting (RRL) — per-client and per-prefix limits</li> TSIG authentication — HMAC-SHA256 and HMAC-SHA512 for all transfers</li> Zero-allocation query path — no heap allocations per answered query</li> </ul> Known limitations in beta.1</h2> No NOTIFY support yet (planned for 1.0.0)</li> Metrics endpoint is HTTP only (HTTPS in 1.0.0)</li> borondnsctl reload</code> requires a full restart on some platforms</li> </ul> Installing</h2> cargo install borondns</code></pre> See the Quick Start guide</a> for full setup instructions. What comes next</h2> The 1.0.0 stable release will add NOTIFY, a Prometheus metrics endpoint over HTTPS, and verified packages for Debian, Ubuntu, and Alpine. Full changelog on GitHub</a>. Hardening advisory: tighten default RRL thresholds before you expose port 53 2026-05-18T00:00:00+00:00 This is a hardening advisory, not a vulnerability disclosure — but it's important enough that we're putting it in the news feed rather than burying it in the docs. The issue</h2> BoronDNS ships with conservative RRL (Response Rate Limiting) defaults so that legitimate high-volume resolvers — large public DNS, corporate forwarders — don't get throttled out of the box: [rrl] responses_per_second = 25 window_seconds = 5</code></pre> On an open, internet-facing secondary, these defaults leave headroom that can be used to amplify reflection traffic before the limiter engages. They're fine behind a network ACL or for internal-only deployments. They are not what we'd recommend for a publicly reachable authoritative server. What to change</h2> For any secondary reachable from the open internet, we recommend: [rrl] responses_per_second = 5 window_seconds = 2 slip = 2 exempt_prefixes = ["YOUR_MONITORING_CIDR/24"]</code></pre> See Security Hardening</a> for the full checklist, including the matching firewall and exempt_prefixes</code> guidance. Will the defaults change?</h2> We're evaluating tightening the shipped defaults in a future release. Until then, treat this as a required step in your rollout checklist, not an optional tuning knob. Why we built a secondary-only DNS server 2026-04-02T00:00:00+00:00 Most authoritative DNS servers try to do everything: primary and secondary, dynamic updates, DNSSEC signing, sometimes even recursive resolution bolted on as an afterthought. BoronDNS does one thing. The constraint</h2> BoronDNS only ever serves zones it received via AXFR/IXFR from an upstream primary. It never accepts dynamic updates, never signs zones, and has no notion of "primary" mode. That sounds like a limitation — it's actually the point. Smaller attack surface. No update path means no update-injection class of bugs.</li> Simpler mental model. A zone on disk either matches the primary or it's actively transferring. There's no third state.</li> Predictable performance. Every query path is a lock-free read against an immutable snapshot — no contention with writers, because there are no writers in the serving path.</li> </ul> What this means for you</h2> If you need a primary nameserver, run BIND, Knot, or PowerDNS upstream and point BoronDNS at it as a secondary fleet. That's the deployment model we optimize for, and it's why the Quick Start guide</a> assumes an existing primary from line one. What's next</h2> We're not adding primary-mode support. We are working on wider RFC coverage and a faster zone-reload path — see Implemented RFCs</a> for where things currently stand.

What comes next</h2>
The 1.0.0 stable release will add NOTIFY, a Prometheus metrics endpoint over HTTPS, and verified packages for Debian, Ubuntu, and Alpine.</p>
Full changelog on GitHub</a>.</p>

`Will the defaults change?</h2> We're evaluating tightening the shipped defaults in a future release. Until then, treat this as a required step in your rollout checklist, not an optional tuning knob.</p>`

What this means for you</h2>
If you need a primary nameserver, run BIND, Knot, or PowerDNS upstream and point BoronDNS at it as a secondary fleet. That's the deployment model we optimize for, and it's why the Quick Start guide</a> assumes an existing primary from line one.</p>

What's next</h2>
We're not adding primary-mode support. We are working on wider RFC coverage and a faster zone-reload path — see Implemented RFCs</a> for where things currently stand.</p>

BoronDNS - News

BoronGun 0.9 preview: scriptable attack profiles

Availability</h2>
0.9 is in internal testing now. See BoronGun</a> for the current stable docs, and watch this feed for the release announcement.</p>

BoronDNS 1.0.0-beta.1 released

Hardening advisory: tighten default RRL thresholds before you expose port 53

Why we built a secondary-only DNS server

BoronDNS - News

BoronGun 0.9 preview: scriptable attack profiles

Availability</h2> 0.9 is in internal testing now. See BoronGun</a> for the current stable docs, and watch this feed for the release announcement.</p>

BoronDNS 1.0.0-beta.1 released

Known limitations in beta.1</h2> No NOTIFY support yet (planned for 1.0.0)</li> Metrics endpoint is HTTP only (HTTPS in 1.0.0)</li>

What comes next</h2> The 1.0.0 stable release will add NOTIFY, a Prometheus metrics endpoint over HTTPS, and verified packages for Debian, Ubuntu, and Alpine.</p> Full changelog on GitHub</a>.</p>

Hardening advisory: tighten default RRL thresholds before you expose port 53

The issue</h2> BoronDNS ships with conservative RRL (Response Rate Limiting) defaults so that legitimate high-volume resolvers — large public DNS, corporate forwarders — don't get throttled out of the box:</p>

Will the defaults change?</h2> We're evaluating tightening the shipped defaults in a future release. Until then, treat this as a required step in your rollout checklist, not an optional tuning knob.</p>

Why we built a secondary-only DNS server

The constraint</h2> BoronDNS only ever serves zones it received via AXFR/IXFR from an upstream primary. It never accepts dynamic updates, never signs zones, and has no notion of "primary" mode. That sounds like a limitation — it's actually the point.</p>

What this means for you</h2> If you need a primary nameserver, run BIND, Knot, or PowerDNS upstream and point BoronDNS at it as a secondary fleet. That's the deployment model we optimize for, and it's why the Quick Start guide</a> assumes an existing primary from line one.</p>

What's next</h2> We're not adding primary-mode support. We are working on wider RFC coverage and a faster zone-reload path — see Implemented RFCs</a> for where things currently stand.</p>

Availability</h2>
0.9 is in internal testing now. See BoronGun</a> for the current stable docs, and watch this feed for the release announcement.</p>

What comes next</h2>
The 1.0.0 stable release will add NOTIFY, a Prometheus metrics endpoint over HTTPS, and verified packages for Debian, Ubuntu, and Alpine.</p>
Full changelog on GitHub</a>.</p>

`Will the defaults change?</h2> We're evaluating tightening the shipped defaults in a future release. Until then, treat this as a required step in your rollout checklist, not an optional tuning knob.</p>`

What this means for you</h2>
If you need a primary nameserver, run BIND, Knot, or PowerDNS upstream and point BoronDNS at it as a secondary fleet. That's the deployment model we optimize for, and it's why the Quick Start guide</a> assumes an existing primary from line one.</p>

What's next</h2>
We're not adding primary-mode support. We are working on wider RFC coverage and a faster zone-reload path — see Implemented RFCs</a> for where things currently stand.</p>