4 ms·

.lan. Please also reserve 'lan' since so many of us running from .local which Apple decided to takeover screwed over. Just reserve that it's for site specific

.lan. Please also reserve 'lan' since so many of us running from .local which Apple decided to takeover screwed over. Just reserve that it's for site specific / local / 'internal' use and that no other brilliant **hole can screw up a perfectly good network for another protocol or extension with it.

loudmax 3y ago
I tend to agree. `.internal` is too easy to misspell or misread. Not that it's that hard, but operating at scale you really want to make things as simple and easy as possible.
- kmoser 3y ago
  .lan might be easily misspelled as .Ian (or .1an), and the three letters look like a "normal" TLD. If anything, .local might be a better choice.
  - deleted 3y ago
    [deleted]
  - AnthonyMouse 3y ago
    Except that .local in 2024 is already in use for mDNS. Moreover, there is no such thing as a "normal" TLD. These are some existing public top level domains: .company .industries .network The reason .lan (or, for that matter, .local) isn't really that great is there will be large corporations wanting an internal use domain that spans multiple sites, which is neither local nor Local Area Network. But since it's likely to see widespread use, it does make sense for it to be short and so easy to type, which .internal is not. A decent one would be .pri, since a lot of companies already use it and "private" is what we're going for here.
  - kps 3y ago
    There's an obvious solution: .local for mDNS, and any (or all) of .Iocal, .locaI, or .IocaI for internal use.
- nyrikki 3y ago
  The simplicity comes from adding it to the search domains list, or domains that will be automatically appended to queries that aren't fully qualified. As .lan,.local,.corp etc... aren't marked as internal, the root domain servers recieve thousands of queries per second for these internal use domains. Not only does this add load to the root servers and add lag to applications, it leaks internal information while providing zero value to the user. Just as you never have to type '.localdomain' on a CentOS or Fedora box, you won't have to type it with this change unless you want to specify a fully qualified domain. Another advantage may be a simplification of internal certificates without the current risky practice of adding internal CAs to the global CA list to get around this problem. https://cabforum.org/internal-names/ https://cabforum.org/internal-names/ The CAB forum doesn't care about internal use but we have to all deal with it. It is quite possible that if this is standardized that companies could apply for intermediate CA's signed by a public cert that only apply to RFC1918 space and the .internal. TLD. Although they will probably still claim it is out-of-scope: https://github.com/cabforum/forum/blob/main/CSCWG-charter.md#2-out-of-scope https://github.com/cabforum/forum/blob/main/CSCWG-charter.md... But at least with an but with a official non-global TLD it may be possible to make a case for it.
lolinder 3y ago
It's not just Apple, I had to fix a brand new install of Debian the other day to turn off mDNS to get my local names resolving. Seeing it in Debian was enough to make me wonder if my frustration at Apple about this was misplaced and maybe I just need to reconfigure my network somehow.
- candiddevmike 3y ago
  systemd-resolved does special handling for .local because it's reserved for use with mDNS only. Using it outside of mDNS will cause problems. > Multi-label names with the domain suffix ".local" are resolved using MulticastDNS on all local interfaces where MulticastDNS is enabled. As with LLMNR, IPv4 address lookups are sent via IPv4 and IPv6 address lookups are sent via IPv6. https://www.freedesktop.org/software/systemd/man/latest/systemd-resolved.service.html https://www.freedesktop.org/software/systemd/man/latest/syst...
- throw0101d 3y ago
  > … and maybe I just need to reconfigure my network somehow. You are using a TLD that is reserved for something else. It is your configuration that is not standards compliant (.local was reserved in 2013 per RFC 6762).
  - lolinder 3y ago
    My network is a few devices in my home, so up until now I've just been using what works. Now it doesn't reliably work so I'll probably change it at some point. I don't really care about the standards, I care about what my devices do, and until the past few months my Linux devices defaulted to (mis)using .local.
p1mrx 3y ago
>>> 'internal'[::-1] 'lanretni'
formerly_proven 3y ago
Per the article, you already lost that fight.
- p1mrx 3y ago
  ICANN is still accepting public feedback: https://www.icann.org/en/public-comment/proceeding/proposed-top-level-domain-string-for-private-use-24-01-2024 https://www.icann.org/en/public-comment/proceeding/proposed-...
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 ago
  Except they appear to have done this in 2013, at least 13 years after people were using it for local internal dns
  - eli 3y ago
    Isn'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.
