UCSFguest, a large enterprise guest Wi‑Fi network, only works reliably when I disable Secure DNS in my browser. I tried several DNS-over-HTTPS providers, including Cloudflare and Google, but none worked. With Secure DNS enabled, HTTPS connections to their resolver endpoints are reset during the TLS handshake. For example, connections to cloudflare-dns.com and dns.google resolve and establish a TCP connection on port 443, but the network immediately resets them. When Secure DNS is disabled, browsing works normally. Why would a public Wi‑Fi network deliberately block encrypted DNS, and what is it likely doing instead?
2 Answers
The diagnostic results point to a network policy rather than a problem with Cloudflare or Google. Name resolution works, TCP connection to port 443 succeeds, and then the connection is reset as soon as the TLS session starts. That is consistent with a firewall identifying and blocking encrypted-DNS services by their destination IP, hostname, or TLS characteristics. Disabling Secure DNS makes the browser fall back to the DNS servers supplied by DHCP, allowing the network’s filtering and captive-network controls to work as designed.
This is probably intentional enterprise filtering. The network wants clients to use its own DNS resolvers so it can apply policies such as blocking malware, adult content, gambling, or other categories. DNS-over-HTTPS would hide those queries and let devices bypass the network’s filtering, so the firewall can block known DoH endpoints or reset their TLS connections. The downside is that this can create false positives and prevent users from choosing a resolver they trust.
The DHCP configuration appears to advertise UCSF-owned resolvers, including 64.54.201.12 and 64.54.201.76. That supports the idea that the network expects clients to use its resolvers rather than an external encrypted DNS service.