Why is an open recursive DNS resolver dangerous, and what server-side configuration stops a DNS server being used as a traffic amplifier?
answer
- answers anyone, forged sources included
- small query, large reply
- recursion for your own clients
- limit identical responses
- truncation sends real clients to TCP
basics
~20 sAn open resolver answers anyone, so attackers send it small UDP queries forged with a victim's address and it fires large replies at the victim; it also lets outsiders trigger lookups for poisoning. Restrict recursion to your clients and rate-limit responses.
solid answer
~50 sRFC 9499 defines an **open resolver** as a full-service resolver that accepts queries from any, or nearly any, client, and notes most are probably misconfigured rather than meant to be open. Two harms follow. **Reflection**: UDP has no handshake, so an attacker sends small queries carrying a victim's forged source address and the resolver sends much larger responses - EDNS0 lifts the old 512-byte limit, and `ANY` or signed data inflate replies - to the victim. **Poisoning**: RFC 5452 section 4.1 notes an open resolver lets a third party force the exact query it wants to spoof. The fixes: offer recursion only to your own address ranges; keep authoritative servers non-recursive; apply **response rate limiting**, an implementation technique rather than an RFC mechanism, which caps identical responses per client prefix and sends some truncated with `TC` set so genuine clients retry over TCP; and return minimal `ANY` responses (RFC 8482).
go deeper
Remember that a resolver answering anyone on the internet can be tricked into sending large replies to a victim whose address the attacker forged.
Explain why UDP allows the forged source, what makes responses large, and why restricting recursion and rate limiting are the server-side answers.
Show you can configure response rate limiting sensibly - truncation to push genuine clients to TCP, awareness of false positives - and that closing recursion does not end poisoning risk.
Weigh offering resolver service beyond your own network against the reflection and poisoning exposure it creates, and decide which transports and limits your authoritative service must carry.
## What makes a resolver open A **recursive resolver** does the work of resolution for its clients; an **authoritative server** answers only for the zones it hosts. RFC 9499 defines an **open resolver** as a full-service resolver that accepts and processes queries from any, or nearly any, client. It adds that the term "public resolver" is used more for resolvers meant to be open, whereas the vast majority of open resolvers are probably misconfigured to be open. That second group is the problem: a resolver meant for one office or one customer base, reachable from the whole internet. ## Why UDP DNS reflects and amplifies Classic DNS runs over UDP, which has no handshake. The server cannot tell whether the source address on a query is real. An attacker exploits that in three steps: 1. It sends queries whose source address is forged to be the **victim's** address. 2. The resolver does its job and sends the response to that address. 3. The victim receives a stream of responses it never asked for, from resolvers it has never heard of. The attack pays because DNS responses can be much larger than the queries that trigger them: - EDNS0 (RFC 6891) lets a query advertise a UDP payload size beyond the classic 512-octet limit of RFC 1035, and an attacker advertises a large one; - `ANY` queries historically returned every RRset at a name - RFC 8482 notes they are frequently used to exploit amplification potential; - DNSSEC-signed answers and large `TXT` records add bulk. How the ratio between query and response is measured, and what it does to a victim, is the subject of attack analysis; the resolver operator's concern is not to be a source of it. ## The second harm: forced queries for poisoning RFC 5452 section 4.1 points out that a resolver needs to serve only its operator's users, and that offering full service lets a third party send the resolver a query for exactly the name it intends to spoof, opening a window of opportunity on demand. Closing recursion helps, but the RFC is candid about its limits: queries can be forced indirectly, for example by inducing a mail server to look names up, and the attacker may be a legitimate customer or employee. Closing the resolver is one layer, not the defence. ## Configuration that refuses to amplify | Control | What it does | Limit | |---|---|---| | Recursion only for your own address ranges | Outsiders get no recursive service, so they cannot use you as a reflector for arbitrary names | Insiders and forwarded clients remain | | Authoritative servers do not recurse | Keeps a server that must answer the world from also resolving for it | Authoritative answers can still be reflected | | Response rate limiting | Caps how many identical responses go to one client prefix per interval | Implementation technique, not an RFC mechanism; tuning trades false positives | | Minimal `ANY` responses (RFC 8482) | Answers `ANY` with one RRset or a synthesised `HINFO` instead of everything | Other large record types remain | | Modest EDNS UDP payload size | Bounds the size of any single UDP response | Larger answers move to TCP | ## Response rate limiting and truncation An authoritative server cannot close itself to the world - answering everyone is its job - so response rate limiting is its main tool, and resolvers can apply it too. The server notices that it is sending the same response to the same client prefix far more often than any real client would, and stops sending most of them. Instead of dropping every excess response, it answers some with the **TC** bit set and no data. A truncated reply is small, so it amplifies little; a genuine client that sees `TC` retries over TCP, which RFC 7766 makes REQUIRED for DNS servers, and a spoofer cannot complete a TCP handshake from a forged address. RFC 7766 names this among the reasons for increased TCP use, noting it is now widely used in response rate limiting. RFC 8906 warns of the cost: a client cannot tell rate limiting apart from packet loss or a server that ignores EDNS queries. ## Encrypted transports and amplification - DoT and DoH run over TCP, whose handshake proves the client's address before any DNS response is sent; RFC 8484 notes this mitigates classic amplification attacks for UDP-based DNS. - DoQ runs over UDP but inherits QUIC's address validation; RFC 9250 section 5.3 says this limits worst-case amplification to a factor of 3. - None of this helps while plain UDP port 53 stays open to the world, so the configuration above still applies.
- Why does response rate limiting send some limited responses truncated with the TC bit rather than dropping them all?A spoofed flood and a real client sharing the same source look alike to the server. A truncated reply is small, so it adds little to a flood, and a genuine client that sees `TC` retries over TCP - which a spoofer cannot complete from a forged address. Dropping everything would instead make the victim's own lookups fail.
- If you close your recursive resolver to outside addresses, is it safe from cache-poisoning attempts?Safer, not safe. RFC 5452 section 4.1 notes attackers can force queries indirectly, for example by making a mail server look names up, may themselves be legitimate customers, and can time attempts from the decreasing TTLs a resolver publishes. Keep unpredictable ports and IDs, and validate DNSSEC where zones are signed.
saying these in an interview costs you the question
- Only authoritative servers can be abused for amplification, never recursive resolvers.
- Rate limiting by source address throttles the attacker, whose address appears on the queries.
- Moving DNS clients to TCP makes reflection floods larger.
- Response rate limiting is a mechanism defined by a DNS RFC.
- An open resolver is harmless as long as its software is patched.
- Refusing ANY queries alone makes a resolver safe to leave open.