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
[email protected]
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to