Looking up 2020-01-31-user-kstrauser.example.com might cause a DNS lookup to go out, even though little snitch will block the subsequent web traffic to it.
Its threat model isn’t to protect you from anything a state-level actor might try to do, but to give you insight into changed app behaviors. Why is my weather app now talking to Bolivia? Why is a shell script trying to connect to an Active Directory server? I don’t think that’s so much a hole as something that’s just out of scope for Little Snitch.
The DNS lookup would be of the form "request PTR record for 128.2.1.2" - this would leak a little info from the nearest recursing resolver, but maybe not enough to be useful to an attacker. I suppose Snitch might conceivably use some other, non-DNS repository like ipinfo.io though.
I don’t know how little snitch does it, but iirc our old fortinet at the office caches the DNS response for logging, so that no extra reverse dns requests are needed (and if there isn’t a cached one, you have to explicitly ask to look it up when looking at the logs)
From a quick look in opensnitch, it should be tracking DNS replies in UDP packets.
I don't see it filtering the responses, so spoofing hostnames or even overloading the translation table (memory exhaustion) might be possible, even for network attackers.
If the app resolves two hostnames (e.g. useful-serivce.cloudprovider.com and malware.cloudprovider.com), that are both at the same ip, and then connects to that ip, which of the hostnames it connects to?
Without sniffing Host header (for http) or SNI (for TLS pre-ESNI), it is just a guess.
Looking up 2020-01-31-user-kstrauser.example.com might cause a DNS lookup to go out, even though little snitch will block the subsequent web traffic to it.
I think umatrix helps with that.