Re:Chromium and Mozilla to enforce 1 year validity for TLS c...
by jt2190 on Monday June 29, 2020 @08:54AM
(#23677119)
I think you’re talking about running DNS locally (not sure) and resolving .local addresses by DNS. In that case, yes, the devices that do lookups by mDNS will experience a delay caused by first querying mDNS before falling back onto DNS. The solution is to set up mDNS for the internal resources.
Using an unregistered domain like .lan has serious security implications. See here: https://serverfault.com/a/17566
Re:Chromium and Mozilla to enforce 1 year validity for TLS c...
by Karunamon on Monday June 29, 2020 @12:05PM
(#23678845)
.lan is called out in appendix G of the MDNS RFC as "not recommended, but many people do this".
Personally speaking, I'm not too worried about .lan getting registered as a gTLD anytime soon. I'm a lot more worried about forgetting to renew my domain and having things horrifically break if/when that domain gets picked up by someone else. This is a lot more likely...
Re:Chromium and Mozilla to enforce 1 year validity for TLS c...
by jt2190 on Monday June 29, 2020 @05:56PM
(#23683689)
I’m not sure I understand... What would break on your local network if a public domain you own and use only for internal resources is registered by someone else? How is this different from making up a domain name? In both cases you have to set up something to resolve the names to IP addresses on your local network, be it a hosts file or DNS. I would expect that to keep working regardless of the ownership of the domain name.
This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local." is link-local, and names within this domain are meaningful only on the link where they originate. [...] 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).
I'd recommend using something like .lan instead.