systemd-resolved is not finding a domain

Bug #1727237 reported by Mark Shuttleworth
94
This bug affects 16 people
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
Fix Released
High
Unassigned
Xenial
Triaged
High
Unassigned
Zesty
Won't Fix
Undecided
Unassigned
Artful
Won't Fix
High
Unassigned
Bionic
Fix Released
High
Unassigned

Bug Description

[Impact]

 * Certain WiFi captive portals do not support EDNS0 queries, as per RFC.
 * Instead of responding with the captive portal IP address, they resond with domain not found
 * This prevents the user from hitting the captive portal login page, able to authenticate, and gain access to the internets.

[The Fix]

 * As per tcp dumps, the problem arrises from receiving NXDOMAIN when queried with EDNS0
 * And receiving the right response without EDNS0
 * The solution was to downgrade transactions, and retry EDNS0 + NXDOMAIN result without EDNS0 with a hope of getting the right answer.

[Test Case]

* systemd-resolve securelogin.example.com
* journalctl -b -u systemd-resolve | grep DVE-2018

You should obverse that a warning message that transaction was retried with a reduced feature level e.g. UDP or TCP.

After this test case is performed the result will be cached, therefore to revert to pristine state perform

* systemd-resolve --flush-caches

[Regression Potential]

 * The code retries, and then caches, NXDOMAIN results for certain queries (those that have 'secure' in them) with and without EDNS0.

 * Thus initial query for these domains may take longer, but hopefully will manage to receive the correct response.

 * Manufacturers are encouraged to correctly support EDNS0 queries, with flag D0 set to zero.

[Other Info]

 * This issue is tracked as a dns-violation at
https://github.com/dns-violations/dns-violations/blob/master/2018/DVE-2018-0001.md

[Original Bug report]

I have an odd network situation that I have so far managed to narrow down to the inability to resolve a domain via systemd-resolved which is resolvable with nslookup. If I use nslookup against the two nameservers on this network I get answers for the domain, but ping says it is unable to resolve the same domain (as do browsers and crucially the captive portal mechanism).

Here are details:

NSLOOKUP:

~$ nslookup securelogin.arubanetworks.com 208.67.220.220
Server: 208.67.220.220
Address: 208.67.220.220#53

Non-authoritative answer:
Name: securelogin.arubanetworks.com
Address: 172.22.240.242

~$ nslookup securelogin.arubanetworks.com 208.67.222.222
Server: 208.67.222.222
Address: 208.67.222.222#53

Non-authoritative answer:
Name: securelogin.arubanetworks.com
Address: 172.22.240.242

PING:

~$ ping securelogin.arubanetworks.com
ping: securelogin.arubanetworks.com: Name or service not known
mark@mark-X1Y2:~$

DIG:

~$ dig @208.67.222.222 securelogin.arubanetworks.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @208.67.222.222 securelogin.arubanetworks.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9416
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;securelogin.arubanetworks.com. IN A

;; AUTHORITY SECTION:
arubanetworks.com. 1991 IN SOA dns5.arubanetworks.com. hostmaster.arubanetworks.com. 1323935888 3600 200 1209600 86400

;; Query time: 34 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Wed Oct 25 10:31:10 CEST 2017
;; MSG SIZE rcvd: 144

MORE DIG:

~$ dig securelogin.arubanetworks.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> securelogin.arubanetworks.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3924
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;securelogin.arubanetworks.com. IN A

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Wed Oct 25 10:34:01 CEST 2017
;; MSG SIZE rcvd: 58

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

What is the release / package version in use of systemd?

How is the networking configured: netplan, ifupdown, networkd, networkmanager?

What is the contents of /etc/resolv.conf?

Where does the symlink of /etc/resolv.conf point to? (if it is a symlink)

What is the contents of /etc/systemd/resolved.conf ?

Is libnss-resolve package installed?

What is the output of $ systemd-resolve --status ?
(if --status option is available)

Is this a captive portal hostage situation with Ubuntu failing to get to the captive portal to enable internet?

Changed in systemd (Ubuntu):
status: New → Incomplete
Revision history for this message
Mark Shuttleworth (sabdfl) wrote :

Yes, this is a captive portal situation on up-to-date 17.10. The captive portal popup fails with a DNS error looking for securelogin.arubanetworks.com and then hilarity ensues. Manually editing /etc/resolv.conf to use one of these DNS servers makes it all work. So the problem is systemd-resolved which is the default resolv.conf:

~$ cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53

search invitados

