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

Todd Derr salty at bandcamp.com
Thu Sep 16 06:29:32 UTC 2021


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

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

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/::

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 | head -1)"; sleep 1;
done


it was a wild ride, thanks for following along and I hope you had a laugh
at my expense.

todd.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20210916/df226d69/attachment.htm>


More information about the Dnsmasq-discuss mailing list