[Dnsmasq-discuss] TCP queries are refused if upstream server is specified with interface

Tore Anderson tore at fud.no
Fri Sep 13 13:37:44 BST 2019


* Tore Anderson

> Start out with the following /etc/dnsmasq.conf, replacing «wlp2s0» as appropriate:
> 
> log-queries
> no-hosts
> no-resolv
> server=1.1.1.1 at wlp2s0
> 
> Start Dnsmasq and send it a TCP query:
> 
> $ src/dnsmasq -d -p 5333

Bisected:

305ffb5ef0ba5ab1df32ef80f266a4c9e395ca13 is the first bad commit
commit 305ffb5ef0ba5ab1df32ef80f266a4c9e395ca13
Author: Simon Kelley <simon at thekelleys.org.uk>
Date:   Sat Mar 16 18:17:17 2019 +0000

    Improve kernel-capability manipulation code under Linux.
    
    Dnsmasq now fails early if a required capability is not available,
    and tries not to request capabilities not required by its
    configuration.

:100644 100644 b942ec269cc6c1b7614a9d57cb0b9468507f031c f2d38a0f9bb73b4f480cd323f49cd574fc3e2744 M      CHANGELOG
:040000 040000 a4dd29e7fbdac449dd9b502e012beb2c25a47387 7b0eb0f197c0cb857981c607be8b08d62cee9ff3 M      src

After some more debugging I realised that this is a heisenbug.

Starting Dnsmasq with the «-d» option does not accurately reproduce the problem, since it will not drop privileges in debug mode.

To me it looks as if using a server specified with an interface requires root privileges.

Thus, to trigger the actual bug, there are two options:

1) Start Dnsmasq as non-root (broken on any version, at least since v2.80).
2) Start Dnsmasq as root (this works in v2.80, but is broken since 305ffb5 presumably because Dnsmasq now drops privileges it is going to need later on).

Tore



More information about the Dnsmasq-discuss mailing list