Port 53 conflicts when in docker-desktop mode

[rmvangun]

If a user already has software using port 53, the docker-desktop virtualization mode will fail due to a port conflict. Using port 53 for local DNS is a key feature of Windsor.

It would be good to make it clear to the user that this is a requirement in the docs. Furthermore, it would be useful to proactively check port availability in the tool and nudge the user towards this documentation.

It is also possible to disable DNS locally for docker-desktop, though the general experience would degrade, would need to shore this up with other features to make it convenient.

None of these are concerns when using a full virtualization option, e.g. colima.

[jenklu-copia]

Had a debugging session with ChatGPT today. Here are my findings:

OK sweet, o3 and I figured it out. All the nitty gritty commands I ran/responses are in there, but to summarize, there were apparently 2 different things holding on to port 53 from what we worked on yesterday:

1. Docker Desktop has a setting called “Resources > Network > Use kernel networking for UDP”. Apparently, in some older versions of Docker Desktop this was enabled by default, so when I upgraded I probably inherited that setting being enabled. According to ChatGPT, this hangs onto Port 53.
2. Additionally, colima uses this thing called socket_vmnet. When that’s running, it was hanging on to port 53.

After I hit the issues I messaged you about yesterday evening, I tried to get rid of all the stuff we changed on the call; killing the containers and brew uninstall-ing colima. But apparently just uninstalling doesn’t actually kill all the colima stuff.

Frankly, I’m a little dubious that “Use Kernel Networking” was actually an issue, based on the following steps I took:

1. Disabled “Use kernel networking” -> port 53 still taken by mDNSResponder
2. Find and kill all colima processes -> port 53 opened up
3. Re-enable “Use kernel networking” just to test things out -> port 53 still available
   Not sure though

Here's the detailed ChatGPT transcript since that's not a public link, I am not going to take the time to clean it up so apologies for the poor formatting in advance:

Here's a conversation I want to continue:

I have a colleague who is on a Mac, attempting to run https://windsorcli.github.io locally. He ran in to an issue with a port 53 conflict. DNS is necessary when running in "docker-desktop" mode as it uses localhost:53. I generally need a way to detect or guide folks through ensuring they don't have other tooling already using port 53. It wasn't obvious looking at the processes, we only saw mDNSResponder which is expected. The only component trying to route to port 53 is docker-compose, running a CoreDNS container. We do use a VPN but this has not been problematic on other MacOS machines at the company.

Can you create a quick guide that would help him diagnose the issue and especially determine what other software has taken this port?

ChatGPT said:
Absolutely—here’s a Mac-focused troubleshooting guide to help your colleague diagnose and resolve conflicts with port 53, especially relevant for DNS setups like CoreDNS via Docker.

🧭 Guide: Diagnosing Port 53 Conflicts on macOS
Port 53 is used by DNS services and can sometimes be occupied by system processes, VPNs, or network-related tools, leading to failures when trying to run local DNS servers like CoreDNS.

🔍 Step 1: Identify What’s Listening on Port 53
Use the lsof and netstat commands to find the process holding port 53.

bash
Copy
Edit
sudo lsof -i :53
OR

bash
Copy
Edit
sudo lsof -nP -iUDP:53 -iTCP:53
These will output the PID and process name. Look for entries other than mDNSResponder.

For a more visual approach:

bash
Copy
Edit
sudo netstat -anv | grep '.53 '
🔎 Step 2: Cross-Check With ps
If you get a PID from lsof, look it up:

bash
Copy
Edit
ps -p <PID> -o pid,comm,args
This helps identify background daemons or agents that may not be obvious.

🧰 Step 3: Known Port 53 Occupants on macOS
Here are usual suspects that may bind to port 53:

mDNSResponder — macOS system service for multicast DNS (expected).

VPN software — Some VPNs (especially Cisco AnyConnect, GlobalProtect) install virtual adapters that bind to port 53 for DNS override.

Ad blockers / DNS tools — Tools like AdGuard, NextDNS CLI, dnsmasq, pi-hole, or custom /etc/resolv.conf configs.

Docker-related tools — Other local containers with their own DNS layers.

Antivirus / Security suites — Some AV software inspects DNS traffic by intercepting it.

