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
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
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
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
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
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
Server
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
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
Server Team, which is subscribed to dnsmasq in Ubuntu.
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
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.
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. Any
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
Server
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 interface.
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
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
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.
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
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
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 to
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
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 through
alan_a...@yahoo.com
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
To manage notifications about this
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
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
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
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 reports
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
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 am
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
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
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
@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
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
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
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
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)
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
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
Is it really still a goal to get these fixes into Precise?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from
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
Server Team, which is subscribed to dnsmasq in Ubuntu.
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
Server Team, which is subscribed to dnsmasq in Ubuntu.
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 to
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
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq
... would be what I suggest (but can't do myself). :)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
** Branch linked: lp:~network-manager/network-manager/ubuntu
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from
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
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
Server Team, which is subscribed to dnsmasq in Ubuntu.
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
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled
** 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
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
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
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
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
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
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 is
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
@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
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:
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
@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
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:
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
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
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
(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
--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
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
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
$ 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
it
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 possible to
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
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
-- 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
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
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
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
** 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
Server Team,
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
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
@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
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
Server Team, which is
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.
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
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
85 matches
Mail list logo
