The Precise Pangolin has reached end of life, so this bug will not be
fixed for that release
** Changed in: djbdns (Ubuntu Precise)
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.lau
The Precise Pangolin has reached end of life, so this bug will not be
fixed for that release
** Changed in: network-manager (Ubuntu Precise)
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://b
The Precise Pangolin has reached end of life, so this bug will not be
fixed for that release
** Changed in: dnsmasq (Ubuntu Precise)
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.laun
The network-manager package still ships /etc/dnsmasq.d/network-manager
with "bind-interfaces" in it
and that breaks the TFTP server of dnsmasq
and sometimes even the DNS server of dnsmasq.
"bind-dynamic" is a little better, but too unreliable to be used in
production.
So this bug is still not res
What is the status of this as at 16.04?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
To manage notifications about this
Mathieu, I reopened this bug because it was never resolved... not just for the
TFTP issue.
Please see my #143 comment.
If you want more feedback tell me what to send, but DNS never worked properly
for me when dnsmasq and nm-dnsmasq are both running.
--
You received this bug notification because
Now that we can use bind-dynamic, I have nothing against setting that
value instead of bind-interfaces, if it indeed solves the latest issues
that were reported.
However, I'd really appreciate if separate bugs could be opened rather
than reopening this bug, it would make each individual issue easi
Through Raring and Saucy, my two modifications to the given LTSP-PNP
setup have been:
In /etc/dnsmasq.d/network-manager replace the "bind-interfaces" line
with a "bind-dynamic" line.
Edit /etc/dnsmasq.d/ltsp-server-dnsmasq.conf: comment out the port=0
line
And those two mods still work for me in
Thomas, yup, TFTP appears to be working fine with bind-dynamic.
I'll test if re-enabling "dns=dnsmasq" in
/etc/NetworkManager/NetworkManager.conf along with bind-dynamic allows
dnsmasq co-exist with nm-dnsmasq, and report back.
Thanks!
--
You received this bug notification because you are a mem
> I just tried Trusty (dnsmasq 2.68-1), and network manager ships
> /etc/dnsmasq.d/network-manager with:
>
> bind-interfaces
>
> So now dnsmasq only binds 127.0.0.1 for its tftp service:
>
> udp 0 0 127.0.0.1:69 0.0.0.0:* 954/dnsmasq
> udp6 0 0 ::1:69 :::* 954/dnsmasq
>
> ...and of
Or better yet, ltsp-server-standalone could "Conflict: network-manager-
local-resolver" so that all LTSP sysadmins that use dnsmasq don't bother
searching for a solution and manually editing configuration files...
--
You received this bug notification because you are a member of Ubuntu
Bugs, whic
The fix for this issue caused another regression, dnsmasq now doesn't
function correctly as a tftp server either.
I just tried Trusty (dnsmasq 2.68-1), and network manager ships
/etc/dnsmasq.d/network-manager with:
bind-interfaces
So now dnsmasq only binds 127.0.0.1 for its tftp service:
udp
I'm still having problems with this on 14.04.
After the default installation, I installed dnsmasq and DNS stopped
working until system restart.
Now it's only working for a few seconds after each network-manager
restart!
If I comment out
#dns=dnsmasq
in NetworkManager.conf, then everything is fin
Aha. /etc/NetworkManager/dispatcher.d/01ifupdown run-partses
/etc/network/if-up.d/ on "up" and /etc/network/if-post-down.d/ on "down"
(which is actually "post-down" in ifupdown terminology). And there is
no /etc/network/if-post-down.d/bind9 so named doesn't get nudged when NM
takes down an interfa
Whoa. When an interface is brought up with NM the scripts in
/etc/network/if-up.d/ somehow get run (how?) but when an interface is
downed with NM, the scripts in /etc/network/if-down.d/ don't get run
(inconsistent!).
--
You received this bug notification because you are a member of Ubuntu
Bugs, w
> Btw, named immediately notices because of the
> /etc/network/if-{up,down}.d/bind9 scripts that trigger
> "rndc reconfig" when an interface goes up or down.
Ah, yes. There is also a hook at /etc/ppp/ip-{up,down}.d/bind9.
But named also notices immediately when I bring up an with
NetworkManager.
If "libnss-nm-dns" would make it easier to introduce per-user caching
and/or if it improved security then those would be important benefits.
Currently nm-dnsmasq has caching disabled because of concerns about
cache poisoning and information leakage.
https://blueprints.launchpad.net/ubuntu/+sp
I would if I considered it a bug. (I didn't fully describe the current
state of samba4, because I figured it was irrelevant: You can alter the
interfaces it binds to, but not for *only* the dns resolver -- so
currently, if you want samba4 listening on the wildcard address you'll
need the dns resolv
> something that conflicts: the internal resolver of the samba4 packages
Please file another report against samba4 describing the conflict with
nm-dnsmasq.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bug
In response to #131 and #134 by Thomas:
I would argue that "will it conflict with anything that exists?" is the
wrong question, here. Certainly it will conflict in the future, and
removing the users ability to run a DNS service on the wildcard address
is suboptimal at best, even if they don't *ne
The O'Reilly book _DNS and BIND_ says:
[QUOTE]
10.4.3.2 Interface interval
We've said already that BIND, by default, listens on all of a host's
network interfaces. BIND 8 is actually smart enough to notice when a
network interface on the host it's running on comes up or goes down. To
do this, it
I wrote in comment #131:
> What benefits would the nm-dns module or the enhanced
> dns module give us relative to what we have now? One is:
> the ability to run nm-dnsmasq on another port, freeing up
> port 53 for BIND named listening on ALL:53. What else?
I just installed bind9 and was surprised
> Btw please don't backport the current solution to Precise
In comment #110 MTL said that backporting the fix to Precise *is*
planned.
Quantal includes dnsmasq 2.63 which has the new "bind-dynamic" option.
In bind-dynamic mode dnsmasq works as it does in bind-interfaces mode
but also updates its
> To my own surprise I haven't seen any complaints related to the switch
from 127.0.0.1 to 127.0.1.1, even though I have been following AskUbuntu
and ubuntuforums.
It's possible that a large portion of Ubuntu users that are using dnsmasq as a
DNS server, only use LTS releases, so complains might
You may be right that developing a new "nm-dns" module would be easier
than trying to enhance the existing dns module to support nonstandard
ports.
But the more immediately relevant comparison is the comparison between
the current solution and any solution involving a new or an enhanced NSS
module
alan_a...@yahoo.com
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
To manage notifications about this bug go to:
https://
You've got the basic idea. The nsswitch.conf file is where Name Service
services are configured, and "hosts" is one of them. DNS is *one* way
to look up hosts, but so is "files" (/etc/hosts) and "mdns4" (avahi).
Anything that extends how names are translated to addresses should,
imnho, be done th
Belated reply to Robin Battey's #116.
My question in #115 was about alternative resolver libraries, not about
DNS resolver libraries. There are libraries that play the same role as
the whole glibc resolver. Generally these alternative resolver libraries
include DNS resolvers and read /etc/resolv.
Agreed. And I had hoped that I could eliminate ntpd as the source of
the problem by using a simple switch in the LTSP configuration to turn
it off for the client. Unfortunately that does not seem to be effective
in disabling ntpd. Troubleshooting that elsewhere .
--
You received this bug n
That the last syslog entries are made by ntpd doesn't necessarily mean
that the machine is hanging because of ntpd. It could be hanging at the
next step, for example.
Bug #999725 reports that ntp doesn't work properly when it is started
before NIS, which is not to be confused with DNS. Probably no
I thought I was done with this kind of issue, but I may be back for
more.
It turns out that the only LTSP client that boots normally is the one
that I was doing all of the above troubleshooting on. Others that I
have tried in my little 2-PC setup all stop at a blank/black screen
after successfull
Question: Why did everything work on your machine when standalone
dnsmasq wasn't in bind-interfaces mode but /etc/NM/NM.conf contained
"dns=dnsmasq"?
Hypothesis: Standalone dnsmasq started first; network-manager second. NM
tried to start NM-dnsmasq but this failed because of the address
conflict a
Thanks for the explanation of how removal of /etc/dnsmasq.d/network-
manager sets up a conflict between standalone dnsmasq and NM-dnsmasq.
(But also see my surprising observation below.)
>> Should this conflict be manifesting itself somehow?
>> Everything seems to be working right now.
>Well, I a
> the LTSP server defers to the router handling DHCP.
OK, I get it.
> I don't understand what you said about standalone dnsmasq
> conflicting with network-manager's instance of dnsmasq
> when /etc/dnsmasq.d/network-manager is removed.
When /etc/dnsmasq.d/network-manager is present, standalone d
RE Thomas Hood's #120: That is very interesting, though I admit it is
near the outer limits of my current understanding.
To address the only questions above:
>> The problem is that the LTSP client, after successfully getting
>> DHCP assignments, fails to download the pxelinux boot image.
>> It re
> the current default installation wherein network-manager starts
> an instance of dnsmasq to act as a DHCP, DNS and TFTP server.
NetworkManager starts an instance of dnsmasq to act only as a non-
caching DNS nameserver forwarder. This instance listens only on the
loopback interface 127.0.1.1.
If
I don't know how my case enters this discussion, but it is certainly
connected to the current default installation wherein network-manager
starts an instance of dnsmasq to act as a DHCP, DNS and TFTP server.
I was troubleshooting an LTSP-PNP client boot problem under Lubuntu
Quantal. I installed
@Svartalf: Can you please describe in more technical detail what fails
to work on the machines in question, and share with us what you know
about the causes of these malfunctionings? Once we have some idea what
you're talking about we can help you further.
You wrote:
> there's tons of local insta
This is a bad idea as it's been implemented, guys- there's tons of local
installations that use internal DNS (My CenturyLink router or my day-
job's setup, for example...) that this flatly breaks out of box. You've
got to do a bunch of manual interventions for MANY corporate desktop and
home deskt
> Are you sure? I am only aware of named.conf's "listen-on { IP_ADDRESS;
}". If there is a feature such as you describe then presumably named
binds ALL:53 and then filters according to the addresses on the
specified interfaces.
Nope, I just verified, you're quite correct. I hadn't heard of it
eit
Yes, the 127.0.1.1:53 solution works so long as dnsmasq and others are
run in bind-interfaces (or equivalent) mode.
NM-dnsmasq currently (12.04) listens at 127.0.01:53 which prevents
others from listening on either ALL:53 or lo:53, i.e., 127.0.0.1:53.
The new (12.10) behavior allows others to list
Another drawback is that you still need to manually configure bind (and
others) to only listen on particular addresses. If you're using dhcp
this presents a problem, because you don't actually know the address.
With bind, this is okay, mostly, because you can say to listen on
everything for a part
Yes, writing an NSS plugin would have been the next resort. It's
certainly easier than getting glibc and all other resolver libraries to
support ports other than 53. But it's more difficult than the solution
that was actually adopted, namely, to make nm-dnsmasq listen at
127.0.1.1.
(BTW, I don't
I just read this entire chain, and I'm surprised not to see mention of
using an NSS plugin, like Avahi (and ldap and NIS and /etc/hosts and DNS
itself). I expect it would be simple enough to write a small NSS plugin
that merely calls the NM-dnsmasq (running on localhost on a port other
than 53) an
AFAIK this is fixed in Quantal for dnsmasq as well as NetworkManager;
barring a minor issue with NM that I'm about to upload a fix for...
** Changed in: dnsmasq (Ubuntu)
Status: Confirmed => Fix Released
** Changed in: dnsmasq (Ubuntu Precise)
Importance: Undecided => High
** Changed i
Yes, it is. I'll provide a package with a bunch of related changes from
Quantal; namely:
- using dbus instead of a config file;
- using a different dbus name than the default for dnsmasq;
- restarting dnsmasq less often (fixed in using dbus, basically)
- avoid refreshing interface config on every
Is it really still a goal to get these fixes into Precise?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
To manage notif
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: djbdns (Ubuntu Precise)
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/959037
Title
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: djbdns (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/959037
Title:
NM-c
... would be what I suggest (but can't do myself). :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
To manage notificat
Changing status to "in progress" in case we still want to implement the
idea in comment #88.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS serv
Note: the dnsmasq.d file included in the new n-m release includes both
"bind-interfaces" and "except-interface=lo".
This is already a big improvement. It allows standalone dnsmasq to run
on a system with NM and nm-dnsmasq: standalone dnsmasq listens on
interfaces other than lo and forwards queries
This bug was fixed in the package network-manager -
0.9.6.0~git201207161259.00297f4-0ubuntu1
---
network-manager (0.9.6.0~git201207161259.00297f4-0ubuntu1) quantal; urgency=low
* upstream snapshot 2012-07-16 12:59:59 (GMT)
+ 00297f49fbbe05c51c02da43cda254c35e053589
[ Edward D
** Branch linked: lp:~network-manager/network-manager/ubuntu
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
To manage not
Well, first we'll ship the file for /etc/dnsmasq.d; changing it to bind-
dynamic after the fact is quick.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents o
Assuming that the plan in comment #88 will be implemented, the next step
is to wait for dnsmasq 2.63 to get into the quantal repo.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-cont
** Also affects: dnsmasq (Ubuntu Precise)
Importance: Undecided
Status: New
** Also affects: pdnsd (Ubuntu Precise)
Importance: Undecided
Status: New
** Also affects: network-manager (Ubuntu Precise)
Importance: Undecided
Status: New
** Also affects: pdns-recursor (
In bug #928524 Stéphane Graber has written that "even if Network Manager
moves to using 127.0.0.2, which I believe is a good idea, it should
still ship a dnsmasq.d config file containing 'bind-interfaces'" So
I gather that Stéphane doesn't necessarily disagree with what has been
proposed here
Simon wrote:
> change --bind-interfaces to --bind-dynamic as see how it goes.
As discussed in bug #928524 and bug #231060 various packages will be
including files in /etc/dnsmasq.d/ with "bind-interfaces". I guess
these will all later have to be changed to include "bind-dynamic"
instead, unless d
Bug #928524 is related insofar as it is proposed there (see comment #18)
to adopt the solution of forcing standalone dnsmasq into
bind-interfaces
except-interface=lo
modes by means of /etc/dnsmasq.d/network-manager.
--
You received this bug notification because you are a member of Ubunt
Next checked PowerDNS Recursor. The Debian package pdns-recursor is
also available in Universe. Its default configuration is to listen only
on 127.0.0.1:53 so it will also no longer conflict with nm-dnsmasq if
the latter is moved to 127.0.0.2.
/etc/powerdns/recursor.conf:
local-address=127.0
@Bert: Can you provide more information about the conflict with djbdns?
The dnscache-run package, one of the binary packages built from djbdns
source, is marked as Conflicting with resolvconf because it messes
directly with /etc/resolv.conf --- see Debian bug report #582755. Its
maintainers haven
Just checked pdnsd. I thought it would be affected since it also starts
in "server_ip=any" mode by default; however the Debian package which is
also in Universe includes "server_ip=127.0.0.1" in /etc/pdnsd.conf. It
therefore starts alongside nm-dnsmasq modified to listen on 127.0.0.2.
So nothing
On 20/06/12 10:56, Thomas Hood wrote:
> I can imagine that it will take a lot of care to avoid introducing races
> inside dnsmasq.
It's OK: notification of new interfaces comes via netlink, so it gets
synchronised via the select() call just like everything else.
Have I mentioned yet that Simon i
Meanwhile my laptop has been working fine with two dnsmasq instances
running in cascade. I'll try to subject this arrangement to more severe
tests in the coming weeks.
# netstat -nl46p | grep :53
tcp0 0 127.0.0.2:530.0.0.0:* LISTEN
7928/dnsmasq
tcp
I can imagine that it will take a lot of care to avoid introducing races
inside dnsmasq. Have I mentioned yet that Simon is a hero?
Do we have to worry about races outside of dnsmasq? Suppose someone was
running dnsmasq in unbound mode and has now switched to the new improved
dnsmasq in bind-inte
On 18/06/12 21:08, Thomas Hood wrote:
> @Simon: This is pretty much what I had in mind (comment #88) as a long-
> term solution. How difficult do you think that this would be?
Don't know. I'm working on it now: seems to be behaving:
dnsmasq: new IPv4: 192.168.3.1
dnsmasq: new IPv6: fe80::f0f6:48
@Simon: This is pretty much what I had in mind (comment #88) as a long-
term solution. How difficult do you think that this would be?
(Moving nm-dnsmasq listening to another port than 53 is at best a veeery
long-term solution since it requires first getting glibc enhanced, then
getting all other
Relevant to my question above:
> What would be the best way to implement this, Simon?
is what Simon wrote in #928524 comment #12:
--- BEGIN QUOTATION ---
I'm wondering about adding a _third_ mode, which is has a desirable
mixture of the properties of the current two (--bind-interfaces and NOT
--
I now agree (see Mathieu's comment #30) that the most expedient thing to
do is
* update dnsmasq to a new release based on the latest code in Simon's git repo;
* patch the two lines in the n-m code such that (1) nm-dnsmasq listens on
127.0.0.2 instead of 127.0.0.1 and (2) NM registers 127.0.0.2 in
Would it be remotely possible in the future for the problem to be addressed
inside libc itself?
Other people not using NM or dnsmasq would still welcome the split VPN
resolving, right?
Should we file a wishlist bug request for it?
--
You received this bug notification because you are a member o
> Applications that don't use the libc resolver?
Hmm, yes. There are several alternative resolver libraries (adns,
firedns, djbdns, ...) and even if we fixed them all so that they could
read the extended resolv.conf syntax then statically linked third party
binaries would still break.
So having
On 15/06/12 15:01, Thomas Hood wrote:
>> -- Solvable by moving nm-dnsmasq to another port:
> There's one more snippet after this dealing with the IPv6 case. That
> should be it. Any obvious problems I'm overlooking?
>
Applications that don't use the libc resolver? I don't know if such
exist be
> -- Solvable by moving nm-dnsmasq to another port:
http://sourceware.org/bugzilla/show_bug.cgi?id=14242
BTW, the required enhancement to glibc shouldn't be difficult to
implement. I expect that all we'd have to do is change the following
code (around line 313 in resolv/res_init.c) so that it cou
"Dnsmasq cascade" (#72) has maintenance advantages. For example it
makes it easy for the distromaestros to switch to other software to
perform the same limited task as nm-dnsmasq now performs, without any
chance of disturbing admins' standalone dnsmasq setups.
Does dnsmasq-cascade have drawbacks
On 15/06/12 08:04, Thomas Hood wrote:
> Alkis: This relies on the assumption that NM's configuration text can be
> dropped in alongside whatever other configuration text is present and
> that dnsmasq will still work properly. This assumption is, er,
> questionable.
There was an attempt, some time
On 15/06/12 10:19, Thomas Hood wrote:
> $ cat /run/nm-dns-dnsmasq.conf
> server=/17.172.in-addr.arpa/172.17.1.2
> server=192.168.1.254
> server=...
>
> The first "server=" line reflects the fact that I am connected to a VPN.
> This can't be expressed in resolv.conf syntax.
FYI only,
It's possib
$ cat /run/nm-dns-dnsmasq.conf
server=/17.172.in-addr.arpa/172.17.1.2
server=192.168.1.254
server=...
The first "server=" line reflects the fact that I am connected to a VPN.
This can't be expressed in resolv.conf syntax.
No doubt dnsmasq could be enhanced to poll its configuration files. But
i
The "real" dnsmasq command line is:
/usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq -r
/var/run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new
I think that NM would just need to update /var/run/dnsmasq/resolv.conf
instead of creating+updating /var/run/nm-dns-dns
> NM kills and starts a new dnsmasq process every time this file
changes. Will that be a problem for your LTSP setup where dnsmasq is
also the DHCP server?
The most time consuming operation that dnsmasq does in our setups is
sending the kernel/initrd via TFTP. That takes a few seconds. If the
teac
> --conf-file not needed
Well, this is used to make nm-dnsmasq read the configuration file that
has been dynamically generated by NM. Without this you will have to do
something like the following.
ln -s /var/run/nm-dns-dnsmasq.conf /etc/dnsmasq.d/nm-dns-
dnsmasq.conf
NM kills and starts a n
> (Another minor problem with your proposal as you phrased it is the
following. The existence of /etc/init.d/dnsmasq does not entail that the
dnsmasq is installed. The package could have been removed and not
purged.)
Correct, but then I wonder what prevents dnsmasq from running even if it's
remov
> This assumption is, er, questionable.
True, but if you don't mind, let's examine that question a bit.
This is the NM-spanwed command line:
/usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces
--pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid
--listen-ad
Alkis: This relies on the assumption that NM's configuration text can be
dropped in alongside whatever other configuration text is present and
that dnsmasq will still work properly. This assumption is, er,
questionable.
And this is also one answer to my question in #72. The "dnsmasq
cascade" may
What if NM always dropped whatever configuration file it needs in
/etc/dnsmasq.d/nm.conf,
and when NM was started, it would check if /etc/init.d/dnsmasq exists,
* if yes, dnsmasq is installed, so it read the configuration file and there's
no need to do anything,
* if not, dnsmasq-base is instal
Regarding #3, I've filed a wish in upstream's bugzilla:
http://sourceware.org/bugzilla/show_bug.cgi?id=14242
#2 is easy to implement and does solve the problem of standalone dnsmasq
not starting on installation in the presence of NM+dnsmasq. What I am
now wondering is how useful the resulting nam
On 14/06/12 16:06, Thomas Hood wrote:
> @Alkis: IIUC dnsmasq in bind-interfaces mode will not start to listen on
> any addresses assigned to interfaces after dnsmasq has started. So,
> yes, she would have to restart standalone dnsmasq if she wants it to
> listen on those newly assigned addresses.
Thanks, so until the #3 idea is implemented (if ever), I'll be disabling the
NM-spawned dnsmasq.
But of course the #2 idea is good enough for many cases, thank you all for your
work on this.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ub
@Alkis: IIUC dnsmasq in bind-interfaces mode will not start to listen on
any addresses assigned to interfaces after dnsmasq has started. So,
yes, she would have to restart standalone dnsmasq if she wants it to
listen on those newly assigned addresses.
IIUC the only way to avoid this is to run dns
I was reading about bind-interfaces at
http://www.thekelleys.org.uk/dnsmasq/docs/FAQ and I'm wondering, are
there any use cases that will have problems with bind-interfaces and the
standalone dnsmasq instance?
* Suppose a teacher boots her laptop (==LTSP server) without a network cable
plugged i
With the latest dnsmasq code the two dnsmasq instances appear to work
correctly in all combinations. I just tested as follows.
* With both dnsmasqs running, nm-dnsmasq forwards to the upstream nameservers
and listens on 127.0.0.2; standalone dnsmasq forwards to 127.0.0.2 and listens
on 127.0.0.
** Summary changed:
- NM-controlled dnsmasq prevents other DNS servers from running, yet
network-manager doesn't Conflict with their packages
+ NM-controlled dnsmasq prevents other DNS servers from starting
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
92 matches
Mail list logo