If you find an unusual PID, try:

bash
Copy
Edit
launchctl list | grep <pid or part of name>
Or use:

bash
Copy
Edit
sudo lsof -nP -iUDP:53 | grep -v mDNSResponder
🛠 Step 4: Try Disabling or Rebinding the Offending Process
Once identified, you can either:

Temporarily kill the process:

bash
Copy
Edit
sudo kill -9 <PID>
Stop the associated launch agent:

bash
Copy
Edit
launchctl bootout system /Library/LaunchDaemons/com.vendor.name.plist
(Substitute the actual plist file name)

If it’s a VPN or AV tool, consider disabling DNS inspection or temporarily quitting the app.

📦 Step 5: Retry Docker Compose
Once port 53 is free, re-run the compose stack:

bash
Copy
Edit
docker-compose down
docker-compose up
Ensure the CoreDNS container can bind to localhost:53 now.

🧪 Optional: Use an Alternate Port for DNS Testing
To bypass conflicts during development, you can run CoreDNS on an alternate port (e.g., 1053) and configure resolv.conf or /etc/hosts accordingly. Update docker-compose.yml:

yaml
Copy
Edit
ports:

• "1053:53/udp"
  📋 Summary Cheatsheet

Command Purpose
sudo lsof -i :53 Who is using port 53?
ps -p <PID> -o args What process is it?
launchctl list grep <name>
kill -9 <PID> Kill a rogue process
docker-compose up Try DNS again
Would you like this guide exported as a Markdown file or PDF to share internally?

---

Here is the output from the first two steps of the guide:
lucasjenkins ~🍏 sudo lsof -i :53
Password:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mDNSRespo 51003 _mdnsresponder 12u IPv4 0x865a6c7020d26ed9 0t0 UDP *:domain
mDNSRespo 51003 _mdnsresponder 14u IPv6 0x3434d6f80723c6de 0t0 UDP *:domain
mDNSRespo 51003 _mdnsresponder 15u IPv4 0x17d54393286d2879 0t0 TCP *:domain (LISTEN)
mDNSRespo 51003 _mdnsresponder 16u IPv6 0xb0818898fc813b09 0t0 TCP *:domain (LISTEN)
lucasjenkins ~🍏 ps -p 51003 -o pid,comm,args
PID COMM ARGS
51003 /usr/sbin/mDNSRe /usr/sbin/mDNSResponder

It doesn't look like there's anything suspicious in there?

ChatGPT said:

Actually, the lsof output is showing the problem — it’s just not obvious why it suddenly started happening.
mDNSResponder normally owns 5353, not 53. When you see it binding *:domain on both TCP and UDP, something on the host has triggered macOS’s DNS‐proxy mode and grabbed the port before your CoreDNS container can map it.

What usually flips that switch on recent Macs is Docker Desktop’s “kernel networking for UDP” feature (added in 4.24.0). When that flag is on, Docker spins up a vmnet interface for faster UDP and macOS responds by having mDNSResponder listen globally on 53, causing the clash. This is why other company laptops (older Docker or the flag off) don’t have the issue.

---

Quick way to confirm

1. Quit Docker Desktop completely (whale‑menu → Quit).

2. Run

   bash
   CopyEdit
   sudo lsof -Pn -i :53
   

   If the list is now empty, Docker was the trigger.

3. Relaunch Docker and run the same command again – you’ll see the port grabbed as soon as the VM starts. GitHub

---

Two fixes that work today

Fix | Where | Notes -- | -- | -- Turn off “Use kernel networking for UDP” | Docker Desktop → Settings → Resources → Network | In 4.26+ it’s a checkbox; in 4.24–4.25 edit ~/Library/Group\\ Containers/group.com.docker/settings.json and set "kernelForUDP": false, then restart Docker. Docker DocumentationApple Developer Upgrade / stay on Docker Desktop ≥ 4.28.0 | Release ≥ 4.28 keeps the checkbox off by default and fixes most regressions. If you’re already on 4.33 or 4.34 and still see the grab, verify the checkbox really is unchecked, then restart Docker. GitHub |  

If you really want to erase every trace of Colima’s data directories (they can be a few hundred MB):

bash
CopyEdit
rm -rf ~/.colima
rm -rf ~/.lima