throw0101d 3y ago
> Please also reserve 'lan' since so many of us running from .local which Apple decided to takeover screwed over. It is the IETF that instructed/approved IANA to reserve .local: * https://datatracker.ietf.org/doc/html/rfc6761 https://datatracker.ietf.org/doc/html/rfc6761 * https://datatracker.ietf.org/doc/html/rfc6762 https://datatracker.ietf.org/doc/html/rfc6762 * https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml https://www.iana.org/assignments/special-use-domain-names/sp... Registering your own domain can cost as little as US$20/year: if you don't want conflicts get one and stop kludging together solutions.
- teaearlgraycold 3y ago
  Domains can be far less than $20/year
- AnthonyMouse 3y ago
  > Registering your own domain can cost as little as US$20/year: if you don't want conflicts get one and stop kludging together solutions. That's how you get conflicts. Somebody forgets to renew the domain or thinks there's nothing there because it doesn't resolve from the public internet and now you've got a conflict with the squatter who registers it 17 seconds later and/or whoever they sell it to. This also works poorly for small and medium organizations where the cost isn't the price, it's the paperwork. They can be small enough to care about money but large enough to require purchasing approval, and then the IT person is going to make up an internal name rather than engage the bureaucracy to buy one. And since that's going to happen anyway there might as well be a standard way to support it.
  - throw0101d 3y ago
    > That's how you get conflicts. No, it is how to avoid conflicts: by publicly claiming a namespace. > Somebody forgets to renew the domain or thinks there's nothing there because it doesn't resolve from the public internet and now you've got a conflict with the squatter who registers it 17 seconds later and/or whoever they sell it to. So you have the option of: theoretically losing the name space and causing conflicts because of incompetence, or the guaranteed chance of strange behaviour due to incompetence of choosing a kludgey solution. > This also works poorly for small and medium organizations […] But even an organization of a modicum of size needs to register a domain for being able to use e-mail. Maybe if you're a sole proprietor you'll use your gmail.com or outlook.com address for business, but once you have even a handful of employees you'll want to give each of them a 'business e-mail' at your company's name. And once you have a company-name e-mail domain/address congratulations, you can now use the same domain for IT namespacing purposes. And if you forget to renew you have larger problems than potentially broken internal/IT DNS: someone else changes the MX records and your company's e-mail is sent somewhere else, and you can't send out.
jeroenhd 3y ago
If you're using TLDs that aren't reserved for local use, there's nothing "perfectly good" about your network. The official guidance has always been to use a subdomains of real domain, probably in split-horizon networking if you don't want to leak internal addresses. There are a few internal TLDs you can use. You always had home.arpa available, and .example, .test, and .invalid were also reserved. Anything else is and always has been fair game. .local has had Apple-specific incompatibilities since at least 1999. Apple should've standardised .local before they released software that relies on special handling of it, but it's been almost 25 years since this problem was introduced and 11 years since this was standardised, it's time to move on.

loudmax 3y ago

I tend to agree. `.internal` is too easy to misspell or misread. Not that it's that hard, but operating at scale you really want to make things as simple and easy as possible.

kmoser 3y ago
.lan might be easily misspelled as .Ian (or .1an), and the three letters look like a "normal" TLD. If anything, .local might be a better choice.
- deleted 3y ago
  [deleted]
- AnthonyMouse 3y ago
  Except that .local in 2024 is already in use for mDNS. Moreover, there is no such thing as a "normal" TLD. These are some existing public top level domains: .company .industries .network The reason .lan (or, for that matter, .local) isn't really that great is there will be large corporations wanting an internal use domain that spans multiple sites, which is neither local nor Local Area Network. But since it's likely to see widespread use, it does make sense for it to be short and so easy to type, which .internal is not. A decent one would be .pri, since a lot of companies already use it and "private" is what we're going for here.
- kps 3y ago
  There's an obvious solution: .local for mDNS, and any (or all) of .Iocal, .locaI, or .IocaI for internal use.
nyrikki 3y ago
The simplicity comes from adding it to the search domains list, or domains that will be automatically appended to queries that aren't fully qualified. As .lan,.local,.corp etc... aren't marked as internal, the root domain servers recieve thousands of queries per second for these internal use domains. Not only does this add load to the root servers and add lag to applications, it leaks internal information while providing zero value to the user. Just as you never have to type '.localdomain' on a CentOS or Fedora box, you won't have to type it with this change unless you want to specify a fully qualified domain. Another advantage may be a simplification of internal certificates without the current risky practice of adding internal CAs to the global CA list to get around this problem. https://cabforum.org/internal-names/ https://cabforum.org/internal-names/ The CAB forum doesn't care about internal use but we have to all deal with it. It is quite possible that if this is standardized that companies could apply for intermediate CA's signed by a public cert that only apply to RFC1918 space and the .internal. TLD. Although they will probably still claim it is out-of-scope: https://github.com/cabforum/forum/blob/main/CSCWG-charter.md#2-out-of-scope https://github.com/cabforum/forum/blob/main/CSCWG-charter.md... But at least with an but with a official non-global TLD it may be possible to make a case for it.

