6 ms·
.local was assigned by IANA for mDNS/Bonjour https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml https://www.iana.org/assig
by goneri 3y ago
.local was assigned by IANA for mDNS/Bonjour https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml https://www.iana.org/assignments/special-use-domain-names/sp...
- mavhc 3y agoExcept they appear to have done this in 2013, at least 13 years after people were using it for local internal dns
- eli 3y agoIsn't that the point of reserving something like .internal? So that people don't "borrow" a TLD that could get assigned to something else later?
- mjevans 3y ago.local wasn't a TLD and was too long to be likely to be assigned as a new country / .com like thing. It was in _wide_ use before mDNS and even vanity TLDs existed.
- throw0101d 3y ago> It was in _wide_ use before mDNS and even vanity TLDs existed. Yes, as noted in the RFC that reserved its use for mDNS: The special treatment of names ending in ".local." has been implemented in Macintosh computers since the days of Mac OS 9, and continues today in Mac OS X and iOS. There are also implementations for Microsoft Windows [B4W], Linux, and other platforms. Some network operators setting up private internal networks ("intranets") have used unregistered top-level domains, and some may have used the ".local" top-level domain. Using ".local" as a private top-level domain conflicts with Multicast DNS and may cause problems for users. Clients can be configured to send both Multicast and Unicast DNS queries in parallel for these names, and this does allow names to be looked up both ways, but this results in additional network traffic and additional delays in name resolution, as well as potentially creating user confusion when it is not clear whether any given result was received via link-local multicast from a peer on the same link, or from the configured unicast name server. Because of this, we recommend against using ".local" as a private Unicast DNS top-level domain. We do not recommend use of unregistered top-level domains at all, but should network operators decide to do this, the following top-level domains have been used on private internal networks without the problems caused by trying to reuse ".local." for this purpose: .intranet. .internal. .private. .corp. .home. .lan. * https://datatracker.ietf.org/doc/html/rfc6762#appendix-G https://datatracker.ietf.org/doc/html/rfc6762#appendix-G Key words: We do not recommend use of unregistered top-level domains at all…. The drafts for the RFC date back to 2001.
- Ferret7446 3y agoIf it wasn't a TLD, then it is invalid/undefined to attempt to use it as a TLD, so whether it works or not, or ceases to work in the future is fair game.
- throw0101d 3y ago> Except they appear to have done this in 2013 The first mDNS draft came out in 2001. And as noted RFC 6762 § Appendix G, .local was used by Mac OS 9 for the same purpose as it it was for mDNS: link-local resolution.
- denkmoon 3y agoSo that this doesn't happen again is exactly why the defacto use of .lan should be codified in an RFC. .local was never reserved for private use, and it got scooped up for mdns. .dev was never reserved for private use, it got gTLD'd and owned by Google who promptly put it on the HSTS preload list. .internal is nice but it's not what people are already using.