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

Matus UHLAR - fantomas uhlar at fantomas.sk
Fri Sep 17 07:45:38 UTC 2021


On 16.09.21 02: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
>
>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>

this is strange, from here it does not look like dummy.com is a CNAME.

is someone hijacking DNS records for dummy.com in addition to yourself?

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

this is not hacky, but documented:


To give both IPv4 and IPv6 addresses for a domain, use repeated --address
flags.  To include multiple IP addresses for a single query, use
--addn-hosts=<path>


>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

that is how DNS and CNAMEs work, however as I noted above, dummy.com is NOT
a CNAME.

>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.

-- 
Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Christian Science Programming: "Let God Debug It!".



More information about the Dnsmasq-discuss mailing list