It's all NM:

~$ cat /etc/netplan/01-network-manager-all.yaml
# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager

Should /etc/resolv.conf be a symlink?

libnss-resolve is not installed.

systemd-resolve --status shows the two local DNS servers, as above.

~$ systemd-resolve --status | cat -
Global
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 7 (wwp0s20f0u6i12)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 4 (wlp4s0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 208.67.222.222
                      208.67.220.220
          DNS Domain: invitados

Link 2 (enp0s31f6)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Revision history for this message
Matthew Alberti (matthewalberti) wrote :

I also experienced this problem on Ubuntu 17.10. Tried to connect to a wifi network, that utilized a captive portal, failed miserably. The DNS redirect to the captive portal would not occur. Manually overwriting /etc/resolv.conf with nameservers other than "127.0.0.53" got me to the captive portal login page. I spent a few hours on vacation trying to workaround this. Really unfortunate problem.

Revision history for this message
Matthew Alberti (matthewalberti) wrote :

What is the release / package version in use of systemd?
234-2ubuntu12.1

How is the networking configured: netplan, ifupdown, networkd, networkmanager?
networkmanager (I presume, ubuntu 17.10 default)

What is the contents of /etc/resolv.conf?
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53

Where does the symlink of /etc/resolv.conf point to? (if it is a symlink)
../run/systemd/resolve/stub-resolv.conf

What is the contents of /etc/systemd/resolved.conf ?
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details

[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=yes
#MulticastDNS=yes
#DNSSEC=no
#Cache=yes
#DNSStubListener=udp

Is libnss-resolve package installed?
No.

What is the output of $ systemd-resolve --status ?
(if --status option is available)
Global
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 2 (wlp2s0b1)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 172.16.50.1

Is this a captive portal hostage situation with Ubuntu failing to get to the captive portal to enable internet?
Yes.

Revision history for this message
oiugews (ioewqnf) wrote :

All captive portal wifi connections are failing with Ubuntu 17.10. This was confirmed on two different captive portals which both worked just fine with other devices. The solution was to go back to Ubuntu 17.04.

You get to the portal page, put in whatever info, then afterwards the redirect wouldn't redirecting properly. This failed in both Chromium and Firefox, and with both "use system proxy" as well as "automatic proxy" settings. Manual proxy configuration settings weren't tried, so I can't confirm if this might be a problem relating to the proxy pac file or not.

Either way this is a pretty critical issue since it seems all captive portals don't work, making Ubuntu 17.10 on laptops pretty broken at the moment.

Revision history for this message
Rob Schultz (rob-schultzfamily) wrote :

The issue is with systemd-resolvd not adding the captive portal DNS after the logon. This worked fine with dnsmasq in 16.04 (and I assume 17.04).

For my laptop I have currently changed to 'unbound' for DNS resolution. Note: If you are running Qemu/KVM you will want to keep dnsmasq-base package.

Will Cooke (willcooke)
Changed in systemd (Ubuntu):
status: Incomplete → New
status: New → Confirmed
Revision history for this message
Seth Arnold (seth-arnold) wrote :

I thought I'd add the information from my favourite DNS debugging tool while the data may still be close to useful:

dnsviz reports NXDOMAIN for securelogin.arubanetworks.com http://dnsviz.net/d/securelogin.arubanetworks.com/dnssec/

dnsviz also currently reports three warnings:

- com to arubanetworks.com: Authoritative AAAA records exist for dns5.arubanetworks.com, but there are no corresponding AAAA glue records.
- com to arubanetworks.com: The following NS name(s) were found in the authoritative NS RRset, but not in the delegation NS RRset (i.e., in the com zone): dns6.arubanetworks.com
- com to arubanetworks.com: The following NS name(s) were found in the delegation NS RRset (i.e., in the com zone), but not in the authoritative NS RRset: dns4.arubanetworks.com

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Checking for the state of the domain from outside a captive portal won't get much; "securelogin.arubanetworks.com" only exists while you're behind the captive portal, in unauthenticated mode.

I think the next steps will be to do some testing with various captive portals and see why systemd-resolved is unhappy with them. As far as I can tell from the provided answers, everything is in place (/etc/resolv.conf has the right values, systemd-resolved knows about the right nameservers, so some part of resolved is failing to send/receive the DNS messages in a meaningful way: this has all the hallmarks of a systemd-resolved bug.

The next steps for debugging this will be to stop systemd-resolved and restart it, then attempt to resolve the domain normally (via ping, for example):

sudo systemctl stop systemd-resolved
sudo SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-resolved

ping securelogin.arubanetworks.com

And carefully look through the logs to figure out what systemd is unhappy with. I'll do this on my end as well, but if anyone can provide the same logs, that would be very helpful.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

So I managed to reproduce this in a way that looks correct (Starbucks WiFi here uses Datavalet but fails in a way that looks the same: it thinks you're logged in once you clicked the "Login" button on the captive portal page once, but then updates DNS, but still attempts to look up secure.datavalet.io (but this is no longer resolving because we're in the public side now); and once you try to hit another site, you did not get to the "landing" page on the public side so it thinks you're still unauthenticated.

One one hand, this looks like just really terrible behavior of the captive portal, and it "worked" only because we were pretty slow to deal with the changing settings; or because we were caching the DNS responses for just long enough.

I got logs from my reproducer as well as packet captures, and I will have to comb through them to figure out if there's anything really obscure and wrong, but my initial guess is that this is an issue related to DNS caching. Probably the cache is invalidated when the IP changes as we get to the public side, but ought to retain the resolution address for the portal.

It needs a little more investigation and testing, but I think this qualifies as "Triaged" now; and should have some fix or workaround to deal with Aruba and Datavalet, both are reasonably common hotspot infrastructure.

Changed in systemd (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → High
Revision history for this message
Steve Langasek (vorlon) wrote :

My understanding is that systemd-resolved as shipped in Ubuntu is meant to not have DNS caching enabled at all.

  https://lists.ubuntu.com/archives/ubuntu-devel/2016-June/039375.html

Looking at the default resolved.conf and the resolved.conf(5) manpage, it appears we do have DNS caching enabled.

Dimitri, is this an oversight, or was there some further discussion with the Security Team that resulted in caching being enabled?

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

I believe caching is enabled by default, this might be a regression in behaviour since switching to 127.0.0.53 caching resolver. It does drop caches upon every new connection / re-connection.

It is freezing out there and snowing out there. But I guess I'll have to make trek to Starbucks with my laptop tomorrow. Also will watch out for this bug happening during my travels next week through different airports.

int manager_new(Manager **ret) {
...
m->enable_cache = true;
...
r = manager_parse_config_file(m);
...
}

[Resolve]
...
#Cache=yes

Revision history for this message
Mark Shuttleworth (sabdfl) wrote : Re: [Bug 1727237] Re: systemd-resolved is not finding a domain

Thanks all, and Dimitri allow me to sponsor that Starbucks coffee :)

Changed in systemd (Ubuntu Bionic):
status: Triaged → Fix Committed
Revision history for this message
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 Zesty):
status: New → Confirmed
Revision history for this message
Axel (nospamforaxel-1) wrote :

Can we know what's the fix?

I apologize but I cannot recognize the patch in this thread.

I am running ubuntu 17.10 and am affected by a securelogin.arubanetworks.com-company-public-network.
I would like to test the fix.
How can I do that?

Thank you very much in advance.

Best regards

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

So, after looking at it more, it seems the issue with Datavalet is due to EDNS0-enabled queries failing to be captured and rewritten by the captive portal. It might not in fact be the same issue as for securelogin.arubanetworks.com, though the wireless hardware comes from the same manufacturer.

I have a tentative patch ready for secure.datavalet.io; I will adapt it to work the same way for securelogin.arubanetworks.com, and I'll put all this in a PPA for testing.

Unfortunately, I haven't found a location that uses securelogin.arubanetworks.com; so we will need to others (if you remember where you encountered such a network) to make sure it really works correctly before uploading to release.

Revision history for this message
Axel (nospamforaxel-1) wrote :

I would like to test it here with our public company-network that uses securelogin.arubanetworks.com.

However, I run 17.10 on my laptop and installing the whole new systemd 235 from Bionic is not so straightforward I experienced. I gave up with too many unfulfilled dependencies.

So could you give me instructions how to load this patch into Artful?

Thank you in advance.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Packages are in my ppa: https://launchpad.net/~cyphermox/+archive/ubuntu/sru/+packages

For bionic and xenial. I'll do one further build for artful.

From the look of things though, this will only be built and ready for amd64/i386, not for other architectures just yet.

Changed in systemd (Ubuntu Bionic):
status: Fix Committed → Triaged
Changed in systemd (Ubuntu Artful):
status: Confirmed → Triaged
Changed in systemd (Ubuntu Zesty):
status: Confirmed → Won't Fix
Changed in systemd (Ubuntu Artful):
importance: Undecided → High
Changed in systemd (Ubuntu Bionic):
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
Changed in systemd (Ubuntu Artful):
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

I updated the importance and status as well, this bug was not in fact Fix Committed, I checked with Dimitri. Fix Committed was set because of the proposed change to caching, but it doesn't look like it helps.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Xenial is affected too (systemd v229 looks to be, in general), so when SRUing we might as well push the fix there too, even if resolved is not typically used on Xenial.

Changed in systemd (Ubuntu Xenial):
status: New → Triaged
importance: Undecided → High
Revision history for this message
Pete (lance321) wrote :

I also have been experiencing this. Connecting to WiFi network that uses any captive portal fails.

I dual boot with Windows, and everything is fine in Windows.

System:
Ubuntu 17.10 (Clean install)

Behavior:
After authenticating with the portal and connecting I cannot resolve DNS.

My work around (after a lot of digging) was to edit "/etc/resolv.conf"

And add "nameserver 8.8.8.8" (Google Public DNS)

So my nameserver looked liked:

nameserver 127.0.0.53
nameserver 8.8.8.8

I had to do this after every reboot obviously.

Also very peculiar:
I have been using this work-around every day since installing 17.10 one week ago. However, I connected to a regular home WiFi network (non-captive portal) fine last night. Then after returning to my work captive-portal WiFi network its now connecting and resolving DNS successfully. Without having to update my /etc/resolv.cong. I don't understand why...

Wanted to mention while searching forums and bug reports I came across many reported bugs that are likely duplicates of this issue. Where users are reporting spotty or intermittent WiFi issues etc. Many think its kernel and driver issues, while this isn't the case.

Revision history for this message
Axel (nospamforaxel-1) wrote :

@ #19: Mathieu,
I included the '234-2ubuntu12.3~mtrudel1' from the ppa you mention to my computer.
Unfortunately no change in behavior. I am still not forwarded to the captive portal after connecting to this particular wifi.
Do you have a suggestion what I could try?

@ #20: Does this: 'but it doesn't look like it helps.' mean that the new systemd does not fix the bug and therefore it does not work on my side?

Axel

Revision history for this message
Pete (lance321) wrote :

I too am still encountering this issue.

Since I can't resolve the webpage to the captive portal I have to manually enter its IP 1.1.1.1

Then accept the agreement. However afterwards DNS still fails to resolve web-pages.

Today I edited /etc/resolv.conf as before, adding Google DNS to show this.

nameserver 127.0.0.53
nameserver 8.8.8.8

But I noticed resolving DNS was slow, because 127.0.0.53 was failing. And after timing out it goes to the Google DNS 8.8.8.8.

After removing 127.0.0.53 in the file and only using "nameserver 8.8.8.8" everything works fine and quickly.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

@Axel, can you record what you see on the screen as you login (I do not need to see keypresses, but maybe seeing what happens on screen as things refresh would help).

Also, have you tried what I wrote in comment #8, stopping systemd-networkd, restarting with the debugging enabled, and reproducing the issue in a browser (and then attaching the logs here)?

Revision history for this message
Axel (nospamforaxel-1) wrote :

@Mathieu,
Were the logs I sent you of any value to you for the debugging?

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

I can't seem to find where you sent me logs?

tags: added: id-5a1c75741121466ff62dc286
Revision history for this message
Mario Limonciello (superm1) wrote :

@cyphermox,

I can readily reproduce this using my company's guest network with current systemd in Bionic. We use "securelogin.networks.dell.com" for our redirector. If I can provide something useful, happy to do so.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Please note this issue is now documented as a DNS violation at
https://github.com/dns-violations/dns-violations/blob/master/2018/DVE-2018-0001.md

@superm1

1. Start wireshark, start recording traffic across all interfaces, turn wifi on, try to connect to the guest network, fail, stop collecting the traffic and please send it to me (via here, new private bug, to my email, ping me a url with the dump - as appropriate).

2. Get online (or pre-cache these ahead of time) and upgrade to:

$ sudo add-apt-repository ppa:ci-train-ppa-service/3216; sudo apt update; sudo apt full-upgrade; sudo reboot

3. Rince repeat full wireshark dump & send that to me as well.

Note: https://launchpadlibrarian.net/362123426/systemd_237-3ubuntu4_237-3ubuntu5.diff.gz
It hardcodes securelogin.networks.dell.com, and I expect to see "DVE-2018-0001" in $ journalctl -u systemd-resolved
If this PPA works, then we can assert that EDNS0 is broken with these captive portals. Or if things don't work either way, then it's something else. So far, this is our best guess.

Revision history for this message
Mario Limonciello (superm1) wrote :

Dimitri,

I've performed your tasks and can confirm with that PPA applied that it works properly.
I've emailed you the packet captures privately to your @ubuntu.com address.

I also do note the following in my journal log:
Mar 26 12:18:43 test-XPS-13-9350 systemd-resolved[507]: DVE-2018-0001 DOWNGRADING to feature level UDP for transaction 10122.
Mar 26 12:18:43 test-XPS-13-9350 systemd-resolved[507]: DVE-2018-0001 DOWNGRADING to feature level UDP for transaction 29698.

tags: added: id-5ab9403dee8a8479eed4dba6
Changed in systemd (Ubuntu Bionic):
status: Triaged → Fix Committed
assignee: Mathieu Trudel-Lapierre (cyphermox) → Dimitri John Ledkov (xnox)
Changed in systemd (Ubuntu Artful):
assignee: Mathieu Trudel-Lapierre (cyphermox) → nobody
description: updated
Revision history for this message
Steve Langasek (vorlon) wrote :

Dimitri, can you please confirm what the effect of this patch is when a user has manually reconfigured resolved to enable DNSSEC? Does this do the right thing, or does it become a downgrade attack?

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package systemd - 237-3ubuntu8

---------------
systemd (237-3ubuntu8) bionic; urgency=medium

  * Workaround captive portals not responding to EDNS0 queries (DVE-2018-0001).
    (LP: #1727237)
  * resolved: Listen on both TCP and UDP by default. (LP: #1731522)
  * Recommend networkd-dispatcher (LP: #1762386)
  * Refresh patches

 -- Dimitri John Ledkov <email address hidden> Thu, 12 Apr 2018 12:12:24 +0100

Changed in systemd (Ubuntu Bionic):
status: Fix Committed → Fix Released
Tony (toekneemi)
Changed in systemd (Ubuntu Bionic):
assignee: Dimitri John Ledkov (xnox) → Tony (toekneemi)
Jeremy Bícha (jbicha)
Changed in systemd (Ubuntu Bionic):
assignee: Tony (toekneemi) → nobody
Revision history for this message
Axel (nospamforaxel-1) wrote :

Hmm... I've installed systemd 237-3ubuntu8.

Nevertheless I don't get forwarded to the captive-portal website to login :-(.

What do I do wrong?

Axel

Revision history for this message
Pete (pt.pete.pt) wrote :

I freshly installed the latest Kubuntu Bionic nightly image from today night. That should be rather close to tomorrow's release.

There systemd 237-3ubuntu10 is installed. However, it still does not work. I can not resolve dns out of the box in my Hotel wifi (Quality Hotel Augsburg, Germany).

The support of the hotspot provider forwarded me to this bug and assumed it to be solved in 18.04.

Revision history for this message
Steve Langasek (vorlon) wrote :

On Wed, Apr 25, 2018 at 07:18:34PM -0000, Pete wrote:
> I freshly installed the latest Kubuntu Bionic nightly image from today
> night. That should be rather close to tomorrow's release.

> There systemd 237-3ubuntu10 is installed. However, it still does not
> work. I can not resolve dns out of the box in my Hotel wifi (Quality
> Hotel Augsburg, Germany).

> The support of the hotspot provider forwarded me to this bug and assumed
> it to be solved in 18.04.

Please open a separate bug report about this issue. "DNS not resolving" is
a high-level symptom which may have a cause unrelated to this bug.

Revision history for this message
Jeremy Bícha (jbicha) wrote :

Axel and Pete, please file new separate bugs for your issues. This particular bug is closed for Ubuntu 18.04 LTS.

Revision history for this message
Pete (pt.pete.pt) wrote :
Revision history for this message
Steve Dodd (anarchetic) wrote :

The fix for this bug is causing me problems with name resolution on the LAN using dnsmasq as an upstream server:

https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1785383/comments/4

Changed in systemd (Ubuntu Artful):
status: Triaged → Won't Fix
Revision history for this message
Ubfan (ubfan1) wrote :

I found the addition of the 18.04 libnss-resolve package fixed my (intermittent) problems with name-resolution failures. Earlier comments indicate this package was not installed. The installation alters the nsswitch.conf file's hosts line to add "resolve [!UNAVAIL=return]" before "dns".

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.