Update: I think it is indeed a dnsmasq bug -- details below...
[trimming some context and cross-posting to dnsmasq-discuss]
On 12/01/2014 10:50 AM, Josh Stone wrote:
> On 12/01/2014 05:18 AM, Martin Kletzander wrote:
>> On Mon, Dec 01, 2014 at 07:49:32AM -0500, Laine Stump wrote:
>>> On 11/30/2014 04:06 PM, Martin Kletzander wrote:
>>>> 2) If your answer to the previous question is "NO", which might very
>>>> well be the case, for example if you don't want to forward that
>>>> one particular domain only (and I misunderstood the commit
>>>> message), I think you should just use the ",local" subparameter of
>>>> the domain parameter (domain=example.com,local).
>>>
>>> Interesting idea - this requires specifying the IP/prefix of the network
>>> in the option along with domain (which I suppose isn't a problem), and
>>> has the same effect as adding local=/domain.com/ as well as the reverse
>>> resolution, which is a nice plus. However, the prefix for the network
>>> must be 8, 16, or 24 for this to work (because of the way that
>>> *.in-addr.arpa records are defined), so we can't do this all the time.
>>> The question is then - do we write in a special case to do it this way
>>> when the prefix is one of the right lengths, or just not do it at all?
>>> Having it "magically happen" for some configs and not others could lead
>>> to confusion, but having reverse resolution when possible would be very
>>> useful (for example, some sshd setups have a long delay if the
>>> reverse-resolve of the client's IP doesn't return something other than
>>> "not found"; a pointless piece of security theater, but still fairly
>>> common).
>>>
>>
>> Looking at the documentation again, I understand it a bit more yet
>> again. Let's assume people use normal domain names. Libvirt can use
>> the IP address and netmask from the 'ip' element (if known) and
>> construct the domain parameter for the config file:
>>
>> domain=virt,192.168.13.0/24,local
>>
>> If there's no IP address known, then it could be constructed as
>> follows:
>>
>> domain=virt
>> local=/virt/
>>
>> What do you say?
>>
>>
>> Currently this is possible to achieve with the following in the XML:
>>
>> <domain name='virt,192.168.13.0/24,local'/>
>>
>> But that's just plain ugly ;-)
>
> Interesting. If this works, and libvirt promises not to take it away
> from me later, then it would be enough to satisfy my itch. :)
>
> However, it doesn't actually seem to do the right thing. The option
> does survive from XML to the dnsmasq conf, but it doesn't seem to
> actually behave as local. When I manually tweak the conf and restart
> libvirt's dnsmasq myself, it seems that having separate "domain=foo" and
> "local=/foo/" terminates properly, but having a oneliner
> "domain=foo,192.168.122.0/24,local" is still forwarding to the host.
> Which then forwards back to libvirt, and I get my loop. :(
>
> This is dnsmasq-2.72-3.fc21.x86_64. Maybe dnsmasq only only treats it
> local when coming from that subnet? But it's documented as equivalent
> to local=/foo/, so maybe dnsmasq has a bug here. Did you try it?
I found that dnsmasq option.c has these lines:
/* generate the equivalent of
local=/<domain>/
local=/xxx.yyy.zzz.in-addr.arpa/ */
struct server *serv = add_rev4(new->start, msize);
serv->flags |= SERV_NO_ADDR;
But that only appears to create the second part for rDNS, where the
first part is more important for my case. That changed in commit
de73a497cad21, which went into v2.69, and before that it did have an
additional snippet to create the local=/domain/ part too.
So, dnsmasq folks, do you agree that this is a bug?
Thanks,
Josh
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list