How does the attacker guess the domain name in a DNS query for DNS cache poisoning

Question

Prior to 2008 before Dan Kaminsky finds the DNS issue, the resolver checked only the Transaction ID. I have seen videos in which it is explained if an attacker manages to send a DNS response like (example.com: type A, class IN, address 192.0.2.6) to resolver before the original response from authoritative name server is received, the malicious IP address (192.0.2.6) will be cached.

But how does the attacker know which domain the client (example.com here) has searched. Or is it the attacker is also the client?

Answer 1

You understood the first part of the DNS flaw the late Daniel Kaminsky exposed, which was not really anything new in 2008. It is what was already named DNS poisoning. You can switch to the last part of the answer for your question, but I feel necessary to explain the whole thing for any other visitors.

How DNS work

When a client wants to resolve a domain name, like www.example.com they will contact their preferred Resolver (usually their ISP's) and asks what's the IP address of www.example.com. The resolver may not know and asks the Name servers:

Client                        Resolver                      Name servers
|                             |                             |
|-- IP of www.example.com? -->|                             |
|                             |-- IP of www.example.com? -->| // Root "." NS
|                             |<- Idk, ask com. ------------|
|                             |                             |
|                             |-- IP of www.example.com? -->| // "com." NS
|                             |<- Idk, ask example.com. ----|
|                             |                             |
|                             |-- IP of www.example.com? -->| // "example.com." NS
|                             |<- 93.184.216.34 ------------|
|<- 93.184.216.34 ------------|                             | // Resolver caches the data

The resolver gets the answer and caches it for the next clients.

DNS poisoning

The idea behind DNS poisoning is for an attacker to provide an incorrect answer to the resolver so it can redirect all the clients to another server. (Either to continue their attack, or simply to provoke a DoS of this domain.)

The question is: how does one craft a DNS reply that would be accepted by the resolver?

Resolvers accept replies on the following conditions:

1. It comes from the Name server to which the request was sent (IP, port)
   DNS mostly using UDP makes very easy to craft a UDP datagram with spoofed IP/port¹.

2. It matches a DNS query that was previously sent (Query ID)
   This is where most of the luck is needed, QID is a 2 bytes field that is randomly selected by the resolver before requesting the name servers. That's 65536 possibilities.

3. The "Question" in the reply matches the question that was sent with the same Query ID
   This is not an issue as the attacker can chose the domain to target and make the request themselves by asking the resolver.

4. The additional records in the reply is within the same domain as the question asked.
   This prevents the authoritative name server of www.example.com from providing information for www.foobar.com.

Most of these information are easy to craft for the attacker, all except the QID. The attacker has to flood the resolver by crafting legitimately-looking answers for all the 65536 possible QID and hopes that the correct one will be received by the resolver before the legitimate one from the name server.

If the attack fails, the attacker will have to wait the duration of the TTL before trying again. That's what was considered as a lottery, and for a 1-day TTL, it was calculated as taking 87 years to win.

_{¹: With Source Port Randomization, it is not possible to identify the source port used. This forces the attacker to try all the possible ports (along with all the QID), greatly increasing the packets to send and reducing the probability of success...}

Daniel Kaminsky's DNS flaw

In 2008 Daniel Kaminsky found a flaw in the way DNS was working to largely increase the odds for an attacker: instead of targeting a specific domain name such as www.example.com and being restricted by the TTL duration between each attack, one can parallel by attacking a.example.com, b.example.com, ..., aadjd.example.com, etc.

As the attacker doesn't have any time restriction, they will quickly end up with a successful poisoning (few seconds.) But the success doesn't come from poisoning <random>.example.com. It comes from the attacker saying in their replies "the name server of example.com is this way" and redirect the resolver to their own malicious name server.

The consequence is that this result will be cached, and for any further requests in the example.com domain, the resolver will contact the fraudulent name server. The attacker has managed to own the entire example.com, at least for the duration of the TTL.