1. What OxideDNS is

OxideDNS is a secondary-only authoritative DNS server, written from the ground up in Rust. It loads zone data from your existing primary name servers over IXFR or AXFR, holds the active zone state in memory, and answers authoritative queries over UDP and TCP. That is the whole of its job. It is deliberately not a recursive resolver, a forwarder, a primary, or a signer — it never originates, resolves, forwards, or signs DNS data, but re-serves exactly what it transfers from a primary. This narrow remit is the point, not a limitation: every capability OxideDNS does not have is also a class of code, configuration, and failure that can never affect the answers it serves.

2. Built for the architecture you already trust

Serious DNS operators have converged on a single pattern for authoritative service: a hidden primary that no resolver talks to directly, fronted by a fleet of public secondaries facing the internet. OxideDNS is built specifically for that public secondary tier. It leaves your primary — along with your zone-management tooling, signing keys, and provisioning workflow — exactly where it is, behind the scenes, and concentrates on doing the exposed job well: transferring zones securely, then serving them quickly and safely under load. For critical zones we recommend going one step further and running the hidden core as multiple independent primaries, so that no single primary is a single point of failure. OxideDNS fits into that picture without asking you to change it.

3. A smaller surface: less to patch, fewer ways to fail

Because OxideDNS contains no resolver and no primary or signing engine, whole categories of vulnerability and operational risk simply do not apply to it. There is no recursion to poison, no cache to exhaust, no signing key for it to mishandle, no dynamic-update path to abuse. What remains is implemented in Rust, where memory safety is the default — and where, in OxideDNS, it is enforced rather than merely hoped for: unsafe code is forbidden by lint across the core and server crates, and the small amount of unsafe needed for the high-rate packet path is isolated in separate components and tracked in an explicit unsafe-boundary registry.

This matters more in 2026 than it did even a year ago. LLM-assisted code analysis has begun surfacing a historic backlog of latent defects in even the most mature, most battle-tested C-language DNS codebases. ISC has been candid about this: it has delayed the BIND 9.22 release until at least the fourth quarter of 2026, citing the volume of potential vulnerabilities that LLM analysis is uncovering, and expects several more months of security-patch maintenance releases as it works through the backlog. This is no criticism of ISC — BIND is the reference implementation of the DNS, and that transparency is exemplary. It is a signal about the era we have entered. A smaller, memory-safe codebase with a deliberately narrow scope is the structural answer: there is far less surface for that class of analysis — or that class of attacker — to find anything in, and correspondingly less to patch.

4. Security and DDoS resistance, designed in

Resilience in OxideDNS is a design property, not a set of options bolted on afterwards. Within its scope it provides:

• Response Rate Limiting (RRL) and DNS Cookies (RFC 9018) to blunt UDP floods, reflection, and spoofing — including staged cookie-secret rollover for load-balanced and anycast fleets.
• Authenticated, encrypted transfers: TSIG (RFC 8945) and zone transfer over TLS 1.3 (XoT, RFC 9103), with optional mutual TLS and no cleartext fallback.
• Fail-closed publication: a transferred zone that cannot be compiled and served cleanly is rejected outright, never served half-applied.
• Runtime hardening: irrevocable privilege drop, process hardening, and a read-only runtime posture, so a worker handling untrusted packets starts from minimal privilege.

The throughput figures in the next section are themselves a measurement of behaviour under flood-scale load.

5. Performance — the raw numbers

We publish our benchmark data and let you draw your own conclusions. On an internal two-host bench — two machines on a directly attached 25 GbE link — OxideDNS was measured against Knot DNS and NSD on identical zone data and an identical query mix, in plain UDP socket mode:

Conditions: Intel Xeon Gold 6246 server, Mellanox mlx5 25 GbE NICs, 5-second measurement windows, the same querydb across all three servers. These are indicative figures from an internal lab on an earlier build; current builds perform at least as well, and a formal reference-hardware benchmark is part of our remaining release work. Full methodology and the per-row raw results are published at oxidedns.com.

6. Engineered in the open

OxideDNS is developed document-first and in public. Its design record is open for inspection: a full Software Requirements Specification, an architecture document, the data-plane memory and I/O design that underpins its performance, the test plan, an honest RFC-compliance matrix that states plainly where each area is fully versus partially covered, a requirement-to-code traceability matrix, and the release evidence behind each build. The software is dual-licensed under MIT or Apache-2.0 — permissive, with no strings — and the project is built in the open. For an audience that has to justify what it runs, that auditability is the point: you need not take our word for any claim in this brief, because you can read the evidence.

At a glance

7. Maturity and roadmap

We are confident in the quality of what we have built. OxideDNS is engineered to the standard required for critical authoritative service, and we will shortly publish the release intended for exactly that role. We are equally clear about what responsible delivery of critical-infrastructure software requires: independent security audits and a multi-month period of field validation alongside real operators have still to be completed. Until they are, we will not yet recommend OxideDNS for critical production deployment — and we would rather say so plainly than rush you. That is precisely why we are inviting DNS operators to take part as beta testers now: to put OxideDNS in front of real primaries, real zone counts, and real traffic, and to help us reach that green light with evidence rather than assertion.

