DNS, by default and when created does not offer neither authenticity (being sure you get a response from the true authoritative nameserver of the zone) nor confidentiality (making sure noone on the wire can understand your query or your answers).
DNSSEC was created to solve the authenticity problem, because it allows one to sign records, and through a mechanism of keys you build a chain of trust and can verify the answers you get. It solves the Man In the Middle problem in the sense that, if the concerned zone is signed (which is still around 0.53% of all zones nowadays) and if someone tries to change the replies for such a zone, then you will be able to spot the changes.
Authenticity is more important than confidentiality, contrary to intuition. Why? Because if you have no guarantee who you are talking too, even if the answer comes to you encrypted, what value does it have? You can be doing encryption with any evil third party if you do not authentify it.
It is true now that if you already have authenticity, because of DNSSEC for example, you may wish to have confidentiality as DNS can convey sensitive or at least personal information. This is also why QNAME minimization now exists, to reduce the quantity of information sent to each nameserver. This is more and more supported (soon in Bind)
So now as for encryption, your first error is to think about UDP. DNS uses UDP and TCP, and nowadays even more often TCP for the reasons we will below. That aside, note that even for UDP, you have encryption options, see DTLS, which is basically TLS in UDP. QUIC, created by Google (basically to be able to create an optimized HTTP, which became now HTTP/2 after having been SPDY), was also architectured over UDP with securities being similar to what TLS offers. Have a look at this two to debunk your idea that a payload could not be encrypted in such case.
Today for encrypted DNS you have these options in no specific order:
- DNSCrypt: this is not a standard in the IETF sense, but it an open protocol, implemented by various actors. See https://dnscrypt.info/
- DNS over TLS is now a standard (RFC7858 and RFC8310), and you have various document explaining how the initial handshake should take place, see the second RFC above and the two security profiles defined and also note how and when DANE could be useful, where DANE mandates the use of DNSSEC; next version of Android will support DNS over TLS by default (see https://security.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html), even if it uses for me a slighty misnomer of "private DNS".
- DNS over HTTPS (which itself uses TLS then) is not yet an IETF standard but is in the way of becoming one.
- Oblivous DNS is the newest kid on the block, which needs both newer clients and servers to use it, as well as the new
Of course in all these cases you need to have specific servers speaking the protocol. Some open resolvers are already offering DNS over TLS. You however only shift your problem: your connection is "secured" up to them but then you have to trust them to work correctly and not lie to you, specially in validating DNSSEC.