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 str
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 process
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:
> Insta
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 li
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
*** 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
-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
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 unpr
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 13/03/
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 success
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) wat
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?
L
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
-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
On 12/02/2025 17:16, jean-christophe manciot wrote:
> Now, if I add dhcp-range option, for instance:
> dhcp-range=192.168.0.50,192.168.0.150,12h
>
> DHCP ports are open on **all** interfaces instead of just lo as specified
> earlier:
> /usr/bin/netstat -tunpevaW | grep dnsmasq
> udp0
It's not clear from this if there's at least one dhcp-range in
/etc/dnsmasq.conf, but from the posted logs, it looks like there isn't.
If so that's the problem. No dhcp-range -> no DHCP server -> no port 67
socket.
Simon.
On 12/02/2025 16:57, jean-christophe manciot wrote:
> Public bug reporte
On 17/02/2025 13:47, jean-christophe manciot wrote:
>> In order to allow multiple dnsmasq instances (for instance in the
>> libvirt case) dnsmasq sets REUSEPORT on DHCP sockets, and, if exactly
>> one interface is specified in the configuration, it sets SO_BINDTODEVICE.
> No, it does not work: if d
On 14/02/2025 13:38, jean-christophe manciot wrote:
> With the following setup:
>
> port=0
> interface=eth0
> bind-interfaces
> dhcp-range=192.168.1.2,192.168.1.254
>
> I get:
> # /usr/bin/netstat -tunpevaW | grep dnsmasq
> udp0 0 0.0.0.0:67 0.0.0.0:*
18 matches
Mail list logo
