[Dnsmasq-discuss] NXDOMAIN on AAAA with Debian LXC

Simon Kelley simon at thekelleys.org.uk
Wed Sep 24 20:38:05 BST 2014

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.



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 @ | egrep 'status:|IN'
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65076
>> ;test-dove. IN A
>> test-dove. 0 IN A
>> ubuntu at wolf ~$ dig -t A test-harp @ | egrep 'status:|IN'
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35736
>> test-harp. 0 IN A
>> However, only "dove" gets a correct answer for AAAA records:
>> ubuntu at wolf ~$ dig -t AAAA test-dove @ | egrep 'status:|IN'
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57038
>> ;test-dove. IN AAAA
>> ubuntu at wolf ~$ dig -t AAAA test-harp @ | 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

More information about the Dnsmasq-discuss mailing list