[Dnsmasq-discuss] NXDOMAIN on AAAA with Debian LXC

[Simon Kelley]

The problem for people on this list is that we don't (or, at least, I
don't) have any knowledge about lxc. If you can give us information
about the dnsmasq configuration that's being generated by lxc, then we
stand a better chance of diagnosing the problem.

I'm assuming that the VMs are getting addresses by DHCP, and therefore
the names test-dove and test-harp are names that derive from DHCP leases.

Can you enable the dnsmasq option --log-queries, and find the logs
associated with your test DNS queries? That should give us some
information about where dnsmasq is getting the information from.


Cheers,


Simon.




On 24/09/14 15:01, Chris West wrote:
> I've re-tested this with the 2.72 release (I'm pretty sure!) and I'm still
> seeing the same intermittent behaviour.
> 
> On 23 September 2014 10:37, Chris West <chris.west at logicalglue.com> wrote:
> 
>> dnsmasq is being run by the Debian (well, Ubuntu) lxc scripts.  I am
>> proxying to lxc vms (by name) with nginx (so using the nginx built-in
>> resolver, which seems more sensitive than normal resolvers).
>>
>> On an Ubuntu Trusty machine (dnsmasq 2.68), everything works fine.
>>
>> On an Ubuntu Utopic machine (dnsmasq 2.71), proxying always fails with
>> "..foo could not be resolved (3: Host not found)".
>>
>> I thought for a while that this might have been:
>> * 288df49 - Fix bug when resulted in NXDOMAIN answers instead of NODATA.
>> (5 days ago) <Simon Kelley>
>>
>> ...so I rolled the Utopic machine back to the 2.68 package.  (I'm not
>> confident with building a replacement dnsmasq given how complex the debian
>> LXC stuff is.)  However, now this still fails intermittently, and I'm at a
>> loss.
>>
>> Currently I have two running machines, named "test-dove" and "test-harp".
>>  "harp" was started after "dove".  Both resolve fine for A records:
>> ubuntu at wolf ~$ dig -t A test-dove @10.0.3.1 | egrep 'status:|IN'
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65076
>> ;test-dove. IN A
>> test-dove. 0 IN A 10.0.3.168
>> ubuntu at wolf ~$ dig -t A test-harp @10.0.3.1 | egrep 'status:|IN'
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35736
>> test-harp. 0 IN A 10.0.3.34
>>
>> However, only "dove" gets a correct answer for AAAA records:
>> ubuntu at wolf ~$ dig -t AAAA test-dove @10.0.3.1 | egrep 'status:|IN'
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57038
>> ;test-dove. IN AAAA
>> ubuntu at wolf ~$ dig -t AAAA test-harp @10.0.3.1 | egrep 'status:|IN'
>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14476
>> ;test-harp. IN AAAA
>>
>> Is this likely to be fixed by that patch, or can anyone else guess what's
>> up with the system?
>>
>>
> 
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>