"This way works well for most people but, your ISP can see and control what website you can visit even when the website employ HTTPS security. Not only that, some ISPs can redirect, block or inject content into websites you visit even when you use a different DNS provider like Google DNS or Cloudflare DNS. Having Technitium DNS Server configured to use DNS-over-TLS, DNS-over-HTTPS, or DNS-over-QUIC encrypted DNS protocols with forwarders, these privacy & security issues can be mitigated very effectively."

And if using Technitium as encouraged/promoted/facilitated,^1 now "DNS provider like Google DNS or Cloudflare DNS [or IBM Quad9 DNS]... _can_ see and control what website you can visit even when the website employ[s] HTTPS security" and "_can_ redirect, block or inject content into websites you visit"

If the ISP seeing "what website you can visit" is the issue, then Technitium is not going to help. A DNS lookup does not necessarily mean a "visit" but even assuming it does, then the ISP can already see the "visit" (the actual TCP connection not the DNS lookup) via the SNI extension in the TLS ClientHello

If the issue is ISP "control [over] what website you can visit", then Technitium _might_ help

But if the issue is _any_ third party "control [over] what website you can visit", then all that has been done with Technitium is to substitute a "DNS provider" other than the ISP as the third party

Technitium uses the word "can" to describe the issue: "your ISP can see and control..." and "some ISPs can redirect, block or inject..."

Maybe this is purely coincidental, who knows

The fact is some ISPs _have_ redirected, blocked or injected content by utilising their control over DNS

It has happened and, certainly with redirection at least, it is ongoing. Why use the word "can". ISPs do it

As far as we know neither Google nor Cloudflare has done it

It may or may not have happened. But either way, they _can_ do it

There is nothing that stops third parties from doing it in the future, whether it's an ISP or an advertising services and surveillance company or a TLS MiTM CDN

Excerpt from RFC 1035:

"Name servers manage two kinds of data. The first kind of data held in sets called zones; each zone is the complete database for a particular "pruned" subtree of the domain space. This data is called authoritative. A name server periodically checks to make sure that its zones are up to date, and if not, obtains a new copy of updated zones from master files stored locally or in another name server. The second kind of data is cached data which was acquired by a local resolver. This data may be incomplete, but improves the performance of the retrieval process when non-local data is repeatedly accessed. Cached data is eventually discarded by a timeout mechanism."

The "DNS provider" is not a source for authoritative data

Many self-proclaimed "technical" people use it this way; hopefully they understand exactly what they are doing

For example, according to RFC 1035 the operator of the nameserver for example.com controls the DNS data for example.com, not the ISP, not Google, not Cloudflare or any other third party "DNS provider"

The internet user can run his own authoritative nameserver and/or a cache^2 and decide what the DNS data for example.com should be served when his computers ask for it; he could thereby eliminate the need for third parties

He could obtain that DNS data from the nameserver(s) for example.com

He could also obtain it from an "upstream" third party cache, such as an ISP, Google, or Cloudflare; i.e., he could rely on a third party

But according to RFC 1035 only the nameserver for example.com is the authoritative source^3

1. "Self-host" is not the default

DnsServer-master/Apps/AdvancedForwardingApp/dnsApp.config

2. These do not have to be the same program, as is the case with Pi-Hole (dnsmasq) and Technitium

3. As it happens, many website operators use third parties for authoritative DNS service