…but that’s optional—those folders won’t run anything by themselves.

Next steps

1. Keep the “kernel networking for UDP” box unchecked in Docker Desktop.

2. Restart your compose stack and make sure CoreDNS binds to 0.0.0.0:53 without errors.

3. If you ever reinstall Colima, remember it can re‑introduce the port‑53 grab when started with socket‑vmnet networking.

Here's a conversation I want to continue:

I have a colleague who is on a Mac, attempting to run https://windsorcli.github.io locally. He ran in to an issue with a port 53 conflict. DNS is necessary when running in "docker-desktop" mode as it uses localhost:53. I generally need a way to detect or guide folks through ensuring they don't have other tooling already using port 53. It wasn't obvious looking at the processes, we only saw mDNSResponder which is expected. The only component trying to route to port 53 is docker-compose, running a CoreDNS container. We do use a VPN but this has not been problematic on other MacOS machines at the company.

Can you create a quick guide that would help him diagnose the issue and especially determine what other software has taken this port?

ChatGPT said:
Absolutely—here’s a Mac-focused troubleshooting guide to help your colleague diagnose and resolve conflicts with port 53, especially relevant for DNS setups like CoreDNS via Docker.

🧭 Guide: Diagnosing Port 53 Conflicts on macOS
Port 53 is used by DNS services and can sometimes be occupied by system processes, VPNs, or network-related tools, leading to failures when trying to run local DNS servers like CoreDNS.

🔍 Step 1: Identify What’s Listening on Port 53
Use the lsof and netstat commands to find the process holding port 53.

bash
Copy
Edit
sudo lsof -i :53
OR

bash
Copy
Edit
sudo lsof -nP -iUDP:53 -iTCP:53
These will output the PID and process name. Look for entries other than mDNSResponder.

For a more visual approach:

bash
Copy
Edit
sudo netstat -anv | grep '.53 '
🔎 Step 2: Cross-Check With ps
If you get a PID from lsof, look it up:

bash
Copy
Edit
ps -p -o pid,comm,args
This helps identify background daemons or agents that may not be obvious.

🧰 Step 3: Known Port 53 Occupants on macOS
Here are usual suspects that may bind to port 53:

mDNSResponder — macOS system service for multicast DNS (expected).

VPN software — Some VPNs (especially Cisco AnyConnect, GlobalProtect) install virtual adapters that bind to port 53 for DNS override.

Ad blockers / DNS tools — Tools like AdGuard, NextDNS CLI, dnsmasq, pi-hole, or custom /etc/resolv.conf configs.

Docker-related tools — Other local containers with their own DNS layers.

Antivirus / Security suites — Some AV software inspects DNS traffic by intercepting it.

If you find an unusual PID, try:

bash
Copy
Edit
launchctl list | grep
Or use:

bash
Copy
Edit
sudo lsof -nP -iUDP:53 | grep -v mDNSResponder
🛠 Step 4: Try Disabling or Rebinding the Offending Process
Once identified, you can either:

Temporarily kill the process:

bash
Copy
Edit
sudo kill -9
Stop the associated launch agent:

bash
Copy
Edit
launchctl bootout system /Library/LaunchDaemons/com.vendor.name.plist
(Substitute the actual plist file name)

If it’s a VPN or AV tool, consider disabling DNS inspection or temporarily quitting the app.

📦 Step 5: Retry Docker Compose
Once port 53 is free, re-run the compose stack:

bash
Copy
Edit
docker-compose down
docker-compose up
Ensure the CoreDNS container can bind to localhost:53 now.

🧪 Optional: Use an Alternate Port for DNS Testing
To bypass conflicts during development, you can run CoreDNS on an alternate port (e.g., 1053) and configure resolv.conf or /etc/hosts accordingly. Update docker-compose.yml:

yaml
Copy
Edit
ports:

• "1053:53/udp"
  📋 Summary Cheatsheet

Command Purpose
sudo lsof -i :53 Who is using port 53?
ps -p -o args What process is it?
launchctl list grep
kill -9 Kill a rogue process
docker-compose up Try DNS again
Would you like this guide exported as a Markdown file or PDF to share internally?

---

