Racing the Resolver

## The situation "Off-path" means the attacker has no position on the network path between the resolver and the authoritative servers it queries. They cannot see the query leave, cannot read any of its fields, and cannot delay or drop the real answer. All they can do is send packets from anywhere on the internet with a forged source address, hoping one is mistaken for the answer the resolver is waiting for. That is a very different problem from sitting on the wire, and the difference is entirely made of guessing. ## What the resolver is actually matching When a recursive resolver needs a name it does not hold, it sends a UDP query and records what it is waiting for. An arriving datagram is only considered as the answer to that query if all of the following line up: - **Source IP address** equal to the authoritative server the resolver chose to ask. A zone usually publishes several nameservers, so the attacker must forge the source address of the *right* one, or spray all of them. - **Source port 53** on that server, and **destination port** equal to the ephemeral port the resolver used for this query. Modern resolvers pick that port at random per query; historically many used one fixed port for their whole lifetime, which is the change that made this attack hard. - **The 16-bit message ID** (often called the transaction ID) carried in the DNS header, chosen at random per query. Sixteen bits is 65,536 possibilities. - **The question section** — the same owner name, type and class the resolver asked about. The attacker generally knows this, because they chose the name they want to poison. A common extra is *case randomisation of the queried name*: the resolver sends the name with the case of each letter chosen at random and requires the echoed question to match exactly. Servers are supposed to copy the question verbatim, so a genuine answer passes and a forger who normalises the name to lowercase does not. It adds roughly one bit per letter, and only against servers that faithfully preserve case. Anything that fails these checks is dropped. There is no error, no negotiation, no second chance for that packet. ## Why it is a race and not a puzzle The window is not "until the attacker gives up". It is the interval between the resolver sending its query and the genuine answer coming back — typically tens to a couple of hundred milliseconds. When the real answer arrives and matches, the resolver takes it, retires the outstanding query and serves the result. A forged packet that arrives one second later matches nothing: there is no query in flight for it to answer. It does not overwrite anything, and it is not cached alongside the real record. This is the single most common misconception about the attack — that a later, louder forgery wins. It does not; it is simply late. Because the resolver now holds the genuine answer, the attacker also cannot immediately try again for that same name: the resolver will serve from its own copy rather than asking again, so a fresh race requires a fresh outbound query. ## What this contrasts with An attacker who *is* on the path has none of these problems. They read the ephemeral port and the message ID straight off the wire and copy them into a reply, and they can be faster than the real server because they are closer. Everything above is what remains once you take that position away. Confusing the two is the classic interview slip: describing an on-path interception while claiming to describe off-path spoofing. ## What the check does and does not buy The matching rules are not authentication. Nothing in a plain DNS response proves the answering server holds the zone; the resolver is only checking that the packet looks like a reply to a question it asked. The defence is entirely statistical — it makes a correct guess unlikely, not impossible — which is why the interesting version of this question is not "can it be forged" but "how many guesses does it cost, and is there something cheaper the attacker could buy instead".