[vavrusa]

I reckon that depends on where you are. I don't have any hard data on this, just a lifetime of disappointment with hotel wifis. It's not the captive portal on first use what irks me, but continued DNS intercepting after you pass the captive portal challenge which hampers either DNSSEC, local resolver, or both. This is not likely to change soon, so DNS folks dream about DNS/HTTP, DNS/TLS and all that.

Intercepting actual content transfers makes more sense to me than intercepting name lookups. One thing should be common - once user authenticates, no more MitMing.

[edwhitesell]

I would agree with you. However, there are valid use-cases for "intercepting" DNS on public WiFi. The most obvious is to block adult content.

One example was a customer operating WiFi in restaurants. If a patron accessing the WiFi network was looking at adult content on their laptop, the restaurant owner could be liable for that. I believe it was a "public nudity/nuisance" law.

[vavrusa]

That is consented filtering and that's fine. I do the same thing locally and I'm okay with a public network operator refusing to serve certain zones (nudity, malware, illegal content).

Refusing to lookup a name != MitMing every query however, the latter crosses a fine line (for me) by both lying about answers (redirection to ad pages), and at the same time preventing users to validate integrity of the answer (or non-existence proof).

I'm not a lawyer and have no idea how much is this enforceable in terms and conditions of the service, but common sense tells me that by opting out of the provided name services liability transfers to patron. If the recursive resolution was more decentralised, this would have been moot.

[contingencies]

If you use public wifi you should really be establishing a VPN connection and then passing all traffic over that, only.