Here is the output from the first two steps of the guide:
lucasjenkins ~🍏 sudo lsof -i :53
Password:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mDNSRespo 51003 _mdnsresponder 12u IPv4 0x865a6c7020d26ed9 0t0 UDP *:domain
mDNSRespo 51003 _mdnsresponder 14u IPv6 0x3434d6f80723c6de 0t0 UDP *:domain
mDNSRespo 51003 _mdnsresponder 15u IPv4 0x17d54393286d2879 0t0 TCP *:domain (LISTEN)
mDNSRespo 51003 _mdnsresponder 16u IPv6 0xb0818898fc813b09 0t0 TCP *:domain (LISTEN)
lucasjenkins ~🍏 ps -p 51003 -o pid,comm,args
PID COMM ARGS
51003 /usr/sbin/mDNSRe /usr/sbin/mDNSResponder

It doesn't look like there's anything suspicious in there?
ChatGPT said:

Thought for 40 seconds
Actually, the lsof output is showing the problem — it’s just not obvious why it suddenly started happening.
mDNSResponder normally owns 5353, not 53. When you see it binding *:domain on both TCP and UDP, something on the host has triggered macOS’s DNS‐proxy mode and grabbed the port before your CoreDNS container can map it.

What usually flips that switch on recent Macs is Docker Desktop’s “kernel networking for UDP” feature (added in 4.24.0). When that flag is on, Docker spins up a vmnet interface for faster UDP and macOS responds by having mDNSResponder listen globally on 53, causing the clash. This is why other company laptops (older Docker or the flag off) don’t have the issue.

Quick way to confirm
Quit Docker Desktop completely (whale‑menu → Quit).

Run

bash
Copy
Edit
sudo lsof -Pn -i :53
If the list is now empty, Docker was the trigger.

Relaunch Docker and run the same command again – you’ll see the port grabbed as soon as the VM starts.
GitHub

Two fixes that work today

Fix Where Notes
Turn off “Use kernel networking for UDP” Docker Desktop → Settings → Resources → Network In 4.26+ it’s a checkbox; in 4.24–4.25 edit ~/Library/Group\ Containers/group.com.docker/settings.json and set "kernelForUDP": false, then restart Docker.
Docker Documentation
Apple Developer
Upgrade / stay on Docker Desktop ≥ 4.28.0 Release ≥ 4.28 keeps the checkbox off by default and fixes most regressions. If you’re already on 4.33 or 4.34 and still see the grab, verify the checkbox really is unchecked, then restart Docker.
GitHub
Either change immediately frees the port and CoreDNS (or Pi‑hole, dnsmasq, etc.) can map 53:53/udp without errors.

If you can’t change that setting right now
Map your container to a different host port temporarily:

yaml
Copy
Edit
ports:

• "1053:53/udp"
• "1053:53/tcp"
  Then point your testing machine’s resolver to 127.0.0.1:1053.

Or stop Docker whenever you need to run a local DNS daemon directly on macOS.

Extra diagnostics (optional)
bash
Copy
Edit

See exactly when mDNSResponder binds 53

sudo log stream --predicate 'process == "mDNSResponder"' --style compact --info

Inspect Docker’s DNS‑acceleration flag

grep kernelForUDP ~/Library/Group\ Containers/group.com.docker/settings*.json
If you toggle the checkbox and watch the log, you’ll notice mDNSResponder drops and re‑opens port 53 in real time.

TL;DR for your colleague
Symptom: Ports are not available: listen udp 0.0.0.0:53
Cause: Docker Desktop’s “kernel networking for UDP” makes macOS bind port 53 with mDNSResponder.
Fix: Disable that checkbox (or set "kernelForUDP": false) or upgrade to Docker Desktop ≥ 4.28. Then restart Docker and retry docker‑compose up.

That should unblock CoreDNS immediately!

Sources
You said:
OK, I don't think that was the issue. I quit docker desktop from the menu icon, and still saw this output:
🍏 sudo lsof -Pn -i :53

