DNS cannot be resolved in Public / Hotel / Starbucks WiFi Hotspot

Bug #1766969 reported by Pete on 2018-04-25
This bug affects 12 people
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
Status tracked in Cosmic

Bug Description


 * More captive portals have been discovered that do not handle DNS requests with D0 set.
 * Thus extend previous aruba-networks fix from https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1727237 by retrying all NXDOMAIN results with lower feature levels just in case.

[Test Case]

 * systemd-resolved something-nonexistant.ubuntu.com
 * monitor the logs, and check that the transaction has been downgraded multiple times and tried at least once at a feature level below D0. There should be a downgrade message in the log.
 * Note, it will be cached, thus one may need to call $ systemd-resolved --flush-caches

[Regression Potential]

 * Legitimate NXDOMAIN queries will now take longer, as they will be retried multiple times with different features sets until an answer is found. At that point the query will be cached and will return quickly. This is needed to work-around bad captive portals that do not support dns queries with D0. Post-captive portal, the feature level can usually be cranked back up and it does after a grace period.

[Other Info]

 * Original bug report

I was asked to create a new bug for this in https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1727237 as it seems to be a different issue.

I have installed the nightly image of Kubuntu Bionic from 25th of April.

There systemd is in version 237-3ubuntu10.

When connecting to the wifi hotspot in my hotel (Quality Hotel Augsburg) I cannot open the hotspot landing page that should give me access to the WIFI. With Windows and on an Iphone it's working.

For the following distributions I can confirm it not working:
Kubuntu 17.10
Kubuntu 18.04 (nightly image 25th of April 2018)

The logs were taken on 18.04.

sudo systemctl disable systemd-resolved.service
sudo service systemd-resolved stop
sudo rm /etc/resolv.conf
sudo nano /etc/NetworkManager/NetworkManager.conf
  >> add "dns=default" under [main]
sudo service network-manager restart

Then I can connect to the WIFI and I see the login page in Firefox.

To capture some data I did the following:
 - connect to Hotspot
 - enter golem.de

Case 1: Fresh default Kubuntu install
With a default Kubuntu install it does not work. I can connect to the WIFI and get IP and DNS from DHCP but I cannot resolve any hostname. When trying to open the router ip directly in the browser it forwards to hotsplots.de which cannot be resolved.

Case 2: With aforementioned Workaround
I connect to the wifi, I open firefox and the login page shows up (if I havent been connected yet. In the capture I already was able to connect to the hotspot which allows immediately to connect to the webpage)

PS: I'll be in this hotel till Friday 27th if more information are required.

Pete (pt.pete.pt) wrote :

Wireshark logs for default conf of Kubuntu and logs with workaround

tags: added: dns systemd systemd-resolv
description: updated
Pete (pt.pete.pt) on 2018-04-25
description: updated
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in systemd (Ubuntu):
status: New → Confirmed
Steve Langasek (vorlon) wrote :

Can confirm that the dns logs indicate that systemd-resolved is not falling back from UDP+EDNS0 to UDP in response to these NXDOMAIN answers.

The existing patch only implements this fallback when the portal name being looked up includes 'secure' as a substring:

