Rancher Desktop on MacOS takes over port 53

[AlexeyRaga]

Actual Behavior

I have Rancher Desktop running on MacOS in dockerd (moby) mode with Kubernetes and Traefik being both disabled.

I see that when Rancher is running, port 53 on my machine is taken:

mDNSRespo   278 _mdnsresponder   72u  IPv4 0x847703863108e61f      0t0  TCP *:53 (LISTEN)
mDNSRespo   278 _mdnsresponder   85u  IPv6 0x8477038aff31d417      0t0  TCP *:53 (LISTEN)
Rancher   43208         alexey   54u  IPv4 0x84770386310970cf      0t0  TCP localhost:6107 (LISTEN)
Rancher   43208         alexey   55u  IPv4 0x8477038632cd10cf      0t0  TCP localhost:6109 (LISTEN)

but when I shut it down then port 53 is free again. Despite the fact that the process name and PID are different, Rancher is definitely causes the port to be taken.

Steps to Reproduce

• Get a Mac ;)
• Start Rancher Desktop in dockerd (moby) mode and switch off Kubernetes and Traefik.
• Issue sudo lsof -PiTCP -sTCP:LISTEN command
• Assert that port 53 is open

Result

Other services on the machine cannot use port 53. Noticing VPN clients (like Cloudflare WARP) and other DNS-related tools.

Expected Behavior

Port 53 is not taken over by Rancher Desktop (the same way Docker Desktop doesn't take over it)

Additional Information

No response

Rancher Desktop Version

1.5.1

Rancher Desktop K8s Version

none

Which container engine are you using?

moby (docker cli)

What operating system are you using?

macOS

Operating System / Build Version

12.5.1 (21G83)

What CPU architecture are you using?

x64

Linux only: what package format did you use to install Rancher Desktop?

No response

Windows User Only

No response

[jandubois]

It is not Rancher Desktop, but mDNSResponder that is taking over port 53. It is a macOS component that is automatically started when Rancher Desktop uses Apple's vmnet framework.

It is being used to get a routable IP address for the VM running the container engine. If you are fine with just using port forwarding to the host and don't require a separate IP address, then you can disable "administrative access" in the Rancher Desktop preferences. Using vmnet requires starting a daemon via sudo, so that is no longer possible, and mDNSResponder will no longer be started either.

This means that Rancher Desktop will also no longer be able to create the Docker socket in the default location at /var/run/docker.sock. It will create a docker context called rancher-desktop and switch to it automatically, so things should still work automatically. But it is good to be aware of this, in case you are running legacy software that doesn't know about docker contexts and expects to find the socket in the default location.

[AlexeyRaga]

@jandubois thank you very much for the explanation and for the workaround!
This solution works and I close this issue.

[jandubois]

Added benefit of the "workaround":

You no longer get prompted for your password the first time you start Rancher Desktop after rebooting your machine (because macOS deletes /var/run on boot, so normally Rancher Desktop would have to recreate the /var/run/docker.sock socket).

[joehorsnell]

Hi @jandubois - I'm on macOS (Sonoma 14.3), on Apple Silicon (M3, incase that's important, so having to use VZ emulation), latest RD 1.12.2 (but same on 1.12.1) and I cannot get this workaround to work.

I've disabled admin access, tried with and without socket-vmnet and starting Rancher Desktop always causes mDNSResponder to be started on port 53, which then causes conflicts with Cloudflare WARP, as noted by @AlexeyRaga in the issue description.

My steps are to quit completely out of RD and verify that there are no RD processes running with psgrep -i rancher and no mDNSResponder processes with sudo lsof -P -i tcp:53, then start RD with the correct settings (ie no admin, etc.) and it always starts mDNSResponder:

❯ sudo lsof -P -i tcp:53
COMMAND   PID           USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
mDNSRespo 657 _mdnsresponder   47u  IPv4 0xfdf805139f33ed63      0t0  TCP *:53 (LISTEN)
mDNSRespo 657 _mdnsresponder   49u  IPv6 0xfdf8051860f7a8d3      0t0  TCP *:53 (LISTEN)

Edits:

• FYI this is also with k8s disabled, although I can't think why that would matter
• The only workaround I've found for now is to have Cloudflare WARP running first and able to bind to port 53, then start RD, which seems to start fine still

Should I open a new issue with these details, or are you able to assist with this information please?

[joehorsnell]

@jandubois - I've been able to test the issue I reported above on an M1 laptop and have confirmed it's the VZ emulation settings (to work around #5943 on M3).

Using default QEMU virtual machine type, which obviously breaks on M3, it does not start the mDNSResponder. Change it back to VZ and even without admin access it starts mDNSResponder on port 53.

Any ideas?

[jandubois]

Using default QEMU virtual machine type, which obviously breaks on M3, it does not start the mDNSResponder. Change it back to VZ and even without admin access it starts mDNSResponder on port 53.

Yes, because under VZ emulation Rancher Desktop uses vzNAT networking, which doesn't require admin access, but still uses VMNET, so will always start mDNSResponder.

Sorry, I can't think of a workaround for VZ mode right now. I'll re-open this issue so we'll look at it again in the future.

[joehorsnell]

Hi @jandubois - thanks for the quick response 👍.

As I mentioned above, the manual workaround I used was to quit Rancher Desktop, then run and connect Cloudflare WARP, so it can bind on port 53, before running RD again. This seems to work, but is it possible Rancher Desktop is broken in some way I haven't discovered yet by not being able to run mDNSResponder? There don't appear to be any other mDNSResponder processes created, or errors that I can see in the RD logs.

[jandubois]

is it possible Rancher Desktop is broken in some way I haven't discovered yet by not being able to run mDNSResponder?

I don't think so; Rancher Desktop doesn't use mDNSResponder itself at all. I'm also not sure why it binds to port 53 as the mDNS port is 5353. So I think letting your VPN bind to the port before starting Rancher Desktop should work fine.

It is possible that not running mDNSResponder will prevent you from resolving names in the *.local domain.