Little Snitch is bound to the API provided by Apple. The NEFilterDataProvider API calls `handleNewFlow()` only after sending out the first IP packet.
Version 6 added DNS encryption and in principle we could filter lookups (similar to PiHole) at this level. That brings other issues, though: This filter is system-wide, so process-specific rules (and overrides) would not work. And results can be cached by mDNSResponder. So when a blocklist causes an issue, you may not be able to fix it by simply disabling the blocklist. But it's still something we consider.
>in principle we could filter lookups
I've been telling people about ya'll's DNS leaks for over a decade [3] — glad to finally hear back — most people won't believe me [0] until this flaw is demonstrated on their specific machine (easy enough). Those already using LittleSnitch will then typically set up better filtering (e.g. DNS white/blacklist, PiHole, et.alius).
And until the behavior is fixed, I will keep spreading the good word. Does the Linux version have this same flaw (i.e. backend requirements similar to Mac initial IP leak)?
----
A very neat product (LittleSnitch), but I stopped using it solely for above reason [1]. IMHO, this flaw should be better documented in your installer/docs.
[0] e.g. they'll lament "there is no way the developer would allow that sort of leak/behavior!" Their denial is a helluvadrug
[1] I had a 5-user site license, IIRC. Shortly after purchasing, I discovered above leakage so stopped using entirely [v3 user 33TEWP20B0-724KY-5XE522FEAC [2]]
[2] Go ahead and blacklist/cancel the above registration (it's a manyyearsold version, barely used) – my current mailing address is in my user profile (no longer use email/phone). Would love to help/feedback to make your product better. Would also love a refund (all these years later, on principle)
[3] e.g: <https://news.ycombinator.com/item?id=35363343> (/hn/2023)