LuLu
LuLu copied to clipboard
objective-see
DNS problem after a while
Problem
- After a few hours Lulu, prevents DNS connections to several apple domains.
- Restarting the mac fixes the issue completely, but the issue consistently reappears after a few hours.
- This bug is a painful. A not-too-inquisitive end user will not realize it, but there will be silent bad consequences (e.g. iCloud not syncing/backing up).
Symptoms
This is apparent by running the command dscacheutil -q host -a name www.apple.com
- After a restart, everything works well, we see:
$ dscacheutil -q host -a name www.apple.com
name: e6858.dscx.akamaiedge.net
alias: www.apple.com www.apple.com.edgekey.net www.apple.com.edgekey.net.globalredir.akadns.net
ipv6_address: 2a02:26f0:7400:1ac::1aca
ipv6_address: 2a02:26f0:7400:1ad::1aca
name: e6858.dscx.akamaiedge.net
alias: www.apple.com www.apple.com.edgekey.net www.apple.com.edgekey.net.globalredir.akadns.net
ip_address: 2.21.169.157
- Following a few hours of runtime, we see:
$ dscacheutil -q host -a name www.apple.com
name: e6858.dscx.akamaiedge.net
alias: www.apple.com www.apple.com.edgekey.net www.apple.com.edgekey.net.globalredir.akadns.net
ipv6_address: 2a02:26f0:7400:1ac::1aca
ipv6_address: 2a02:26f0:7400:1ad::1aca
The command then hangs for some time, and returns. Therefore, no IPv4 resolution is made. The mac is in a network that does not support ipv4, and therefore www.apple.com cannot be accessed.
In that state, flushing the DNS cache, resetting any network settings in any way that I can think, does NOT solve the problem. DNS resolution will continue to be blocked by Lulu.
However, in that state, if I disable Lulu, then flush the DNS cache, then reenable Lulu, the subsequent DNS call will resolve correctly IPv4. This gives me a few hours of uptime without problems, after which LuLu resumes breaking IPv4 DNS lookups.
Can anyone with a more intimate knowledge of the codebase understand why LuLu would show such a behaviour, and then fix it?
specs
- Lulu 2.4.0
- macOS Big Sur 11.5 and 11.6.1 (tested on both, issue showed up on both)
- ipv6 is turned off in System/Settings/Network/Advanced
PS
Thanks for this amazing piece of software!
I don't have your reported issue:
xxxx@iMac-528 ~ % dscacheutil -q host -a name www.apple.com
name: e6858.dscx.akamaiedge.net
alias: www.apple.com www.apple.com.edgekey.net www.apple.com.edgekey.net.globalredir.akadns.net
ipv6_address: 2600:140a:a000:29f::1aca
ipv6_address: 2600:140a:a000:293::1aca
name: e6858.dscx.akamaiedge.net
alias: www.apple.com www.apple.com.edgekey.net www.apple.com.edgekey.net.globalredir.akadns.net
ip_address: 23.201.193.8
xxxx@iMac-528 ~ % uptime
15:14 up 22:53, 2 users, load averages: 10.01 10.80 10.28
xxxx@iMac-528 ~ %
I rebooted yesterday and have been up for almost 23 hours and the command returns results immediately. This may be an issue with your DNS service provider.
Hey, thanks for checking.
Hmm, that is strange. I am pretty sure it's not an issue with my DNS provider, because I tried a few different DNS providers. I tried pointing to Cloudflare's or Google's. I also tried using my own dnsmasq. The issue was still there. Also, the fact the issue is immediately solved by disabling LuLu is a strong sign there is an issue with LuLu.
I am not sure how to go about this one...
I'm having the same issue (and I'm really glad that I'm not the only one, for the sake of my sanity). Only a handful of Apple domains are affected, absolutely everything else works fine. nslookup also works on those domains, so it's definitely not an issue with the DNS provider. Needless to say mDNSResponder and mDNSResponderHelper are whitelisted in LuLu, otherwise DNS would be entirely broken. But yet, there are tons of these logs in Console.app:
Yes... I have been unable to solve this issue in spite of spending a while on it. It is clear it is an issue with Lulu, as turning it off and flushing dns cache solves the problem straight away.
Does anyone have iCloud+ Private Relay enabled when having issues with this?
a year and a bit later, I seem to be having the same issue. At first I thought it was related to the issues of Cisco Packet Filters but having deleted those network filters, I still once in a while have the issue described by the OP. I'm thinking about making a bash script to run to get around this--something that disables Lulu, runs dscacheutil -flushcache and then re-enables Lulu but I haven't figured out a good way to stop and start Lulu. There's a bash terminal way to disable and enable network services but Lulu doesn't even show up with networksetup -listallnetworkservices so I don't think networksetup can be used. Lulu does show up with systemextensionsctl list so I'm researching if there's a method that way.
It still exists, and it's still a thorn in my side.
I did some logging and looked at the code, and I really don't get it. If I disable LuLu through its context bar menu, then it all works. So the issue must be within these lines: https://github.com/objective-see/LuLu/blob/master/LuLu/Extension/FilterDataProvider.m#L164-L206
But the only thing that modifies verdict (away from the default "allow") is [self processEvent:flow]. And no matter the verdict, it would be logged by Apple code. Here's a log I did while running curl https://www.apple.com and waiting until it timed out: Terminal Saved Output.txt
So there's three possibilities I could see:
- The request is dropped.
- The request is paused (possibly indefinitely).
- The code actually doesn't return and stalls, never providing a response.
Number 2 can be ruled out because there's no occurrence of pause = YES in my log. Number 3 seems very unlikely since for every Handling new flow, there is a matching New flow verdict log. And number 1 doesn't seem apparent from my log either.
What I have noticed though is that curl doesn't show up in the log at all. mDNSResponder does, but usually that carries info on what process initiated that request. So either the request never makes it that far, or it's being masked as something else.