Markdown source
massdns Has No --max-queries or QPS Flag Markdown source
Readable source view for humans. The raw Markdown endpoint remains available for crawlers and agent readers.
---
title: "massdns Has No --max-queries or QPS Flag"
description: "massdns has no --max-queries or QPS flag, and -q just means quiet. What actually shapes throughput: -s concurrency, resolver count, and --processes."
kind: snippet
maturity: budding
confidence: high
origin: ai-drafted
author: "Agent"
directedBy: "krow"
tags: [dns, networking, reference, rate-limiting]
published: 2026-05-10
modified: 2026-06-13
wordCount: 838
readingTime: 4
related: [go-dns-scanner-4000qps, aimd-rate-limiting, dns-resolution-full-picture]
url: https://krowdev.com/snippet/massdns-rate-limit-flags/
---
## Agent Context
- Canonical: https://krowdev.com/snippet/massdns-rate-limit-flags/
- Markdown: https://krowdev.com/snippet/massdns-rate-limit-flags.md
- Full corpus: https://krowdev.com/llms-full.txt
- Kind: snippet
- Maturity: budding
- Confidence: high
- Origin: ai-drafted
- Author: Agent
- Directed by: krow
- Published: 2026-05-10
- Modified: 2026-06-13
- Words: 838 (4 min read)
- Tags: dns, networking, reference, rate-limiting
- Related: go-dns-scanner-4000qps, aimd-rate-limiting, dns-resolution-full-picture
- Content map:
- h2: TL;DR — the flags that exist (and the ones that don't)
- h2: Why there's no QPS knob
- h2: Common confusions
- h2: Sane starting values
- h2: If you genuinely need a hard QPS ceiling
- h2: Sources
- Crawl policy: same canonical content is exposed through HTML, Markdown, and llms-full; no crawler-specific content gate.
If you came here searching for `massdns --max-queries`, `massdns -q 1000`, or "massdns maximum queries per second" — the short answer is that **massdns has no flag that caps queries per second.** There is no `--max-queries`, no `--max-qps`, no `--qps`. And `-q` is the *quiet* flag, not a rate limit. Throughput in massdns is an emergent property of concurrency and parallelism, not a number you set directly. Here's what actually controls it.
## TL;DR — the flags that exist (and the ones that don't)
| Flag | Long form | Default | What it actually does |
|---|---|---|---|
| `-q` | `--quiet` | off | **Quiet mode** — suppresses the status line. **Not** queries-per-second. |
| `-s N` | `--hashmap-size N` | 10000 | **Concurrent in-flight lookups** (the slot pool). The main throughput knob. |
| `-i N` | `--interval N` | 500 | Milliseconds to wait before re-resolving an unanswered name. |
| `-c N` | `--resolve-count N` | 50 | Attempts per name before giving up. |
| — | `--processes N` | 1 | Resolver processes (fork-based parallelism). |
| — | `--socket-count N` | 1 | Sockets per process. |
| `-r FILE` | `--resolvers FILE` | required | Resolver list. Real-world rate is divided across these. |
Flags people Google that **do not exist**: `--max-queries`, `--max-qps`, `--qps`, `--maximum-queries-per-second`. None of them are real. (Verified against the massdns `--help` output and source — there is zero occurrence of "qps" in the codebase.)
## Why there's no QPS knob
massdns is built to go *as fast as the slot pool and the network allow*. The event loop sends a new query whenever a socket is writable and a slot is free, and matches responses back by `(domain, type)`. There is no token bucket, no per-second governor. So "rate" is really three things multiplied together:
1. **Concurrency** — `-s` (`--hashmap-size`): how many queries can be outstanding at once. This is the closest thing to a throttle. A smaller hashmap means fewer in-flight queries means lower effective QPS.
2. **Parallelism** — `--processes` and `--socket-count`: how many workers and sockets push packets.
3. **Resolver fan-out** — the `-r` list: queries are spread across resolvers round-robin, so 4000 effective qps over 20 resolvers is 200 qps each (and most public resolvers rate-limit you well below that).
There's no single dial for "1000 queries per second." You shape it with `-s` and the resolver list, then watch the live status counter.
## Common confusions
**`-q` is quiet, not queries.** This is the one that bites people. `-q`/`--quiet` silences the real-time status output. It has nothing to do with rate. The visual similarity to a hypothetical "qps" flag is the whole trap.
**In-flight concurrency ≠ queries per second.** `-s 10000` allows 10,000 *unanswered* queries at any instant. With fast resolvers that's a high QPS; with slow ones the pool fills and stalls long before you'd call it "10,000 per second." If throughput feels capped, raising `-s` is what unblocks it — not a QPS flag, because there isn't one.
**Resolver count is the real-world ceiling.** A short or unhealthy `-r` list throttles you no matter how high `-s` goes. The [Public DNS Server List](https://public-dns.info/) is a common starting point, though most entries are unstable — curate aggressively.
## Sane starting values
```bash
massdns \
-r resolvers.txt \
-t A \
-o S \
-s 10000 \
-i 500 \
domains.txt > results.txt
```
- `-s 10000` (default) — fine for most workloads; raise to 50000+ for slow resolvers or WAN-heavy lookups, lower it to *reduce* effective throughput when you're being too aggressive.
- `-i 500` — 500 ms retry interval; lower for fast local resolvers, raise (1000–2000) when hammering public infrastructure.
- `-o S` — simple text output (the valid output flags are `L`, `S`, `F`, `B`, `J`).
To go wider, add `--processes` and a longer resolver list rather than reaching for a rate flag that doesn't exist.
## If you genuinely need a hard QPS ceiling
massdns won't enforce one, so you have three options:
1. **Throttle indirectly** — shrink `-s` and the resolver list until the live counter sits where you want. Crude but works.
2. **Rate-limit upstream** — put massdns behind a forwarder or pipe its input through a pacer so packets leave at a fixed rate.
3. **Use an adaptive scanner** — if you don't know the safe ceiling in advance, the [AIMD rate limiting](/note/aimd-rate-limiting/) pattern (TCP congestion control applied to a DNS scanner) discovers it by backing off on errors and probing upward on success. For the architecture behind a custom Go scanner that does this — and why a single multi-goroutine process can match massdns's per-thread efficiency — see [Building a High-Throughput DNS Scanner in Go](/article/go-dns-scanner-4000qps/).
## Sources
- [massdns `--help` / source](https://github.com/blechschmidt/massdns/blob/master/src/main.c) — authoritative flag list (B. Blechschmidt). No `qps` / `max-queries` option exists.
- [massdns README](https://github.com/blechschmidt/massdns#usage) — usage reference.
- [zdns](https://github.com/zmap/zdns) — Go-based alternative from ZMap; different flags, same problem space.
- [DNS Resolution: The Full Picture](/guide/dns-resolution-full-picture/) — what's happening behind each query.