[Dnsmasq-discuss] dnsmasq: RFE: Add new option to allow dnsmasq to answer local DNS queries when using --bind-dynamic

Simon Kelley simon at thekelleys.org.uk
Wed Jan 30 10:17:03 GMT 2013


On 29/01/13 09:53, Tomas Hozza wrote:
> ----- Original Message -----
>> ----- Original Message -----
>>> On 28/01/13 13:41, Tomas Hozza wrote:
>>>> Hi Simon.
>>>>
>>>> After fixing the "incoming interface of the DNS query" problem
>>>> for
>>>> TCP
>>>> and UDP a new problem appeared in libvirt's use case.
>>>>
>>>> There are people that have NetworkManager's dnsmasq configured to
>>>> forward
>>>> DNS queries for a local domain to <IP-of-local-virt.-bridge>
>>>> (virtual bridge to which
>>>> the libvirt's dnsmasq is bound to) so it can resolve DNS queries
>>>> to
>>>> virtual machines
>>>> DHCP hostnames.
>>>>
>>>> Before, when libvirt was using --bind-interfaces for its dnsmasq
>>>> instances
>>>> everything worked fine. After moving to --bind-dynamic it still
>>>> worked
>>>> for TCP queries (since incoming interface of UDP queries was
>>>> checked).
>>>> Now, when TCP queries are fixed to also check the incoming
>>>> interface, the previous
>>>> use case doesn't work at all.
>>>>
>>>> Checking the incoming interface is completely fine! The problem
>>>> is,
>>>> that those
>>>> local DNS queries are routed on Linux (I don't know how it is on
>>>> other OS) through
>>>> loopback interface. Since libvirt's dnsmasq is run with
>>>> --except-interface lo it is
>>>> not bound to loopback, therefore every DNS Query coming through
>>>> loopback is discarded.
>>>> Libvirt's dnsmasq cannot bind to loopback interface (because
>>>> there
>>>> may be more
>>>> instances running and so on...).
>>>>
>>>> Therefore I was thinking maybe you could add new dnsmasq option,
>>>> that would allow
>>>> dnsmasq to answer DNS queries that came through loopback
>>>> interface
>>>> even if it is
>>>> not bound to loopback. It would make sense to use this option in
>>>> case the default
>>>> network mode is used or --bind-dynamic.
>>>>
>>>> I prepared and tested a patch (for the current git HEAD) that
>>>> adds
>>>> new option
>>>> --answer-local-query with this functionality.
>>>>
>>>> Please have look and consider adding this new option to dnsmasq.
>>>> Thank you!
>>>>
>>>
>>> Will certainly think about doing this, or something like it, but
>>> first
>>> there may be a simpler solution. I remeber, when testing the
>>> previous
>>> code, noticing that IPv4 and IPv6 are different in this respect.
>>> Access
>>> to a local IPv4 address does indeed have arrival interface == lo,
>>> but
>>> for IPv6, it was the interface to which the local address was
>>> bound.
>>> Any
>>> chance you could solve the problem simply by moving from IPv4 to
>>> IPv6?
>>>
>>> Cheers,
>>>
>>> Simon.
>>
>> Thank you for your reply. The question about moving from IPv4 to IPv6
>> would
>> be better for libvirt maintainers. I tested DNS queries with IPv6 and
>> it works
>> even though packets are routed through loopback (examined with
>> wireshark).
> 
> Well, I knew that there must be a good reason why IPv6 is not used by
> libvirt by default. It looks like it caused some problems in the past.
> Please see https://bugzilla.redhat.com/show_bug.cgi?id=501934


OK, that's fair enough. It's probably too soon to rely on systems having
IPv6 available anyway.

I've committed my take on your patch. I've eliminated the configuration
option, it doesn't add any usefulness, it's just another "which set of
uneasy compromises do you want" selector, like --bind-interfaces and
--bind-dynamic. Those two are more enough, if we can avoid adding extra.

I justify this by making the checks more stringent: you can't get an
answer to a query to 127.0.0.1, even when binding the wildcard address,
just because lo has address 127.0.0.1 and the loopback bit set. The
query must still be sent to an address we've allowed, even if it's now
allowed to arrive via a loopback interface. The cleverness is in a new
function: loopback_exception().

I've applied the same rules to TFTP; they're not really relevant for DHCP/RA

As always, please could you sanity check this?

Git HEAD, or dnsmasq2.66test13


Cheers,

Simon.









More information about the Dnsmasq-discuss mailing list