Reply to post: Re: "AND the header-level clues that DNS resolution is being requested."

Re: "AND the header-level clues that DNS resolution is being requested."

@Jellied Eel

But un-encrypted DNS is useful, like Vixie says. So user sends request (not just HTTP) looking for evil.stuffhere.ru and DNS resolves that back to an IP address. Being a simple, plain text request, it's easy for net/security admins to capture that request, match against security policy and perhaps go have stern words with the requestor.

Any organisation that cares about it's security for outbound users desktop requests has the following configuration:

1) firewall blocks by default all outbound requests coming from any source.

2) firewall is configured to allow known hosts that have a need to connect externally (e.g. non-HTTP/S B2B links, such as direct messaging systems).

3) it provides its own DNS servers internally, and since a desktop cannot send any request, including DNS, through the firewall, to perform DNS resolution you need to use the organisations DNS servers.

4) A MITM proxy (HTTP/S, possibly others, FTP, SSH, etc.) that requires user authentication and authorization to use.

5) as a MITM proxy, it decrypts all traffic (except any on the exception lists, known 'good' sites such as major banks, or government websites) and it establishes a secure session between the client and the server, client <-> (TLS) mitm proxy (TLS) <-> server.

6) Firewall allows authorized requests from the MITM proxy that have been vetted out to the rest of the world.

Therefore using DoH, DoT, TLS, whatever doesn't matter if you are on a business/organisation network that cares about its security, as you'll be hitting their DNS/DoT/DoH server which means they get to inspect the unencrypted contents of the DNS request and make the usual decisions on what to do with it - resolve it, block it, redirect it.

So the only network management layer that cares about whether the DNS (or other) request is encrypted or not are the middleman transport networks, ISPs, Peering providers, and anyone outside the source network and target network that wants to eavesdrop or control the data. The source network and destination network know what's in the packet.