DNS over HTTPS (DOH) cause misunderstanding info

Answers

• BWC Cybersecurity Overlord ✭✭✭

  April 2022

  @Enzino78 that is very interessting, but the current DoH situation on SNWL goes IMHO a bit deeper. I guess the DoH was enabled manually on Chrome by checking Secure DNS lookups?

  The CFS categorization is incorrect, that we can say for sure.

  But DoH (if not addressed properly by SNWL) will cause more problems, like FQDN wildcard lookups will not work any longer, because the Firewall cannot intercept the DNS requests anymore.

  There is a clear demand for DoH and might be resolved on DNS proxy level, accept old-school DNS from the network behind the firewall and translate into DoH or DoT on the way out. This would make FQDN lookups possible, DNS Security would still work etc.

  I will not even think about having DPI-SSL involved in DoH.

  As usual, just my € .02

  --Michael@BWC

  1
• CRISL Newbie ✭

  April 20

  Hi Michael@BWC

  the topic seems to be older and I can't find anything on this topic on SNWL. With the new Edge version 124 stable, the content filter and DPISSL are bypassed.Is there a way to block DOH enough so that the content filter and DPISSL work again?

  0
• BWC Cybersecurity Overlord ✭✭✭

  April 20

  @CRISL I did no further digging on this topic, but IMHO it's not addressed by App Control or CFS, which is long overdue.

  The most simple solution I could think of is blocking TCP 443 (DoH) to known DoH resolvers, hoping to catch all relevant ones. You might block TCP 853 (DoT), UDP 8853 (DoQ) and UDP 443 (Quic) to ANY as well to be on the safe side.

  Maybe these lists are a starting point:

  https://dnsprivacy.org/public_resolvers/

  https://dnscrypt.info/public-servers/

  —Michael@BWC

  0
• CRISL Newbie ✭

  April 20 edited April 20

  Michael@BWC thank you for the fast information. I assume that it will now affect a lot of users and SNWL should provide a solution. Even Draytek has implemented it into the configuration.

  0