Password:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mDNSRespo 51003 _mdnsresponder 12u IPv4 0x865a6c7020d26ed9 0t0 UDP *:53
mDNSRespo 51003 _mdnsresponder 14u IPv6 0x3434d6f80723c6de 0t0 UDP *:53
mDNSRespo 51003 _mdnsresponder 15u IPv4 0x17d54393286d2879 0t0 TCP *:53 (LISTEN)
mDNSRespo 51003 _mdnsresponder 16u IPv6 0xb0818898fc813b09 0t0 TCP *:53 (LISTEN)
lucasjenkins ~🍏 ps -ef | grep docker
501 52005 1 0 Tue04PM ?? 0:26.00 /opt/homebrew/bin/colima daemon start windsor-local --inotify --inotify-runtime docker --inotify-dir /Users/lucasjenkins/ --inotify-dir /tmp/colima-windsor-local/
501 63924 17123 0 5:23PM ttys015 0:00.00 grep --color=auto docker

This is also the copy-pasted output from the "About" dialog in Docker desktop, i.e. I'm already well past 4.28:
logo
Version

4.40.0 (187762)

Engine: 28.0.4

Compose: v2.34.0-desktop.1

Credential Helper: v0.9.3

Kubernetes: v1.32.2
ChatGPT said:

Thought for 46 seconds
The port‑53 grab you’re seeing is coming from Colima/Lima, not Docker Desktop.
When Colima’s VM is started it uses Apple’s socket_vmnet networking backend; macOS then launches mDNSResponder in “DNS‑proxy” mode and it binds TCP/UDP 53 on all host interfaces. Quitting Docker Desktop does nothing because the Colima daemon that’s still running keeps the VM (and thus socket_vmnet) alive. The behaviour is documented by both the Colima maintainers and Apple‑framework users:

“If you are using socket_vmnet, then it will start mDNSResponder which will bind to port 53 on the host. This is an Apple thing that is not under the control of Lima.” – jandubois, Lima/Colima maintainer
GitHub

Similar reports exist for Rancher Desktop and Docker Desktop because they also switch to vmnet‑based networking.
GitHub

How to free port 53

Option Command(s) What it does
1 – Stop Colima completely (quick test) bash colima stop windsor-local # or just colima stop if you only run one profile
Re‑run sudo lsof -Pn -i :53 Shuts down the VM; mDNSResponder drops port 53 almost instantly.
2 – Disable auto‑start and background daemon bash brew services stop colima # if it was started as a service Prevents Colima from grabbing the port on each boot.
3 – Keep Colima but avoid the vmnet DNS proxy a) Start Colima with an explicit VM IP:
bash colima start --network-address
b) Map CoreDNS to that IP instead of 0.0.0.0:
yaml ports: ["192.168.106.2:53:53/udp", "192.168.106.2:53:53/tcp"] Colima still runs, but port 53 is bound only on the VM’s private address, leaving 127.0.0.1 free on the host.
GitHub
4 – Run your DNS on an alternate host port yaml ports: ["1053:53/udp","1053:53/tcp"] Easiest fallback if you can’t change Colima right now.
Recommended next step
Stop Colima (colima stop windsor-local).

Re‑check sudo lsof -Pn -i :53. You should see no entries.

Start your docker‑compose up again. If it succeeds, you’ve confirmed Colima was the culprit.

Decide whether to keep Colima stopped, switch it to --network-address, or always run your DNS service on a non‑53 port.

That should unblock Windsor CLI/CoreDNS on your Mac without having to touch VPN settings or downgrade Docker Desktop.

Sources
You said:
Uploaded an image
Oh, but interesting, even though I'm on a newer Docker desktop, I only updated yesterday from a much older version. Just checked out that kernel networking for UDP setting, and it was enabled; maybe because I upgraded from an old version where it was on by default
ChatGPT said:

Thought for 15 seconds
Bingo — that checkbox is exactly what keeps mDNSResponder glued to 53 after the upgrade.
Docker Desktop left your old “Use kernel networking for UDP” setting switched on, even though new installs have it off by default. When that box is checked Docker brings up a socket_vmnet interface; macOS then starts mDNSResponder in DNS‑proxy mode, binding TCP/UDP 53 on every host interface and colliding with CoreDNS.
GitHub

How to clear the conflict
Untick the box
Docker Desktop ▸ Settings ▸ Resources ▸ Network → “Use kernel networking for UDP” (the screen you just showed).

Apply & Restart Docker Desktop.
The engine must fully stop and start for the vmnet interface (and the port‑53 bind) to disappear.

Verify

bash
Copy
Edit
sudo lsof -Pn -i :53 # should now return nothing
Start your compose stack again:

bash
Copy
Edit
docker‑compose up # or docker compose up
Watch out for Colima too
Earlier you still had a Colima daemon running:

bash
Copy
Edit
/opt/homebrew/bin/colima daemon start windsor-local …
Colima also uses socket_vmnet, so if you leave it running you may see port 53 grabbed again even after fixing Docker Desktop. If you still get conflicts:

bash
Copy
Edit
colima stop windsor-local # or just colima stop
sudo lsof -Pn -i :53 # confirm it's clear
Keep only one of the two (Docker Desktop or Colima) running at a time, or start Colima with --network-address so its DNS proxy binds only to the VM’s IP.

Why the setting persisted
Upgrading from an old Docker Desktop kept the "kernelForUDP": true flag in ~/Library/Group Containers/group.com.docker/settings.json. Disabling the checkbox writes "kernelForUDP": false and future upgrades will respect that.
GitHub

Once the box is unchecked and Colima isn’t simultaneously running, sudo lsof -Pn -i :53 should stay empty and your CoreDNS container will bind to 127.0.0.1:53 without errors. Let me know how the test goes!

Sources
You said:
Agh, I already uninstalled colima from brew, but I guess this daemon is hanging around. Do I need to brew install it again just to get this to stop?

lucasjenkins ~🍏 colima stop
fish: Unknown command: colima
lucasjenkins ~ [127]🍏 bash colima stop
bash: colima: No such file or directory
lucasjenkins ~ [127]🍏
ChatGPT said:

Thought for 1m 5s
colima left its launch‑agent running after you removed the package, so the VM (and its DNS proxy on port 53) keeps coming back every login. You don’t have to reinstall it—the goal is simply to unload and delete the launchd service and kill the orphaned process.

1. Unload the launchd job
   bash
   Copy
   Edit

see if it’s loaded for your user…

launchctl list | grep colima

…or at the system level

sudo launchctl list | grep colima
Typical label is homebrew.mxcl.colima
GitHub

Unload whichever one you find:

bash
Copy
Edit

user‑scope job

launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/homebrew.mxcl.colima.plist

system‑scope job (rare)

sudo launchctl bootout system /Library/LaunchDaemons/homebrew.mxcl.colima.plist
(If bootout errors with “No such process”, it’s already gone—move on.)

2. Delete the leftover plist so it can’t relaunch
   bash
   Copy
   Edit
   rm -f ~/Library/LaunchAgents/homebrew.mxcl.colima.plist
   sudo rm -f /Library/LaunchDaemons/homebrew.mxcl.colima.plist # if it existed
   Homebrew’s service wrapper just writes those plists; once they’re gone, macOS won’t start Colima again.
   Gist

3. Kill the in‑memory Colima VM & helpers (one‑off)
   bash
   Copy
   Edit
   sudo pkill -9 colima # the supervisor
   sudo pkill -9 limactl qemu # its VM/runtime

4. Verify the fix
   bash
   Copy
   Edit
   sudo lsof -Pn -i :53 # should return NOTHING now
   If the list is empty, port 53 is free and CoreDNS can bind successfully.

Optional tidy‑up with Homebrew
If you still have Homebrew installed:

bash
Copy
Edit
brew services cleanup # removes stale service entries
brew cleanup --zap colima # scrubs any lingering Colima files
(If you ever want Colima back, just brew install colima again and start it manually.)

TL;DR
Unload the homebrew.mxcl.colima launchd job, delete its plist, kill the stray Colima processes, and port 53 will stay free. No re‑install needed.

Sources
You said:
Seems like the service is not running, though there is a colima process hanging around. Should I just kill the process?

