[Dnsmasq-discuss] address option doesn't work correctly if the target domain is a cname
Simon Kelley
simon at thekelleys.org.uk
Mon Apr 18 13:38:00 UTC 2022
On 16/04/2022 18:13, Анна Тихомирова via Dnsmasq-discuss wrote:
> Hello.
>
> I'm using dnsmasq version 2.86.
>
> I've found that address option works incorrectly if the target domain is
> a cname.
>
> Here is an example:
>
> 1) Add a domain to dnsmasq configuration:
>
> address=/api.ott.kinopoisk.ru/::
>
> 2) Make a DNS query for this domain. Everything is fine now: dnsmasq
> replies with an IPv4 address received from the upstream DNS server and
> an IPv6 address from the configuration file
>
> root at veronika:~# nslookup api.ott.kinopoisk.ru
> Server: 127.0.0.1
> Address: 127.0.0.1:53
>
> Name: api.ott.kinopoisk.ru
> Address: ::
>
> Non-authoritative answer:
> api.ott.kinopoisk.ru canonical name =
> ott-api-production-balancer.ott.yandex.net
> Name: ott-api-production-balancer.ott.yandex.net
> Address: 93.158.134.102
>
> Sat Apr 16 19:13:20 2022 daemon.info dnsmasq[1]: 419 127.0.0.1/58719
> query[A] api.ott.kinopoisk.ru from 127.0.0.1
> Sat Apr 16 19:13:20 2022 daemon.info dnsmasq[1]: 419 127.0.0.1/58719
> forwarded api.ott.kinopoisk.ru to 213.234.192.7
> Sat Apr 16 19:13:20 2022 daemon.info dnsmasq[1]: 420 127.0.0.1/58719
> query[AAAA] api.ott.kinopoisk.ru from 127.0.0.1
> Sat Apr 16 19:13:20 2022 daemon.info dnsmasq[1]: 420 127.0.0.1/58719
> config api.ott.kinopoisk.ru is ::
> Sat Apr 16 19:13:20 2022 daemon.info dnsmasq[1]: 419 127.0.0.1/58719
> reply api.ott.kinopoisk.ru is <CNAME>
> Sat Apr 16 19:13:20 2022 daemon.info dnsmasq[1]: 419 127.0.0.1/58719
> reply ott-api-production-balancer.ott.yandex.net is 93.158.134.102
>
> 3) You may repeat a query and everything is still fine:
>
> root at veronika:~# nslookup api.ott.kinopoisk.ru
> Server: 127.0.0.1
> Address: 127.0.0.1:53
>
> Non-authoritative answer:
> api.ott.kinopoisk.ru canonical name =
> ott-api-production-balancer.ott.yandex.net
> Name: ott-api-production-balancer.ott.yandex.net
> Address: 93.158.134.102
>
> Name: api.ott.kinopoisk.ru
> Address: ::
>
> Sat Apr 16 19:13:26 2022 daemon.info dnsmasq[1]: 431 127.0.0.1/34089
> query[A] api.ott.kinopoisk.ru from 127.0.0.1
> Sat Apr 16 19:13:26 2022 daemon.info dnsmasq[1]: 431 127.0.0.1/34089
> cached api.ott.kinopoisk.ru is <CNAME>
> Sat Apr 16 19:13:26 2022 daemon.info dnsmasq[1]: 431 127.0.0.1/34089
> cached ott-api-production-balancer.ott.yandex.net is 93.158.134.102
> Sat Apr 16 19:13:26 2022 daemon.info dnsmasq[1]: 432 127.0.0.1/34089
> query[AAAA] api.ott.kinopoisk.ru from 127.0.0.1
> Sat Apr 16 19:13:26 2022 daemon.info dnsmasq[1]: 432 127.0.0.1/34089
> cached api.ott.kinopoisk.ru is <CNAME>
> Sat Apr 16 19:13:26 2022 daemon.info dnsmasq[1]: 432 127.0.0.1/34089
> config api.ott.kinopoisk.ru is ::
>
> 4) Now query the original domain to which our configured domain points to:
>
> root at veronika:~# nslookup ott-api-production-balancer.ott.yandex.net
> Server: 127.0.0.1
> Address: 127.0.0.1:53
>
> Non-authoritative answer:
> Name: ott-api-production-balancer.ott.yandex.net
> Address: 93.158.134.102
>
> Non-authoritative answer:
> Name: ott-api-production-balancer.ott.yandex.net
> Address: 2a02:6b8::272
>
>
> Sat Apr 16 19:13:33 2022 daemon.info dnsmasq[1]: 442 127.0.0.1/51782
> query[A] ott-api-production-balancer.ott.yandex.net from 127.0.0.1
> Sat Apr 16 19:13:33 2022 daemon.info dnsmasq[1]: 442 127.0.0.1/51782
> cached ott-api-production-balancer.ott.yandex.net is 93.158.134.102
> Sat Apr 16 19:13:33 2022 daemon.info dnsmasq[1]: 443 127.0.0.1/51782
> query[AAAA] ott-api-production-balancer.ott.yandex.net from 127.0.0.1
> Sat Apr 16 19:13:33 2022 daemon.info dnsmasq[1]: 443 127.0.0.1/51782
> forwarded ott-api-production-balancer.ott.yandex.net to 213.234.192.7
> Sat Apr 16 19:13:33 2022 daemon.info dnsmasq[1]: 443 127.0.0.1/51782
> reply ott-api-production-balancer.ott.yandex.net is 2a02:6b8::272
>
> 5) Let's query our configured domain again. Now you can see that dnsmasq
> starts to reply with IPv6 from upstream server instead of our configured
> IPv6:
>
> root at veronika:~# nslookup api.ott.kinopoisk.ru
> Server: 127.0.0.1
> Address: 127.0.0.1:53
>
> Non-authoritative answer:
> api.ott.kinopoisk.ru canonical name =
> ott-api-production-balancer.ott.yandex.net
> Name: ott-api-production-balancer.ott.yandex.net
> Address: 93.158.134.102
>
> Non-authoritative answer:
> api.ott.kinopoisk.ru canonical name =
> ott-api-production-balancer.ott.yandex.net
> Name: ott-api-production-balancer.ott.yandex.net
> Address: 2a02:6b8::272
>
>
> Sat Apr 16 19:13:37 2022 daemon.info dnsmasq[1]: 458 127.0.0.1/35410
> query[A] api.ott.kinopoisk.ru from 127.0.0.1
> Sat Apr 16 19:13:37 2022 daemon.info dnsmasq[1]: 458 127.0.0.1/35410
> cached api.ott.kinopoisk.ru is <CNAME>
> Sat Apr 16 19:13:37 2022 daemon.info dnsmasq[1]: 458 127.0.0.1/35410
> cached ott-api-production-balancer.ott.yandex.net is 93.158.134.102
> Sat Apr 16 19:13:37 2022 daemon.info dnsmasq[1]: 459 127.0.0.1/35410
> query[AAAA] api.ott.kinopoisk.ru from 127.0.0.1
> Sat Apr 16 19:13:37 2022 daemon.info dnsmasq[1]: 459 127.0.0.1/35410
> cached api.ott.kinopoisk.ru is <CNAME>
> Sat Apr 16 19:13:37 2022 daemon.info dnsmasq[1]: 459 127.0.0.1/35410
> cached ott-api-production-balancer.ott.yandex.net is 2a02:6b8::272
>
>
Thanks for the detailed description.
It's kind-off obvious what's going on here: the CNAME gets cached from
the IPv4 lookups and then the AAAA record that the CNAME points to gets
cached when it's looked up directly.
What's not obvious is what to do about it: In versions before 2.86, this
wouldn't be a problem, because
address=/api.ott.kinopoisk.ru/::
would stop any queries for api.ott.kinopoisk.ru, including the IPv4
query, being sent upstream. That means the an A query (or any other
query) would return NODATA, and an AAAA query would return ::, which is
all consistent.
2.86 changed this behaviour, half by accident. (I made assumptions about
what would be sensible, and didn't check exsiting behaviour well enough.
Never make assumptions.)
The 2.86 behaviour is not consistent. api.ott.kinopoisk.ru can't be both
a CNAME and an all-zeros AAAA record. It could be a CNAME pointing to an
all-zeros AAAA record, but then you'd still get a different answer if
you looked up that AAAA record stand-alone.
I'm sort-of persuaded that this is another good argument to return to
the pre-2.86 behaviour, despite the fact that is imposes a second
incompatible change: at least it's only incomptable if you're upgrading
from 2.86.
Opinions, list?
Simon.
> _______________________________________________
> 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