lolinder 3y ago

It's not just Apple, I had to fix a brand new install of Debian the other day to turn off mDNS to get my local names resolving. Seeing it in Debian was enough to make me wonder if my frustration at Apple about this was misplaced and maybe I just need to reconfigure my network somehow.

candiddevmike 3y ago
systemd-resolved does special handling for .local because it's reserved for use with mDNS only. Using it outside of mDNS will cause problems. > Multi-label names with the domain suffix ".local" are resolved using MulticastDNS on all local interfaces where MulticastDNS is enabled. As with LLMNR, IPv4 address lookups are sent via IPv4 and IPv6 address lookups are sent via IPv6. https://www.freedesktop.org/software/systemd/man/latest/systemd-resolved.service.html https://www.freedesktop.org/software/systemd/man/latest/syst...
throw0101d 3y ago
> … and maybe I just need to reconfigure my network somehow. You are using a TLD that is reserved for something else. It is your configuration that is not standards compliant (.local was reserved in 2013 per RFC 6762).
- lolinder 3y ago
  My network is a few devices in my home, so up until now I've just been using what works. Now it doesn't reliably work so I'll probably change it at some point. I don't really care about the standards, I care about what my devices do, and until the past few months my Linux devices defaulted to (mis)using .local.

p1mrx 3y ago

>>> 'internal'[::-1] 'lanretni'

formerly_proven 3y ago

Per the article, you already lost that fight.

p1mrx 3y ago
ICANN is still accepting public feedback: https://www.icann.org/en/public-comment/proceeding/proposed-top-level-domain-string-for-private-use-24-01-2024 https://www.icann.org/en/public-comment/proceeding/proposed-...

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 ago
Except they appear to have done this in 2013, at least 13 years after people were using it for local internal dns
- eli 3y ago
  Isn'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.

throw0101d 3y ago

> Please also reserve 'lan' since so many of us running from .local which Apple decided to takeover screwed over. It is the IETF that instructed/approved IANA to reserve .local: * https://datatracker.ietf.org/doc/html/rfc6761 https://datatracker.ietf.org/doc/html/rfc6761 * https://datatracker.ietf.org/doc/html/rfc6762 https://datatracker.ietf.org/doc/html/rfc6762 * https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml https://www.iana.org/assignments/special-use-domain-names/sp... Registering your own domain can cost as little as US$20/year: if you don't want conflicts get one and stop kludging together solutions.

teaearlgraycold 3y ago
Domains can be far less than $20/year
AnthonyMouse 3y ago
> Registering your own domain can cost as little as US$20/year: if you don't want conflicts get one and stop kludging together solutions. That's how you get conflicts. Somebody forgets to renew the domain or thinks there's nothing there because it doesn't resolve from the public internet and now you've got a conflict with the squatter who registers it 17 seconds later and/or whoever they sell it to. This also works poorly for small and medium organizations where the cost isn't the price, it's the paperwork. They can be small enough to care about money but large enough to require purchasing approval, and then the IT person is going to make up an internal name rather than engage the bureaucracy to buy one. And since that's going to happen anyway there might as well be a standard way to support it.
- throw0101d 3y ago
  > That's how you get conflicts. No, it is how to avoid conflicts: by publicly claiming a namespace. > Somebody forgets to renew the domain or thinks there's nothing there because it doesn't resolve from the public internet and now you've got a conflict with the squatter who registers it 17 seconds later and/or whoever they sell it to. So you have the option of: theoretically losing the name space and causing conflicts because of incompetence, or the guaranteed chance of strange behaviour due to incompetence of choosing a kludgey solution. > This also works poorly for small and medium organizations […] But even an organization of a modicum of size needs to register a domain for being able to use e-mail. Maybe if you're a sole proprietor you'll use your gmail.com or outlook.com address for business, but once you have even a handful of employees you'll want to give each of them a 'business e-mail' at your company's name. And once you have a company-name e-mail domain/address congratulations, you can now use the same domain for IT namespacing purposes. And if you forget to renew you have larger problems than potentially broken internal/IT DNS: someone else changes the MX records and your company's e-mail is sent somewhere else, and you can't send out.

jeroenhd 3y ago

If you're using TLDs that aren't reserved for local use, there's nothing "perfectly good" about your network. The official guidance has always been to use a subdomains of real domain, probably in split-horizon networking if you don't want to leak internal addresses. There are a few internal TLDs you can use. You always had home.arpa available, and .example, .test, and .invalid were also reserved. Anything else is and always has been fair game. .local has had Apple-specific incompatibilities since at least 1999. Apple should've standardised .local before they released software that relies on special handling of it, but it's been almost 25 years since this problem was introduced and 11 years since this was standardised, it's time to move on.