I'm not sure if the term "cache poisoning" means what you think it means; it's not a form of DoS but rather a security breach.
Regarding UDP and DoS attacks, as the source IP field for UDP packets aren't always filtered by ISPs it's sometimes possible to fraudulently send packets on behalf of other servers. This makes all sorts of amplified and reflected DoS attacks possible, the subject of which I believe your question is about.
One of the most dangerous DoS attacks nowadays is the classical DNS amplification attack, where much like a classical SYN flood, packets are forged at a computer with the source IP field maliciously tampered with. In this attack, the source of the packet is reported to be the end target, so that the response from the server, usually crafted to be many times larger than the request sent by the attacker, will be sent to the target. This causes nameservers to multiply the size of the flood, thus the bandwidth consumed and also makes the source of the attack incredibly difficult to track down.
This can of course be extended to a DRDoS (distributed, reflected denial of service) attack, where multiple malicious connections are forging requests at multiple nameservers on behalf of the target of the attack, in order to multiply the bandwidth of the nameservers and aim it at the end target.
To be clear, UDP isn't required to poison a DNS cache, though the unreliability of packets certainly introduces many attacks, particularly when DNSSEC extensions aren't installed!
It's entirely possible that a malicious employee at an ISP (or anyone who has administrative access to a nameserver in question) could corrupt a piece of memory using some local vulnerability, for example, and this would constitute a DNS cache poisoning attack which doesn't rely upon UDP at all.
Even when TCP is used in place of UDP, it's entirely possible that there may be an error somewhere in a chip of RAM between source and destination which causes a bit to flip. A bit flipping from stac
koverflow.com to stac
ioverflow.com at the client side would cause the request to be forwarded to a potentially malicious nameserver, for example, which might respond as though it owns that domain. That's called bitsquatting, and it doesn't rely specifically upon UDP; DNS does (at least partially) support TCP, after all.
Furthermore, on each packet there is a TTL (time-to-live) field, which each router updates as the packet is sent from router to router towards the destination. The reason for this is so that the source can be notified if no route exists, for example. Unfortunately, this means the checksum needs to be updated at each hop, which means errors in memory at each hop might not be identified by UDPs checksum mechanism. Big frown: :(
While we can see DNS cache poisoning attacks are certainly a major concern, I think you should now be able to see how they're not really relevant to the bulk of your question.