Still an issue in 20.10
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1726124
Title:
DNS domain search paths not updated when VPN started
To manage notifications about this bug go to:
https://bugs.
** Tags added: fr-13
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1726124
Title:
DNS domain search paths not updated when VPN started
To manage notifications about this bug go to:
https://bugs.lau
Still an issue in 20.04 LTS
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1726124
Title:
DNS domain search paths not updated when VPN started
To manage notifications about this bug go to:
https://b
** Tags removed: ddstreet
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1726124
Title:
DNS domain search paths not updated when VPN started
To manage notifications about this bug go to:
https://bug
** Tags added: ddstreet
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1726124
Title:
DNS domain search paths not updated when VPN started
To manage notifications about this bug go to:
https://bugs.
My guess is that rls-bb-notfixing means this is not getting fixed in
Bionic Beaver 18.04. Really hoping a fix can make it into the 20.04 LTS
release though.
I agree with Paul - systemd-resolve is not doing what it promises to do.
>From systemd.network(5):
Both "search" and "routing-only" doma
What does that rls-bb-notfixing tag mean? This is just a bug that won't
be fixed? Split tunnel DNS with openconnect is still completely broken
in 19.04 and it would be very nice to have this working. The last
couple years of Ubuntu releases have required me to ditch systemd-
resolved in order to
So, is anyone going to fix this? It is in LTS now and causing havoc.
Fwiw, I support that it should allow split resolution just like it used
to do.
This change was a major breaking one that shouldn't have been forced on
people. Security opinions don't belong in implementation, only
configuration.
** Tags added: rls-bb-notfixing
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1726124
Title:
DNS domain search paths not updated when VPN started
To manage notifications about this bug go to:
https
** Tags removed: rls-bb-incoming
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1726124
Title:
DNS domain search paths not updated when VPN started
To manage notifications about this bug go to:
http
We won't be able to add the option to select between the two options
this cycle.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1726124
Title:
DNS domain search paths not updated when VPN started
To
I would also like to chime in, that it is very useful to have the
ability to append a DNS-suffix when doing short-name DNS lookups on a
split-tunnel VPN connection.
It would be great if the devs could find a way to include this
functionality in the upcoming LTS! :)
--
You received this bug notif
** Tags added: id-5a7491099adc12270ee9c94d
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1726124
Title:
DNS domain search paths not updated when VPN started
To manage notifications about this bug g
I'm not sure why it's being asserted that these two uses are mutually
incompatible, especially since I've been using them in a coordinated way
forever and can still do so (at the expense of junking systemd-resolve
and going back to using dnsmasq and a custom configuration, which is
obviously a big
I hope something can be worked out before this lands in the next LTS-
release. This breaks one of the most common uses of a VPN (remote work).
Right now a workaround is using this script after connecting to a VPN-
server:
https://github.com/jonathanio/update-systemd-resolved
It calls systemd-res
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: network-manager (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1726124
Tit
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: network-manager-openvpn (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1726
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: systemd (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1726124
Title:
DN
This change in behavior is deliberate. There are two mutually
incompatible interpretations of DNS search lists provided via a VPN
connection. One is for split DNS, to say "this is the list of domains
for which you should send lookups to the accompanying DNS server". The
other is to use it as a s
Andreas: unfortunately disallowing short name lookups is not acceptable:
many environments use short names in embedded URLs all over the place,
and without domain search paths the entire environment is rendered
completely unusable (e.g., URLs are simply https://tools/foo or
https://wiki/foo or what
BTW, the long timeout you see on short name lookup failures is most
likely due to LLMNR being on by default. I think this is insane and I
always switch it off in /etc/systemd/resolved.conf .
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubun
Paul Smith, what you describe is information leakage and shouldn't IMHO
work as you say by default.
Consider that I'm connected to a corporate network and have an
(untrusted) VPN active which I only want to use to access resources on
its network (never-default: yes). Then by having the resolver ad
to->two
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1726124
Title:
DNS domain search paths not updated when VPN started
To manage notifications about this bug go to:
https://bugs.launchpad.net/ub
Hi Sebastien, thanks for your interest. This issue is causing me
extreme pain. I believe I'm going to have to reconfigure N-M to use the
old-style dnsmasq setup and throw out systemd-resolve pretty soon.
It's not clear to me whether this is an N-M bug vs. a systemd bug, but
I'm happy to file mor
It would probably be a good idea to forward it to n-m upstream as well
on bugzilla.gnome.org
** Changed in: systemd (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/b
** Changed in: network-manager (Ubuntu)
Importance: Undecided => High
** Changed in: network-manager-openvpn (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/
** Tags added: rls-bb-incoming
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1726124
Title:
DNS domain search paths not updated when VPN started
To manage notifications about this bug go to:
https:
I'm not sure I understand what you mean. In a typical configuration you
never send "foo" to the nameservice, there's always a search domain and
those lookups are always tried first (because the default value for the
ndots is 1). This is handled by the libc resolver linked into every
program, it's
Right, so it seems like NM checks the never-default setting, and doesn't
push them as resolve domains =/ I will test things out to be sure.
Specifically:
$ nmcli c show YOUR_VNP_CONNECTION_NAME | grep never-default
ipv4.never-default: yes
ipv6.never-default:
Does everything work, if you route all traffic via VPN?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1726124
Title:
DNS domain search paths not updated when VPN started
To manage notifications abo
Thank you for the update. I will check the code, and will try to resolve
this as soon as possible.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1726124
Title:
DNS domain search paths not updated wh
To be clear, they are NOT updated in /etc/resolv.conf. They ARE updated
in /run/NetworkManager/resolv.conf, but that has no effect since we're
not using that for resolution: instead we're using systemd-resolve.
And as I noted above, it does appear that systemd-resolve is notified
about the search
network-manager has resolved integration and it does push search domains
to resolved and they are updated in the /etc/resolv.conf.
This should continue to work in 17.10. Hence marking this bug affect
network-manager and network-manager-openvpn
** Also affects: network-manager (Ubuntu)
Importan
33 matches
Mail list logo
