Acknowledge that RFC non-compliance. Fixing this is actually a fairly
big ask, since the problem is not that dnsmasq omits the SOA when
answering from cache, but that dnsmasq doesn't cache SOA records. The
design philosophy was (and is) to cache only a few RR types to make the
code and data
tftp-root is a security feature. The tftp protocol is entirely
unauthenticated, and if a request was allowed to go outside the
specified root directory, than that effectively makes all readable files
on the host available for internet-wide access, which is not generally
desirable. If you want TFTP
dhcp-range for static ranges is
dhcp-range=,static,..
ie, there's only one address before the static keyword.
Simon.
On 28/10/2018 12:55, Lutz Heitmüller wrote:
> Public bug reported:
>
> Description:Ubuntu 18.04.1 LTS
> Release:18.04
> __
> dnsmasq:
>
This was fixed upstream, in release 2.77.
Simon.
On 18/07/18 14:59, Frank Klaassen wrote:
> Public bug reported:
>
> If one would add a CNAME-record that would point to itself like so:
> CNAME=test.example.com,test.example.com
>
> This will result in a segfault and crash of the dnsmasq
Testing this, the results are not quite as clear-cut as the example. I
don't always see the same errors.
Also, I don't understand why the send() calls in dig, which are sending
UDP packets over the loopback interface, should return the invalid
argument. ARP is not needed over loopback, surely?
Looking again. the loop probably involves systemd-resolverd too, dnsmasq
forwards to 127.0.0.53 which is systemd-resolverd, and systemd-resolverd
then returns it to dnsmasq at 127.0.0.1
Why, oh why is Ubuntu running both?
Cheers,
Simon.
On 14/03/17 11:15, Paul wrote:
> I have cpulimit(1)
Ok, so the amplification is arising from dnsmasq looping queries around
127.0.0.1 -> 127.0.0.53 -> 127.0.0.1 -> .
It would be really useful to get dnsmasq's idea of what it's upstreams
are. We know that 127.0.0.1 is in the list from your previous post, and
I guess that dnsmasq has
Are we clear that this is a dnsmasq problem, and not a systemd-resolved
one? Can you add --log-queries to the dnsmasq configuration and see what
dnsmasq is doing? That should demonstrate if the loop is dnsmasq
forwarding to itself, of if the problem is something else.
Cheers,
Simon.
On
Whenever the set of servers to which dnsmasq is forwarding queries
changes, the whole set is logged to syslog. It would be useful to have
that information.
On 13/03/17 00:01, Paul wrote:
> Restarting dnsmasq immediately stops an ongoing DNS storm.
>
The actual upstream server used can change
*** This bug is a duplicate of bug 1042275 ***
https://bugs.launchpad.net/bugs/1042275
On 06/10/15 11:08, Alkis Georgopoulos wrote:
> Hi Robie,
>
> while this also happens in Debian, the use case is more common in Ubuntu,
> because NetworkManager is patched to use a spawned dnsmasq instance
*** This bug is a duplicate of bug 1042275 ***
https://bugs.launchpad.net/bugs/1042275
On 06/10/15 11:08, Alkis Georgopoulos wrote:
> Hi Robie,
>
> while this also happens in Debian, the use case is more common in Ubuntu,
> because NetworkManager is patched to use a spawned dnsmasq instance
What configuration was in use to get that exact error message. If
dnsmasq is binding the wildcard address (0.0.0.0), I'd expect to see a
message like
dnsmasq: failed to create listening socket for port 53
Whilst if dnsmasq is configured to bind the hosts addresses, I'd expect
to see something
I'm sympathetic to aim, but this solution is rather fragile, there are
plenty of ways to get dnsmasq to read configuration from places other
than /etc/dnsmasq.conf and /etc/dnsmasq.d/*, for instance adding
conf-file=/path/to/more/configuration
to the existing config files.
It's also possible to
I'm sympathetic to aim, but this solution is rather fragile, there are
plenty of ways to get dnsmasq to read configuration from places other
than /etc/dnsmasq.conf and /etc/dnsmasq.d/*, for instance adding
conf-file=/path/to/more/configuration
to the existing config files.
It's also possible to
What configuration was in use to get that exact error message. If
dnsmasq is binding the wildcard address (0.0.0.0), I'd expect to see a
message like
dnsmasq: failed to create listening socket for port 53
Whilst if dnsmasq is configured to bind the hosts addresses, I'd expect
to see something
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The underlying problem is that 2.73 accidentally change the meaning of
dnsmasq --conf-file
from don't read any conf-file to read the default conf-file.
This is a bug, not a feature, and I've just committed a fix to git.
Cheers,
Simon.
On
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The underlying problem is that 2.73 accidentally change the meaning of
dnsmasq --conf-file
from don't read any conf-file to read the default conf-file.
This is a bug, not a feature, and I've just committed a fix to git.
Cheers,
Simon.
On
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Thomas, this is fixed upstream. I'll add (LP: #1416895) to the
changelog.
Cheers,
Simon.
On 01/02/15 21:04, Thomas Hood wrote:
Confirmed that the bug affects 2.72-2.
$ cat /etc/dnsmasq.conf | tail -n 2 # Include all files in a
directory
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Thomas, this is fixed upstream. I'll add (LP: #1416895) to the
changelog.
Cheers,
Simon.
On 01/02/15 21:04, Thomas Hood wrote:
Confirmed that the bug affects 2.72-2.
$ cat /etc/dnsmasq.conf | tail -n 2 # Include all files in a
directory
I think the following, much simpler, patch should solve the problem.
Simon.
diff --git a/src/dbus.c b/src/dbus.c
index 93c597c..4696442 100644
--- a/src/dbus.c
+++ b/src/dbus.c
@@ -156,13 +156,16 @@ static void dbus_read_servers(DBusMessage *message)
I think the following, much simpler, patch should solve the problem.
Simon.
diff --git a/src/dbus.c b/src/dbus.c
index 93c597c..4696442 100644
--- a/src/dbus.c
+++ b/src/dbus.c
@@ -156,13 +156,16 @@ static void dbus_read_servers(DBusMessage *message)
On 08/05/14 22:18, James Hunt wrote:
A bit of debugging shows that the culprit is blockdata_expand() which is
being called via blockdata_init(). The issue seems to be that
blockdata_expand() is passed a parameter of zero. That function then
mallocs zero bytes (successfully seemingly), the
On 08/05/14 22:18, James Hunt wrote:
A bit of debugging shows that the culprit is blockdata_expand() which is
being called via blockdata_init(). The issue seems to be that
blockdata_expand() is passed a parameter of zero. That function then
mallocs zero bytes (successfully seemingly), the
Annoyingly, I still can't reproduce this on the systems I have
available. On a system where the problem occurs, can it be reproduced
when dnsmasq is started standalone with the same command-line
parameters? The idea situation would be to get the bug to show up in a
dnsmasq instance running under
Annoyingly, I still can't reproduce this on the systems I have
available. On a system where the problem occurs, can it be reproduced
when dnsmasq is started standalone with the same command-line
parameters? The idea situation would be to get the bug to show up in a
dnsmasq instance running under
On 02/05/14 12:00, Adam Smith wrote:
LSOF output below. I tried to put a strace in init.d but failed
miserably
lsof | grep dnsmasq
dnsmasq 1430 dnsmasq cwd unknown
/proc/1430/cwd (readlink: Permission denied)
dnsmasq 1430
On 02/05/14 12:00, Adam Smith wrote:
LSOF output below. I tried to put a strace in init.d but failed
miserably
lsof | grep dnsmasq
dnsmasq 1430 dnsmasq cwd unknown
/proc/1430/cwd (readlink: Permission denied)
dnsmasq 1430
On 01/05/14 07:45, Colin King wrote:
I'm seeing this too, strace show it spinning on:
select(8, [0 3 6 7], [], [6], NULL) = 1 (in [0])
recvmsg(0, 0x7fffdb2aa6d0, 0) = -1 ENOTSOCK (Socket operation on non-socket)
accept(0, 0, NULL) = -1 ENOTSOCK (Socket operation on non-socket)
select(8, [0
On 01/05/14 07:45, Colin King wrote:
I'm seeing this too, strace show it spinning on:
select(8, [0 3 6 7], [], [6], NULL) = 1 (in [0])
recvmsg(0, 0x7fffdb2aa6d0, 0) = -1 ENOTSOCK (Socket operation on non-socket)
accept(0, 0, NULL) = -1 ENOTSOCK (Socket operation on non-socket)
select(8, [0
This is useful, thanks. A couple of questions:
1) Is this easily reproducible?
2) Could you tell me exactly what command-line flags dnsmasq is being
started with?
Cheers,
Simon.
On 27/04/14 18:02, Dave Gilbert wrote:
Public bug reported:
I hit a case where dnsmasq was running at 100%
On 27/04/14 18:53, Dave Gilbert wrote:
Hi Simon,
1) Apparently so - I just rebooted the vm to see if I could repeat it, and
it was already stuck at 100% and non-responsive.
(and blueskaj who confirmed it was seeing the same problem on irc)
2) /usr/sbin/dnsmasq --no-resolv
On 27/04/14 18:53, Dave Gilbert wrote:
Hi Simon,
1) Apparently so - I just rebooted the vm to see if I could repeat it, and
it was already stuck at 100% and non-responsive.
(and blueskaj who confirmed it was seeing the same problem on irc)
2) /usr/sbin/dnsmasq --no-resolv
This is useful, thanks. A couple of questions:
1) Is this easily reproducible?
2) Could you tell me exactly what command-line flags dnsmasq is being
started with?
Cheers,
Simon.
On 27/04/14 18:02, Dave Gilbert wrote:
Public bug reported:
I hit a case where dnsmasq was running at 100%
On 27/04/14 18:53, Dave Gilbert wrote:
Hi Simon,
1) Apparently so - I just rebooted the vm to see if I could repeat it, and
it was already stuck at 100% and non-responsive.
(and blueskaj who confirmed it was seeing the same problem on irc)
2) /usr/sbin/dnsmasq --no-resolv
On 27/04/14 18:53, Dave Gilbert wrote:
Hi Simon,
1) Apparently so - I just rebooted the vm to see if I could repeat it, and
it was already stuck at 100% and non-responsive.
(and blueskaj who confirmed it was seeing the same problem on irc)
2) /usr/sbin/dnsmasq --no-resolv
On 12/03/14 13:24, fish wrote:
Public bug reported:
Hi,
I'm running dnsmasq in a (docker) container. If I tried to start dnsmasq
without arguments and it failed with:
dnsmasq: setting capabilities failed: Operation not permitted
Guess this is expected because the container has
On 12/03/14 13:24, fish wrote:
Public bug reported:
Hi,
I'm running dnsmasq in a (docker) container. If I tried to start dnsmasq
without arguments and it failed with:
dnsmasq: setting capabilities failed: Operation not permitted
Guess this is expected because the container has
On 09/11/13 19:07, Philip Potter wrote:
I agree that the postinst is a better place than the init script to run
resolvconf -u.
I'm not sure that it should be conditional on IGNORE_RESOLVCONF though -
given that the update script will be run next time anything touches
resolvconf, what's to be
On 09/11/13 19:07, Philip Potter wrote:
I agree that the postinst is a better place than the init script to run
resolvconf -u.
I'm not sure that it should be conditional on IGNORE_RESOLVCONF though -
given that the update script will be run next time anything touches
resolvconf, what's to be
On 27/09/13 10:37, Franck wrote:
Public bug reported:
Since I upgraded to Saucy, my local dnsmasq instance seems to lose its
primary dns server and fallback to secondary dns.
Since the primary dns is a dnsmasq instance that knows of local servers, and
the secondary one is external, my
On 27/09/13 10:37, Franck wrote:
Public bug reported:
Since I upgraded to Saucy, my local dnsmasq instance seems to lose its
primary dns server and fallback to secondary dns.
Since the primary dns is a dnsmasq instance that knows of local servers, and
the secondary one is external, my
Fixed in developement version.
thttp://hekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=edf0bde0c6837b010560c40e6b74d2f67b64da09
Simon.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
Fixed in developement version.
thttp://hekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=edf0bde0c6837b010560c40e6b74d2f67b64da09
Simon.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1203430
Title:
On 24/07/13 20:33, Thomas Hood wrote:
Hi Simon,
I think we've established that the submitter is having a problem with
dnsmasq server, not with NetworkManager-controlled dnsmasq. So it would
be interesting to know if clear-on-reload fixes the submitter's problem.
(He already said that
On 24/07/13 20:33, Thomas Hood wrote:
Hi Simon,
I think we've established that the submitter is having a problem with
dnsmasq server, not with NetworkManager-controlled dnsmasq. So it would
be interesting to know if clear-on-reload fixes the submitter's problem.
(He already said that
On 08/07/13 15:02, Thomas Hood wrote:
What do you think, Simon?
** Changed in: dnsmasq (Ubuntu)
Status: Incomplete = New
I'm confused: dnsmasq won't cache a negative answer if it has no
upstream servers. To cache a negative answer it has to _receive_ a
negative answer (and the
Whatever is going on, it's more complex. Maybe the problem is that
dnsmasq gets a negative answer from some upstream server, and then
gets a new upstream server which has the correct information? The
solution then is --clear-on-reload but I think NM sets that?
but --clear-on-reload
On 08/07/13 15:02, Thomas Hood wrote:
What do you think, Simon?
** Changed in: dnsmasq (Ubuntu)
Status: Incomplete = New
I'm confused: dnsmasq won't cache a negative answer if it has no
upstream servers. To cache a negative answer it has to _receive_ a
negative answer (and the
Whatever is going on, it's more complex. Maybe the problem is that
dnsmasq gets a negative answer from some upstream server, and then
gets a new upstream server which has the correct information? The
solution then is --clear-on-reload but I think NM sets that?
but --clear-on-reload
On 15/02/13 18:00, Steve Langasek wrote:
Public bug reported:
On a raring system, the dnsmasq instance spawned by libvirt is not
forwarding DNS requests to the upstream resolver. dnsmasq is run as:
/usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf
Steve, what version of
On 15/02/13 18:52, Steve Langasek wrote:
On Fri, Feb 15, 2013 at 06:35:40PM -, Simon Kelley wrote:
On 15/02/13 18:00, Steve Langasek wrote:
Public bug reported:
On a raring system, the dnsmasq instance spawned by libvirt is not
forwarding DNS requests to the upstream resolver. dnsmasq
On 15/02/13 19:52, Marc Deslauriers wrote:
I was waiting for 2.66 to come out.
Simon, is a 2.66 release planned soon?
Probably not soon. There are no current showstopper issues, but there's
a lot of new code over 2.65, so it will need a reasonably long
release-candidate period to get it
On 15/02/13 18:00, Steve Langasek wrote:
Public bug reported:
On a raring system, the dnsmasq instance spawned by libvirt is not
forwarding DNS requests to the upstream resolver. dnsmasq is run as:
/usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf
Steve, what version of
On 15/02/13 18:52, Steve Langasek wrote:
On Fri, Feb 15, 2013 at 06:35:40PM -, Simon Kelley wrote:
On 15/02/13 18:00, Steve Langasek wrote:
Public bug reported:
On a raring system, the dnsmasq instance spawned by libvirt is not
forwarding DNS requests to the upstream resolver. dnsmasq
On 15/02/13 19:52, Marc Deslauriers wrote:
I was waiting for 2.66 to come out.
Simon, is a 2.66 release planned soon?
Probably not soon. There are no current showstopper issues, but there's
a lot of new code over 2.65, so it will need a reasonably long
release-candidate period to get it
On 06/02/13 08:59, Thomas Hood wrote:
Hi Simon.
Before I forget to ask: can you please update dnsmasq(8) to include
under --strict-order a description of what happens when nameserver
addresses are passed in via D-Bus instead of via a file?
You wrote,
you can very easily provide the same
On 06/02/13 09:18, Thomas Hood wrote:
[...cont'd after in order to fix...] bug #1072899, dnsmasq will
have to be enhanced such that proposition #1 is true. But we can
discuss the details of that in bug #1072899.
parenthesis There is a close analogy between the problem here (bug
#1003842)
On 06/02/13 08:59, Thomas Hood wrote:
Hi Simon.
Before I forget to ask: can you please update dnsmasq(8) to include
under --strict-order a description of what happens when nameserver
addresses are passed in via D-Bus instead of via a file?
You wrote,
you can very easily provide the same
On 06/02/13 09:18, Thomas Hood wrote:
[...cont'd after in order to fix...] bug #1072899, dnsmasq will
have to be enhanced such that proposition #1 is true. But we can
discuss the details of that in bug #1072899.
parenthesis There is a close analogy between the problem here (bug
#1003842)
On 04/02/13 22:05, Thomas Hood wrote:
Simon in #49:
It doesn't work [...] the order of servers given to the DBus
interface isn't preserved internally
Aha, so the answer to my question
Will switching on strict-order have the same effect
now that nameserver addresses are sent over D-Bus?
Belay my previous comment about 1072899, it looks like network manager
is losing the second server before it ever gets to dnsmasq. Not a
dnsmasq problem.
Simon.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
On 04/02/13 22:05, Thomas Hood wrote:
Simon in #49:
It doesn't work [...] the order of servers given to the DBus
interface isn't preserved internally
Aha, so the answer to my question
Will switching on strict-order have the same effect
now that nameserver addresses are sent over D-Bus?
Belay my previous comment about 1072899, it looks like network manager
is losing the second server before it ever gets to dnsmasq. Not a
dnsmasq problem.
Simon.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
On 03/02/13 07:48, Thomas Hood wrote:
there's still the unresolved question
of whether re-enabling --strict-order
will suffice as a workaround, since
12.10 relies on DBus to populate the
nameservers. Is there any extra
information on this?
Please try it and report back. :-)
(Put
On 04/02/13 15:36, Sergio Callegari wrote:
On 04/02/2013 15:40, Simon Kelley wrote:
On 03/02/13 07:48, Thomas Hood wrote:
there's still the unresolved question
of whether re-enabling --strict-order
will suffice as a workaround, since
12.10 relies on DBus to populate the
nameservers
On 03/02/13 07:48, Thomas Hood wrote:
there's still the unresolved question
of whether re-enabling --strict-order
will suffice as a workaround, since
12.10 relies on DBus to populate the
nameservers. Is there any extra
information on this?
Please try it and report back. :-)
(Put
On 04/02/13 15:36, Sergio Callegari wrote:
On 04/02/2013 15:40, Simon Kelley wrote:
On 03/02/13 07:48, Thomas Hood wrote:
there's still the unresolved question
of whether re-enabling --strict-order
will suffice as a workaround, since
12.10 relies on DBus to populate the
nameservers
On 29/10/12 21:50, Glenn Coombs wrote:
The nm-dns-dnsmasq.conf file only shows information relating to the 1st
server - it seems to have totally ignored the 2nd server:
$ cat /var/run/nm-dns-dnsmasq.conf
server=/kl.imgtec.org/192.168.15.221
server=/79.168.192.in-addr.arpa/192.168.15.221
On 29/10/12 21:50, Glenn Coombs wrote:
The nm-dns-dnsmasq.conf file only shows information relating to the 1st
server - it seems to have totally ignored the 2nd server:
$ cat /var/run/nm-dns-dnsmasq.conf
server=/kl.imgtec.org/192.168.15.221
server=/79.168.192.in-addr.arpa/192.168.15.221
On 17/08/12 19:26, Mathieu Trudel-Lapierre wrote:
Any news about this?
There's actually multiple issues here; one of them being that loopback
probably isn't ready yet, which is something we fixed in NetworkManager
(which had the same issue) by depending on it through upstart before
starting
On 17/08/12 19:26, Mathieu Trudel-Lapierre wrote:
Any news about this?
There's actually multiple issues here; one of them being that loopback
probably isn't ready yet, which is something we fixed in NetworkManager
(which had the same issue) by depending on it through upstart before
starting
On 27/07/12 16:10, Launchpad Bug Tracker wrote:
This bug was fixed in the package dnsmasq - 2.62-3ubuntu1
---
dnsmasq (2.62-3ubuntu1) quantal; urgency=low
* debian/rules: install the dnsmasq dbus configuration in dnsmasq-base,
since
users of the standalone binary might
On 27/07/12 16:10, Launchpad Bug Tracker wrote:
This bug was fixed in the package dnsmasq - 2.62-3ubuntu1
---
dnsmasq (2.62-3ubuntu1) quantal; urgency=low
* debian/rules: install the dnsmasq dbus configuration in dnsmasq-base,
since
users of the standalone binary might
Simon, do you think that dnsmasq could misbehave as described here?
The only way I can see for this to occur is if a DNS server is return wrong (ie
NXDOMAIN or NODATA) answers, no answer shouldn't be a problem.
I suggest adding --log-queries to the dnsmasq configuration to try and
get a handle
Simon, do you think that dnsmasq could misbehave as described here?
The only way I can see for this to occur is if a DNS server is return wrong (ie
NXDOMAIN or NODATA) answers, no answer shouldn't be a problem.
I suggest adding --log-queries to the dnsmasq configuration to try and
get a handle
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
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
On 19/06/12 10:10, Chris Halse Rogers wrote:
Additionally, I'd like to know what the likely impact of adding bind-
interfaces to dnsmasq is on users. What (if anything) will break on
users' systems?
Three things change.
1) Dnsmasq loses the ability to provide service on dynamically created
On 19/06/12 10:10, Chris Halse Rogers wrote:
Additionally, I'd like to know what the likely impact of adding bind-
interfaces to dnsmasq is on users. What (if anything) will break on
users' systems?
Three things change.
1) Dnsmasq loses the ability to provide service on dynamically created
On 18/06/12 18:11, Thomas Hood wrote:
Hi Stéphane,
Changing the default of dnsmasq to bind-interfaces wouldn't have been a
very good solution because some people run dnsmasq without installing
those other packages and rely upon the unbound mode. The implemented
solution is better because
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:
On 18/06/12 18:11, Thomas Hood wrote:
Hi Stéphane,
Changing the default of dnsmasq to bind-interfaces wouldn't have been a
very good solution because some people run dnsmasq without installing
those other packages and rely upon the unbound mode. The implemented
solution is better because
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:
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
On 15/06/12 14:54, Christian Parpart wrote:
Hey, thanks, and now I also found this one:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898
which is exactly what I was talking about (interesting that I didn't
find earlier).
However, the last commenter says he's pulling 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
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
On 15/06/12 14:54, Christian Parpart wrote:
Hey, thanks, and now I also found this one:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898
which is exactly what I was talking about (interesting that I didn't
find earlier).
However, the last commenter says he's pulling 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
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.
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.
On 13/06/12 11:07, Thomas Hood wrote:
OK, so the ::1 idea fails as a quick hack. The alternatives seem to be
as follows.
1. Either we accept that nm-dnsmasq is incompatible with every standalone
nameserver and enforce this in a better way;
2. or we force every standalone nameserver into
On 13/06/12 11:07, Thomas Hood wrote:
OK, so the ::1 idea fails as a quick hack. The alternatives seem to be
as follows.
1. Either we accept that nm-dnsmasq is incompatible with every standalone
nameserver and enforce this in a better way;
2. or we force every standalone nameserver into
On 13/06/12 11:07, Thomas Hood wrote:
OK, so the ::1 idea fails as a quick hack. The alternatives seem to be
as follows.
1. Either we accept that nm-dnsmasq is incompatible with every standalone
nameserver and enforce this in a better way;
2. or we force every standalone nameserver into
On 13/06/12 11:07, Thomas Hood wrote:
OK, so the ::1 idea fails as a quick hack. The alternatives seem to be
as follows.
1. Either we accept that nm-dnsmasq is incompatible with every standalone
nameserver and enforce this in a better way;
2. or we force every standalone nameserver into
On 12/06/12 10:05, Alkis Georgopoulos wrote:
Note that while bind-interfaces can be specified multiple times,
defining except-interfaces more than once is a syntax error in my
dnsmasq 2.59-4.
Are you sure? That should be allowed.
Simon.
--
You received this bug notification because you
On 12/06/12 11:24, Thomas Hood wrote:
Hmm, just tested this myself. You can't use except-interface=lo; it
seems you have to use listen-address=10.1.2.3. Perhaps Simon knows a
better way.
If you want to listen on an address which doesn't appear on an interface
(ie 127.0.1.1) then you have
On 12/06/12 20:31, Thomas Hood wrote:
(Executive summary of the following: I think we should fix this by
making nm-dnsmasq listen at ::1.)
Thanks for your much-needed help, Simon.
It is good to know that the except-interface avenue is available. We
want, however, to be able to enjoy the
1 - 100 of 156 matches
Mail list logo
