skip to content

How much entropy must an off-path DNS forger beat inside one query's lifetime?

level: middleimportance: should knowfreq 47%

answer

  1. count it in bits, then in packets
  2. sixteen bits plus the ephemeral port
  3. the window is one round-trip
  4. odds per race are guesses over combinations
  5. attempts throttle harder than bandwidth

basics

~10 s

Roughly 2^30 to 2^32: a 16-bit message ID times 14 to 16 bits of ephemeral-port randomisation, all inside one round-trip. A gigabit of forgeries buys odds near one in tens of thousands per race.

solid answer

~50 s

Price it as a budget. The message ID is 16 bits, so 65,536 values. The source port is drawn from an ephemeral range of typically tens of thousands of ports, so another 14 to 16 bits. Combined that is roughly one to four billion combinations, and the attacker may also have to pick the right one of the zone's several authoritative servers to spoof. The window is one round-trip — call it 100 ms. A forged response is around 100 bytes on the wire, so a gigabit uplink pushes on the order of a million packets a second, meaning about a hundred thousand distinct guesses land inside the window. That is roughly a one-in-thirty-thousand chance per race. So bandwidth is not the binding constraint; **attempts** are. The attacker needs tens of thousands of fresh races, and each race needs the resolver to be asking that question again.

go deeper

for a junior

Know the two numbers that make up the guess space: a 16-bit message ID and a randomly chosen source port from a range of tens of thousands, and that both must be right in the same packet.

for a middle

Do the arithmetic out loud — combinations, window length, packets per second, odds per race — and state which term dominates. Say explicitly that guesses land only while a query is outstanding.

for a senior

Judge whether the entropy the software chose actually reaches the wire. NAT port rewriting, forwarders reusing a socket and weak generators are what turn a theoretical 2^32 into a practical 2^16.

for a principal

Be able to convert the budget into a decision: what sustained multi-gigabit traffic for hours costs an adversary, and whether an objective priced that high is one they would ever buy this way.

## Turning the attack into arithmetic The useful way to think about off-path answer forgery is as a purchase: how much traffic, over how long, buys one accepted forgery? Every term in that sum is knowable, so the question is answerable on a whiteboard. ### The entropy on offer - **Message ID: 16 bits.** Fixed by the protocol header. 65,536 values, and a resolver that picks them with a weak generator effectively has fewer. - **Source port: 14 to 16 bits in practice.** A resolver that randomises the ephemeral port per query draws from a range of tens of thousands of ports — roughly 2^14 to 2^16 depending on the range configured. Historically resolvers bound one socket and used a single port for their entire uptime, which reduced this term to zero and is exactly why per-query randomisation became the baseline recommendation. - **Which server was asked.** A zone typically publishes two to six authoritative nameservers. The resolver picks one, often by measured responsiveness, and the forged packet's source address must match that choice — a couple of bits, or a couple of times more traffic if the attacker sprays all of them. - **Question-name case, where used.** Random capitalisation of the queried name, echoed verbatim by a compliant server, adds roughly one bit per letter, but only against servers that preserve case. Multiply the first two and you get the number everyone quotes: about 2^32, four billion combinations, in the good case; nearer 2^30 with a narrow ephemeral range. ### The window The race is not open-ended. It runs from the moment the resolver emits its query to the moment the genuine reply arrives and retires the outstanding state. For an authoritative server a continent away that is perhaps 100 to 200 ms; for a nearby one it can be 20 ms. A shorter round-trip is a *smaller* target for the attacker, which is a slightly counter-intuitive consequence: a fast, well-connected zone is harder to race than a slow one. ### The per-race odds A minimal forged DNS response for a short name is on the order of 100 bytes on the wire including link, IP and UDP overhead. One gigabit per second is therefore roughly a million packets per second — call it 100,000 distinct guesses inside a 100 ms window, assuming the attacker never repeats a guess and can actually sustain line rate at the target. With N combinations and n distinct guesses landed inside the window, the chance of success in one race is about n/N. Here that is 100,000 / 4,300,000,000, or roughly one in forty thousand. Ten gigabits improves it to about one in four thousand. Expected races before a hit is N/n — tens of thousands, in the good case. ### Why the binding constraint is attempts, not bandwidth This is the part candidates miss. Bandwidth only fills one window. To fire another shot the attacker needs the resolver to have another query for that name in flight — and after a successful legitimate lookup the resolver serves its own copy instead of asking again, so a naive attacker is throttled to one attempt per expiry of the record. At one attempt per record lifetime, tens of thousands of attempts is not hours, it is years. The constructions that made this attack famous are precisely the ones that break that throttle by getting the resolver to keep asking, and they are what turned an implausible race into a practical one. So the honest budget line reads: *sustained multi-gigabit traffic at a specific resolver, held for hours, plus a reliable way to force repeated lookups, plus the target resolver not de-randomising anything, plus nobody noticing hours of spoofed-source flood.* That is not free, and it is not stealthy. ### Where the entropy quietly collapses The arithmetic assumes the randomness survives the path, and sometimes it does not: - A NAT device or middlebox between the resolver and the internet may rewrite the source port into a small or sequential range, destroying most of the port entropy no matter what the resolver chose. - A stub or branch resolver that forwards everything to an upstream may reuse a single socket, so the port term goes to zero on that hop. - A weak ID generator with a predictable sequence turns 16 bits into a handful. When one of those holds, the real N is nearer 2^16 than 2^32, and 100,000 guesses in one window is no longer a lottery ticket — it is a near certainty. That is why the correct answer to "how much entropy" is always "how much *actually reaches the wire*", not "how much the software intended". ### The comparison that finishes the answer Having priced the race in gigabit-hours, the follow-through is to notice what that money buys elsewhere. The objective is not to win a race; it is to be believed as the authority for a name. Changing the delegation at the registry achieves that permanently, for every resolver in the world, with no packets and no entropy — which is why this arithmetic, done honestly, usually argues *against* the technique rather than for it.

  • Where can the port entropy be lost without the resolver knowing?
    On the path out. A NAT or middlebox that rewrites source ports into a narrow or sequential range replaces the resolver's random choice with a predictable one, and a forwarding resolver that reuses a single socket has no per-query port at all. In both cases the effective combination count collapses towards 2^16 and the race becomes winnable in a single window.
  • Does a faster authoritative server help or hurt the attacker?
    It hurts them. The race ends when the genuine reply arrives, so a short round-trip is a smaller window and fewer guesses fit into it. A slow or distant authoritative server, or one under load, widens the target — which is why deliberately slowing the real answer is a lever an attacker would like and an off-path one mostly does not have.
  • Why does a successful legitimate lookup make the attacker's life much worse?
    Because the resolver then answers from its own copy rather than querying again, so there is no new outstanding query to race. Without a way to force repeated lookups the attacker gets roughly one attempt per record lifetime, and tens of thousands of attempts at that rate is not a feasible campaign.

saying these in an interview costs you the question

  • Quotes 16 bits and forgets the source port entirely
  • Says enough bandwidth makes success certain in one window
  • Ignores that each race needs a fresh outstanding query
  • Assumes the randomisation always survives NAT and forwarders
  • Treats 2^32 as a proof of impossibility rather than a price

context