Skip to content
a DNS performance and functional testing utility (by @ns1)
C++ Other
  1. C++ 99.8%
  2. Other 0.2%
Branch: master
Clone or download
weyrick Merge pull request #16 from DNS-OARC/remote-ldns-rcv
remove use of ldns for parsing replies
Latest commit 0d30e38 Jul 11, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
3rd OSS import Jan 7, 2019
ci Updated the Dockerfile to output a smaller image thanks to @fcelda, a… Apr 16, 2019
flame from review: simplify Jul 11, 2019
man doc: add manual page for flame Feb 6, 2019
tests OSS import Jan 7, 2019
.clang-format OSS import Jan 7, 2019
.gitignore Ignore all build* subdirs. Feb 13, 2019
.travis.yml Add GnuTLS to Travis Linux build pre-requisites. Mar 1, 2019
CMakeLists.txt use 0.10.0 instead due to new feature Mar 13, 2019

Flamethrower Build Status

A DNS performance and functional testing utility.

2017-2019 © NSONE, Inc.


This code is released under Apache License 2.0. You can find terms and conditions in the LICENSE file.


Flamethrower is a small, fast, configurable tool for functional testing, benchmarking, and stress testing DNS servers and networks. It supports IPv4, IPv6, UDP and TCP, and has a modular system for generating queries used in the tests.

It was built as an alternative to dnsperf (, and many of the command line options are compatible.


  • CMake >= 3.8
  • Linux or OSX
  • libuv >= 1.23.0
  • libldns >= 1.7.0
  • gnutls >= 3.3
  • C++ compiler supporting C++17


CMake based, requires libuv and ldns.

mkdir build; cd build
cmake ..

Docker based, requires a recent version of docker.

docker build --network host -t ${org}/${image}:${tag} -f Dockerfile .
docker run --rm -it --net host ${org}/${image}:${tag} --help


Current command line options are described with:

flame --help

Quick Examples

Flame localhost port 53, UDP, maximum speed:

flame localhost

Flame target, port 5300, TCP:

flame -p 5300 -P tcp

Flame target, port 443, TCPTLS:

flame -p 443 -P tcptls

Flame target with random labels:

flame -g randomlabel lblsize=10 lblcount=4 count=1000

Flame multiple target at once, reading the list from a file:

flame file --targets myresolvers.txt

Detailed Features

Query Generators

Flamethrower uses a modular system for generating queries. Most modules generate all queries before sending begins, for performance reasons. Each module may include its own list of configuration options which can be set via key/value pairs on the command line. See full --help for the current list of generators and their options.

Rate Limiting

By default, Flamethrower will send traffic as fast as possible. To limit to a specific overall queries per second, use -Q

Dynamic QPS Flow

Flamethrower can adjust its QPS flow over time. This is useful for generating a "signal" of traffic (e.g. a square wave) for calibrating metrics collection. For example, to send 10 QPS for 120000ms, then 80 QPS for 120000ms, etc use --qps-flow "10,120000;80,120000;10,120000;". Flow change will not loop, you should list as many changes as necessary. Once the flow reaches the final QPS number, it will hold it until program termination.

Output Metrics

Flamethrower can generate detailed metrics for each of its concurrent senders. Metrics include send and receive counts, timeouts, min, max and average latency, errors, and the like. The output format is JSON, and is suitable for ingestion into databases such as Elastic for further processing or visualization. See the -o flag.


Flamethrower is single threaded, async i/o. You specify the amount of concurrent senders with the -c option. Each of these senders will send a configurable number of consecutive queries (see -q), then enter a configurable delay period (see -d) before looping.

Each concurrent sender will pull the next query from the total queries generated by the Query Generator, looping once it reaches the end of the query list (if the program is configured to continue).

There is currently no built-in support for multiprocess sending, so the maximum throughput will be reached once a single CPU is saturated. However, you may manually start several concurrent flame processes, including up to 1 per CPU available. There is future planned support for builtin multiprocess sending.

You can’t perform that action at this time.