DNS breaks when port=0 is used in dnsmasq.conf

[Alkis Georgopoulos]

The following function is defined in /etc/init.d/dnsmasq:

start_resolvconf()
{
# If interface "lo" is explicitly disabled in /etc/default/dnsmasq
# Then dnsmasq won't be providing local DNS, so don't add it to
# the resolvconf server set.
        for interface in $DNSMASQ_EXCEPT
        do
                [ $interface = lo ] && return
        done

        if [ -x /sbin/resolvconf ] ; then
                echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.$NAME
        fi
        return 0
}

When someone puts port=0 in dnsmasq.conf, because e.g. he wants to use it only as a (proxy)DHCP/TFTP server,
127.0.0.1 is added to resolvconf, and DNS is broken because nothing listens there.

One workaround is to put DNSMASQ_EXCEPT=lo in /etc/default/dnsmasq.
But that doesn't make much sense, we don't want to exclude some interface, we're not running a DNS server at all.

So it would be nice if dnsmasq checked if port=0 is defined in its configuration, and didn't add 127.0.0.1 to resolvconf then.

Sample implementation code, to be inserted before `if [ -x /sbin/resolvconf ]`:
    grep -qr port=0 /etc/dnsmasq.d/ /etc/dnsmasq.conf && return

[Alkis Georgopoulos (alkisg)]

Better regex to avoid a possibly commented #port=0:
    grep -qr "^[[:space:]]*port=0" /etc/dnsmasq.d/ /etc/dnsmasq.conf && return

[Simon Kelley (simon-thekelleys)]

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 override things in /etc/default/dnsmasq.

A better solution might be to extend the IGNORE_RESOLVCONF setting in
/etc/default/dnsmasq so that it inhibits adding 127.0.0.1 to resolvconf,
as well as stopping dnsmasq from using the resolvconf output as upstream.

Simon.

On 30/09/15 07:38, Alkis Georgopoulos wrote:
> Public bug reported:
>
> The following function is defined in /etc/init.d/dnsmasq:
>
> start_resolvconf()
> {
> # If interface "lo" is explicitly disabled in /etc/default/dnsmasq
> # Then dnsmasq won't be providing local DNS, so don't add it to
> # the resolvconf server set.
> for interface in $DNSMASQ_EXCEPT
> do
> [ $interface = lo ] && return
> done
>
> if [ -x /sbin/resolvconf ] ; then
> echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.$NAME
> fi
> return 0
> }
>
> When someone puts port=0 in dnsmasq.conf, because e.g. he wants to use it only as a (proxy)DHCP/TFTP server,
> 127.0.0.1 is added to resolvconf, and DNS is broken because nothing listens there.
>
> One workaround is to put DNSMASQ_EXCEPT=lo in /etc/default/dnsmasq.
> But that doesn't make much sense, we don't want to exclude some interface, we're not running a DNS server at all.
>
> So it would be nice if dnsmasq checked if port=0 is defined in its
> configuration, and didn't add 127.0.0.1 to resolvconf then.
>
> Sample implementation code, to be inserted before `if [ -x /sbin/resolvconf ]`:
> grep -qr port=0 /etc/dnsmasq.d/ /etc/dnsmasq.conf && return
>
> ** Affects: dnsmasq (Ubuntu)
> Importance: Undecided
> Status: New
>
>
> ** Tags: patch
>

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

This sounds like a valid bug for a relatively uncommon use case. Does this bug affect Debian also? In that case, it would be appropriate to seek a fix there.

[Alkis Georgopoulos (alkisg)]

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 as a local resolver, and mixing the two DNS servers is problematic (neither bind-dynamic nor bind-interfaces work very well).
In Debian they more frequently use the normal dnsmasq/DNS service as it was designed, because NM doesn't spawn a local resolver there.

For upstream report, Simon (the upstream dnsmasq developer and Debian maintainer) already answered here, Simon would you like me to file a debian bug as well? It's easy to work around this issue, so we can even close it with won't fix if you prefer.

Thank you.

[Robie Basak (racb)]

Thanks Alkis. I didn't realise that Simon is the Debian maintainer. I just wanted to try and make sure this bug doesn't languish because it hasn't gone to the right place.

I'm quite happy for this bug to remain open in Ubuntu if that's what Simon wants to do. As long as we consider the bug valid and open then that's the right status as long as the issue remains unfixed in Ubuntu, whether or not the fix belongs in Debian.

[Simon Kelley (simon-thekelleys)]

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 as a local resolver, and mixing the two DNS servers is problematic (neither bind-dynamic nor bind-interfaces work very well).
> In Debian they more frequently use the normal dnsmasq/DNS service as it was designed, because NM doesn't spawn a local resolver there.
>
> For upstream report, Simon (the upstream dnsmasq developer and Debian
> maintainer) already answered here, Simon would you like me to file a
> debian bug as well? It's easy to work around this issue, so we can even
> close it with won't fix if you prefer.
>
> Thank you.
>

No need to file a Debian bug, whatever fix goes in will go into upstream
and Debian anyway.

Cheers,

Simon.