Gargoyle Forum

Greeting everyone...

In order for the web monitor and other Gargoyle functions to work, DoH must be deactivated for clients - Source

Procedure for "dnsmasq" DNS resolver:
1. Edit the /etc/dnsmasq.conf file and add a line: Add more domains
2. Reboot the router (for cache cleaning)
3. Restart client machines (also for cache cleaning)
Source

If someone is using "unbound" DNS resolver:
1. Edit the /etc/unbound/unbound_srv.conf file and add a line: Add more domains
2. Reboot the router (for cache cleaning)
3. Restart client machines (also for cache cleaning)
Source

I can't try it better in practice (I don't know how, I consider it experimental yet) than with the nslookup command: or test here: https://1.1.1.1/help

And here something to laugh : https://i.iinfo.cz/images/358/packet-sniffer-pes.jpg (Source)

Good luck testing ...

This only applies to Firefox as well

ispyisail wrote:

If a user has chosen to manually enable DoH, the signal from the network will be ignored and the user’s preference will be honored.

Yes, if the client manually enters hard to go through DoH, then the game is over. I forgot to add that this is an automatic switching, not a manual setting - sorry for that.

Lantis wrote:This only applies to Firefox as well

Unfortunately yes:

...We have no plans to support this approach. We believe that our deployment model is significantly different from Mozilla's, and as a result canary domains won't be needed. In particular, our deployment model is designed to preserve the current user experience, i.e. auto-upgrading to the current DNS provider's DoH server which offers the same features...

Source

In addition, if clients are going through DoH, the web monitor and adblock will not work (maybe even more DNS-dependent services such as filters) .

So I modified my first post so that it wouldn't use DoH even if the function was turned on manually.

Tested on Firefox - works for me.

I couldn't start DoH in Chrome even though I forced it according to these instructions: Source1, Source2.

P.S. I don't know if such a hack is a way in the right direction - but to maintain Gargoyle functionality, I don't see a better way .

Is this something for Eric to consider?

Nothing to consider in my opinion. Its a feature that is going to be slowly rendered unusable.
We have previously discussed using nslookups on the IPs that are connected to, but so many websites using CDN and cloudflare etc would make it not very effective.

I'll bring it up next time we have a chat.

I'm pretty sure we're not talking about blocking all of Cloudflare, just the DNS server, while leaving most of Cloudflare functionality usable, right? Blocking only the DNS server on the necessary ports (443 and 853 for DoH and DoT respectively) should be feasible and won't lead to blocking everyone using their CDN.

However, on the other hand... Right now Firefox switches to standard DNS if it can't connect via DoH. If that changed... that would be huge liability to having a feature like this.

Additionally, more DoH services are going to pop up. In order to implement this we can only block the ones we know about / have in our list. It's a start, but with time it's not going to be complete and there's no way to block the whole protocol (that's the point of people using DoH in the first place!)

It's occurred to me that if I had time (of which I admittedly have had zero, I have rather been a lazy bum with regards to Gargoyle lately), implementing an option to proxy all outbound DNS requests from dnsmasq via DoH via a DoH server of the user's choice would be a good feature. That would allow for web monitoring while implementing privacy from ISP snooping.

Eric wrote:I'm pretty sure we're not talking about blocking all of Cloudflare, just the DNS server, while leaving most of Cloudflare functionality usable, right?

Yes, this is only a domain-level dns blocking, so it should not affect services (DNS resolvers) such as unbound, kresd, bind, stubby, etc. that support DoH (DoT).
- Maybe I am wrong when I am at home, so I will try in the way another router with services running as unbound + DoT .

EDIT: So it is good, routers are connected to each other and the service (unbound) works through DoT - it has configuration at the IP address level .

Again, it would be up to the agreement between the client (such as a PC) and the IT administrator (router) so that the user knows that even if he has the option manually selected, doH (DoT) will not work (because the browser does not appear anywhere failure of DoH, eg by warning icon) and automatically switches to classic DNS in the system.

Maybe I would see a solution using a plugin in which the administrator would determine the list of blocked dns domains and based on the development of the administrator would edit the list, + check mark if he wants to block the blocker or not warning that nothing is 100% and is a preventive measure (experiment).