Is public Wi-Fi DNS safe? No, and the usual defences don't fix it

Short answer: no, and the four things people reach for to fix it all have a hole. Setting a public resolver does nothing. Encrypted DNS is switched off by default and does nothing until you go and find it. DNSSEC would not have caught this. Even the VPN, the one control that genuinely works once it is up, cannot protect the ninety seconds you spend logging in to the hotel's own portal.

The reason to care right now is that somebody is actively working the hole. One compromised box in a hotel basement, and every guest who joins that network gets whatever answers the attacker feels like giving. Not the guests who clicked something. All of them.

That is what ReliaQuest described on 23 July 2026, and Infosecurity Magazine covered independently the same week: captive portal appliances at hotels and conference centres in several US cities, plus India and Saudi Arabia, quietly reconfigured so the gateway hands out forged DNS answers. Guests were funnelled to four Microsoft-lookalike domains (m365-owa, owa-ms365, ms365-device, ms365-live) sitting on three IPs. Nobody had to be phished and nothing was installed on anyone's laptop. It has been running since at least June.

Whoever hands out DNS decides what your laptop believes

When your laptop joins a network, it accepts that network's resolver via DHCP and then trusts what comes back. That is not a bug anyone forgot to fix, it is how joining a network has always worked. DNS turns login.microsoftonline.com into an IP address, and the machine answering has no obligation to tell you the truth.

Take the gateway, and you are not attacking anybody's device. You are just answering the question they were always going to ask.

The symptom will look like a flaky hotel network. A login page that needed two attempts, or a certificate warning that seemed like the usual public-Wi-Fi nonsense. Nobody opens a ticket for slow Wi-Fi in a hotel.

Setting 8.8.8.8 changes who you ask, not who answers

A plain DNS query to 8.8.8.8 leaves your laptop as unencrypted UDP on port 53, straight through the gateway, which can read it, drop it, and answer it itself. ReliaQuest logged exactly that: a request for a legitimate Microsoft domain, resolver 8.8.8.8, response an attacker IP. Google never saw the question.

This is the one that catches technical people, because typing a public resolver into your network settings feels like taking control. On plenty of captive portals it is worse than useless, because outbound port 53 to anywhere except their own resolver is blocked until you have authenticated anyway.

Does DNS over HTTPS protect you on public Wi-Fi? Only in strict mode

Not as it comes out of the box, because out of the box it is switched off. Turn it on properly and it does genuinely fix this, which makes it the one control on this list that a traveller can set up in advance and forget.

Most implementations run opportunistic: try encrypted, and if that fails, fall back to plaintext. The gateway decides whether it fails. So it fails, and you get silently downgraded to port 53. That is not my characterisation, it is Microsoft's. Describing the setting that permits fallback, their own documentation says "you won't be provided with any notification if DNS queries are switched from DoH to plain text".

On Windows 11 the control is in Settings under Network & internet, Wi-Fi, then Hardware properties, DNS server assignment, Edit. Switch the dialog from Automatic (DHCP) to Manual and turn IPv4 on, and two things appear under each server box: a DNS over HTTPS dropdown (Off, On with an automatic template, or On with a manual one) and, separately, a Fallback to plaintext toggle. Both matter, and only one of them is likely to be wrong.

Encrypted DNS with fallback left on is opportunistic mode, and opportunistic mode is what this attack walks straight through. Set the dropdown to On, the template to automatic, and check that the fallback is Off, on the preferred and the alternate server both.

Credit where it is due, and it surprised me: on the machine I tested, that fallback toggle was already sitting at Off, untouched. Windows is not quietly opting you into opportunistic mode. What it is doing is shipping with DNS over HTTPS switched off altogether, which is worse than opportunistic and easier to miss, because a dropdown reading "Off" looks like a setting rather than a warning. Turn it on and Windows does the strict part for you.

Then go back to the properties page and read the same two lines you started with.

Fleet-wide, the same thing lives in the Configure DNS over HTTPS (DoH) name resolution group policy under Computer Configuration\Policies\Administrative Templates\Network\DNS Client, set to Require DoH.

macOS has no such switch, and the network can put itself first

macOS will show you the resolvers. Go to System Settings, Wi-Fi, Details on the network you are joined to, then DNS. The list is there, and anything the network handed you rather than you typing it appears greyed out.

Two things on that screen are worth more than the list itself. The heading reads "Encrypted DNS Servers or IP addresses", so the field does accept an encrypted resolver, which is more than I expected before I looked. But nothing on the pane tells you which of the three listed servers is encrypted and which is not, and there is no equivalent of the Windows fallback toggle. You get the addresses and no answer to the question that matters.

