jandubois
commented
2 years ago We use .local addresses for many of our internal tooling, including our image repository.
From our dialog on Slack I understand that the *.local names are not resolved via mDNS, but provided by regular DNS (over a VPN).
However .local is a designated Special-Use Domain and using it for regular DNS is discouraged by RFC6762:
Any DNS query for a name ending with ".local." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB). [...] Implementers MAY choose to look up such names concurrently via other mechanisms (e.g., Unicast DNS) and coalesce the results in some fashion. Implementers choosing to do this should be aware of the potential for user confusion when a given name can produce different results depending on external network conditions (such as, but not limited to, which name lookup mechanism responds faster).
The Lima DNS service will resolve the *.local names eventually, but not until it receives a timeout from mDNS that the name could not be resolved locally. This typically takes too long, so the application querying the name reports a time-out.
It is not clear if extending the DNS timeout value inside the guest would fix this, but it would result in a poor user experience because the queries are not being cached inside the guest.
The best way forward would be to move to a Private DNS Namespace. I'm not certain that ICANN is using this list; I remember reading that they promised that .corp, .home, and .mail would never be assigned and are available for private use, but can't find an authoritative reference right now.
Note that .local hostnames that can be resolved via mDNS work normally in Rancher Desktop.
We should keep this bug report open for now, in case we can find a way to speed up the lookup of .local names by giving regular DNS preference (optional and opt-in only), but given that this is not a standards-compliant configuration, this will be at a low priority.
Rancher Desktop Version
0.7.1
Rancher Desktop K8s Version
1.22.5
What operating system are you using?
macOS
Operating System / Build Version
12.0.1 Monterey
What CPU architecture are you using?
x64
Windows User Only
No response
Actual Behavior
We use .local addresses for many of our internal tooling, including our image repository. The VM rancher uses can't resolve any .local addresses. Even if I add the full .local address in the host's /etc/hosts file it doesn't work.
Steps to Reproduce
If you have something hosted at a .local address, try entering the VM and ping the name
Result
ping redacted.infra.local ping: bad address 'redacted.infra.local'Expected Behavior
The name should resolve
Additional Information
No response