>>If you're filtering with a Pi-Hole or similar, you can go unencrypted from your clients to the Pi-Hole, but I strongly recommend setting its upstream resolution to use DoH, if available.
>>
>
>True. At the moment results in sometimes IP check, as PiHole is not the DHCP server and I have not checked fine print of Help. But if DNS query is already embedded & encrypted via query from inside Javascript, Pi-Hole is left twiddling thumbs while blacklisted target DNS query cannot be deciphered and subsequently blocked..

What I'm suggesting is

Client computer/browser  -----------------------------> Pi-Hole  -------------------------------> Upstream resolver: CloudFlare, Google etc.
                              unencrypted                              encrypted DoH/DoT

The above assumes your Pi-Hole is the sole/enforced DNS server for your client computer. Actually, thinking on this further you could go encrypted from your client computer to the Pi-Hole (as long as the Pi-Hole supports DoH). Regardless of transport encryption from the client to the Pi-Hole, the Pi-Hole must be able to interpret the DNS query effectively. Only then can it decide what to do - return the answer from local cache (if available) or forward the request to the upstream resolver. The response can then be filtered per the Pi-Hole's default rules or whatever else you may have set up.

The filtering should take place at the application level in the DNS server, not at the transport layer. The response is always available in "plain text" to the filtering app. This is the gist of Mozilla's response when they were criticized for promoting DoH: https://en.wikipedia.org/wiki/DNS_over_HTTPS#Criticisms_and_implementation_considerations

There's a detailed discussion at https://www.zdnet.com/article/dns-over-https-causes-more-problems-than-it-solves-experts-say/ . DoH is not a privacy panacea and can cause some issues with enterprise security, but for average Joes it doesn't hurt and can improve privacy. Schneier like it: https://www.schneier.com/blog/archives/2020/02/firefox_enables.html

As an aside, NoScript in Firefox blocks active content such as Javascript by default. It's a good line of defense against compromised or outright malicious web sites.