On 20/06/2021 05:31, Xingcong Li wrote:
> Hello, I have reproduced the bug. The issue is valid Now!
> 
> Here is my dnsmasq config file:
> 
> # /tmp/dnsmasq.conf
> port=30000
> no-resolv
> no-poll
> server=114.114.114.114
> server=/fb.me/8.8.8.8 <http://fb.me/8.8.8.8>
> address=/qq.com/127.0.0.1 <http://qq.com/127.0.0.1>
> 
> I used git bisect to find the first buggy commit is
> 6860cf932baeaf1c2f09c2a58e38be189ae394de
> 
> Query qq.com <http://qq.com> and www.qq.com <http://www.qq.com> to test
> if it can reply 127.0.0.1.
> 
> $ dig @localhost -p30000 qq.com <http://qq.com>
> $ dig @localhost -p30000 www.qq.com <http://www.qq.com>
> 
> In commit 0276e0805b2ca4657d8017e878f8a400354bdf78 (parent of buggy
> 6860cf932), Everything works fine:
> 
> $ ./src/dnsmasq -d -C /tmp/dnsmasq.conf -q
> dnsmasq: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n
> no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-cryptohash
> no-DNSSEC loop-detect inotify dumpfile
> dnsmasq: using nameserver 8.8.8.8#53 for domain fb.me <http://fb.me>
> dnsmasq: using nameserver 114.114.114.114#53
> dnsmasq: read /etc/hosts - 11 addresses
> dnsmasq: query[A] qq.com <http://qq.com> from 127.0.0.1
> dnsmasq: config qq.com <http://qq.com> is 127.0.0.1
> dnsmasq: query[A] www.qq.com <http://www.qq.com> from 127.0.0.1
> dnsmasq: config www.qq.com <http://www.qq.com> is 127.0.0.1
> 
> In buggy commit 6860cf932baeaf1c2f09c2a58e38be189ae394de, queries are
> always forwarded to upstream:
> 
> $ ./src/dnsmasq -d -C /tmp/dnsmasq.conf -q
> dnsmasq: started, version 2.86test2-5-g6860cf9 cachesize 150
> dnsmasq: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n
> no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-cryptohash
> no-DNSSEC loop-detect inotify dumpfile
> dnsmasq: using nameserver 8.8.8.8#53 for domain fb.me <http://fb.me>
> dnsmasq: using nameserver 114.114.114.114#53
> dnsmasq: read /etc/hosts - 11 addresses
> dnsmasq: query[A] qq.com <http://qq.com> from 127.0.0.1
> compares: 7
> dnsmasq: forwarded qq.com <http://qq.com> to 114.114.114.114
> dnsmasq: reply qq.com <http://qq.com> is 123.151.137.18
> dnsmasq: reply qq.com <http://qq.com> is 61.129.7.47
> dnsmasq: reply qq.com <http://qq.com> is 183.3.226.35
> dnsmasq: query[A] www.qq.com <http://www.qq.com> from 127.0.0.1
> compares: 7
> dnsmasq: forwarded www.qq.com <http://www.qq.com> to 114.114.114.114
> dnsmasq: reply www.qq.com <http://www.qq.com> is <CNAME>
> dnsmasq: reply ins-r23tsuuf.ias.tencent-cloud.net
> <http://ins-r23tsuuf.ias.tencent-cloud.net> is 121.14.77.201
> dnsmasq: reply ins-r23tsuuf.ias.tencent-cloud.net
> <http://ins-r23tsuuf.ias.tencent-cloud.net> is 121.14.77.221
> 
> I added a line to print qdomain.
> 
> // domain-match.c around line 180
> if (leading_dot)
> {
>     leading_dot = 0;
>     crop_query--;
> }
> qdomain += crop_query;
> printf("qdomain=%s\n", qdomain);
> 
> When I got qdomain="qq.com <http://qq.com>", the actual print result is
> "q.com <http://q.com>", I guess it should be ".com" or "com".
> 
> Any idea to fix it?
> 

The problem is in the code which aggressively crops the query length by
calculating the value of crop_query, just above that. There's a comment
that says "try now points to the last domain that sorts before the
query", but that's not true if the query sorts before _any_ of the
domains. Since in this case the earliest-sorting domain is qq.com, and
the first query tried is .qq.com, which sorts before qq.com (since it's
longer), the assumption doesn't hold, and the code reduces the length of
the query to the length of the next domain, fb.me, when it shouldn't.
That's why you see it looking for q.com. Since q.com doesn't match
qq.com the search continues and falls out at the default.

The net affect of this is that the longest domain (or the longest, and
lexigraphically earliest, if there are more than one of the longest
length) will be effectively ignored.

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=a0a3b8ad3e91db5181023fceea6732eb6c6f0759

should fix this, if I've got  it right. Please test, and thanks again
for your testing and bug discovery so far.


Cheers,m

Simon.



_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Reply via email to