With a little attention, as it turns out, one can spoof fake DNS responses using fragmented datagrams.

How is it done?

To match authentic DNS responses to their corresponding queries, resolvers and operating system check:

• Name of the query
• Type of the query
• Source/destination address
• Destination port (16 bits)
• DNS transaction ID (16 bits)

The first three items can be predictable, the last two aren’t supposed to be. To spoof in a false response, it would mean to guess 32 bits of random. To do so, the attacker needs to send the resolver lots and lots of fake answers with guesses for destination port and the transaction ID. Over (prolonged) time, their chosen response arrives ahead of the authentic response, is accepted, and they are able to spoof a domain name.

 

 

 

 

 

 

 

 

 

 

 
In practice this turns out to be very hard to do. The 32 bit requirement plus the short timeframe in which to send false responses means it is nearly impossible to do this.

Using Fragments

DNS queries and responses can be carried in UDP (user datagram protocol) datagrams. A UDP datagram can be many kilobytes in size – far larger than most UDP packets. This means that a sufficiently large UDP response datagram can get split up into multiple packets. These are then called fragments.

Such fragments travel the network separately, to be joined together again on receipt.

Fragmented DNS responses happen occasionally with DNSSEC.

Matching fragments together is quite comparable to matching DNS queries to responses. Every IP packet, even a fragment, carries a 16 bit number called an IPID. This IPID is not copied from the query to the response, it is picked by the DNS responder.

 

 

 

 

 

 

 

 

 

 

 

 

On receipt, fragments are assembled by IPID, after which the checksum of the reassembled datagram is checked. On the off chance that right, the DNS reaction gets sent to the resolver procedure.

In the event that we need to spoof a DNS reaction, we could pick a DNS inquiry that prompts a divided datagram, and after that attempt to parody just the second section. On first sight, this does not give off an impression of being a lot simpler as we presently need to figure the IPID (16 bits) and we likewise need to ensure the checksum of the entire datagram matches (another 16 bits). This at that point additionally requires a 32 bit figure to succeed. In any case, in the event that we send a server a DNS question, it will more often than not send the equivalent DNS reaction to everybody who asks (likewise for divided answers). At the end of the day, if the aggressor needs to parody a specific reaction, it will know precisely what that reaction resembles – except for the goal port and the DNS exchange ID (32 bits). In any case, take note of that both of these eccentric parts are in the primary piece. The second part is totally static, with the exception of the IPID. Presently for the sharp piece. The ‘web checksum’ is truly,  a whole. So the checksum of the whole datagram comprises of the checksum of the principal piece in addition to the checksum of the second section (modulo 16 bits).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This means that to make sure the whole reassembled datagram passes the checksum test, all we have to do is make sure that our fake second fragment has the same known partial checksum as the original. We can pick the checksum of our fake second segment easily through the TTL of the our chosen response record.

This leaves us with only 16 bits to guess, which simplifies the problem

Randomness of the IPID

Some operating systems pick the IPID from a global counter. This means by picking up the currently used IPID, the next response can be picked up.

Other operating systems use an IPID that increments per destination which means we can’t remotely guess the IPID. However through clever use of multiple fragments, this still allows an attacker to “capture” one of these.

Is that it?

Well, this definitely sounds like a big problem but in order to get a certificate issued falsely using this technique, an attacker has to go through some other efforts. First we must be able to force many questions. Secondly, we must make sure that the original authoritative server fragments the answer just right.

Countermeasures

In the meantime, DNSSEC does actually protect against this vulnerability, but it does require that your domain is signed and that your CA validates.