+ if (DNS_PACKET_RCODE(p) == DNS_RCODE_NXDOMAIN && t->current_feature_level >= DNS_SERVER_FEATURE_LEVEL_EDNS0) {
+ dns_resource_key_to_string(t->key, key_str, sizeof key_str);
+ if (strstr(key_str, "secure") != NULL) {
+ t->current_feature_level = t->current_feature_level - 1;
+ log_warning("Server returned error %s, suspecting DNS violation DVE-2018-0001, retrying transaction with reduced feature level %s.",

The packet capture shows a number of DNS lookups, but not containing the substring 'secure'; and none that appear to correspond to the captive portal itself. This may require a different sort of solution than the previous bug, I'm not sure.

I'm now questioning if it is at all sensible to use EDNS by default.

It seems like the fallback should be widened for all NXDOMAIN lookups.

I've validated, that lookups fail, when DNSSEC enabled (however with a SERVFAIL, rather than NXDOMAIN). Note DNSSEC is not enabled by default.

Mark Daku (markdaku) wrote :

I have encountered this bug as well.

I have raised it with systemd-resolved.
The internal resolver of systemd does not properly search the local dns. Only fqdn's will resolve. This is easily mitigated and does not require a whole bunch of enabling or disabling of things.

The DHCP process will almost always provide a valid DNS locally and the DHCP client in systemd does actually create a valid resolve.conf. You just have to point /etc/resolv.conf to it.

At the time of writing the systemd people refuse to accept that this is a bug. They continue to refer to it as a documentation issue. I honestly don't believe they are testing it.

# Just making sure I'm out of the / dir
cd /etc
# resolv.conf is a link to ../run/systemd/resolve/stub-resolv.conf Which directs thing to use the local resolved. So I nuke it.
sudo rm resolve.conf
# Then I go and use the actual resolv.conf that actually works.
sudo ln -s ../run/systemd/resolve/resolv.conf resolv.conf

The above workaround is good. It will allow you to take your laptop onto all different types of networks. It will work correctly. This is for at least systemd version 237 and above. I haven't checked to see if 236 has the proper file generated or not.

Steve Langasek (vorlon) wrote :

> The internal resolver of systemd does not properly search the local dns.
> Only fqdn's will resolve. This is easily mitigated and does not require
> a whole bunch of enabling or disabling of things.

That is unrelated to this bug report.

I have the latest systemd recommended by #1727237, and this issue still occurs at Starbucks as well. The Starbucks WIFI defect is #1767900 which appears to be a duplicate of this one.

ii systemd 237-3ubuntu10 amd64 system and service manager

I'm in a Starbucks now. #1727237 (the systemd above) does not fix my issue. aruba.odyssys.net is still not resolved using the stub-resolv.conf file (linked from /etc/resolv.conf).

cd /etc
sudo /bin/rm resolv.conf
sudo /bin/ln -s ../run/systemd/resolve/resolv.conf resolv.conf

Using the original resolv.conf however, as per the changes above, does work. I did not make any changes to /etc/hosts. The real resolv.conf above contains the google nameservers and is sufficient to resolve aruba.odyssys.net.

search home

Steve Langasek (vorlon) wrote :

I can reproduce @earth2mark-eeepc's findings at another Starbucks.

mike stewart (mdrmike) on 2018-05-17
summary: - DNS cannot be resolved in Hotel Hotspot
+ DNS cannot be resolved in Public / Hotel / Starbucks WiFi Hotspot
mike stewart (mdrmike) wrote :

This seems to affect many public Wifi Hotspots. A very common example is the new setup by Starbucks/Google (usually seen as **Google Starbucks Wifi**) in the US by (Tech behind it is https://globalreachtech.com/ with their http://odyssys.net/).

Under Ubuntu 16.04, Windows, Android, Mac OS, or iPhone, a WiFi guest user can connect without problem. However, since upgrading to Ubuntu 18.04, I've encountered this in at least three separate Starbucks stores in Southern California.


An easier workaround, with fewer system modifications than the original bug report is to use `ip route` to determine the IP address of the host router, then add the hostname with that adress to `/etc/hosts`

Step by step details can be found here: https://askubuntu.com/a/1027605/139249

Changed in systemd (Ubuntu Cosmic):
status: Confirmed → Fix Committed
description: updated
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in systemd (Ubuntu Artful):
status: New → Confirmed
Changed in systemd (Ubuntu Bionic):
status: New → Confirmed

Hello Pete, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in systemd (Ubuntu Bionic):
status: Confirmed → Fix Committed
tags: added: verification-needed verification-needed-bionic
Pete (pt.pete.pt) wrote :


I'd love to help but i won't be in the affected hotel anytime soon.

So i hope some of the others could test.

Best regards, Pete

Using 237-3ubuntu10.1, with as DNS server, the resolutions of nonexistant.ubuntu.com and secure.ubuntu.com both are retried with following messages in the journal:
systemd-resolved[1434]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.

With 237-3ubuntu10, a similar message only appeared for "secure.ubuntu.com" NXDOMAIN query, but not for the nonexistant.ubuntu.com.

tags: added: verification-done verification-done-bionic
removed: verification-needed verification-needed-bionic
Steve Langasek (vorlon) wrote :

I confirm that this fixes the problem for the newly rolled out Starbucks aruba hotspots.

Tom McLaughlin (thomasjm42) wrote :

I confirm that 237-3ubuntu10.1 works also

Pete (pt.pete.pt) wrote :

@Tom: Than it's not the same issue. As this is the version the bug was reported with.

Pete (pt.pete.pt) wrote :

Correction: I did not see the .1 in your version number.

Jeff Nessen (jeff-jeffy) on 2018-06-05
Changed in systemd (Ubuntu Bionic):
status: Fix Committed → Fix Released
Jeff Nessen (jeff-jeffy) wrote :

Obviously I didn't just jump in and release a fix. I accidentally updated the status and can't set it back. Sorry folks. I didn't mean to get anyone excited about the fix being out.

Changed in systemd (Ubuntu Bionic):
status: Fix Released → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments