ICANN proposes creating .INTERNAL domain to do the same job as 192.168.x.x
theregister.com
theregister.com
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'The "magic", as I understand it, of the 192.x.x.x network is that the Internet "knows" to not route it. Networking isn't my strength, so I don't know where, or what part of the my local network decides that 192.x.x.x can't be routed, and so doesn't. (I guess it's the router at the edge, but I don't know about internal routers.)
But anyway, however it's manifest, the "magic" of it is that 192 is "safe" because, at the assorted gateways that are emplaced on the Internet, that traffic just "stops".
So, how does ".internal" work? I mean, it's just a hostname, and DNS responds to queries about hostnames.
Would it work similarly where the DNS server "knows" where a request came from, and thus, "knows" that "oh this is internal traffic, so if they're asking for an .internal domain name, I can safely respond the appropriate IP"?
Is that how this supposed to work? Is that where the magic happens?
First of all, it's 192.168.x.x, there are other networks which begin with 192 and are not treated as internal networks.
The trick is simple: it's not "the Internet knows to not route it", it's "the Internet doesn't know how to route it". These ranges (there are others, like 10.x.x.x) are reserved for private use, and will never be allocated for an Internet network. Since there's no network announcing it (and if some network mistakenly tries to announce a route to these addresses, they will be filtered since everyone knows there shouldn't be routes for it), any attempt to send a packet to it will go nowhere.
That is why they know they can filter it. However the reason they bother is they often are using those addresses internally in their data center and so if someone else announces it their local network would break.
1. RFC1918 space is not "filtered". It is unroutable, because no route exists on the internet.
1a. Effectively, this is the same result, however it is still an important distinction to note: telecom networks rarely ACL or "filter" transit traffic without a) an associated service offering (like DDoS Mitigation) b) a customer request or c) RPF.
1b. Telecom networks do however filter transit routes. RFC1918 routes would be filtered on internet BGP sessions.
2. It is infrequent that RFC1918 space is used internally in telecom networks. It does happen, but it is rare.
I have worked at 2 different ISPs... RFC1918 is used EVERYWHERE, including on networks that customers can reach by sending packets through their modems/CPE. I am also familiar with the internal network of 3 others because we closely worked together during a bunch of merger/acquisitions/divestments/territory split-ups.
This caused a lot of fun when one customer ran nmap across all of RFC1918 space and hit internal security systems that were advertised across the ISPs backbone but were not properly filtered for traffic coming from customers because of a bug in a CMTS that failed to properly apply ACL's.
Management networks are a different story, but hey, some Tier 1's think they're so large they don't even need OOB anymore! (haha...)
The fact that is is not routed throughout Internet is another thing.
It's a standard that is "enforced" in two places I think:
* Place 1: ISPs configure their carrier-grade routers to drop it if they receive it.
Technically, there really is nothing stopping an ISP from actually routing it, just like there is nothing preventing you from assigning an already-assigned address like one of Google's to a NIC in your LAN.
But ...
* Place 2: Internet registries won't give out IP blocks in these ranges. So no ISP can make an AS that has routes for these addresses.
Technically again, there really is nothing stopping a registry from assigning something in the block. Imagine if someone bribed a registry to give them out. These assignments are basically what makes the global BGP table that is the "top layer" routing information for the Internet.
But:
A) all registries would have to cooperate at once for it to be globally reachable - ARIN, RIPE, APNIC, AFRNIC, and LACNIC - and current geopolitics would almost guarantee that wouldn't happen. IPv4 space is scarce and valuable, so they'd really fight over it, and
B) everyone is already using it for private IP space anyway, so even if you hosted something on a publicly accessible 192.168.1.1, no one would be able to reach it due to existing configs and assumptions, so it would be pointless.
A lot of ISPs are using these addresses internally as part of a carrier grade NAT since there are not enough IPv4 addresses to go around. So they do give them out, they just don't route them except through their NAT system, and they wouldn't want to route them as any effort would break their system.
Of course some ISPs have more IPs free than others.
RFC6598 defines CGNAT IP space as 100.64.0.0/10 (https://datatracker.ietf.org/doc/html/rfc6598). RFC1918 (private IP space) is a different allocation.
That's a relatively recent RFC; there are ISPs which have been using CGNAT for longer than that, and they do use RFC1918 addresses for their CGNAT (for instance, I know of one which used something in the 10.x.x.x range for CGNAT, which works in practice since most domestic networks use something in the 192.168.x.x range).
I'd be surprised (but not too surprised honestly) if the other ones haven't cleaned up the skeletons in their routers yet.
I don't think this is the normative intent but you could certainly say that this TLD is reserved for use with the private IP range. That would mean that a) local resolvers would not forward requests to internet resolvers and b) local resolvers can reject records pointing to non-local IPs. That's not suuuper useful because you wouldn't get an answer anyway.
What would've been useful roughly 40 years ago is for ICANN to do something like this and also say "oh, and btw., domains under internet TLDs CANNOT resolve to non-internet (local, private) IPs". That would've preempted DNS rebinding and all related attacks.
It's of course impossible to do now because the "best practice" for the last ~15 years has been to register an internet domain and then use it for your internal network because there are no private TLDs and any TLD you come up with might be registered by someone else and suddenly become attacker-controlled over night (troublesome because now VPN leakage, which none of the Expensive Enterprise Client VPNs address, allows someone not-you to easily and globally impersonate you for leaked traffic and it's not even a rebinding attack in the narrow sense).
Arguably the "Old Guard" of IP networking did "a little oopsie whoopsie" with their "Thou shalt have no other networks before me, IP, your god" commandment (the idea that the IP stack exists to support exactly one network, the internet).
Whereas something like .pri for private might one day be set up as a new TLD.
Then, in my private DNS on my private network I create an authoritative .internal zone.
[0] https://www.rfc-editor.org/rfc/rfc1918.html
edit: I think I read the parent slightly incorrectly. I conflated TLD assignment with number assignment. Apologies.
The Internet, at the end of the day, is not about technology, but an agreement: I send you traffic and you move it around, and you send me traffic and I move it around.
We all agree to use the same protocols (IP, BGP) and so can talk to each other, and the moving of bits can either be on a paid (ISPs) basis or non-paid (IXPs) basis.
As part of this everyone agrees to not move certain addresses (RFC 1918), and if they come across any, they filter/drop them as soon as possible.
Another part of this agreement is various vendors agree to the same rules, so your home firewall/router (Linksys, D-Link, Asus) acts in certain ways, which includes making sure that any traffic from (e.g.) 192.168/16 does not go out the interface labelled "WAN". (Though if it does, your ISP also agrees to filter it.)
As an example, some (terrible) ISPs intercept NXDOMAIN records which could leak into misconfigured networks that are squatting on unregistered gTLDs. This behavior would be far worse if they did this for the proposed .internal.
ftp -vd4 ftp://192.0.32.9/domain/root.zone