The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Flamethrower is an open-source command-line traffic generator for testing DNS servers and networks. It sends configurable DNS requests over IPv4 or IPv6 using UDP, TCP, DNS over TLS (DoT), or DNS over HTTPS (DoH), then reports response counts, timeouts, latency, and errors. It is an operator and developer tool—not a consumer “fastest DNS” checker—so useful results depend on a realistic workload and a test host powerful enough to generate it.
The project describes itself as “a small, fast, configurable tool for functional testing, benchmarking, and stress testing DNS servers and networks.” See the upstream README for the current release, syntax, and examples.
What Flamethrower tests
Flamethrower can exercise an individual resolver, authoritative server, network path, or encrypted DNS endpoint. Its documented transports are:
- IPv4 and IPv6
- DNS over UDP and TCP
- DNS over TLS (DoT)
- DNS over HTTPS (DoH), using HTTP GET or POST
Queries are produced by modular generators. The README demonstrates generated random labels and loading multiple targets from a file, allowing a test to model more than one fixed name or destination. The generator you choose is part of the experiment: a cache-friendly repeated name and a stream of random names measure very different resolver behavior.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors#1 Best Overall
- Performance Tests – Acts as a mobile plug-and-play iPerf3 server for network throughput and performance testing. Measure network speeds against one test point.
- Powered by batteries or PoE for 24/7 availability, for local or remote locations.
- One-button, tri-state LED interface
- Provides simple network port tests (PoE, Link, DHCP, DNS, Gateway, and Internet) and sends results to Link-Live.com.
- Measures upload and download TCP/UDP throughput, packet loss, and jitter.
How its traffic controls work
Uncapped and fixed-rate sending
Without a rate limit, Flamethrower sends as quickly as its event loop, CPU, sockets, network, and destination allow. Use -Q to set an overall target queries-per-second rate when you need controlled load rather than maximum pressure.
Changing the rate over time
--qps-flow schedules different rates for specified durations. The project README illustrates 10 queries per second for 120,000 ms, then 80 queries per second for 120,000 ms, then 10 queries per second for 120,000 ms. That sequence is an example of a traffic signal for observing saturation or calibrating monitoring; it is not a published performance result.
Concurrent senders and batches
Concurrent senders can issue work in parallel, with configurable query batches and delay behavior. Increasing concurrency can expose server limits, but it can also move the bottleneck to the generator. Record the sender count and batch settings with every run.
Machine-readable results
Per-sender JSON metrics include sends, receives, timeouts, minimum, maximum and average latency, and errors. JSON is suitable for ingesting into a time-series system or for plotting a rate ramp. Treat averages carefully: an unanswered request cannot contribute a latency sample.
Free tools Windows power users keep installed
One-click scans. No signup required.
Installation and prerequisites
Installation depends on the operating system and distribution. The upstream project recommends its public Docker image or a source build and states that it does not publish general prebuilt operating-system packages. Fedora’s package catalog separately lists Flamethrower builds for several Fedora-family releases, so package availability is distribution- and release-specific; check Fedora’s current package page for the release you use.
Building on Linux or macOS
The README lists these build requirements:
- A C++20-capable compiler
- Meson and Ninja
- pkgconf
- libuv, libldns, and GnuTLS
- nghttp2 is optional for DoH support
Use the exact source-build steps and dependency names in the project README, because package names and supported releases change. After installation, run flame --help; that output is the authoritative list of options in the binary you installed.
Docker
The Docker route avoids installing the compiler and native libraries on the host. Use the image and invocation documented by the upstream project, and ensure the container has the network access and privileges required to reach the DNS endpoint under test.
A practical test workflow
- Define the question. Decide whether you are checking correctness, transport behavior, capacity, latency under a fixed rate, or a stress limit. Specify resolver versus authoritative service, protocol, address family, and test duration.
- Prepare the workload. Choose names that represent production traffic. Use a controlled list or the documented random-label generator when testing cache misses. If multiple destinations matter, load them from a file as shown in the README.
- Validate a low-load baseline. Run a small request rate first and confirm that answers, status codes, and the selected transport are correct. A high error count at this stage indicates configuration or reachability trouble, not server capacity.
- Choose rate and concurrency. Leave sending uncapped only for a deliberate stress test. Otherwise set
-Qand, for ramps or bursts, configure--qps-flow. Note sender count, batch size, delays, and duration. - Capture JSON and system telemetry. Keep the per-sender output together with CPU, memory, socket, interface, packet-loss, and server telemetry. Preserve the exact command, software revision, query set, and network location.
- Repeat and change one variable. Compare transports or workloads only when the other conditions are held constant. Run enough repetitions to distinguish a stable effect from transient network or cache state.
Reading the results without fooling yourself
| Metric | What it tells you | Important qualification |
|---|---|---|
| Send and receive counts | How much traffic was attempted and answered | A gap can reflect server failure, network loss, client limits, or an unsuitable timeout. |
| Timeouts | Requests with no response before the configured wait | Timeouts are not latency samples; report them separately. |
| Minimum, maximum, average latency | Distribution endpoints and the mean for responses received | The average excludes requests that receive no response, so it can look healthy while loss is severe. |
| Errors | Failures reported by the client or protocol | Classify error types and correlate them with server and network logs. |
Do not turn throughput into a universal ranking. A result is credible only when the generator is not the limiting component, the path is appropriate for the question, and packet loss and timeouts are understood.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The single-process ceiling
Flamethrower uses single-threaded asynchronous I/O and has no built-in multiprocess sender mode, according to the project documentation. One sender process may saturate one CPU. If that happens, launch multiple processes manually and divide the workload, or move generation to additional hosts. Multiple processes improve offered load but also make coordination, deduplication, and result aggregation your responsibility.
Flamethrower compared with dnsperf and resperf
Flamethrower was created as an alternative to dnsperf, and its README says many command-line options are compatible. The projects serve overlapping but not identical test designs.
| Decision axis | Flamethrower | dnsperf / resperf guidance |
|---|---|---|
| Transports | IPv4/IPv6; UDP, TCP, DoT, and DoH are documented. | Consult the current project documentation for the transports supported by the version you deploy. |
| Workload generation | Modular generators, random-label example, and target files. | dnsperf documentation focuses on supplied query data; resperf is intended for caching tests against live Internet resolution. |
| Rate and flow control | -Q, --qps-flow, concurrent senders, batches, and delays. |
Options and semantics vary by tool and version. |
| Output | Per-sender JSON metrics plus command-line reporting. | Use each tool’s documented output; compare definitions before merging results. |
| Typical emphasis | Functional, transport, benchmark, and stress experiments. | dnsperf is characterized primarily as an authoritative-server performance tool; its documentation prefers resperf for caching-server tests. |
These are project descriptions, not an independent head-to-head benchmark. For dnsperf’s methodology and cautions, read the upstream dnsperf README.
Benchmark design checks
- Run the generator on a separate, sufficiently capable machine rather than on the server being measured.
- Verify that generator CPU, NIC, socket limits, and packet capture are not constraining the run.
- Measure packet loss and path congestion; loss or timeouts can make a server appear faster or slower than it is.
- Use realistic query names, sizes, cache state, response codes, and transport setup costs.
- Report unanswered requests alongside latency. A low average calculated only from successful responses is incomplete.
- State region, address family, server role, software versions, duration, rate profile, and concurrency with the result.
Origins and licensing
DNS-OARC’s record for the May 13, 2019 OARC 30 presentation identifies Jan Včelák of NS1 as speaker and primary author. It says the tool was developed at NS1, open-sourced in January 2019, and hosted on DNS-OARC’s GitHub. The current repository identifies the project as Apache License 2.0. See the OARC 30 event page for that historical account.
Recommended Free Tools
The Bottom Line
Use Flamethrower when you need programmable DNS traffic across modern transports and machine-readable measurements. For defensible capacity numbers, control the workload, prove the sender is not saturated, and publish timeouts and loss alongside latency and QPS.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
