touch-packages team mailing list archive

[Thomas Hood <1349011@xxxxxxxxxxxxxxxxxx>]

>>> undesirable behavior: all DNS queries go to the VPN nameservers
>> That is in most cases the *desired* behavior
> On today's systems, I don't think so. [...] Ubuntu run a dnsmasq instance...
> Rather than overwrite this...

You are right in saying that when there is a local forwarding nameserver
then it should be used (i.e., its address should be listed in
resolv.conf) instead of external nameservers.

Resolvconf is designed to implement this. If a nameserver address is
127.* or ::1 then resolvconf doesn't list any more addresses (provided
the value of the environment variable
TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS is 'y'). And if the
interface configurer follows resolvconf conventions and registers the
address using the pattern lo.CONFIGURER then resolvconf's interface
prioritization will cause a 127.* address to be listed first, and thus
listed exclusively.

Unfortunately, in Ubuntu, network-manager does not follow resolvconf
conventions. NetworkManager starts a local forwarding nameserver and
registers its listening address 127.0.1.1 under the record name
"NetworkManager" instead of the correct "lo.NetworkManager".
Consequently NetworkManager's record has a low priority as defined by
/etc/resolvconf/interface-order instead of a high priority. Consequently
nameserver addresses registered by other interface configurers can pre-
empt NetworkManager's local forwarding nameserver address. This is a
longstanding bug in NetworkManager.

> Well, if you work at home and connect to an employer's VPN,
> what earthly reason is there to send them all your Internet
> DNS lookups?

The only reason is that the most commonly used resolver libraries can't
route DNS traffic according to the name looked up; such a library
connects to a single nameserver which is expected to answer all queries.
The idea that the local system should know about multiple nameservers
having different information is foreign to DNS. So in general you want
to configure the resolver to contact the nameserver with the most
complete information.

Having said that, I grant that in the special case where you have a
private network with its own nameservers which have information about a
private (sub)namespace and you have a local forwarding nameserver
capable of routing DNS queries to the appropriate servers based on the
domain then there may be speed and privacy benefits to doing such
routing.

> There has to be a better way of handling this than excluding every one
specifically...

If the aforementioned bug were fixed then, in the case where
NetworkManager runs a local forwarding nameserver, it wouldn't do any
harm for PPP to register nameserver addresses with resolvconf because
those addresses would have lower priority than the loopback address in
lo.NetworkManager and wouldn't end up appearing in resolv.conf.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1349011

Title:
  nm-l2tp-service needs exception in ppp ip-up/down scripts

Status in resolvconf package in Ubuntu:
  Confirmed

Bug description:
  There is an actively maintained NetworkManager L2TP VPN plugin,
  available as an Ubuntu package here: https://launchpad.net/~seriy-
  pr/+archive/ubuntu/network-manager-l2tp. Hopefully it will be a part
  of Ubuntu soon.

  Like nm-pptp-service, it needs an exception in
  /etc/ppp/ip-{up,down}.d/000resolvconf (part of the resolvconf package)
  as follows:

  % diff /etc/ppp/ip-up.d/000resolvconf /tmp/resolvconf-1.69ubuntu1.1/debian/resolvconf.000resolvconf.ppp.ip-up
  16c16
  <   nm-l2tp-service-*|nm-pptp-service-*|/org/freedesktop/NetworkManager/PPP/*)
  ---
  >   nm-pptp-service-*|/org/freedesktop/NetworkManager/PPP/*)

  Since that's how it works for the PPTP plugin, could we add the L2TP
  one as well so that it can work out of the box on Ubuntu?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1349011/+subscriptions