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.w...@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@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@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@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@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@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss