[Dnsmasq-discuss] [PATCH] Re: case sensitive split-dns setup?

Simon Kelley simon at thekelleys.org.uk
Wed Dec 1 14:34:29 UTC 2021


I just pushed a fix for this. It works for me, please test.


Cheers,

Simon.



On 14/10/2021 20:24, Petr Menšík wrote:
> I Confirm it is broken, even in v2.87test4 release.
> 
> The wrong use case is special domain, which provides internal VPN only
> name for kerberos.
> 
> It seems it forwards correctly to domain-specific forwarder. But during
> that the case of original query is lowered, according to log-queries.
> Then response is truncated from domain-specific forwarder.
> 
> Interesting enough query is then forwarded to resolvers without a
> domain. This time response is accepted. But because it was a VPN
> forwarding site-specific domain to internal-only servers, it only
> responds with NXDOMAIN.
> 
> This bug was reported in our bugzilla too [1]. Found it happens because
> our VPN has quite long list of SRV records for kerberos. So much it
> makes truncated reply and re-requests it via TCP. However TCP is for
> some reason a bit different.
> 
> There is one important issue:
> 
> a) query search does not end on domain-specific resolvers, but continues
> to general resolvers without domain.
> 
> One less important issue too:
> 
> b) response does not keep original case of the query
> 
> Found simple way to reproduce it:
> 
> dnsmasq -d --conf-file=/dev/null --port 2053 --server=127.0.0.1 --no-resolv --server='/test/::1' --log-queries &
> 
> dig +tcp @localhost -p 2053 srv _tcp.TEST
> dig @localhost -p 2053 srv _udp.TEST
> 
> Results in log:
> dnsmasq: started, version 2.87test4-11-g80fae3c cachesize 150
> dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus no-i18n IDN2 DHCP DHCPv6 no-Lua TFTP no-conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
> dnsmasq: using nameserver 127.0.0.1#53
> dnsmasq: using nameserver ::1#53 for domain test 
> dnsmasq: read /etc/hosts - 16 addresses
> dnsmasq: query[SRV] _udp.TEST from ::1
> dnsmasq: forwarded _udp.test to ::1
> dnsmasq: reply _udp.TEST is NXDOMAIN
> dnsmasq: query[SRV] _tcp.TEST from ::1
> dnsmasq: forwarded _tcp.TEST to ::1
> dnsmasq: reply _tcp.TEST is NXDOMAIN
> 
> Note forwarded name differs in case, UDP is forwarded lowercase. But TCP query is forwarded as received without modified case. It then requires case insensitive comparison strcasecmp in order() function in domain-match.c, where strcmp is used now.
> 
> Without a patch, previous version would forward it to 127.0.0.1.
> It seems strange to lowercase forwarded UDP queries. I think they should remain as received on client.
> If there is a good reason for it, it should be applied to TCP queries similar way.
> 
> Proposed change attached. Though I remember code in dnsmasq mentions it does not like changes in
> locale and does case comparison custom way in few places. Would it make issues here?
> I guess it would be safe for all encodings containing ASCII subset. Are other encodings still in use?
> 
> Cheers,
> Petr
> 
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=2014019
> 
> On 10/13/21 21:58, Aleksandar Kostadinov wrote:
>> Hi,
>>
>> I observe a very strange occasion in a split dns setup. It seems like
>> between 2.85 and 2.86 the match for domain name became case sensitive
>> or something. After upgrade to 2.86 I still see in log:
>>
>>> using nameserver 10.8.5.26#53 for domain example.com
>> then this DNS query returns no results:
>>
>>> dig srv _kerberos._tcp.EXAMPLE.COM
>> But these two queries return proper results:
>>
>>> dig srv _kerberos._tcp.example.com
>>> dig srv _kerberos._tcp.EXAMPLE.COM @10.8.5.26
>> With 2.85 all queries are returning the records.
>>
>> Any idea what's going on?
> 
> -- 
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemensik at redhat.com
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
> 
> 
> _______________________________________________
> 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