Enable mDNS in cluster

[nirs]

When using mDNS vms on the host can be accessed using the vm hostname:

% ssh krunkit.local -- hostname
krunkit

But inside minikube cluster the name cannot be resolved:

% minikube ssh -- resolvectl query krunkit.local
krunkit.local: resolve call failed: All attempts to contact name servers or networks failed
ssh: Process exited with status 1

Because mDNS is disabled by default:

Link 2 (eth0)
    Current Scopes: DNS LLMNR/IPv4
         Protocols: +DefaultRoute +LLMNR -mDNS DNSOverTLS=opportunistic DNSSEC=no/unsupported
Current DNS Server: 192.168.105.1
       DNS Servers: 192.168.105.1

If we enable mDNS, resolving works:

% minikube ssh -- sudo resolvectl mdns eth0 yes 

% minikube ssh -- resolvectl query krunkit.local
krunkit.local: 192.168.105.5                   -- link: eth0

-- Information acquired via protocol mDNS/IPv4 in 2.1ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

Possible fix

• enable mDNS by default in minikube iso
• add --enble-mdns start flag and config

Expansion of start flags and node configuration

The current proliferation of flags in minikube start is a result of the tool's role as an all-in-one appliance managing the guest operating system.

• Limitations of extra-config: The --extra-config flag is technically scoped to kubernetes components like the kubelet or apiserver. Extending it to cover arbitrary node-level systemd settings would require a significant refactor of the provisioning logic.
• Benefits of a structured file: A dedicated --dns-config or --node-config yaml file provides a declarative way to manage nested settings that are difficult to express as flat key-value pairs in a cli flag.

Defaulting mDNS in minikube

Enabling mdns by default involves a trade-off between user convenience and network hygiene.

• Pros: It enables seamless discovery of .local addresses for users on macos and linux without manual configuration. This is particularly useful for tools like vfkit that use virtual bridges.
• Cons: Multicast traffic can be problematic in restricted corporate environments or public networks. It also creates a dependency on the host having a functional mdns responder listening on the virtual network interface.

Historical reasons for current defaults

Minikube defaults are generally optimized for a predictable, minimal environment that mirrors cloud behavior.

• Cloud consistency: Standard cloud environments do not use mdns for discovery, relying instead on unicast dns and service meshes.
• Driver compatibility: Multicast support varies across drivers. While it works with vfkit, it can be inconsistent on older nat implementations, leading to a fragmented user experience.
• Resource constraints: The buildroot-based iso aims for the smallest possible footprint. Disabling non-essential protocols by default reduces background noise and potential attack vectors.

Comparison of mDNS defaults in Linux distributions

The default state of mdns in 2026 depends heavily on the distribution's philosophy regarding systemd-resolved.

• Fedora 43: Typically enables mdns by default as part of its standard systemd-resolved integration. Fedora Changes: systemd-resolved
• Debian 13 (trixie): Often disables mdns in systemd-resolved by default to avoid conflicts with the avahi-daemon, which remains the preferred provider for the project. Debian Release Notes
• General systemd-resolved behavior: The upstream default for systemd-resolved is often opportunistic, but distributions frequently apply their own overrides. systemd-resolved documentation