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

Tomas Hozza thozza at redhat.com
Wed Jan 30 10:42:06 GMT 2013


----- Original Message -----
> 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.

You are right. Your change looks way better and doesn't add need to
change anything in libvirt.

> 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().

This solution looks very sane. Thank you very much for your effort!
 
> 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

I will do some testing and if everything works also push a testing update in Fedora.
I'll let you know if there is any issue regarding the change.

Thank you again!


Regards,

Tomas Hozza



More information about the Dnsmasq-discuss mailing list