DNS is not case sensitive. m3047.net is equivalent to M3047.NeT, etc. That’s the standard, and it’s the way that nameservers work. Regarding the behavior described below: is this intentional, or is it just evolving randomly via bitrot and pain? What is the objective of caching?
Where do I go with this line of inquiry? I’m not assuming a SuSE forum is going to answer a question this fundamental to network architecture and which spans all Linux distributions. However as we’ll see, different distributions / releases do things slightly differently.
Using python3 socket.getaddrinfo() for testing on SuSE Leap 15.0; although 15.1 might be different in some regards, unless this issue has been thoughtfully addressed I’ll assume it persists in some form or another. Let’s assume a wildcarded domain (like m3047.net) for the following (but please use your own domain, don’t code that into your automated testing) and a caching resolver (BIND).
Assuming that the caching resolver hasn’t seen it before an initial request for SuSE.m3047.net will be resolved, cached and returned (in the answer section) with the oname SuSE.m3047.net. A subsequent request for suse.m3047.net will be resolved from cache and returned with the oname SuSE.m3047.net. This is all expected and correct behavior, there are RFCs so “I disagree” is not on the table. 
SuSE Leap 15.0
SCENARIO:
We make a request e.g. socket.getaddrinfo(‘mARble.m3047.net’,6379), which the wildcarded domain answers with fidelity as to fqdn case; the nameserver caches it preserving case fidelity; the DNS answer is returned to the client (over the wire) with the question fqdn matching the case of the answer oname, i.e. mARble.m3047.net. socket.getaddrinfo() completes successfully and correctly (with the correct address).
In all cases, socket.getaddrinfo() returns successfully and correctly.
Now if we issue a second call socket.getaddrinfo(‘mARble.m3047.net’,6379), there is no DNS request/response, a correct answer is returned from some local cache.
However, if we issue a third call socket.getaddrinfo(‘marble.m3047.net’,6379), a DNS request is generated and answered by the caching resolver from its cache; the DNS answer is returned to the client (over the wire) with the question fqdn matching the request, but the answer oname matching the case of the original cached answer i.e. mARble.m3047.net.
If we issue a fourth call socket.getaddrinfo(‘mARble.m3047.net’,6379), there is no DNS request/response, a correct answer is returned from local cache.
If we issue a fifth call socket.getaddrinfo(‘mARble.m3047.net’,6379), there is no DNS request/response, a correct answer is returned from local cache.
CONCLUSIONS:
SuSE Leap has a local cache, although it is case sensitive.
Debian 9.8 32 bit (in a VM)
SCENARIO:
We make a request e.g. socket.getaddrinfo(‘ballOOn.m3047.net’,6379), and again the authoritative nameserver replies to the caching nameserver with fidelity, and again the caching nameserver caches it with fidelity.
We make a second request socket.getaddrinfo(‘ballOOn.m3047.net’,6379) and a DNS request is issued and answered by the caching nameserver from cache, with fidelity.
We make a third request socket.getaddrinfo(‘balloon.m3047.net’,6379) and a DNS request is issued and answered by the caching nameserver from cache, with the oname ballOOn.m3047.net. As noted previously socket.getaddrinfo() returns with the correct answer.
We make a fourth request socket.getaddrinfo(‘balloon.m3047.net’,6379) and a DNS request is issued and answered by the caching nameserver from cache.
We make a fifth request socket.getaddrinfo(‘ballOOn.m3047.net’,6379) and a DNS request is issued and answered by the caching nameserver from cache.
CONCLUSIONS:
Debian 9.8 does no local caching whatsoever. At least 32 bit in a VM. 
Who are the brilliant minds behind all of this? I suppose in the best of all possible worlds local caching does no harm, as long as you always get it right; which is why I’m slightly concerned that the cache can’t see mARble and marble as equivalent.
I was a little more concerned a few weeks ago, when Leap failed to resolve a mixed-case FQDN unless the case of the DNS reply exactly matched the query. However, that problem seems to have fixed itself after an OS update. But that’s what drew my attention. Since VirtualBox for Leap only support 32 bit OS and Leap doesn’t have 32 bit it’s hard to go all out on testing without hardware lying around or a credit card.
My next test iteration would involve DNS replies with serious brokenness.