[Dnsmasq-discuss] change in behavior where v4 address exists but not v6 in 2.86

Simon Kelley simon at thekelleys.org.uk
Sat Sep 18 23:03:59 UTC 2021

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/ <http://dummy.com/>
> 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
>     Sep 13 16:29:38 dnsmasq[68]: config dummy.com <http://dummy.com> is
>     Sep 13 16:29:38 dnsmasq[68]: query[AAAA] dummy.com
>     <http://dummy.com> from
>     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
>     Sep 14 20:50:08 dnsmasq[31529]: config dummy.com <http://dummy.com>
>     is
>     Sep 14 20:50:08 dnsmasq[31529]: query[AAAA] dummy.com
>     <http://dummy.com> from
>     Sep 14 20:50:08 dnsmasq[31529]: forwarded dummy.com
>     <http://dummy.com> to
>     Sep 14 20:50:08 dnsmasq[31529]: forwarded dummy.com
>     <http://dummy.com> to
>     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


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?


> 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
> (, 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 at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

More information about the Dnsmasq-discuss mailing list