On 16/09/2021 07:29, Todd Derr wrote: > Hi, first time poster and I'm relatively new to dnsmasq. I'm using > dnsmasq from brew on MacOS; I recently upgraded and ran into an issue > with a name that has a v4 address but no v6 address, like so: > > log-queries > log-facility=/usr/local/var/log/dnsmasq.log > address=/dummy.com/127.0.0.2 <http://dummy.com/127.0.0.2> > > On 2.85 and below, the A query is answered and the AAAA returns NODATA: > > Sep 13 16:29:38 dnsmasq[68]: query[A] dummy.com <http://dummy.com> > from 127.0.0.1 > Sep 13 16:29:38 dnsmasq[68]: config dummy.com <http://dummy.com> is > 127.0.0.2 > Sep 13 16:29:38 dnsmasq[68]: query[AAAA] dummy.com > <http://dummy.com> from 127.0.0.1 > Sep 13 16:29:38 dnsmasq[68]: config dummy.com <http://dummy.com> is > NODATA-IPv6 > > > Whereas on 2.86 the AAAA query gets forwarded to the system nameservers: > > Sep 14 20:50:08 dnsmasq[31529]: query[A] dummy.com > <http://dummy.com> from 127.0.0.1 > Sep 14 20:50:08 dnsmasq[31529]: config dummy.com <http://dummy.com> > is 127.0.0.2 > Sep 14 20:50:08 dnsmasq[31529]: query[AAAA] dummy.com > <http://dummy.com> from 127.0.0.1 > Sep 14 20:50:08 dnsmasq[31529]: forwarded dummy.com > <http://dummy.com> to 8.8.8.8 > Sep 14 20:50:08 dnsmasq[31529]: forwarded dummy.com > <http://dummy.com> to 8.8.4.4 > Sep 14 20:50:08 dnsmasq[31529]: reply dummy.com <http://dummy.com> > is <CNAME> > Sep 14 20:50:08 dnsmasq[31529]: reply odrfn4em.cname.us.ngrok.io > <http://odrfn4em.cname.us.ngrok.io> is 2600:1f16:d83:1202::6e:5 > > Was this an intentional change in behavior? I didn't see anything in > the CHANGELOG and haven't tried to look through the code changes yet.
The whole implementation of this got re-written for 2.86, but the intention was not to actually change behaviour. It looks like this slipped through. I'm in a quandary about if this change is a bad thing, or not. In general the dnsmasq philosophy is that you configure stuff that you want it to overlay on the public DNS, and everything else gets passed through unchanged. It is, for instance, the case that if you put an IPV4 address in /etc/hosts but not an IPv6 address, then AAAA queries will be passed through, and all versions of dnsmasq forever have done that. In 2.86, there's a defined priority list for domains, so the behaviour you want is easy to define address=/dummy.com/127.0.0.2 local=/dummy.com/ For A queries, the first line has priority, for all others, the second line returns NODATA* *Actually, NODATA comes from the combination of both lines; the second by itself would generate NXDOMAIN. TL;DR The new behaviour is a regression, and an unintended one. But the new behaviour is more consistent and well defined and allows for a different configuration which provides the old behaviour if required. Maybe better documentation is the solution? Cheers, Simon. > > Is there any way to disable it? As a workaround I added this to the > config, which may have the same basic effect as NODATA but it's hacky > and worries me a bit: > > address=/dummy.com/ <http://dummy.com/>:: > See above. > The actual problem this caused is kind of comical in retrospect but > bewildering and frustrating until I figured it out: > * Since the initial A query still returns the expected v4 address > (127.0.0.2), the HTTP request that triggered the lookup succeeded. > * However, since the AAAA query contains a CNAME, the resolver dutifully > looks up the v4 address for that CNAME and effectively poisons the cache > and makes future requests fail (since the ngrok tunnel is not up) > * Adding to the fun, since ping only does the A query, it didn't perturb > the state of the cache. > * The TTL for the CNAME is 1 hour > > add that all up, and I had this running in a terminal and would see the > address spontaneously change for reasons that took me quite a while to > discern: > > while true; do echo "$(date) $(ping -c1 -t1 dummy.com > <http://dummy.com> | head -1)"; sleep 1; done > > > it was a wild ride, thanks for following along and I hope you had a > laugh at my expense. We're not laughing. We like a thorough analysis of the problem, and that is one. > > todd. > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss > _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
