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 successfully worked out not to use that as it
loops back to itself. It's very likely that it didn't work out that
127.0.0.53 also loops back to itself too, but it's not clear how that's
getting into the list of upstreams.
This is starting to look like an Ubuntu/systemd plumbing problem, rather
than a dnsmasq bug.
Simon.
On 14/03/17 11:15, Paul wrote:
> 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 there were no Transmission processes running, with queries
> from Firefox or perhaps some unidentified Gnome weather applet.
>
> ** Attachment added: "syslog_dns_storm.txt"
> https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1672099/+attachment/4837521/+files/syslog_dns_storm.txt
>
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 successfully worked out not to use that as it
loops back to itself. It's very likely that it didn't work out that
127.0.0.53 also loops back to itself too, but it's not clear how that's
getting into the list of upstreams.
This is starting to look like an Ubuntu/systemd plumbing problem, rather
than a dnsmasq bug.
Simon.
On 14/03/17 11:15, Paul wrote: dns_storm. txt" /bugs.launchpad .net/ubuntu/ +source/ dnsmasq/ +bug/1672099/ +attachment/ 4837521/ +files/ syslog_ dns_storm. txt
> 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 there were no Transmission processes running, with queries
> from Firefox or perhaps some unidentified Gnome weather applet.
>
> ** Attachment added: "syslog_
> https:/
>