Fixed my dnsmasq systemd-resolve race with dnsmasq config.
/etc/dnsmasq.d/myconfig
#PES 20180808 dnsmasq and systemd-resolve conflict.
# dont use /etc/resolv.conf, go direct to systemd-resolve, only bind to lo
no-resolv
bind-interfaces
interface=lo
server=127.0.0.53
--
You received this bug
The same problem arises, only when in dnsmasq I register local addresses
on the virtual local server
address=/.dev/192.168.56.20
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1672099
Title:
DNS
You're right, it turns out dnsmasq was only installed because I had
installed polipo, which depends on the dnsmasq package. Purging polipo
removes dnsmasq.
I have been running polipo (with config files unmodified from default)
for several years, including since fresh installing Ubuntu-Gnome
Where does the dnsmasq package come from that is listening on 127.0.0.1?
dnsmasq should normally not be listening on that address if it was
spawned by NetworkManager.
Do you have the 'dnsmasq' package installed instead of dnsmasq-base?
dnsmasq-base can be used in a variety of scenarios as a local
What are the contents of /etc/resolv.conf when this happens?
What is the output of 'dpkg -l dnsmasq\*'?
What are the contents of /etc/NetworkManager/NetworkManager.conf?
Your bug report shows that this system was installed with 16.10 media
and then upgraded to 17.04. How long ago did you
I asked on IRC:
18:15 rbasak: AFAIK dnsmasq is dropped out of the default DNS stack
again in 17.04, so that shouldn't be happening?
18:15 certainly, resolved+networkd+resolvconf+dnsmasq might have
bugs like this
18:15 but that's not the config we're supposed to be shipping
So I think
I just found that I can reproduce this loop state by reconnecting to my
Wi-Fi access point. The storm starts right after this line, 5 seconds
after the link comes up:
systemd-resolved[1188]: Server 127.0.0.1 does not support DNSSEC,
downgrading to non-DNSSEC mode.
The (much shorter this time)
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
I have cpulimit(1) watching dnsmasq now, so it only goes berserk for a
second before being killed, but the attached syslog extract captures the
moments before and during the DNS storm. These particular lookups are
mostly originated by Transmission, but previously the storms have
happened when
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
There aren't any such entries in syslog, presumably because I had
hardcoded two upstream servers (208.67.222.222 and 208.67.220.220) using
the GUI Wi-Fi settings dialog in 16.10 and they're not changing. Oddly,
I can't see that setting in the 17.04 dialog, even though "systemd-
resolve --status"
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
Restarting dnsmasq immediately stops an ongoing DNS storm.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1672099
Title:
DNS loop, >5,000 queries per second for minutes at a time
To manage
14 matches
Mail list logo
