DNS requests and replies are not HTTP; they are... DNS. See the standard. Most of the time, DNS requests and responses use UDP: the request is a single IP packet, and so is the response.
With UDP, each packet is identified by:
- the source IP address
- the destination IP address
- the source port
- the destination port
A DNS request from client C to DNS server S will use C's IP address as source, S's IP address as destination, a random port value p as source port, and 53 as destination port (the standard port value for the DNS server). The DNS response will use C's IP address as destination, S's IP address as source, 53 as source port and p as destination port. The client will accept the response as "correct" because it uses p as destination port, the same p as the one used by the client as source for its request.
An attacker who wish to feed fake DNS information to the client C can know C's IP address and S's IP address, and can make a good guess about the moment the client will send its request. The attacker's goal is to send a fake DNS response, claiming to come from the DNS server S, but containing. Without full eavesdropping access, the attacker cannot know the value of p, because he cannot see packets. However, port numbers are in a limited range (port numbers range from 0 to 65535, but the actual range for randomly allocated numbers is smaller, and depends on the involved operating system). Therefore, the attacker may just send a few thousands of spoofed IP packets, each containing the fake information, for all possible port p values. The client will drop all of them except the one using the correct p value.
The same concept can be extended to communications between DNS servers, because they talk to each other, and cache responses. It is often easier to pull off for the attacker, because he can trigger himself the DNS-to-DNS exchange, allowing a precise timing for his launch of his thousands of spoofed responses. When he succeeds at feeding fake information to a DNS server, then that DNS server is said to be poisoned.
This sort of things is relatively easy even for low-tech attackers who don't have eavesdropping abilities, let alone interception power as would be required for a true MitM between the client and its DNS server, or between DNS servers. The reason which makes it easy is the use of UDP, which implies that the attacker knows everything except the random source port, which lives in a small range. If the two DNS servers talk to each other over TCP, then the attack is more difficult, because injecting fake data in a TCP flow implies guessing the connection sequence numbers, which are randomly chosen in a 32-bit range: the "thousands of packets" have become "billions of packets".