The second thing is the order, and it is the reason to open Terminal. Run scutil --dns and read the top block, resolver #1.

The same three servers, and a different order. System Settings put the fe80:: address at the bottom of the list. scutil puts it at the top, which is where it counts, because that is the order the machine actually asks in.

That address is link-local, advertised by the network itself, and in plain terms it is almost always the router. It got to the front because IPv6 router advertisement puts it there. So the Mac is asking the network's own box first and Google second, while the settings pane shows Google first and the network's box last.

Confirming that none of it was chosen locally takes one more command:

$ networksetup -getdnsservers Wi-Fi
There aren't any DNS Servers set on Wi-Fi.

Nothing set by hand, three servers in use, headed by the router. In a hotel that first entry belongs to the hotel.

That is the false trail. Somebody opens Settings, sees a familiar public resolver sitting at the top of the list, and treats the question as handled. The list is not the queue. Read the queue with scutil --dns.

Two honest limits. Turning IPv6 off makes that fe80:: entry disappear without fixing anything, so I would not build a habit on it. And neither the settings pane nor scutil will tell you whether a given query travelled encrypted, which is the one thing Windows does better here. Both tell you who is being asked. That is worth knowing, and it is not a clean bill of health.

Two limits ride along with that, and the second one is not optional. Windows will only let you turn any of this on if your resolver is on its known-DoH list (Cloudflare, Google and Quad9 ship in the box). And Microsoft explicitly says not to enable Require DoH on domain-joined machines, because Active Directory leans on DNS and the Windows DNS Server service does not speak DoH, so you will break domain logon. Strict mode is for the laptop's public-network profile, not for your domain controllers.

Strict mode has a second price, and it is the hotel login page

Strict mode also breaks captive portals. The hotel's own login page needs plaintext DNS to a hostname only the hotel's resolver knows about, so a laptop locked to encrypted-only sits there unable to join the network at all. That is not theoretical. It is why the Apple encrypted DNS profiles people share all carve out captive.apple.com, and why Apple's own developer forums have a long-running thread on portals and DNS settings arguing with each other.

So you get a real choice rather than a setting: strict mode plus a manual unlock for the sixty seconds you spend logging in, or opportunistic mode and a hole. I prefer strict with the unlock, and I accept that it makes joining hotel Wi-Fi genuinely annoying. Whatever you can actually live with is the one that will still be enabled in March.

DNSSEC would not have saved you here, and I went and checked

DNSSEC signs answers so a resolver can prove they came from the real authoritative server. It sounds like the exact defence for a forged answer. It is not, for two separate reasons, and the second one is the fun one.

First, validation normally happens at the recursive resolver, which on hotel Wi- Fi is the attacker. The machine you would be asking to check the signature is the same machine that forged the answer.

Second, and this is the bit I did not expect until I ran it through our own DNSSEC checker while writing this paragraph: microsoftonline.com is not signed. Nor is microsoft.com. The checker walks the chain from the root down and asks four validators independently, so a single resolver's cache cannot hide a break. There is no DS record at the parent, no DNSKEY at the zone, and Cloudflare, Google, Quad9 and OpenDNS all return the answer as insecure rather than validated. Checked 27 July 2026, and you can re-run it yourself in about four seconds. There is no signature on Microsoft's login domain for anything to validate, so even a stub resolver doing its own validation would have had nothing to compare the forged answer against.

If you want DNSSEC explained properly rather than in a paragraph, that is a separate article. The point here is narrow: it is a good thing to turn on for your own domain, and it was never going to be the control that stopped this.

The VPN advice is right, and it has a hole exactly where you connect

ReliaQuest's headline recommendation is always-on, full-tunnel VPN, and they are right. Once the tunnel is up, DNS goes through your resolver and the gateway is carrying encrypted traffic it cannot read. Split tunnelling that lets DNS out locally undoes the whole thing, so audit for that.

The gap they do not mention is the order of operations. The tunnel cannot come up until you have internet, and you do not have internet until you have cleared the captive portal, and clearing the captive portal means talking plaintext to the attacker's resolver. Every serious client ships an explicit hole for this. Cisco's captive portal remediation has to be permitted in the profile before an always-on closed policy will let you reach a login page at all. Palo Alto's GlobalProtect has a Captive Portal Exception Timeout, 0 to 3600 seconds, default 0, which administrators routinely raise to something like 60 precisely so that staff in hotels can get online.

Sixty seconds of unprotected DNS on a hostile network is a much smaller window than a whole trip. It is not zero. Treat anything that happens before the tunnel icon goes green as untrusted, and in particular do not sign into anything during it.

