DNS over HTTPS/TLS not getting blocked

[Cajuntank]

Was doing some log parsing and came across some traffic flows that had me scratching my head. I have a policy with DPI enabled, but I do have reputable websites with various categories and address objects exempt. I also have a application control profile applied to said policy where I explicitly block DNS over HTTPS and DNS over TLS. 

The traffic in question going through that policy shows traffic to dns.google (8.8.8.8) with application of DNS over HTTPS and DNS over TLS as Allowed (again, app control profile has it set to block). My assumption is, that due to my DPI profile having pretty much all things google exempt, this is causing the traffic to pass Allowed. This seems the most logical reason, but just wanted to bounce this out there and get some thoughts if I'm on the right track or there is some other "rabbit hole" I need to go down.

[bkrishnan]

Hello 
I believe that the signature(DNS over HTTPS\TLS) requires "deep-inspection" to identify and perform the action.

[Cajuntank]

Yes, sorry if I wasn't clear on that. When I say DPI, I mean deep packet inspection. So yes, I have deep packet inspection certificate enabled on this policy along with the app control profile blocking DNS over HTTPS/TLS, but since the DNS over HTTPS/TLS is occurring on traffic to a exempt domain (in this instance, google's DNS) in that deep inspection certificate profile, I am thinking this might be why its passing through instead of being blocked. That is the logic I am trying to confirm or if there is something else I might need to look at. I know I can block port 853, but does not help with DNS over HTTPS and I am just wanting to confirm my logic.

[Debbie_FTNT · Accepted solution]

Hey Cajuntank,

if you have configured an exemption for broadly all things Google, then it is indeed very likely the reason that the traffic is allowed. If it's exempted from inspection, that means any subsequent UTM filters do not apply, and the traffic is simply passed through.

You could create another policy above it (specific to DNS and/or DNS via TLS/HTTPS), and apply deep inspection without the exemption, so DNS traffic IS inspected, but other Google-related traffic goes through your current policy and IS exempted.

[Cajuntank]

Not really wrapping my brain around this one to do a good workflow to be honest. I have a policy that blocks DNS (port53) for my users to ensure they are forced to use my internal DNS. I can block port 853 to mitigate against DNS over TLS. So with DNS over HTTPS, while I can do a deep inspection profile with no exemptions for example, I'd still have to focus it to a destination. If I'm having to do that, in this example being 8.8.8.8, then I might as well just block port 443 access to 8.8.8.8 (and 8.8.4.4 if we are talking about just Google). I'm just not sure how to "surgically" exclude Google DNS from a deep inspection profile while allowing all other things Google due to the exhaustive nature of Google...if that makes sense.

[Cajuntank]

So the way I see it, I had two choices. The one you mentioned at first caused me to scratch my head some... like I was still missing something. It's not until I found that there is a Google-DNS Internet Service entry. So I can either deny or deep packet inspect on policy with that entry along with a custom deep packet profile not trusting anything... so it's either deny all or scan it and it should deny based on app control profile. Sounds like my best bet is to deny (which I've done as that seem like it would be less CPU cycles for the hardware to deal with).