lucasjenkins ~🍏 ps -ef | grep docker
501 52005 1 0 Tue04PM ?? 0:26.23 /opt/homebrew/bin/colima daemon start windsor-local --inotify --inotify-runtime docker --inotify-dir /Users/lucasjenkins/ --inotify-dir /tmp/colima-windsor-local/
501 63942 1 0 5:24PM ?? 0:00.41 /Applications/Docker.app/Contents/MacOS/com.docker.backend
501 63944 63942 0 5:24PM ?? 0:03.90 /Applications/Docker.app/Contents/MacOS/com.docker.backend run
501 64030 63944 0 5:24PM ?? 0:00.02 /Applications/Docker.app/Contents/MacOS/com.docker.dev-envs -watchdog
501 64031 63944 0 5:24PM ?? 0:00.18 /Applications/Docker.app/Contents/MacOS/com.docker.build
501 64743 63944 0 5:29PM ?? 0:00.14 /Applications/Docker.app/Contents/MacOS/com.docker.virtualization --kernel /Applications/Docker.app/Contents/Resources/linuxkit/kernel --cmdline init=/init loglevel=1 root=/dev/vdb rootfstype=erofs ro vsyscall=emulate panic=0 eth0.dhcp eth1.dhcp linuxkit.unified_cgroup_hierarchy=1 console=hvc0 virtio_net.disable_csum=1 vpnkit.connect=connect://2/1999 --boot /Applications/Docker.app/Contents/Resources/linuxkit/boot.img --disk /Users/lucasjenkins/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw --networkType gvisor --macaddr-filename-prefix /Users/lucasjenkins/Library/Containers/com.docker.docker/Data/vms/0/macaddr --cpus 10 --memoryMiB 8092 --console-log /Users/lucasjenkins/Library/Containers/com.docker.docker/Data/log/vm/console.log --console /Users/lucasjenkins/Library/Containers/com.docker.docker/Data/vms/0/console.sock --api /Users/lucasjenkins/Library/Containers/com.docker.docker/Data/virtualization.sock --watchdog --virtiofs /Users --virtiofs /Volumes --virtiofs /private --virtiofs /tmp --virtiofs /var/folders --rosetta
501 65575 17123 0 5:31PM ttys015 0:00.00 grep --color=auto docker
lucasjenkins ~🍏 launchctl list | grep colima

lucasjenkins ~ [0|1]🍏 sudo launchctl list | grep colima

lucasjenkins ~ [0|1]🍏
ChatGPT said:

Thought for 35 seconds
Yes — at this point the quickest, cleanest fix is simply to terminate the orphaned Colima daemon and any helpers it spawned.
Because the launch‑agent isn’t loaded anymore, killing the running process will not come back after you log out or reboot.

1 . Kill the stray Colima VM & helpers
bash
Copy
Edit

send a polite TERM to the main daemon first

kill 52005 # ← the PID you saw in ps

if it doesn’t exit within ~5 s, be blunt:

pkill -9 colima limactl qemu-system # wipes out the whole Colima VM stack
limactl and qemu-system (or Apple Virtualization.framework) are the child processes that actually keep the VM and its socket_vmnet interface alive, so include them in the pkill to be sure.

2 . Verify port 53 is free
bash
Copy
Edit
sudo lsof -Pn -i :53 # should return nothing
If the list is empty, mDNSResponder has dropped its “DNS‑proxy” role and the port is yours.
(Colima + socket_vmnet is what triggers that special mode.
GitHub
)

3 . Optional tidy‑up
Remove the stale Home‑brew plist (if it’s still on disk)

bash
Copy
Edit
rm -f ~/Library/LaunchAgents/homebrew.mxcl.colima.plist
This guarantees launchd can’t revive Colima later.

Scrub leftover CLI bits

bash
Copy
Edit
brew cleanup --zap colima # removes misc files if Home‑brew is present
Switch Docker back to its default context (harmless if already set)

bash
Copy
Edit
docker context use default
unset DOCKER_HOST # if you had pointed it at Colima’s socket

Why killing it is safe
The running binary is just a copy Colima had already mapped into RAM before you uninstalled it; once quit, the file it points to is gone and nothing will relaunch.

Your Docker Desktop processes (com.docker.backend, com.docker.virtualization, etc.) are entirely separate and will keep running.

After the kill + verification, go ahead and start your compose stack again:

bash
Copy
Edit
docker compose up
CoreDNS should now bind to localhost:53 with no conflict. Let me know if anything stubborn still sticks around!



Sources
You said:
OK sweet, that appears to have worked. Port 53 is finally free!

