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

Petr Menšík pemensik at redhat.com
Thu Oct 14 19:24:16 UTC 2021


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20211014/e8ec6819/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Compare-order-case-insensitive.patch
Type: text/x-patch
Size: 1038 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20211014/e8ec6819/attachment.bin>


More information about the Dnsmasq-discuss mailing list