WPAD is the second hole, and the obvious way to close it breaks software

In about a third of the cases observed, the attacker also went after Web Proxy Auto-Discovery. Windows, on joining a network, asks that network whether it has a proxy, first via DHCP option 252, then by looking up a host called wpad. The gateway controls both answers. Succeed, and most Windows application traffic routes through the attacker's proxy, which in the logs looks like a perfectly ordinary HTTPS connection made by svchost.exe.

Turn it off if you do not use it, and do not do it by disabling the WinHttpAutoProxySvc service. That is the advice you will find first, and it has a documented habit of stopping unrelated applications from launching. Leave the service running and kill the discovery instead: DisableWpad set to 1 under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp.

Then read the next bit of Microsoft's own page, because it is the part that gets skipped. That key only stops WPAD detection for calls made through the WinHTTP API. Applications can still resolve the name wpad by asking DNS directly, and Microsoft says in the same breath that you also need to turn it off in the Windows Settings UI, since browsers and third-party apps read that instead. One registry key is not the whole job.

The device-code prompt is the one a human can actually catch

The nastiest piece is a redirect into Microsoft's device-code authentication flow. There is no fake password page to spot, because there is no fake page. Microsoft's real sign-in appears, the user approves it, and the tokens go to the attacker's client, MFA already satisfied. Approving a genuine prompt is the whole attack.

Which is why the fix is administrative rather than educational. In Entra ID, Conditional Access has an Authentication flows condition. Set it to device code flow, grant control Block. Microsoft's own wording is to "get as close as possible to a unilateral block", which is unusually direct for them. Their documented steps have you create it in report-only first, which is worth doing to find the shared-device edge case you forgot about, and it needs Entra ID P1 for every user it covers.

What to actually do before your next trip

For whoever is travelling, in the order that matters:

1. Tether to your phone instead. Unglamorous, and it removes the entire attack. Mobile data is the cheapest security control in this article.
2. Get the VPN up before you do anything else, and treat the pre-tunnel window as hostile. Clear the portal, connect, then start work.
3. Refuse every unexpected sign-in prompt. Not "check it carefully". Refuse it. If Outlook was working ten minutes ago and now something wants you to approve a code, the answer is no, on that network, permanently.
4. Check the certificate before you type a password, and treat a warning as a full stop rather than a speed bump. The lookalike domains here were things like owa-ms365.com, which reads fine at a glance in a hotel lobby at 22:00.
5. Check who is actually answering, not who you configured. scutil --dns on a Mac, Get-DnsClientServerAddress on Windows. Read the order. If something belonging to the network sits above the resolver you chose, the resolver you chose is not the one being asked first.
6. Do the nonsense-domain test. Run nslookup thisisnotarealdomain-4f7q.com from the terminal. It should come back NXDOMAIN. In this campaign every query resolved to attacker infrastructure, so an answer where there should be none is a strong tell. The limit: a more careful attacker only forges the domains they care about, so a clean result proves nothing. It is a smoke alarm, not a survey.
7. Compare notes with the outside world. Look up the domain you care about on the hotel network, then check what the rest of the internet says from your phone on mobile data with our DNS propagation checker. Different answers, different network, same question.

For whoever runs the fleet:

1. Always-on full-tunnel VPN, split tunnelling audited off. Everything else on this list is a second line.
2. Block device code flow in Conditional Access. Report-only first.
3. Encrypted DNS in strict mode on the travelling laptops only, never on domain-joined machines that need AD, and with a documented way for staff to unlock it while they clear a portal.
4. Disable WPAD by registry, not by killing the service, and in the Settings UI as well, or browsers will carry on asking.
5. Hunt for the IOCs. The four domains and the IPs 38.146.28.75, 31.57.243.154, 104.194.159.150 are published; run them against your DNS and proxy logs for June and July. Also worth a look: authentications arriving from hosts you do not recognise, and devices freshly registered in Entra ID, since an attacker-enrolled device survives a password reset.

And if you happen to run the Wi-Fi rather than just use it, the whole thing started with management interfaces (SSH, SNMP, web consoles) reachable from the internet with weak or reused credentials. ReliaQuest only rates that low-to- medium confidence because they could not get inside the appliances. It is still where I would look first on my own kit.

One caveat worth keeping. The APT28 resemblance is ReliaQuest's assessment based on overlapping tradecraft, and they explicitly stop short of attributing it. The infrastructure is different, the targeting is different, and there is none of the keyword filtering the FrostArmada campaign used before it was disrupted in April. Whoever is doing this, the gateway answers your DNS either way.