Tanks. I'll make this change upstream in Debian too.
--
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/1680811
Title:
Request to add wireguard interface to
** Changed in: resolvconf (Ubuntu)
Status: Incomplete => Invalid
--
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/1663345
Title:
10-15 seconds delay until host is
Wait a sec, I just noticed that you have the line "nameserver 127.0.0.1"
in your /etc/resolvconf/resolv.conf.d/head file. Remove that line, it
shouldn't be there.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in
Please post the output of /usr/share/resolvconf/dump-debug-info run from
a terminal.
--
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/1663345
Title:
10-15 seconds delay
Make sure "RESOLVCONF=no" in /etc/default/bind9. If not, set
RESOLVCONF=no in /etc/default/bind9 and restart.
--
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/1663345
** Changed in: resolvconf (Ubuntu)
Status: New => Incomplete
--
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/1663345
Title:
10-15 seconds delay until host is
Have you unintentionally installed either the dnsmasq or the bind9
package?
--
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/1663345
Title:
10-15 seconds delay until
I revised the patch slightly (to put the wl* names with the wifi* names)
and have applied it to the Debian package which I plan to release soon.
** Attachment added: "interface-order-patch_20170213-th1"
Hi, I understand why you might suggest this but on balance I don't think
that resolvconf should be so verbose in normal operation.
** Changed in: resolvconf (Ubuntu)
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
I am not convinced that this patch is correct. (I will look more
carefully when I return from a trip.)
Are you aware that resolvconf by default (unless
TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS=no) truncates the list
of nameservers after a loopback address?
** Changed in: resolvconf
Right, I think the file should only document the Ubuntu-specific things
such as the facts that by default resolvconf and the systemd resolver
are used, NetworkManager is used by default on Desktop and ifup on
Server, and so on. There have been hundreds of questions about these
basic things on
If such a comment were to be added then in order not to mislead it would
have to take into account the configurability of various components. So
you'd have to say something like:
«If the line "nameserver 127.0.0.53" is present then it probably refers
to the systemd resolver listening on the
Compare bug #1631241.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1637700
Title:
Caching dnsmasq stops resolving after some time
Status in Ubuntu:
New
Edit /etc/NetworkManager/NetworkManager.conf and comment out the line
"dns=dnsmasq" with a leading '#'. Then reboot.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
NetworkManager is starting a dnsmasq instance whereas it shouldn't do
that any more.
** Package changed: dnsmasq (Ubuntu) => ubuntu
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
In yakkety there is no longer supposed to be a local forwarding
nameserver (instance of dnsmasq) listening at 127.0.1.1. Instead an
instande of resolved is started. Name resolution requests are fed to it
via the name service switch (configured with nsswitch.conf) rather than
via the libc resolver
** Changed in: resolvconf (Ubuntu)
Status: New => Incomplete
** Changed in: ifupdown (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
Are there cases where the interface is configured properly but
resolv.conf is not updated to include material from the dns-* lines?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
Obviously the presence of material in the "base" file should have no
effect on the processing of material from /etc/network/interfaces. Are
you still sure that material from /e/n/i is sometimes incorrectly
omitted from the /etc/resolv.conf file?
--
You received this bug notification because you
Comment lines from the "base" file are always omitted from resolv.conf.
Try adding a line "search bogus.com“ and see if "bogus.com" shows up on
the "search" line in resolv.conf.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to
Hi and thanks for the report. How 'bout a patch?
--
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/1610479
Title:
interface-order needs definitions for systemd
Thanks for the bug report. Yes, this is a bug. Here's a patch I have
applied to the Debian version which will appear shortly in Debian
resolvconf version 1.80. This should fix the bug in the Ubuntu version
of the package when it's merged.
** Attachment added: "resolvconf_bug_1593489_patch"
This possibly arises from bug #1003842.
What is possibly happening: the second or third nameserver on the list
of available nameservers supplied to dnsmasq replies quickly to
dnsmasq's query with a negative answer and dnsmasq immediately passes
that negative answer back to the resolver.
When
** Summary changed:
- DNS resolution stops working after sometime
+ DNS resolution stops working after some time
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1522057
** Changed in: dnsmasq (Ubuntu)
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1577720
Title:
dnsmasq resolves xyzzy.xyzzy.xyzzy. to
*** This bug is a duplicate of bug 1003842 ***
https://bugs.launchpad.net/bugs/1003842
What remains unexplained is why the dnsmasq package was installed on
your machine at all. Is it the case that dnsmasq was not installed
before the upgrade and it was installed after the upgrade? In that
*** This bug is a duplicate of bug 1003842 ***
https://bugs.launchpad.net/bugs/1003842
** This bug has been marked a duplicate of bug 1003842
dnsmasq sometimes fails to resolve private names in networks with
non-equivalent nameservers
** Package changed: resolvconf (Ubuntu) => dnsmasq
That name service does not work properly when dnsmasq is installed is
most probably due to bug #1003842. If that is the case then if you
remove 8.8.8.8 from the list of nameserver addresses then name service
will work reliably.
--
You received this bug notification because you are a member of
Everything looks correct. Does name service work both when dnsmasq is
installed and when it is not installed? If so then there is no problem.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
If you install the dnsmasq package then that package starts a standalone
instance of the dnsmasq program and resolv.conf will contain a line
`nameserver 127.0.0.1` which tells the resolver to consult that instance
of the dnsmasq program, which will by default forward DNS queries to the
nameservers
Not dnsmasq but dnsmasq-base is pulled in by ubuntu-desktop.
If you define your interfaces statically using /etc/network/interfaces
then you have to add the nameserver information to
/etc/network/interfaces on lines like "dns-nameserver 1.2.3.4". See
resolvconf(8) for more info.
** Changed in:
*** This bug is a duplicate of bug 1003842 ***
https://bugs.launchpad.net/bugs/1003842
This is the known bug #1003842. Workaround: comment out "dns=dnsmasq" in
/etc/NetworkManager/NetworkManager.conf
** This bug has been marked a duplicate of bug 1003842
dnsmasq sometimes fails to resolve
** Description changed:
- resolveconf does not reliable receive nameserver information from
- network manager.
+ resolvconf does not reliable receive nameserver information from
+ NetworkManager.
In the journal I see things like:
Apr 11 11:13:52 ottawa dnsmasq[3122]: setting upstream
br matching was added to interface-order in Debian release 1.77, thus in
wily which has resolvconf 1.77ubuntu1.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1384394
The content of the base file is processed, but due to resolvconf's rules
they may fail to show up in resolv.conf. Comments in the base file get
discarded. Lines like "nameserver w.x.y.z" are omitted if another line
is, e.g., "nameserver 127.0.1.1.". If you set
Do you have the "dnsmasq" package installed and is the instance of the
dnsmasq program started by the "dnsmasq" package configured to listen at
127.0.1.1?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
First, it appears that NetworkManager doesn't handle the error well and
retries without sleeping. Needs fixing.
Separate issue: Why is the error occurring on your machine? Why do you
get "dnsmasq[30613]: failed to create listening socket for 127.0.1.1:
Address already in use"?
--
You received
To prioritize pdns-recursor's listen address in resolv.conf, edit
/etc/resolvconf/interface-order and replace the line
lo.!(pdns|pdns-recursor)
with the following line.
lo.*
See https://bugs.debian.org/308677 for background.
** Package changed: resolvconf (Ubuntu) => pdns-recursor
Try purging and reinstalling the resolvconf package.
Is there anything unusual about your machine?
--
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/1525613
Title:
** Package changed: resolvconf (Ubuntu) => dnsmasq (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1516329
Title:
DNS BUG delay resolution of LAN DNS
Status in
*** This bug is a duplicate of bug 1042275 ***
https://bugs.launchpad.net/bugs/1042275
** This bug has been marked a duplicate of bug 1042275
Please enhance dnsmasq to talk directly to resolvconf and to register only
its actual listening address(es)
--
You received this bug notification
Can you please try to figure out what part of the resolvconf postrm
script is yielding the exit status 128?
** Changed in: resolvconf (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to
** Changed in: resolvconf (Ubuntu)
Status: Expired => New
** Changed in: resolvconf (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
Best to submit this wish to the Debian bug tracking system so that
Debian will also benefit from this enhancement.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1485316
Is the resolvconf package even installed?
Assuming it is, why doesn't it get called when the interfaces are
configured?
Can things be changed so that resolvconf does get called in the normal
way when interfaces are configured? (The normal way and all other
things resolvconf are explained in
Here is a rough draft, untested, of a script that would be run once in
the main boot sequence in order to bring the resolvconf database up to
date. The main difference from your script is that it sends the info to
resolvconf instead of writing directly to resolv.conf. (I am assuming
that
Hi there and thanks for your report.
I don't see any evidence here of a bug in resolvconf. There is most
probably something wrong with your machine's configuration. So this
report should be reassigned to something else... or closed if the
configuration shortcomings are purely local. Where did you
Christian, the workaround is to comment out the line dns=dnsmasq in
/etc/NetworkManager/NetworkManager.conf.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1003842
Title:
To add that, or any other, option to resolv.conf permanently, add the
line
options edns0
to the file
/etc/resolvconf/resolv.conf.d/base
and then resolvconf will include it in the resolv.conf that it
generates.
** Changed in: dnsmasq (Ubuntu)
Status: New = Invalid
--
You
Hi. I don't see how resolvconf could be responsible for this problem.
Initial observation: it seems that dig gets the correct answer from
dnsmasq when it supplies the additional option udp:1280, but the glibc
resolver doesn't get the right answer from dnsmasq when it fails to
supply that option.
Should this be reassigned to network-manager-openvpn?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1430077
Title:
[vivid] VPN connection breaks /etc/resolv.conf
** Changed in: network-manager (Ubuntu)
Status: In Progress = New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1003842
Title:
dnsmasq sometimes fails to resolve
Does this bug still affect anyone?
** Changed in: network-manager (Ubuntu)
Status: Confirmed = Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
Now, it is being pushed instead to /etc/resolv.conf.
nameserver 10.99.244.1
nameserver 127.0.1.1
[...]
Connecting to the VPN also pushes search paths to /etc/resolv.conf -
overriding the search
domains that I have already configured, and which should take precedence.
Is this being
A workaround may be to edit /etc/NetworkManager/NetworkManager.conf and
comment out the line dns=dnsmasq.
** Description changed:
- Using a laptop with a hardware switch for enable/disable WLAN.
- Connected to two different LANs using DHCP on ETH/WLAN.
+ I have a laptop with a hardware switch to
Public bug reported:
The following versions of resolvconf have a postinst that runs update-
rc.d resolvconf defaults.
* 1.77ubuntu1 YES
* 1.76ubuntu1 in Vivid 15.04 YES
* 1.69ubuntu4 in Utopic 14.10 YES
* 1.69ubuntu1.1 in Trusty-updates YES
* 1.69ubuntu1 in Trusty 14.04 YES
* 1.63ubuntu16 in
Fixed upstream in resolvconf 1.77.
** Changed in: resolvconf (Debian)
Status: In Progress = Fix Released
--
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/1446681
Fixed in resolvconf 1.77ubuntu1.
** Changed in: resolvconf (Ubuntu)
Status: Confirmed = Fix Released
--
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/1446681
You know, I didn't even look closely at those warnings. Duh. Now that I
read them I see that I am being warned that I have runlevel symlinks in
1 2 3 4 5. Those aren't supposed to be there! (I run Ubuntu 15.04
upgraded from 14.04 originally.) What the aytch-e-double-hockey-stick?
Consider the
Yay.
We may now get a complaint from someone who has deleted the symlink at
/etc/resolv.conf but still has resolvconf installed and relies upon
dhclient updating /etc/resolv.conf dynamically. Their problem:
/etc/resolv.conf is no longer updated after resolvconf is upgraded to
1.77ubuntu1.
** Changed in: resolvconf (Ubuntu)
Status: Confirmed = Incomplete
--
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/1392297
Title:
resolvconf 1.69ubuntu1.1 breaks
This was fixed in some release prior to 1.77ubuntu1.
** Changed in: resolvconf (Ubuntu)
Status: Confirmed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
@Cs-gon: Can you reproduce this problem (bug #1392297) with resolvconf
1.77ubuntu1?
--
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/1392297
Title:
resolvconf
debian/templates in 1.77ubuntu1:
[...]
Template: resolvconf/link-tail-to-original
Type: boolean
Default: false
[...]
debian/changelog in 1.77ubuntu1:
[...]
- resolvconf/link-tail-to-original debconf question again defaults to
false; it's rather irrelevant as we install resolvconf by
Fixed in 1.77ubuntu1.
** Changed in: resolvconf (Ubuntu)
Status: Confirmed = Fix Released
--
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/1279760
Title:
The indirection via /etc/resolvconf/run dates from the era before /run/.
I introduced resolvconf in 2003 as part of a larger effort to make it
possible to run Debian with a read-only root filesystem[1] but the
project to introduce the /run/ tmpfs into Debian base failed due to lack
of consensus
Yep, I see that debian/triggers is present in 1.77ubuntu1, and when I
install the package I see the report of the trigger being processed.
Thx! P.S. Is there something we should do to silence those insserv
warnings?
$ sudo dpkg -i resolvconf_1.77ubuntu1_all.deb
(Reading database ... 282465 files
Resolvconf 1.77ubuntu1's debian/rules runs dh_installinit with `--no-
start` and so there is no longer a `invoke-rc.d resolvconf start` (which
wipes runtime directories) in debian/postinst. To enable resolvconf
updates, postinst simply does resolvconf --enable-updates.
If `invoke-rc.d resolvconf
Continuing with my investigation of how a default symlink field got
created for resolvconf on my machine... (What I am calling a 'default
symlink field' is the set of symlinks /etc/rc[1-5].d/S??resolvconf -
../init.d/resolvconf as would be created by update-rc.d resolvconf
defaults with
I'd like to comment on the remaining differences between Debian
resolvconf and Ubuntu resolvconf.
Besides the extensive source-textual differences arising from Debian's
use of /etc/resolvconf/run versus Ubuntu's direct use of
/run/resolvconf, I see only three substantial differences.
1. The
@Martin: My previous comment raced with your release of 1.76.1ubuntu2.
Looks good.
--
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/1453185
Title:
resolvconf: updates
In the Debian postinst there is a case clause at the end whose purpose
is to enable updates. In Debian this is done by means of a trigger.
resolvconf 1.77
[...]
case $1 in
reconfigure)
resolvconf --enable-updates
;;
configure)
@Cs-gon: Do you have any problem with resolvconf 1.76ubuntu1?
--
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/1392297
Title:
resolvconf 1.69ubuntu1.1 breaks network
Just to note that nowadays, e.g., in 1.76ubuntu1, Ubuntu also does
`dh_installinit --no-start`.
--
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/1085862
Title:
Dnsmasq treats all nameservers as equivalent (except insofar as it is
instructed to use particular nameservers to resolve names in particular
domains).
The C library resolver, on the other hand, tries one nameserver at a
time in the order that their addresses are listed in resolv.conf.
If you
** Also affects: resolvconf (Debian)
Importance: Undecided
Status: New
** Changed in: resolvconf (Debian)
Assignee: (unassigned) = Thomas Hood (jdthood)
** Changed in: resolvconf (Debian)
Status: New = In Progress
** Changed in: resolvconf (Debian)
Assignee: Thomas
Try this.
lo.inet6
lo.inet
lo.@(dnsmasq|pdnsd)
lo.!(pdns|pdns-recursor)
lo
tun*
tap*
hso*
em+([0-9])?(_+([0-9]))*
p+([0-9])p+([0-9])?(_+([0-9]))*
@(br|eth)*([^.]).inet6
@(br|eth)*([^.]).ip6.@(dhclient|dhcpcd|pump|udhcpc)
@(br|eth)*([^.]).inet
@(br|eth)*([^.]).@(dhclient|dhcpcd|pump|udhcpc)
** Changed in: resolvconf (Ubuntu)
Status: Fix Committed = Fix Released
--
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
** Changed in: resolvconf (Ubuntu)
Status: Confirmed = Fix Released
--
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/1110331
Title:
nscd no longer needs to be
The original problem was fixed in resolvconf 1.70 which has since been
merged to Vivid.
** Changed in: resolvconf (Ubuntu)
Status: Confirmed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in
** Changed in: resolvconf (Ubuntu)
Status: New = Confirmed
--
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/1392297
Title:
resolvconf 1.69ubuntu1.1 breaks network
Not fixed in 1.76ubuntu1.
debian/templates in 1.76ubuntu1:
[...]
Template: resolvconf/link-tail-to-original
Type: boolean
Default: true
[...]
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
** Summary changed:
- resolvconf not updated correctly for interfaces configured in initramfs
+ resolv.conf not updated correctly for interfaces configured in initramfs
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd
First a parenthetical remark. According to interfaces(5) the manual
keyword is used exclusively in the method field, as in `iface eth0
inet manual`. But in your example you use it at the beginning of a line.
Perhaps you think that in that context manual means the opposite of
auto (non-auto?) but
I just tried to reproduce the bug in Ubuntu 14.10 by editing the file
/etc/network/interfaces to look like the following (complete with bogus
manual line).
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
manual eth0
iface eth0 inet dhcp
dns-nameservers 1.2.3.4
*** This bug is a duplicate of bug 1314697 ***
https://bugs.launchpad.net/bugs/1314697
** This bug has been marked a duplicate of bug 1314697
DNS resolution no longer works; dnsmasq uses 100% CPU
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
Confirmed that the bug affects 2.72-2.
$ cat /etc/dnsmasq.conf | tail -n 2
# Include all files in a directory which end in .conf
#conf-dir=/etc/dnsmasq.d/*.conf$ od -t c /etc/dnsmasq.conf | tail -n 2
0062620 / * . c o n f
0062627
$
** Changed in: dnsmasq (Ubuntu)
Status:
Just checked 2.72-1 and it doesn't seem to have this problem.
$ cat /etc/dnsmasq.conf | tail -n 2
#conf-file=/etc/dnsmasq.more.conf
#conf-dir=/etc/dnsmasq.d
$ od -t c /etc/dnsmasq.conf | tail -n 2
0062320 / e t c / d n s m a s q . d \n
0062337
--
You received this
First, as suggested by the author of dnsmasq, the `local-service`
should be in the default configuration. However, Ubuntu 14.10
doesn't have that
What the man page exactly says is that local-service only has effect
i[f] there are no --interface --except-interface, --listen-address or
Ubuntu 13.10 (Saucy) included dnsmasq 2.66 or so. In dnsmasq 2.69 an
important change was made which may be the cause of your problem. This
change affects Ubuntu 14.10 and later, but not Ubuntu 14.04LTS (Trusty)
which shipped with dnsmasq 2.68-1. The change is mentioned in the
changelog (quoted
** Summary changed:
- squid3 gets killed at startup with dnsmasq and no networkmanager
+ squid3 gets killed at startup with dnsmasq
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
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
Returning to the main issue...
Could this fix be considered for trusty-updates?
The patch is very simple and applying it involves little risk, so I'd
say yes.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in
I see that your change has made it to vivid
\o/
undesirable behavior: all DNS queries go to the VPN nameservers
That is in most cases the *desired* behavior, since only the VPN
nameservers have name information about both the VPN and the Internet.
Also, under what circumstances do you not
*** This bug is a duplicate of bug 1385010 ***
https://bugs.launchpad.net/bugs/1385010
did not know I am stepping on your toe here
No toes being stepped on here.
had to take care of this, so I generate the resolv.conf from a package
- no link anymore
OK. Leave the resolvconf package
I wrote:
The proper way for the admin to stop /etc/resolv.conf from
being updated by resolvconf is for him or her to remove the
symbolic link /etc/resolv.conf - ../run/resolvconf/resolv.conf.
HeinMueck wrote:
what you describe as the proper way will not work at all
- take a look at
Is dnsmasq getting its DNS server information from resolvconf,
which in turn gets it from /etc/network/interfaces? Or, does
dnsmasq take what it likes from /etc/network/interfaces directly,
discarding the rest?
1. If you have only the dnsmasq-base and network-manager packages installed
then
The proper way for the admin to stop /etc/resolv.conf from being updated
by resolvconf is for him or her to remove the symbolic link
/etc/resolv.conf - ../run/resolvconf/resolv.conf. The resolvconf
program only ever writes to the target of that symlink. Thus, in the
absence of that link,
I gather that you want to use the fact that the resolver happens to try
one address after another, in the order that they are listed in
resolv.conf, as a way of giving precedence of one domain name system
(the service provided over the br* interfaces) over another domain name
system (the one
** Description changed:
The resolvconf package comes with /etc/dhcp/dhclient-enter-
- hooks.d/resolvconf which convieniently undefines make_resolve_conf
- (previously defined by dhclient-script) and calls resolvconf.
+ hooks.d/resolvconf which, if /sbin/resolvconf is present, undefines
+
1 - 100 of 106 matches
Mail list logo
