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.
It is the IETF that instructed/approved IANA to reserve .local:
* https://datatracker.ietf.org/doc/html/rfc6761
* https://datatracker.ietf.org/doc/html/rfc6762
* 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.
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.
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.
Which is what this is doing, by publicly claiming a namespace for anyone's internal use. Since it's internal use and there is no public use, there can't be a public conflict.
> theoretically losing the name space and causing conflicts because of incompetence
This is not theoretical. It's a major part of the squatter's business model. People don't renew their domains and then get extorted to buy them back. Happens all the time, and is significantly more likely to happen for an internal domain that has no DNS records with the registrar and doesn't appear to be in use.
> But even an organization of a modicum of size needs to register a domain for being able to use e-mail.
Which will be a different domain, often administered by different people, because it's being used for the company's public infrastructure rather than its internal network.
Wat?
I've worked at 3-IT-person academic departments, 30-person start-ups, and 3000-person publicly traded corporations, and I've always seen the same domain used internally and externally.
The only exception is where I'm currently at, where the dumbasses who were here previously (and set things up initially) decided to use .local—instead of the sane thing, which would have been to peal off a sub-domain of the public domain we already have. I'd like to know which illegal substance they were using when that decision was made.
And the last of those is a major contributor to this since it wants to take over the domain it's on. You can solve this by delegating a subdomain to it, but now your internal use domain is longer, and there are security implications to this because now unrelated internal systems may e.g. have access to cookies set for the public website. Or have the ability to issue dynamic DNS updates, so an attacker who compromises a random low-level internal system can point a name inside the company's public domain to their own servers and even potentially have a TLS certificate issued to it via ACME, even if the public infrastructure hasn't been compromised.
Not sure about others, but I am not gonna trust that person to manage my .local network regardless.
> This also works poorly for small and medium organizations where the cost isn't the price, it's the paperwork.
I had been in that position to chase an approval of $20 domain name purchase. Totally worth it. Much less headache than managing a bunch of made up domains and their weird internal name server configs.
"Corporate bureaucracies are infallible" is an extremely unrealistic assumption.
> Much less headache than managing a bunch of made up domains and their weird internal name server configs.
How is an internal domain weirder to configure or less made up than a public one?
Especially when dealing with corporate bureaucracies -- If you don't have skilled engineers to manage .local, then just purchase a real domain and get public CA signed certificates. There will be fewer things that can go wrong.
The only excuse I would understand is turn-over. Otherwise, I would say that the organization in question has to get more comfortable with firing their employees.
First, the payment method on file with the registrar became invalid. Often because of turnover as you say -- the old IT manager's company credit card got turned off and the payment failed emails went to their email address, also turned off. Sometimes for other reasons, e.g. the credit card company changed the card number because of a data breach and then the non-payment notification got caught in a spam filter.
Second, there's somebody whose job it is to check which of the company's 5000 domain names are still being used. They find one with no public DNS records, or old ones that point to nothing. They call up the web server team and the email team and ask what it is, they've never heard of it because it's not them using it. So they cancel the domain -- and the company doesn't even notice at first because the internal systems carry on using the name as ever, until somebody else registers it and starts using it.
It takes a few seconds to document what a domain is used for / what department is using it. If you have 5,000 domains, you're already doing this. As well, at that scale you're likely using an enterprise domain registrar, so there is absolutely zero possibility of a domain expiring. (If you're not ... phew)
Many other industries with zero tolerance for failure are able to successfully implement multi-layered approaches for anticipating and eliminating issues. Yet, IT manages to find excuses to explain why a $10 domain can't be reliably renewed. That's wild. That's embarrassing.
Sure, and then you have a piece of documentation that says the domain is being used by "IT" for "account services" and the person reading this thinks it's the web server administrators using it for customer accounts and they say they're not using it.
> As well, at that scale you're likely using an enterprise domain registrar, so there is absolutely zero possibility of a domain expiring.
The company where the domain expires for non-payment and the company with 5000 domains don't have to be the same company, or the same division of the same company.
> Many other industries with zero tolerance for failure are able to successfully implement multi-layered approaches for anticipating and eliminating issues. Yet, IT finds excuses to explain why a $10 domain can't be reliably renewed. That's wild. That's embarrassing.
The traditional approach to this is to operate with redundancy. Domain registrations are a single point of failure consequent of having a single global hierarchical namespace. One way to mitigate this is to relax the global uniqueness requirement in instances where it isn't necessary, like internal use domains, so you can't "lose" the domain since nobody has exclusive control over it. To do that you'd need to carve out a piece of the hierarchy for that use so it doesn't conflict with other names that have to be globally unique. Which is the current proposal.
A disproportionate amount of the internet depends on those 2 domains, and even so, there is zero redundancy for the situation you are describing. It's just that simple though: there doesn't need to be. This is a solved problem that does not occur in competently run organizations. Domains do not need to be a failure point, and if they are, you should put more focus on resolving the deeper issues within your organization.
.lan is short and convenient, there is no good case for using it in any other context. .lan is used defacto as a private TLD. ICANN should reflect this reality by codifying it in an RFC.
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.
Key words: We do not recommend use of unregistered top-level domains at all….
The drafts for the RFC date back to 2001.
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.
.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.
.company
.industries
.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.
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/
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...
But at least with an but with a official non-global TLD it may be possible to make a case for it.
> 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/syst...
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).
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.
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.
https://www.icann.org/en/public-comment/proceeding/proposed-...
>>> 'internal'[::-1]
'lanretni'