<div dir="ltr">I've re-tested this with the 2.72 release (I'm pretty sure!) and I'm still seeing the same intermittent behaviour.</div><div class="gmail_extra"><br><div class="gmail_quote">On 23 September 2014 10:37, Chris West <span dir="ltr"><<a href="mailto:chris.west@logicalglue.com" target="_blank">chris.west@logicalglue.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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).<div><br></div><div>On an Ubuntu Trusty machine (dnsmasq 2.68), everything works fine.</div><div><br></div><div>On an Ubuntu Utopic machine (dnsmasq 2.71), proxying always fails with "..foo could not be resolved (3: Host not found)".</div><div><br></div><div>I thought for a while that this might have been:</div><div><div>* 288df49 - Fix bug when resulted in NXDOMAIN answers instead of NODATA. (5 days ago) <Simon Kelley></div></div><div><br></div><div>...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.</div><div><br></div><div>Currently I have two running machines, named "test-dove" and "test-harp".  "harp" was started after "dove".  Both resolve fine for A records:</div><div><div><div>ubuntu@wolf ~$ dig -t A test-dove @<a href="http://10.0.3.1" target="_blank">10.0.3.1</a> | egrep 'status:|IN'</div><div>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65076</div><div>;test-dove.<span style="white-space:pre-wrap">                     </span>IN<span style="white-space:pre-wrap">      </span>A</div><div>test-dove.<span style="white-space:pre-wrap">              </span>0<span style="white-space:pre-wrap">       </span>IN<span style="white-space:pre-wrap">      </span>A<span style="white-space:pre-wrap">       </span>10.0.3.168</div></div><div><div>ubuntu@wolf ~$ dig -t A test-harp @<a href="http://10.0.3.1" target="_blank">10.0.3.1</a> | egrep 'status:|IN'</div><div>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35736</div><div>test-harp.<span style="white-space:pre-wrap">            </span>0<span style="white-space:pre-wrap">       </span>IN<span style="white-space:pre-wrap">      </span>A<span style="white-space:pre-wrap">       </span>10.0.3.34</div></div></div><div><br></div><div>However, only "dove" gets a correct answer for AAAA records:</div><div><div>ubuntu@wolf ~$ dig -t AAAA test-dove @<a href="http://10.0.3.1" target="_blank">10.0.3.1</a> | egrep 'status:|IN'</div><div>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57038</div><div>;test-dove.<span style="white-space:pre-wrap">                        </span>IN<span style="white-space:pre-wrap">      </span>AAAA</div><div>ubuntu@wolf ~$ dig -t AAAA test-harp @<a href="http://10.0.3.1" target="_blank">10.0.3.1</a> | egrep 'status:|IN'</div><div>;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14476</div><div>;test-harp.<span style="white-space:pre-wrap">                    </span>IN<span style="white-space:pre-wrap">      </span>AAAA</div><div><br></div><div>Is this likely to be fixed by that patch, or can anyone else guess what's up with the system?</div></div><div><br></div></div>
</blockquote></div><br></div>