Support and where to start

Support is available from INTEGRITY Ltd. on an ad-hoc or subscription basis. Learn more, download builds, and read the full documentation and benchmark methodology at oxidedns.com; the project's open community lives at oxidedns.org. To take part in the beta, or to report a security issue, contact security@integrity.hu.

OxideGun is a DNS-over-UDP load generator, written in Rust. It is the tool we use to produce OxideDNS's release benchmark evidence — and the same harness measured Knot DNS and NSD on identical hardware, so the numbers are comparable rather than self-serving. OxideGun is support tooling: it is deliberately not an OxideDNS server component, a resolver, or a production traffic generator.

What makes it different

Its core value is something ordinary socket-based load tools cannot do well: controlled source-address and source-port generation at line rate. Using Linux AF_XDP, OxideGun can drive traffic from a wide, deterministic spread of source IPs and ports — exactly what you need to exercise Response Rate Limiting (RRL), anycast and RSS tuple spread, and spoofed-source flood scenarios realistically. DNS queries are generated RFC-correctly (RFC 1035), with EDNS0 / DNSSEC-OK signalling and deterministic query pools, so a run is a defined experiment rather than approximate noise.

Two backends, one binary

• Portable UDP (default): runs without root. Intended for CI, development, and sanity checks — DNS packet generation, response classification, TOML configuration, and JSON summaries. A self-test needs nothing special:
  $ cargo run -p oxide-gun -- --self-test --max-packets 8 --target-qps 1000
• Linux AF_XDP (lab): line-rate, zero-copy-capable TX/RX through AF_XDP UMEM rings. Adds source-address strategies (random CIDR, sequential ranges, explicit lists), source-port spread for RSS, kernel-side reply drop via a Rust eBPF object (or userspace suppression), latency percentiles, and per-class response accounting. The same statically linked binary ships in OxideDNS release archives, so a lab host runs exactly the binary behind the published evidence.

Measurement you can trust

OxideGun is built so you don't have to take a headline number on faith. Every lab run can record OxideGun's own TX/RX counters alongside the NIC's counters (ip -s link, ethtool -S); preflight rejects loopback and default-route interfaces, and a saturation_claim_allowed gate must read true before any saturation claim is permitted. Runs are deterministic (--seed), summaries are machine-readable JSON (requested vs. achieved QPS, response-class counters, unanswered count, latency percentiles), and completed evidence directories are packaged with a SHA-256 manifest. The result is reproducible: the methodology and raw rows behind OxideDNS's benchmarks can be re-run and checked.

Honest about scope

OxideGun is a lab instrument, not a production traffic generator. The AF_XDP backend needs a dedicated test interface, CAP_NET_RAW or root, a correct target MAC, and an isolated network where the chosen source range routes back to the host. IPv4 is the primary path today; broader IPv6 source-pool parity and ARP-based target-MAC discovery are still in progress. Like OxideDNS itself, OxideGun is pre-1.0 — capable and already doing real work, with some surface still settling.

Where to find it

OxideGun is part of the OxideDNS project, dual-licensed under MIT or Apache-2.0, and shipped with OxideDNS releases. Documentation, the requirements specification, and full benchmark methodology live at oxidedns.com; the open community is at oxidedns.org.

Quickstart — first zone in 5 minutes

1. Download the static binary or the installer archive, or load the Docker image.
2. Describe each secondary zone in a TOML config file — primaries, TSIG keys, XoT trust, and listener addresses.
3. Validate the config, then start the server and watch the first transfer reach ACTIVE.

System requirements

Reference & knowledgebase

• Configuration reference — every TOML key, with secure defaults.
• Hardening checklist — fail-closed transfers, TSIG/XoT, RRL and DNS Cookies.
• RFC compliance matrix — the standards OxideDNS implements, and how far.
• Changelog & support lifecycle — what changed and which series get fixes.
• Security & engineering evidence — coverage, fuzzing, evidence and disclosures.

The company

OxideDNS grew out of INTEGRITY Ltd.'s own need for a hardened, memory-safe secondary that does exactly one job and nothing else. More at integrity.hu.

The team

OxideDNS is built by INTEGRITY's DNS and systems engineers, with development happening in the open.

No cookies, no tracking, no forms

We do not use cookies, analytics or any third-party tracking, and this site has no input fields or forms. Simply browsing these pages does not cause any personal data about you to be collected or stored by us.

If you contact us by email

You can reach us by email at office@integrity.hu. If you write to us, we process the data you choose to send (such as your email address and the content of your message) only to handle your enquiry, and we keep that correspondence only for as long as it is needed for that purpose.

Controller and your rights

The data controller is INTEGRITY Ltd.; full company details are in the imprint. Under the GDPR you have the right to access, rectification, erasure, restriction, portability and objection, and you may lodge a complaint with the Hungarian supervisory authority (NAIH).