DNS on Public Wi-Fi: What Hotel and Café Networks See, and Fixes

What the hotspot sees on public Wi-Fi

When you connect, the network’s DHCP server hands your device a resolver address, often the access point itself. From then on, every name you look up passes through equipment you know nothing about. RFC 9076 describes the spot between your device and the recursive resolver as the best place to eavesdrop, because nothing is cached away there.

Encrypted HTTPS does not change this. The RFC spells it out: the web page is encrypted, but the DNS exchange that came before it is not. A list of names is often enough to tell which bank, health site or messaging service a guest uses, and it can be logged quietly without anyone on the network noticing anything at all.

Tampering: answers you did not ask for

Reading lookups is the passive problem. The active one is changing them. Whoever controls the resolver, or simply sits on the same network segment, can answer a query with an address of their choosing and send you to a look-alike server. The DNS spoofing guide walks through the attack mechanics and how DNSSEC helps.

The DNSCrypt FAQ also recommends port 443 for its protocol, partly because routers frequently hijack port 53. On public Wi-Fi that is common: plain DNS to any resolver, even one you typed in yourself, can be caught and answered by the access point. Changing the resolver address without encrypting the queries leaves that path wide open.

Captive portals: a login page built on DNS interception

The page that asks for a room number or a voucher code is a captive portal, and it typically works by lying. Until you log in, RFC 8310 notes, registration may rely on DNS interception and spoofing: every name resolves to the portal, so whatever you open lands on the login page.

That clashes with strict encrypted DNS. Under the RFC 8310 Strict Privacy profile, a client must not send queries until an authenticated private resolver is reachable, and the system must warn you if DNS is not private during the bootstrap. In plain terms: encrypted DNS may stay silent until you have clicked through the portal.

How dnscrypt-proxy deals with captive portals

Operating systems run connectivity checks after every network change by resolving fixed names and fetching known URLs. The dnscrypt-proxy wiki explains that these checks can fail while the proxy is still starting, so the system reports No Internet and never shows the portal. The [captive_portals] section exists to stop that.

Enable it by uncommenting the map_file line in the [captive_portals] section of dnscrypt-proxy.toml and pointing it at a list of those names. The proxy then starts a lightweight UDP listener before it has fully initialised and answers these names instantly with hard-coded addresses and a one-second TTL. The project ships example-captive-portals.txt with entries for Apple, Android and Windows:

[captive_portals]
map_file = 'example-captive-portals.txt'

captive.apple.com               17.253.109.201, 17.253.113.202
connectivitycheck.gstatic.com   64.233.162.94, 64.233.164.94
www.msftconnecttest.com         13.107.4.52

The file format is one hostname per line followed by comma-separated addresses, and the wiki notes that wildcards are not supported, so every name has to be listed exactly. Copy the example next to your configuration, restart the proxy and reconnect to the network; the login page should now appear as it would without encryption.

Free Wi-Fi that blocks encrypted DNS

Some free Wi-Fi networks go further and block anything that looks like encrypted DNS. A dedicated port is the easiest target: DNS-over-TLS needs TCP port 853, which the DNSCrypt FAQ calls trivially blocked. DoH and DNSCrypt can both use port 443, which a network cannot close without breaking the web for every guest.

The worse outcome is a silent fallback. Windows 11 has a Fallback to plaintext switch for DNS over HTTPS, and Microsoft’s description is clear: with it on, a query that cannot go over HTTPS is sent unencrypted. On free Wi-Fi that blocks DoH, you would never notice. Turn it off, accept the occasional failure, and treat that failure as information.

DNS settings to turn on, device by device

Each platform puts the switch somewhere else, and the protocol differs too: Windows 11 offers DoH, Android offers DoT, and Apple’s platforms accept either one. These DNS settings are the ones that survive a change of network, so set them once at home, with time to test, rather than at the departure gate:

• Windows 11: Settings, Network and internet, Wi-Fi, your network, then Edit next to IP assignment. Enter the resolver, set DNS over HTTPS to On, and turn Fallback to plaintext off.
• Android 9 and later: search Settings for Private DNS and enter a provider hostname such as dns.quad9.net. The Private DNS guide lists hostnames and explains the Automatic mode.
• iPhone, iPad and Mac: Apple’s platforms take DoH or DoT through an app built on NEDNSSettingsManager or a configuration profile with a DNSSettings payload.
• Laptops on any system: a local dnscrypt-proxy with the captive portal map enabled. The installation guides cover Windows, macOS and Linux.

The Android setting has one catch worth knowing before you travel. Quad9’s guide notes that Private DNS is not used while a VPN is active, so if you connect to a VPN on hotel Wi-Fi, the VPN app’s own DNS settings take over and the hostname you typed has no effect at all.

Before you connect to public Wi-Fi at the next airport

Set up encrypted DNS at home, where a mistake costs nothing, and check that it really works with the commands on the DNS leak check page. On public Wi-Fi, log in to the portal first, then run the Akamai whoami query once to confirm the answering resolver is yours, not the hotspot’s.

If nothing resolves after login, look at the failure before you switch encryption off. A blocked port 853 points to DoT, so try a DoH or DNSCrypt server on port 443 instead. If even those fail, the network is probably filtering heavily, and a VPN, or your phone’s mobile data, is the more honest option for that session.