DNS is not working

[rgaudin]

I don't know if this is due to some "weirdness" in my setup but on the image I created I failed to get DNS answers from the raspberry. I had to configure the IP manually in /etc/hosts and then everything was fine.

It is important to note that the captive portal was OK.

The hostname was metrics4.hotspot.

I'm on MacOS Monterey 12.7.1.

The DNS server and TLD have been properly setup automatically once associated with the Wifi but it looks like nothing was responding to DNS queries on 192.168.2.1

That been said, I don't know exactly what should respond to these queries in the image, my knowledge of the base image is too limited 🤣

Edit: In fact dig metrics4.hotspot @192.168.2.1 is working OK, only dig metrics4.hotspot is not responding, so the issue seems to be more linked to the fact that my machine is not really using 192.168.2.1 as DNS server.

[kelson42]

@rgaudin DNS client cache? What is rhe TTL of these DNS responses?

[rgaudin]

OK this is finally fixed. I had a draft issue about the CP Webview not closing on iOS when Pi is offline but made the mistake to consider your ticket a potentially different problem that should be fixed first. That rabbit hole was very deep and as absurd as Alice's!

Background: when the Pi is Online, it acts as a DNS relay to upstream servers (CloudFare and Google) so once you've registered to the CP, you're good to go. That was working fine.

When offline, the DNS server provides all answers. .hotspot ones are for the Pi and others were responded with 1.1.1.1 in order to have clients go through our routing table.

One problem was that DNSmasq isn't reliably responding with our static target when it has upstream servers configured (even though those are not reachable and have never been). This is visible in the logs. Some requests get their static responses, some are “forwarded” (this times out). This was fixed by conditionally feeding upstream to dnsmasq.

Another problem is that Systems (macOS and iOS but also windows11 from what I've seen) gets really funky without a working DNS setup.

Solving this was done by enforcing the CP – which is the best behavior if you think about it: either you're accessing the Pi via a .hotspot address or you're looking for something else and should be reminded that there's only the hotspot.

We're doing this by returning a different address for all those non-hotspot domains (198.51.100.1: reserved for tests) and then in our CAPTIVE_PASSLIST chain (where our client IP gets checked for registration), we first check if the destination IP is that one and then return from the chain, making all those request end-up in the captive portal.

Check the sample routing table here if you're interested ; it's more explicit.

This has been tested only-offline, only-online and changing status as well.