There are initiatives to protect DNS, for example DNS over TLS or DNS over HTTPS. Given that the ISP can find out the domains the user visit by other means (Host header in plain HTTP, SNI in TLS handshake with HTTPS) I don't understand the threat DNS over TLS/HTTPS is adressing.
The main point of DNS over TLS/HTTPS today is likely to bypass DNS based blocking of sites which are considered harmful, which might include Google, Youtube, Facebook ... depending on where you are. DNS based blocking is easy and cheap since most users use the DNS server provided by the ISP which can simply return a different response for blocked domains. Even if the user explicitly configures a different public DNS server the ISP can create a cheap packet filter rule so that any traffic to port 53 (DNS) gets transparently handled by the ISP's DNS server, even if the user tried to use a different one. While there is in theory DNSSec to allow authorized DNS answers it is not used for a large part of the domains which also means that clients usually don't enforce it.
If the user instead uses DNS over TLS or HTTPS then the simple redirect of port 53 will no longer work since the ISP does not have the matching certificates for these TLS connections. While the ISP could simply block any traffic on port 853 (DNS over TLS) in the hope that the client falls back to normal DNS, blocking DNS over HTTPS can not be done without serious side effects since it uses the same port (443) and maybe even the same destination (content delivery networks) as normal HTTPS web traffic.
This means that in order to block sites the ISP has to rely on DPI (deep packet inspection) to extract the destination from the
Host header (plain HTTP) or SNI in the TLS handshake (HTTPS) and then block the traffic. This is way more expensive than a simple layer 4 (port based) redirect and also impacts the performance of the traffic. This makes it more likely that the ISP lobby will oppose the blocking, especially if the ISP's has to come up with all the additional costs themselves.
Additionally the proposed encrypted SNI means that even DPI will not reliably help to find out the visited site and thus blocking a site based on the domain name will not reliably work.
To be honest, your privacy at ISP level is at risk if you directly connect to the site without using proxies (TOR or VPN, for examples, are all proxies but with different secure privacy level) and every proxy should use secure DNS too.
What are threats implied using secure DNS?
The answer is: the same which affect web browsing in TLS/SSL or any other under layered service.
The threats reside in the traffic encrypted related to the service used (in fact, you should decrypt and verify traffic before accepting it in inbound and outbound connections), but principally in which way the encryption get established and maintained during all the transmit session in secure level:
TLS/SSL should prevent traffic injection once the authentication and encryption process is verified and executed, that's the most useful feature the secure layer offers in the end.