DNS over TLS / HTTPS with TLS Inspection

It highly depends on the implemention of DNS on those devices. Often times, they are using certificates as well and check if somebody reroutes something - Meaning, if you do something with this traffic, they will stop interacting with the traffic. 

Blocking it, like doing on QUIC, helps to get DNS plain running but throws often times errors. 

DNS over TLS is a privacy feature for IOT devices or browsers - So you need to think about the use cases. Sometimes you need to simply allow it and check the devices (Endpoints etc.) or in terms of IOT isolate those devices. 

It is now used by most Apple devices unless you block it at the firewall. 

Also you cannot apply policies eg block ads while usingSSL/TLS inspection.

Ian

Your firewall rules will determine if the traffic is allowed or blocked.

The SSL/TLS inspection rules will determine if the TLS traffic is decrypted.

If the TLS is decrypted then we will rewrite the TLS handshake so that it is using our Certificate Authority.  The caller may be okay with that if it trusts the CA, but may also decide not continue (at which point I assume it would fall back to traditional DNS).
It it is TLS decrypted and the connection is established, it is examined to see if it is HTTPS.  If it is, the Web Filtering applies  If it is not HTTPS then it is just allowed.

Thank you, the last sentence was exactly what I was looking for. In this case we will probably block DNS over TLS outright. I imagine that by the encrypted nature of this traffic it is much loved by intruders communicating with their C&C servers and the like, and because of the firewall just allowing this traffic even in the case of decrypting it it poses too much of a potential threat.

Thank you!

Any form of encrypted traffic is a potential avenue for threats.  I don't think DNS over TLS is specifically an issue more than others. 

Here is a more full picture:

A TLS connection is attempted on port 853.
DPI engine will look at the SNI (Server Name Identification) to determine the FQDN of who it is contacting.
The FQDN can be blocked by Web policy.  If ATP configured, the FQDN and IP is checked against Command and Control servers.
GeoIP and Country Blocking can apply.

If TLS Decryption is performed
The decrypted traffic on port 853 is examined to see if it is HTTP.  If it is then web policy and a/v is performed.
The decrypted traffic is given to the IPS / App Control engine.

If TLS Decryption is not performed
The undecrypted traffic is given to the IPS / App Control engine.

If you look in a TLS connection and it is not HTTP traffic you don't actually know what it is.  Maybe it is DNS, or SMTP, or any number of existing protocols.  Or theoretically (but not practically) a custom malware protocol.  You can take a guess based on the port.

That being said, the IPS / App Control engine CAN detect many things that are not HTTPS.  There is a specific detection for DNS over TLS - I don't know if it only works with decrypted TLS or if it does undecrypted as well.

So if you are worried about Command and Control - ATP will block it before it gets decrypted.  IMO the case 

--------

Now as for DNS over HTTPS (which occurs on port 443).  For example https://dns.google/dns-query

As above, the SNI is checked against ATP.  The SNI is also checked against web policy.  The few that I checked are categorized as Information Technology.  Web policy blocks for URL group (domain name only) are applied.

If decrypted, it is HTTPS.  Web policy blocks for URL group (domain name and path) are applied.  Virus scanning occurs.

dnsprivacy.org/.../