lucasjenkins ~🍏 kill 52005  
lucasjenkins ~🍏 ps -ef | grep lima
  501 52072     1   0 Tue04PM ??         2:30.56 /opt/homebrew/bin/limactl usernet -p /Users/lucasjenkins/.colima/_lima/_networks/user-v2/usernet_user-v2.pid -e /Users/lucasjenkins/.colima/_lima/_networks/user-v2/user-v2_ep.sock --listen-qemu /Users/lucasjenkins/.clima/_lima/_networks/user-v2/user-v2_qemu.sock --listen /Users/lucasjenkins/.colima/_lima/_networks/user-v2/user-v2_fd.sock --subnet 192.168.5.0/24
  501 52073     1   0 Tue04PM ??         0:06.67 /opt/homebrew/bin/limactl hostagent --pidfile /Users/lucasjenkins/.colima/_lima/colima-windsor-local/ha.pid --socket /Users/lucasjenkins/.colima/_lima/colima-windsor-local/ha.sock colima-windsor-local
  501 52116     1   0 Tue04PM ??         0:07.75 ssh: /Users/lucasjenkins/.colima/_lima/colima-windsor-local/ssh.sock [mux]                                   
  501 65767 17123   0  5:34PM ttys015    0:00.01 grep --color=auto lima
lucasjenkins ~🍏 pkill -9 colima limactl qemu-system
lucasjenkins ~🍏 ps -ef | grep lima
  501 65796 17123   0  5:35PM ttys015    0:00.00 grep --color=auto lima
lucasjenkins ~🍏 stat ~/Library/LaunchAgents/homebrew.mxcl.colima.plist
stat: /Users/lucasjenkins/Library/LaunchAgents/homebrew.mxcl.colima.plist: stat: No such file or directory
lucasjenkins ~ [1]🍏 brew cleanup --zap colima
Usage: brew cleanup [options] [formula|cask ...]

Remove stale lock files and outdated downloads for all formulae and casks, and
remove old versions of installed formulae. If arguments are specified, only do
this for the given formulae and casks. Removes all downloads more than 120 days
old. This can be adjusted with $HOMEBREW_CLEANUP_MAX_AGE_DAYS.

      --prune                      Remove all cache files older than specified
                                   days. If you want to remove everything, use
                                   --prune=all.
  -n, --dry-run                    Show what would be removed, but do not
                                   actually remove anything.
  -s, --scrub                      Scrub the cache, including downloads for even
                                   the latest versions. Note that downloads for
                                   any installed formulae or casks will still
                                   not be deleted. If you want to delete those
                                   too: rm -rf "$(brew --cache)"
      --prune-prefix               Only prune the symlinks and directories from
                                   the prefix and remove no other files.
  -d, --debug                      Display any debugging information.
  -q, --quiet                      Make some output more quiet.
  -v, --verbose                    Make some output more verbose.
  -h, --help                       Show this message.
Error: invalid option: --zap
lucasjenkins ~ [1]🍏 brew cleanup colima
lucasjenkins ~🍏 sudo lsof -Pn -i :53  
Password:
lucasjenkins ~ [1]🍏
ChatGPT said:
🎉 Great news—lsof gave you an empty result, so nothing is bound to port 53 anymore.
Your CoreDNS container (or anything else that needs port 53) should start cleanly now.

A couple of tidy‑up notes

What you did	Status	Anything left?
Killed orphaned Colima processes	✅	All good—the pkill removed the VM and its socket_vmnet interface.
Removed launch‑agent plist	✅ (file wasn’t there)	Nothing to reload at login.
brew cleanup --zap colima	--zap only works for casks (brew uninstall --zap <cask>). Colima is a formula, so cleanup alone was the right call.	
If you really want to erase every trace of Colima’s data directories (they can be a few hundred MB):

bash
Copy
Edit
rm -rf ~/.colima
rm -rf ~/.lima
…but that’s optional—those folders won’t run anything by themselves.

Next steps
Keep the “kernel networking for UDP” box unchecked in Docker Desktop.

Restart your compose stack and make sure CoreDNS binds to 0.0.0.0:53 without errors.

If you ever reinstall Colima, remember it can re‑introduce the port‑53 grab when started with socket‑vmnet networking.