Posting because OpenWRT, possibly others as well, assign .lan names to devices on the LAN by default. People who make use of this might want to follow the application, and, if it goes through, either change the name or make sure queries can't get incorrectly get sent to upstream resolvers.
Regarding that last point, I've had issues with dnsmasq in the past where it was remotely resolving domains even when they were configured to resolve locally. For .lan domains, this could be disastrous because I often send plaintext traffic to them. I did submit a fix/workaround[0], but it's still something to look out for. If anyone knows more about this issue or other ways queries could leak, please share!
It looks like as part of the process, they delegate the prefix in global DNS and see how much traffic it currently gets; if it gets too much it will be classified as "high-risk" which at least makes things harder. Which is to say, we want as much leakage as possible to hopefully make ICANN think twice about approving this.
This test is poorly designed for .lan because the opposite problem is more likely: that many people using .lan will have any resolution attempts swallowed by their routers. This is certainly true for OpenWrt and GL.iNet. It may be true for Unifi AmpliFi, which reserves .lan by default. It's potentially true for other vendors when .lan is configured as the local domain (which many online guides suggest people do).
The same thing happened to AVM recently, who make a popular (in Germany) series of home routers that assign <hostname>.fritz.box hostnames to devices by default. `ssh foo.fritz.box` would conveniently work – until .box became a registerable TLD and somebody snatched fritz.box and directed it somewhere else, concerningly also running SSH...
Arguably that's on them, but .lan seems much more controversial and I really hope ICANN does the right thing here and at least declares it permanently reserved/non-registerable.
Once that happens, browsers and other stakeholders could then consider allowing self-signed TLS certificates, maybe with TOFU semantics, for .lan hosts, ideally together with .local mDNS ones.
RFCs were originally formalization of what was being used in practice, home.arpa was chosen apparently for reasons of beauracratic convenience rather than what would best serve existing users, who all would prefer .lan and continue to do so since that was published in 2018
- Originally, IETF specified .home, but never went through the process to add it to the list of reserved names.
- Someone applied for the .home gTLD, and while it ultimately didn't go through there was a while while it was up in the air. Due to this the homenet working group had to change gTLDs.
- They decided to switch to .homenet. However, because of DNSSEC, whatever they used would need an insecure delegation in the root zone or validating resolvers wouldn't be able to resolve it. Since IAB controls .arpa but IANNA controls the root and there was no process to ask IANNA for this, they eventually decided to use home.arpa instead.
> RFCs were originally formalization of what was being used in practice
You may be confusing it with the IETF’s policy.
In early days of the RFCs, most started out as proposals, often but not always with some existing implementation as a jumping-off point to conversation (hence the name). I no longer remember why they started to be numbered and tracked, as the process naturally preceded that.
You can verify what I say by just reading some old ones at the rfc editor site.
- WTF is arpa? (in reality, I know, but there are better names than an obscure reference to internet prehistory)
- it is a second-level domain, why?
- 9 characters (home.arpa) is a lot
I kind of understand the motivation, it is a "technical" domain since it doesn't represent something in the global DNS registry, so it gets the .arpa TLD. However, that's reasoning that it out of touch from normal users. Normal users don't want to be exposed to the technicalities of DNS when they enter something in the address bar, and "myserver.lan" is more meaningful than "myserver.home.arpa", and giving meaningful names is the whole point of DNS.
I'm on that side that it was not a good idea right from the beginning.
Because this problem exists in small enterprises since ages and the workaround always was to use a domain you own.
At home I use home.arpa since 10 or 8 years or something.
Your DHCP/SLAAC RA tells clients "here is a list of search domains, when you attempt to query a bare name, also look for the name plus any suffixes listed in the search domain list". So on a system with "home.arpa" in the search domains, you can do something like 'ping myhost' and your system should attempt to resolve 'myhost.home.arpa'.
Next time may narrow down the search space and look for those keywords combinend.
The DHCP spec includes the search domain so it's not that hard to find and follow.
Of course without any context this search would be not reveal anything useful.
Ubiquiti aren't the only ones. OpenWrt (and, by extension, GL.iNet) explicitly refuses to forward .lan DNS queries to public resolvers. This is a good thing: "LAN" has a singular, unambiguous meaning that directly contradicts its use as a public TLD. The fact that we're even debating this is outrageous.
But why is it that nowadays, it's enough for a vulture corporation to have enough money to be able to privatize a part of the "web" that is in common usage (in the sense of common good) since so long?
It should be logical even without thinking that the request have to be rejected.
If you actually think it's a trivial affair to change a well-established default with more than 20 years of history that is, on top of all other difficulties that such a change typically encompasses, used to identify and name things, I hereby beg you to never design or provide any kind of infrastructure.
Looking at your links, subjective and legacy considerations aside, .alt per RFC 9476[1] seems as good a choice as .lan.
Personally, I just use a registered domain for this purpose, as they're cheap enough to not care (last I checked, I pay $10–20/domain/year for registrations, depending on registrar and TLD, and $0.21/zone/month for hosting public zones on Google Cloud).
A registered domain has the added benefit that you can use the same namespace for externally accessible services. I personally do this (using Cloudflare Tunnels, not open ports).
This reminds me of when I used to do IT work for small businesses in college. One printing company I worked for, had about 100 computers on their network, and was using public ipv4 addresses, that they did not own, on their internal network. I forget what range they were using now. But imagine seeing a DHCP server handing out addresses like 142.250.110.1/16 on a LAN and the public ip being something totally different.
It was funny, because when I brought it up to them, it was hard to articulate why it was a problem and I couldn't convince them it was worth the effort of trying to fix. They never ran into a specific issue due to this while I was there but it felt so gross.
It's always hard because when you contrive possible examples of how it goes wrong, every single example sounds contrived because of course they are contrived.
Sure one day your printer might start spewing random json code meant for some microservice of the rightful IP owner.
Sure the IP's might be owned by the Air Force and one day they might start getting traffic from your pos ipad that they decide looks like an attempt to attack one of their internal secret networks...
Sure one day traffic meant to go to your printer ends up flooding and dossing a windmill controller, preventing the rightful operators from turning it the right direction during bad weather and causing $25M damage...
And of course the real failures are more like, only people from the Maldives can't send email to your email server, a failure with no impact.
The problem is that they wouldn't be able to talk to any internet service that legitimately used those addresses. Whether that was likely to be a problem very much depends on whose addresses they were.
I used to do consulting for companies that weren't connected to the Internet yet. This was the early-mid-1990s and "Private IP Network" assignments literally did not exist until 1996.
Therefore, people who weren't on the Internet yet, or didn't expect to be connected to any particular WAN, or even had their own intranet WAN without public access, they improvised like crazy. Like, whatever IP address ranges worked for them, they just plugged 'em in.
Since it was indeed early, and IPv4 networks were being handed out like candy, the savvy companies just applied for their own network space, hopefully of an appropriate size. The applications at the time didn't specify or require that they route the traffic or put it into BGP, so registering your intranet with IANA was the right thing to do, and future-proof. Unfortunately, in the wild-west early days before CIDR, IANA needed to find either a chunk of class C, or class B without significant nuance. And that is how Apple, HP, and Ford came to control gigantic swaths of "Class A" space.
Renumbering private networks was one of the nightmare scenarios of consulting firms like mine. And it hasn't really stopped, I suppose. If your company does an M/A their private LANs may clash, and they either renumber or they NAT.
By the way, OpenWRT isn't supposed to be using ".lan". That's a ridiculous non-compliant behavior. Someone should've stopped that, long ago.
There are ways to subdomain properly and IETF has provided dedicated TLDs for it even now, but back in the day, it was not easy, and I get it. When I needed DNS for my homelab, I discovered that the best practice among bad practices was to subdomain your ISP's. Like, make up a fictitious subdomain and hang it off their real one. Then your DNS had an anchor in reality, even if it was all made up, never delegated, unreachable, unresolvable from the outside.
There's a good reason to do this if you can't be certain what reserved subnets are used in a given network and you absolutely need a static ip for some reason.
At least that's the conclusion I've arrived at at some point, but I don't remember what was the exact use case anymore.
However there are still several global IPv4 ranges that are not local reserved ranges but are effectively reserved and you could use them if you really want to without any issues.
When I was working with Linux based kiosks and PoS systems I had a good share of issues with the Microsoft MVP signature use of .local on their forests. Back then their training material recommended .local for Active Directory services.
Specifically, either a registered name or a subdomain of a registered name reserved for this purpose, because the A records for the apex should or must — I don't remember which, but it's definitely the default configuration — point to the domain controllers, and you probably don't want to host your public web site on the same addresses as your DCs (or for that matter, your internal and public records necessarily hosted on the same server).
Historically (20+ years ago), some Microsoft documentation suggested .local as an example of an unregistered domain that could be used for this purpose, which was problematic when .local was subsequently reserved for multicast DNS.
Meanwhile, I watched a very prominent Microsoft consultancy shop install a client's ActiveDirectory as <nameoforganization>.ad. You know, the country of Andorra? That has an actual real ccTLD?
Given that there don't appear to be any BGP announcements for 25.anything, is it possible that the MoD uses this address range internally, or not at all, and has agreed to continue to do so?
Given that the plain text meaning of .lan is even more unambiguous than .home, it's overwhelmingly likely that .lan will suffer the same fate, where delegation was "indefinitely deferred".
This seems like a good time to educate myself about the application (and objection) process.
The bureaucracy seems precision-engineered to stultify, but apparently the public have 104 days after “String Confirmation Day” (17th Nov; capitalization theirs) to lodge objections, assuming the “GAC” doesn’t beat them to it…
…welp, hope somebody more organized (and better-funded) than I can organize an objection. Much as I feel like I’m giving up my right to gripe by assuming somebody else will come along to do the weeding.
There's a short list of grounds they will consider for an objection, and none of them are applicable here. Paraphrasing your second link, they only allow:
- "String Confusion" -- looks or sounds like an existing (approved or being applied for) gTLD. Must be filed by whoever owns (or is applying for) that gTLD.
- "Legal Rights" -- someone else owns a trademark this would violate. Must be filed by whoever's legal rights would be violated.
- "Limited Public Interest" -- the gTLD is immoral under recognized principles of international law. I have no idea when this could be applicable.
- "Community" -- An established community organization believes the group this gTLD is intended to target will object to it. This seems more like a vehicle for e.g. Little People of America to let ICANN know that ".midget" would be offensive.
Unfortunately there doesn't seem to be a way to tell ICANN that .lan has been widely used and will break things in a way they will listen to.
> Unfortunately there doesn't seem to be a way to tell ICANN that .lan has been widely used
ICANN isn't the DNS police, and lobbying them is pointless. We should campaign for open-source router projects[0], commercial hardware developers[1], DNS resolver developers, and major providers[2] to collectively designate commonly used private TLDs such as .home, .lan, .intranet, and .private as non-resolvable in public DNS.
Local resolution would continue to work, but these names would never be forwarded upstream. With sufficient adoption, we'd establish a de facto reservation and make the TLDs commercially worthless, regardless of what ICANN decides.
--
[0] There is precedence here. OpenWrt already reserves .lan in its default dnsmasq configuration.
[1] There is precedence here. GL.iNet inherits from its OpenWrt roots. Ubiquiti uses .lan as the default in its AmpliFi products. MikroTik documents it as part of its network-discovery mechanism.
[2] I'm thinking of Cloudflare, Quad9, and others.
ICANN and IANA very much are the DNS police. As a matter of fact, IANA maintains a list of special-use domains - though, despite its widespread use, .lan is not on the list - and these domains will get rejected from gTLD applications outright. The last thing I want is to require each recursive resolver to have their own idea of what should and shouldn't be resolved.
On a related note, Google owns a registry (CRR) and a recursive resolver (8.8.8.8) that's commonly used by default or as fallback. Letting them ban entire TLDs would be a massive conflict of interest.
ICANN only have enforcement power over registries and registrars. They have no enforcement power over hardware vendors, software vendors or public resolvers.
What I implied (but failed to emphasise) is that what I'm calling for is already in de-facto effect, with multiple software and hardware vendors treating .lan as not publicly resolvable. What you describe as "the last thing [you] want" is already happening; my proposal is for more of the same.
It is valid to note that ICANN could abuse their contractual arrangements with resolvers who also operate registrars, but this would be an illegal intimidation tactic. It would not be a conflict of interest for Google to act if part of a wider campaign involving other parties.
ICANN _are_ the DNS police? They author DNS RFCs, they manage namespace delegation.
Community groups can make their own competing DNS hierarchy and governing body and perhaps should but I don't think saying ICANN aren't responsible here is reasonable.
ICANN are the registry police, not the resolver police. I am proposing that resolvers wield their influence, not registries/registrars.
Formal objections require standing, procedural compliance and fees. Demanding monetary payment in order to issue an objection means that ICANN not acting as a responsible party in my view.
On the other hand we could end up in a much worse situation where Google and Cloudflare effectively control the evolution of DNS just like Google has wrangled control of web strandards from W3C.
As someone who believes that Chrome is a slow-moving coup, turning the open Web into the Chrome Platform, I'm sympathetic to that perspective. But I'm also unmoved by unspecific slippery slope arguments. This isn't wrangling control, it's enforcing the status quo. It's an absolute gimmie.
The most valuable parties to sway wouldn't even be Google or Cloudflare. As registrars as well as resolvers, I've no serious expectation that they'd stick their neck out. Ubiquiti might though.
As former AD person and dealing with that several companies, the recommendation for internal network DNS has long been subdomain.company.com that is not on public internet.
Even today when setting up greenfield networks, I generally use internal.company.com. It also lets you get public trusted SSL certificates so you don't have to deal with internal PKI.
while .local is reserved, it's reserved for mDNS, and should be avoided on things like active directory. using an internal subdomain of a registered public domain is best practice. .internal is also okay.
Then why hasn't there been a gTLD reserved for local use? The only ones that are reserved are .local and .home.arpa. .local is out, since it is entirely for use with mDNS / Bonjour.
That leaves .home.arpa, which is very awkward and only a thing since 2018 (my home network's use of .lan definitely predates this). Especially as a non US citizen. It also seemed so far that .lan was the "unofficial" gTLD to be used, since much software like OpenWRT was already using it anyway.
Either way: making .lan internet routable seems entirely unhinged to me. LAN has always been the acronym for Local Area Network. Why would anyone sane think that it is a good idea to make this into a gTLD that can be internet routable? The only way I see forward to do this justice, is to only allow RFC 1918 and IPv6 addresses that are within the assigned prefix for your router.
This seems like a worse version of allowing .zip to be a gTLD. Remember the idea of downloading something from https://github.com/[...]@evil.zip?
> Then why hasn't there been a gTLD reserved for local use?
.qm to .qz and .xa to .xz have always been implicitly reserved as TLDs that will never be globally-routable [0] [1], but these aren't exactly the most intuitive names so it's unsurprising that nobody uses them.
(".internal" as mentioned by the sibling comment [2] is the best choice these days, but its definition is somewhat recent.)
(note: i hope .lan does not get approved, but people have to understand that they are rolling dice when using unreserved names)
edit: fucking wild that this is downvoted into negatives. press the wiki link and read the first line if you don't believe me. in fact, i will quote it: "The name internal is reserved by ICANN "
The only ones rolling dice here is anyone attempting to use the .lan TLD for public services, given that OpenWrt (and by extension most GL.iNet products) will not publicly resolve .lan under their default configuration.
Pihole here will still serve .lan internal domains. Anyone that registers .lan globally are the ones guilty of using a culturally busy domain that was unreserved before.
In time we'll see articles like "Don't register a .lan domain if you want people to visit your site"
Eh, maybe someone spinning up a brand new environment using it in 2026 should have known better. But you don't have to go that far back to reach a point where the current list of gTLDs would make .lan feel safe.
Why would you even want something like “lan” as a global TLD? Does it mean something else than the obvious?
Fortunately there’s no need to speculate as the application explains this clearly:
AGB Q118: What is the meaning/definition of the applied-for gTLD string?
Answer: Lan commonly refers to a broadly recognized term used across a wide range of contexts.
Man, my whole life I’ve identified with, related to, and wished to finally just be associated with “the concept represented by the applied-for string”!
This being on the front page at the same time as the coffee machine sending 1TB of data, and the icann application being submitted by Coffee Danger LLC is just beautiful
While you're not wrong, I suspect that .lan sees more real world usage than .local
It may not be an official standard, but it does have some weight as a de-facto standard.
I've tried briefly to try and find some numbers to back that up, but can't find much beyond apple's bonjour vs consumer routers - although I've seen companies with AD domains using .lan as well. (Although, I've also seen companies using 1.0.0.0/8 for their internal addressing...)
it definitely gets used, and i hope that the application is denied, but i also hope this is another wake up call for people that pick unreserved domains.
Wake up to what? The fact ICANN have failed in their governance responsibilities by not encoding a widely used defacto private namespace into the reserved namespace RFC and considering delegating it publicly?
whether you consider this a failure of ICANN or not is completely beside the point.
if you choose to use an unreserved domain, you are choosing to accept the risk of something like this happening. take ownership of your choices. "but other people use it" is not a great defense.
Bear in mind the advice on these things changes over time, and it's possible that the situation in the past may not have been as clear cut.
As an example, at one point in the past (I think in the 90's?), Microsoft recommended using .local for AD domains, whereas now they explicitly recommend against it.
It's a default on OpenWRT and Ubiquiti devices. I don't think consumers should be blamed nor suffer because they didn't know their pricey Ubiquiti router was using a de facto but not officially reserved TLD. you can blame Ubiquiti i guess, but once upon a time there were no reserved TLDs and it was the job of ICANN to deny new ones that had widespread understanding not to be internet routable, so it's not like there's no precedent for Ubiquiti's behavior either.
I just bought mysefl a '.casa' domain, got wildcard cert for it from lets encrypt and haven't bothered with any of these. Downside, if internet goes down resolver stops, but thats why I have local NS mirror and all DNS queries go through my resolver.
Another downside is that some devices these days use their own encrypted DNS resolver and fall back to local DNS only for non-public TLDs. Not sure if that will continue working then as expected if your internet connection goes down.
I've been bitten by this with my home router which uses <device>.fritz.box when somebody registered fritz.box.
You can buy a cheap domain to make sure no one else uses it and just roll it on your lan. Throw some DNS ACME challenges and you have valid certificates too.
I do it for the LE certificate. But "cheap" is subjective. Domain registration and management should not be as expensive as it is. Nothing the registrar or registry does could be worth $8/10/200 a year with guaranteed 5-10% price increases every year. It is a grift.
Beside the fact that was standard or not it made sense to use .lan domain for local devices, and a lot of router sold were configured with that domain for resolving local network hosts.
To me is a very bad idea to implement this proposal, it should instead be standardized and reserved for internal usage as a fix. There were even RFC like https://www.rfc-editor.org/info/rfc6762/#appendix-G that suggested their usage for local devices in a network.
What is the point of selling the .lan domain, except for making money at the expense of a security risk for millions of networks that already use that domain for internal hosts?
BTW to me there was never any sense to add new TLD domain despite country code. They decided to render internet less secure, by giving scammers infinite TLD to register they scam domain like "apple.lan", with the sole purpose of making for them easy money.
If you care a lot about home network security: spend $12 and buy a domain name for your home network. Your DNS entries can still be on your local DNS server. You can have HTTPS certificates without warnings, and there's no risk of someone else registering the domain and your requests going to an outside IP.
There's an "Objections" section on the website which currently says:
> Objections for this Application have not yet been published. Information will be added when it becomes available. Please check back periodically for updates.
How does this work? Who can submit an objection? Can I submit one as someone with .lan domains inside my home network?
For those not in the know, Google lobbied ICANN to get the name and in their application they stated (repeatedly) that the intent was to buy it so that it could be reserved; as .dev was already used by developers and if someone bought it for commercial purposes it would harm the developer community.[0]
.... they then proceeded to start selling them.
Leading to all kinds of issues, the exact issues that they raised...
Your linked icann doc is huge, but from skimming it the top portions seem to describe google’s intent to use it themselves for hosting their own projects and services.
> RFC 8375 defines the intranet domain as .home.arpa, but ICANN in 2024 says it should use .internal instead. Is ICANN not choosing .lan or .home because these two domains might still fetch a good price?
I've been using a single letter "fake" tld for my internal LAN DNS zone. Looks like ICANN requires 3+ letters in tld applications, so hopefully should be safe for quite a while.
This being on the front page at the same time as the coffee machine sending 1TB of data, and the icann application being submitted by Coffee Danger LLC is just beautiful
They make sense given the history of the Internet, but not in hindsight. Most obviously, .gov, .edu and .mil should be under the .us TLD, but obviously the inventor's prerogative applies.
It's arguably defensible to have a limited number of non-geographic TLDs. "Dot com" was an aesthetic as much as a technical decision. I wonder though, if .com/net/org had never existed, we would have a different sense of aesthetic around domain names, and there's no reason to think that it would be any better or worse than what we have now.
The .lan domain has been on an rpz blocklist along with several other commonly used names in my networks for quite some time. I have no plans for that domain to ever successfully resolve regardless of whether or not it goes live.
Debian should apply for this so they can take advantage of case insensitivity and sans-serif fonts so to let people go to DEB.lAN to view their website
Granted I'm someone using a normal TLD across my lan, but I do find it funny some suggesting those obscure alternative ones that are like 50% longer than my entire FQDN.
I'd imagine you're hard pressed to get people to commit to something so lengthy and unmemorable.
> AGB Q118. What is the meaning/definition of the applied-for gTLD string?
> Lan commonly refers to a broadly recognized term used across a wide range of contexts.
> 1. Describe the mission and purpose of the applied-for gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose.
> The mission of .LAN is to provide a namespace associated with the applied-for string.
Okay I think this is one of those situations where we should harness our collective autism and prevent the gTLD from going through. As others have pointed out there seems to be a mechanism for objecting.
Just purely from common sense perspective why the fuck should .lan be something that’s an internet/public TLD? Hello? LOCAL Area Network?
While we’re at it let’s update a few RFCs. Plus I don’t want to find out what organisations use .lan for their networks and what will end up leaking to the internet as a consequence of this.
.lan is widely used (by OpenWRT and Ubiquity and likely others) by home / SMB routers, where all connected devices will automatically be assigned hostname.lan. Technically, .home.arpa and/or .internal are designated for this, but .home.arpa is pretty clunky and they're very new (.home.arpa is from 2018 and .internal from 2024). Usage of .lan for this predates either.
The applicant appears to be an agglomeration of LLCs and legal diversions to hide responsible parties. It does lead me to assumptions about their motivations, whomever they may be.
Source: the application refers to multiple layers of LLC ownership, and the responsible parties listed are general counsels at some IP financialization company, "Identity Digital"
I mean, aside from people who regularly browse HN and have OpenWRT routers and home servers, would "Normies" have any issue with browsing to some-website.lan?
I don't really see what website would use it though. Maybe for networking companies like mikrotik.lan or self hosted services like immich.lan?
Every year around $4B is spent on websites. Where is the money going, who's getting rich?
It's monopolies like Verisign (of the .com tld) that have luxurious profits. No competition, plus they are allowed to raise their prices above inflation while their infrastructure costs go down every year.
Posting because OpenWRT, possibly others as well, assign .lan names to devices on the LAN by default. People who make use of this might want to follow the application, and, if it goes through, either change the name or make sure queries can't get incorrectly get sent to upstream resolvers.
Regarding that last point, I've had issues with dnsmasq in the past where it was remotely resolving domains even when they were configured to resolve locally. For .lan domains, this could be disastrous because I often send plaintext traffic to them. I did submit a fix/workaround[0], but it's still something to look out for. If anyone knows more about this issue or other ways queries could leak, please share!
[0]: https://github.com/openwrt/openwrt/pull/18610
It looks like as part of the process, they delegate the prefix in global DNS and see how much traffic it currently gets; if it gets too much it will be classified as "high-risk" which at least makes things harder. Which is to say, we want as much leakage as possible to hopefully make ICANN think twice about approving this.
https://icannwiki.org/Name_Collision_Risk_Management_Framewo...
Do we know if leakage is currently under test?
This test is poorly designed for .lan because the opposite problem is more likely: that many people using .lan will have any resolution attempts swallowed by their routers. This is certainly true for OpenWrt and GL.iNet. It may be true for Unifi AmpliFi, which reserves .lan by default. It's potentially true for other vendors when .lan is configured as the local domain (which many online guides suggest people do).
The same thing happened to AVM recently, who make a popular (in Germany) series of home routers that assign <hostname>.fritz.box hostnames to devices by default. `ssh foo.fritz.box` would conveniently work – until .box became a registerable TLD and somebody snatched fritz.box and directed it somewhere else, concerningly also running SSH...
Arguably that's on them, but .lan seems much more controversial and I really hope ICANN does the right thing here and at least declares it permanently reserved/non-registerable.
Once that happens, browsers and other stakeholders could then consider allowing self-signed TLS certificates, maybe with TOFU semantics, for .lan hosts, ideally together with .local mDNS ones.
uncannily fritz.box even displays AVM.de style text at present and a Grand Cayman technical contact.
i can't understand why AVM don't allow this to be configured!
RFC 8375: Special-Use Domain 'home.arpa.' is supposed to be used for this.
https://www.rfc-editor.org/info/rfc8375/
RFCs were originally formalization of what was being used in practice, home.arpa was chosen apparently for reasons of beauracratic convenience rather than what would best serve existing users, who all would prefer .lan and continue to do so since that was published in 2018
I looked into the actual reasoning here:
- Originally, IETF specified .home, but never went through the process to add it to the list of reserved names.
- Someone applied for the .home gTLD, and while it ultimately didn't go through there was a while while it was up in the air. Due to this the homenet working group had to change gTLDs.
- They decided to switch to .homenet. However, because of DNSSEC, whatever they used would need an insecure delegation in the root zone or validating resolvers wouldn't be able to resolve it. Since IAB controls .arpa but IANNA controls the root and there was no process to ask IANNA for this, they eventually decided to use home.arpa instead.
https://mailarchive.ietf.org/arch/msg/homenet/8cfJkr7SPMaPS4...
RFC 8244 is an interesting read on the topic: https://datatracker.ietf.org/doc/rfc8244/
> RFCs were originally formalization of what was being used in practice
You may be confusing it with the IETF’s policy.
In early days of the RFCs, most started out as proposals, often but not always with some existing implementation as a jumping-off point to conversation (hence the name). I no longer remember why they started to be numbered and tracked, as the process naturally preceded that.
You can verify what I say by just reading some old ones at the rfc editor site.
and most people dont use it because its an incredibly poor name.
Why don't they just put home.arpa or .arpa in their search path?
What, exactly, makes it poor? Be specific.
I will be very specific about why it is poor. The specific reason is my home network is not the Advanced Research Projects Agency.
having two levels, for one. "arpa" not being remotely memorably to non-technical people, for another.
- WTF is arpa? (in reality, I know, but there are better names than an obscure reference to internet prehistory)
- it is a second-level domain, why?
- 9 characters (home.arpa) is a lot
I kind of understand the motivation, it is a "technical" domain since it doesn't represent something in the global DNS registry, so it gets the .arpa TLD. However, that's reasoning that it out of touch from normal users. Normal users don't want to be exposed to the technicalities of DNS when they enter something in the address bar, and "myserver.lan" is more meaningful than "myserver.home.arpa", and giving meaningful names is the whole point of DNS.
It feels like a choice that was made at the end of a very long meeting about much more important topics.
The character count. lan is 3 char, home.arpa is 9. Subjectively, tt is also aesthetically unappealing.
I can't fucking _wait_ to type bender.home.arpa instead of bender.lan. Hyped.
Then use search domain and let your DHCP and DHCP6 server hand that out to clients.
or we could just not publicly delegate a defacto private space?
Search domain is handy but it's ambiguous.
I'm on that side that it was not a good idea right from the beginning. Because this problem exists in small enterprises since ages and the workaround always was to use a domain you own. At home I use home.arpa since 10 or 8 years or something.
> use search domain
I don't know what this means, and searching is thorny. Help?
https://en.wikipedia.org/wiki/Search_domain
Your DHCP/SLAAC RA tells clients "here is a list of search domains, when you attempt to query a bare name, also look for the name plus any suffixes listed in the search domain list". So on a system with "home.arpa" in the search domains, you can do something like 'ping myhost' and your system should attempt to resolve 'myhost.home.arpa'.
Thanks, appreciated. Forgot that wiki is good at this (and TV series ;-)
Next time may narrow down the search space and look for those keywords combinend. The DHCP spec includes the search domain so it's not that hard to find and follow. Of course without any context this search would be not reveal anything useful.
So now you’re potentially in conflict with ALL gTLDS? I don’t get what this is supposed to accomplish.
It would be awesome if Ubiquity will actually follow this RFC too. The Amplifi product line from Ubiquity have `.lan` support but no `home.arpa`.
[0]: https://amplifi.com/
Or ICANN could just do the right thing and reserve .lan as well, which is so much more intuitive and memorable.
Ubiquiti aren't the only ones. OpenWrt (and, by extension, GL.iNet) explicitly refuses to forward .lan DNS queries to public resolvers. This is a good thing: "LAN" has a singular, unambiguous meaning that directly contradicts its use as a public TLD. The fact that we're even debating this is outrageous.
But why is it that nowadays, it's enough for a vulture corporation to have enough money to be able to privatize a part of the "web" that is in common usage (in the sense of common good) since so long?
It should be logical even without thinking that the request have to be rejected.
yeah I'm not going to tell my s/o to use plex.home.arpa. instead of plex.lan
That's nice and all, but OpenWrt (and its use of .lan) predates this particular RFC by a rough 14 years.
I hope the gTLD application gets struck down.
God forbid OpenWrt ever receives an update or something.
You know, just because it's in an RFC doesn't mean it's actually practical. 'home.arpa' is significantly worse than every other option.
An update wouldn't change all the existing configurations.
If you actually think it's a trivial affair to change a well-established default with more than 20 years of history that is, on top of all other difficulties that such a change typically encompasses, used to identify and name things, I hereby beg you to never design or provide any kind of infrastructure.
But what if my LAN is in the garage?
well then it's a home for your lan.
Internal. is also an valid option. I moved everything there about a year ago
.internal is ICANN and not (yet?) an IETF RFC:
* https://en.wikipedia.org/wiki/.internal
Other special use domains:
* https://en.wikipedia.org/wiki/Special-use_domain_name
* https://en.wikipedia.org/wiki/Top-level_domain#Reserved_doma...
* https://datatracker.ietf.org/doc/html/rfc6761
Looking at your links, subjective and legacy considerations aside, .alt per RFC 9476[1] seems as good a choice as .lan.
Personally, I just use a registered domain for this purpose, as they're cheap enough to not care (last I checked, I pay $10–20/domain/year for registrations, depending on registrar and TLD, and $0.21/zone/month for hosting public zones on Google Cloud).
[1] https://www.rfc-editor.org/rfc/rfc9476
A registered domain has the added benefit that you can use the same namespace for externally accessible services. I personally do this (using Cloudflare Tunnels, not open ports).
.internal as well I believe
This reminds me of when I used to do IT work for small businesses in college. One printing company I worked for, had about 100 computers on their network, and was using public ipv4 addresses, that they did not own, on their internal network. I forget what range they were using now. But imagine seeing a DHCP server handing out addresses like 142.250.110.1/16 on a LAN and the public ip being something totally different.
It was funny, because when I brought it up to them, it was hard to articulate why it was a problem and I couldn't convince them it was worth the effort of trying to fix. They never ran into a specific issue due to this while I was there but it felt so gross.
It's always hard because when you contrive possible examples of how it goes wrong, every single example sounds contrived because of course they are contrived.
Sure one day your printer might start spewing random json code meant for some microservice of the rightful IP owner.
Sure the IP's might be owned by the Air Force and one day they might start getting traffic from your pos ipad that they decide looks like an attempt to attack one of their internal secret networks...
Sure one day traffic meant to go to your printer ends up flooding and dossing a windmill controller, preventing the rightful operators from turning it the right direction during bad weather and causing $25M damage...
And of course the real failures are more like, only people from the Maldives can't send email to your email server, a failure with no impact.
The problem is that they wouldn't be able to talk to any internet service that legitimately used those addresses. Whether that was likely to be a problem very much depends on whose addresses they were.
I used to do consulting for companies that weren't connected to the Internet yet. This was the early-mid-1990s and "Private IP Network" assignments literally did not exist until 1996.
Therefore, people who weren't on the Internet yet, or didn't expect to be connected to any particular WAN, or even had their own intranet WAN without public access, they improvised like crazy. Like, whatever IP address ranges worked for them, they just plugged 'em in.
Since it was indeed early, and IPv4 networks were being handed out like candy, the savvy companies just applied for their own network space, hopefully of an appropriate size. The applications at the time didn't specify or require that they route the traffic or put it into BGP, so registering your intranet with IANA was the right thing to do, and future-proof. Unfortunately, in the wild-west early days before CIDR, IANA needed to find either a chunk of class C, or class B without significant nuance. And that is how Apple, HP, and Ford came to control gigantic swaths of "Class A" space.
Renumbering private networks was one of the nightmare scenarios of consulting firms like mine. And it hasn't really stopped, I suppose. If your company does an M/A their private LANs may clash, and they either renumber or they NAT.
By the way, OpenWRT isn't supposed to be using ".lan". That's a ridiculous non-compliant behavior. Someone should've stopped that, long ago.
There are ways to subdomain properly and IETF has provided dedicated TLDs for it even now, but back in the day, it was not easy, and I get it. When I needed DNS for my homelab, I discovered that the best practice among bad practices was to subdomain your ISP's. Like, make up a fictitious subdomain and hang it off their real one. Then your DNS had an anchor in reality, even if it was all made up, never delegated, unreachable, unresolvable from the outside.
There's a good reason to do this if you can't be certain what reserved subnets are used in a given network and you absolutely need a static ip for some reason.
At least that's the conclusion I've arrived at at some point, but I don't remember what was the exact use case anymore.
However there are still several global IPv4 ranges that are not local reserved ranges but are effectively reserved and you could use them if you really want to without any issues.
When I was working with Linux based kiosks and PoS systems I had a good share of issues with the Microsoft MVP signature use of .local on their forests. Back then their training material recommended .local for Active Directory services.
Pretty sure MS's official documentation always strongly suggested using a real domain you own for AD.
Specifically, either a registered name or a subdomain of a registered name reserved for this purpose, because the A records for the apex should or must — I don't remember which, but it's definitely the default configuration — point to the domain controllers, and you probably don't want to host your public web site on the same addresses as your DCs (or for that matter, your internal and public records necessarily hosted on the same server).
Historically (20+ years ago), some Microsoft documentation suggested .local as an example of an unregistered domain that could be used for this purpose, which was problematic when .local was subsequently reserved for multicast DNS.
Meanwhile, I watched a very prominent Microsoft consultancy shop install a client's ActiveDirectory as <nameoforganization>.ad. You know, the country of Andorra? That has an actual real ccTLD?
In the UK, Virgin Media uses UK Ministry of Defence's 25.0.0.0/8 for CGNAT
Given that there don't appear to be any BGP announcements for 25.anything, is it possible that the MoD uses this address range internally, or not at all, and has agreed to continue to do so?
.lan should just become reserved
Given that the plain text meaning of .lan is even more unambiguous than .home, it's overwhelmingly likely that .lan will suffer the same fate, where delegation was "indefinitely deferred".
This seems like a good time to educate myself about the application (and objection) process.
The bureaucracy seems precision-engineered to stultify, but apparently the public have 104 days after “String Confirmation Day” (17th Nov; capitalization theirs) to lodge objections, assuming the “GAC” doesn’t beat them to it…
https://newgtldprogram.icann.org/en/application-rounds/round...
…of course there’s a “filing fee,” priced in “hours of a panel of lawyers’ time,” to lodge such an objection…
https://newgtldprogram-2026-agb.icann.org/en/8-module-4-comm...
…welp, hope somebody more organized (and better-funded) than I can organize an objection. Much as I feel like I’m giving up my right to gripe by assuming somebody else will come along to do the weeding.
Following "String Confirmation Day" there's also a "Name Collision Risk Management Framework" assessment that new gTLDs will need to pass in order for the application to proceed: https://icannwiki.org/Name_Collision_Risk_Management_Framewo...
This may very well end up to be determined too risky to be delegated, like .corp, .home and .mail in 2018.
There's a short list of grounds they will consider for an objection, and none of them are applicable here. Paraphrasing your second link, they only allow:
- "String Confusion" -- looks or sounds like an existing (approved or being applied for) gTLD. Must be filed by whoever owns (or is applying for) that gTLD.
- "Legal Rights" -- someone else owns a trademark this would violate. Must be filed by whoever's legal rights would be violated.
- "Limited Public Interest" -- the gTLD is immoral under recognized principles of international law. I have no idea when this could be applicable.
- "Community" -- An established community organization believes the group this gTLD is intended to target will object to it. This seems more like a vehicle for e.g. Little People of America to let ICANN know that ".midget" would be offensive.
Unfortunately there doesn't seem to be a way to tell ICANN that .lan has been widely used and will break things in a way they will listen to.
> Unfortunately there doesn't seem to be a way to tell ICANN that .lan has been widely used
ICANN isn't the DNS police, and lobbying them is pointless. We should campaign for open-source router projects[0], commercial hardware developers[1], DNS resolver developers, and major providers[2] to collectively designate commonly used private TLDs such as .home, .lan, .intranet, and .private as non-resolvable in public DNS.
Local resolution would continue to work, but these names would never be forwarded upstream. With sufficient adoption, we'd establish a de facto reservation and make the TLDs commercially worthless, regardless of what ICANN decides.
--
[0] There is precedence here. OpenWrt already reserves .lan in its default dnsmasq configuration.
[1] There is precedence here. GL.iNet inherits from its OpenWrt roots. Ubiquiti uses .lan as the default in its AmpliFi products. MikroTik documents it as part of its network-discovery mechanism.
[2] I'm thinking of Cloudflare, Quad9, and others.
> ICANN isn't the DNS police
ICANN and IANA very much are the DNS police. As a matter of fact, IANA maintains a list of special-use domains - though, despite its widespread use, .lan is not on the list - and these domains will get rejected from gTLD applications outright. The last thing I want is to require each recursive resolver to have their own idea of what should and shouldn't be resolved.
On a related note, Google owns a registry (CRR) and a recursive resolver (8.8.8.8) that's commonly used by default or as fallback. Letting them ban entire TLDs would be a massive conflict of interest.
ICANN only have enforcement power over registries and registrars. They have no enforcement power over hardware vendors, software vendors or public resolvers.
What I implied (but failed to emphasise) is that what I'm calling for is already in de-facto effect, with multiple software and hardware vendors treating .lan as not publicly resolvable. What you describe as "the last thing [you] want" is already happening; my proposal is for more of the same.
It is valid to note that ICANN could abuse their contractual arrangements with resolvers who also operate registrars, but this would be an illegal intimidation tactic. It would not be a conflict of interest for Google to act if part of a wider campaign involving other parties.
ICANN _are_ the DNS police? They author DNS RFCs, they manage namespace delegation.
Community groups can make their own competing DNS hierarchy and governing body and perhaps should but I don't think saying ICANN aren't responsible here is reasonable.
ICANN are the registry police, not the resolver police. I am proposing that resolvers wield their influence, not registries/registrars.
Formal objections require standing, procedural compliance and fees. Demanding monetary payment in order to issue an objection means that ICANN not acting as a responsible party in my view.
On the other hand we could end up in a much worse situation where Google and Cloudflare effectively control the evolution of DNS just like Google has wrangled control of web strandards from W3C.
As someone who believes that Chrome is a slow-moving coup, turning the open Web into the Chrome Platform, I'm sympathetic to that perspective. But I'm also unmoved by unspecific slippery slope arguments. This isn't wrangling control, it's enforcing the status quo. It's an absolute gimmie.
The most valuable parties to sway wouldn't even be Google or Cloudflare. As registrars as well as resolvers, I've no serious expectation that they'd stick their neck out. Ubiquiti might though.
It's a shame that ICANN did get so greedy and put everyone at risk.
Having internal domain names owned by some guy on the internet has already compromised multiple corporate networks. See the talk from this guy:
https://www.romhack.io/wp-content/uploads/2025/10/Internal-D...
As former AD person and dealing with that several companies, the recommendation for internal network DNS has long been subdomain.company.com that is not on public internet.
Even today when setting up greenfield networks, I generally use internal.company.com. It also lets you get public trusted SSL certificates so you don't have to deal with internal PKI.
`.internal` and `.local` are safe and won't be used in the future. There are reserved for internal networks
while .local is reserved, it's reserved for mDNS, and should be avoided on things like active directory. using an internal subdomain of a registered public domain is best practice. .internal is also okay.
im not super keen on all of these gTLDs, but anyone choosing to use .lan should have been aware of the risks of using an unofficial/unreserved domain.
at the very least, the .dev stuff should have had people second-guessing their usage of unreserved domains.
Then why hasn't there been a gTLD reserved for local use? The only ones that are reserved are .local and .home.arpa. .local is out, since it is entirely for use with mDNS / Bonjour.
That leaves .home.arpa, which is very awkward and only a thing since 2018 (my home network's use of .lan definitely predates this). Especially as a non US citizen. It also seemed so far that .lan was the "unofficial" gTLD to be used, since much software like OpenWRT was already using it anyway.
Either way: making .lan internet routable seems entirely unhinged to me. LAN has always been the acronym for Local Area Network. Why would anyone sane think that it is a good idea to make this into a gTLD that can be internet routable? The only way I see forward to do this justice, is to only allow RFC 1918 and IPv6 addresses that are within the assigned prefix for your router.
This seems like a worse version of allowing .zip to be a gTLD. Remember the idea of downloading something from https://github.com/[...]@evil.zip?
> Then why hasn't there been a gTLD reserved for local use?
.qm to .qz and .xa to .xz have always been implicitly reserved as TLDs that will never be globally-routable [0] [1], but these aren't exactly the most intuitive names so it's unsurprising that nobody uses them.
(".internal" as mentioned by the sibling comment [2] is the best choice these days, but its definition is somewhat recent.)
[0]: https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#User-assign...
[1]: https://en.wikipedia.org/wiki/Country_code_top-level_domain#...
[2]: https://news.ycombinator.com/item?id=50012163
Cool! Also .aa and .zz based on the table from your Wikipedia link.
>Then why hasn't there been a gTLD reserved for local use?
there is. it's .internal.
https://en.wikipedia.org/wiki/.internal
(note: i hope .lan does not get approved, but people have to understand that they are rolling dice when using unreserved names)
edit: fucking wild that this is downvoted into negatives. press the wiki link and read the first line if you don't believe me. in fact, i will quote it: "The name internal is reserved by ICANN "
The only ones rolling dice here is anyone attempting to use the .lan TLD for public services, given that OpenWrt (and by extension most GL.iNet products) will not publicly resolve .lan under their default configuration.
> Introduced 29 July 2024; 2 years ago
That explains why I hadn't heard of this yet. My current incarnation of my internal network dates from ~april 2024.
It seems odd to ask why there isn’t a reserved option for this, then acknowledge home.arpa and immediately discard it.
Home.arpa exists, or buy a domain and use that. Or pick something that’s not reserved and run the risk of this happening.
Pihole here will still serve .lan internal domains. Anyone that registers .lan globally are the ones guilty of using a culturally busy domain that was unreserved before.
In time we'll see articles like "Don't register a .lan domain if you want people to visit your site"
My personal head canon is that ICANN told Google they had to open registration or someone who would open it up would get it
Eh, maybe someone spinning up a brand new environment using it in 2026 should have known better. But you don't have to go that far back to reach a point where the current list of gTLDs would make .lan feel safe.
>But you don't have to go that far back to reach a point where the current list of gTLDs would make .lan feel safe.
throughout most of my career, there was no unreserved domain that felt safe. but especially after .dev.
> but anyone choosing to use .lan [gTLD] should [be] aware of the risks of [of it being used for local routing for the last 20 years or more]
FTFY
Why would you even want something like “lan” as a global TLD? Does it mean something else than the obvious?
Fortunately there’s no need to speculate as the application explains this clearly:
Man, my whole life I’ve identified with, related to, and wished to finally just be associated with “the concept represented by the applied-for string”!
This is a security issue for many devices. What could possibly go wrong overriding a tld used for internal networking....
This being on the front page at the same time as the coffee machine sending 1TB of data, and the icann application being submitted by Coffee Danger LLC is just beautiful
Indeed. It akin to an application for a .local TLD.
>It akin to an application for a .local TLD.
it is not, as .local is designated as a special-use domain name and .lan is not.
While you're not wrong, I suspect that .lan sees more real world usage than .local
It may not be an official standard, but it does have some weight as a de-facto standard.
I've tried briefly to try and find some numbers to back that up, but can't find much beyond apple's bonjour vs consumer routers - although I've seen companies with AD domains using .lan as well. (Although, I've also seen companies using 1.0.0.0/8 for their internal addressing...)
I've habitually used .home since 2014 when its ICANN delegation was indefinitely deferred.
it definitely gets used, and i hope that the application is denied, but i also hope this is another wake up call for people that pick unreserved domains.
Wake up to what? The fact ICANN have failed in their governance responsibilities by not encoding a widely used defacto private namespace into the reserved namespace RFC and considering delegating it publicly?
whether you consider this a failure of ICANN or not is completely beside the point.
if you choose to use an unreserved domain, you are choosing to accept the risk of something like this happening. take ownership of your choices. "but other people use it" is not a great defense.
Bear in mind the advice on these things changes over time, and it's possible that the situation in the past may not have been as clear cut.
As an example, at one point in the past (I think in the 90's?), Microsoft recommended using .local for AD domains, whereas now they explicitly recommend against it.
It's a default on OpenWRT and Ubiquiti devices. I don't think consumers should be blamed nor suffer because they didn't know their pricey Ubiquiti router was using a de facto but not officially reserved TLD. you can blame Ubiquiti i guess, but once upon a time there were no reserved TLDs and it was the job of ICANN to deny new ones that had widespread understanding not to be internet routable, so it's not like there's no precedent for Ubiquiti's behavior either.
it would be more defensible of ubiquiti 7 years ago, before the whole .dev situation. not as much anymore
You would hope someone would finally learn after .dev and .local started getting used.
RFC 6762 reserves the .local. TLD for Multicast DNS. There are no reservations for .lan. so something like home.arpa. should be used instead.
router.home vs router.home.arpa
.home.arpa is so clunky. Why do I have to put the acronym of a US military project in my domain to access resources on my own local network?
Yes, I know that organization was central to the development of the l Internet, but it's not relevant as a domain 40 years later.
I just bought mysefl a '.casa' domain, got wildcard cert for it from lets encrypt and haven't bothered with any of these. Downside, if internet goes down resolver stops, but thats why I have local NS mirror and all DNS queries go through my resolver.
Another downside is that some devices these days use their own encrypted DNS resolver and fall back to local DNS only for non-public TLDs. Not sure if that will continue working then as expected if your internet connection goes down.
I've been bitten by this with my home router which uses <device>.fritz.box when somebody registered fritz.box.
You can buy a cheap domain to make sure no one else uses it and just roll it on your lan. Throw some DNS ACME challenges and you have valid certificates too.
Why should I have to purchase something (yearly subscription, mind) in order to access something that is potentially half a meter away?
This is not how anything should work.
you dont have to. .internal is fine.
yep, I supply 2 search domains via DHCP option 119: .lan and .internal
guess I'll be migrating things 100% over to internal...
I do it for the LE certificate. But "cheap" is subjective. Domain registration and management should not be as expensive as it is. Nothing the registrar or registry does could be worth $8/10/200 a year with guaranteed 5-10% price increases every year. It is a grift.
router.internal avoids the military arconym
What could go wrong using tlds that were not explicitly reserved for internal use?
Beside the fact that was standard or not it made sense to use .lan domain for local devices, and a lot of router sold were configured with that domain for resolving local network hosts.
To me is a very bad idea to implement this proposal, it should instead be standardized and reserved for internal usage as a fix. There were even RFC like https://www.rfc-editor.org/info/rfc6762/#appendix-G that suggested their usage for local devices in a network.
What is the point of selling the .lan domain, except for making money at the expense of a security risk for millions of networks that already use that domain for internal hosts?
BTW to me there was never any sense to add new TLD domain despite country code. They decided to render internet less secure, by giving scammers infinite TLD to register they scam domain like "apple.lan", with the sole purpose of making for them easy money.
What could go wrong with puting the interests of a couple corporations over those of the rest of the internet community.
not putting lan in the most recent update to the reserved private namespace was a massive miss. It is defacto a reserved private namespace.
This has been widely used since before there were any TLDs explicitly reserved for internal use.
This was my first thought as well. Yikes.
If you care a lot about home network security: spend $12 and buy a domain name for your home network. Your DNS entries can still be on your local DNS server. You can have HTTPS certificates without warnings, and there's no risk of someone else registering the domain and your requests going to an outside IP.
I guess https://www.rfc-editor.org/rfc/rfc6762#appendix-G should be updated
There's an "Objections" section on the website which currently says:
> Objections for this Application have not yet been published. Information will be added when it becomes available. Please check back periodically for updates.
How does this work? Who can submit an objection? Can I submit one as someone with .lan domains inside my home network?
I'm still seething about `.dev`.
For those not in the know, Google lobbied ICANN to get the name and in their application they stated (repeatedly) that the intent was to buy it so that it could be reserved; as .dev was already used by developers and if someone bought it for commercial purposes it would harm the developer community.[0]
.... they then proceeded to start selling them.
Leading to all kinds of issues, the exact issues that they raised...
https://github.com/basecamp/pow/issues/397
https://github.com/laravel/valet/issues/433
https://danielbachhuber.com/switch-laravel-valet-from-dev-to...
https://community.localwp.com/t/dev-domain-doesnt-work/4277
https://forums.theregister.com/forum/all/2017/11/29/google_d...
[0]: https://gtldresult.icann.org/applicationstatus/applicationde...
Your linked icann doc is huge, but from skimming it the top portions seem to describe google’s intent to use it themselves for hosting their own projects and services.
Didn't know this history. Thanks for educating me.
Same. An I use .lan internally. I'm tilted.
> RFC 8375 defines the intranet domain as .home.arpa, but ICANN in 2024 says it should use .internal instead. Is ICANN not choosing .lan or .home because these two domains might still fetch a good price?
My tweet on Sep 26, 2026
The way they've filled out the application surprises me.
There are questions that literally say as part of the question "Choose Yes or No", so they've answered "true"...
And Q165 is fun: "Is it likely that consumers will face significant risks if domain names in the TLD(s) in the application are abused?" Answer: "No"
They should finally set aside .home and .corp as reserved domains. They're already considered not a valid gTLD:
https://en.wikipedia.org/wiki/.home
https://icannwiki.org/Name_Collision
Full collection of proposed new gTLDs: https://newgtldprogram-aps.icann.org/statistics
Also see a .bldg application, which also might conflict with some legacy naming schemes.
Can I get a group of Ians and register .Ian?
You can apply for any gTLD string for any reason, the hard part is the application fee: USD$227,000.
The one downside of being named Ian is being predisposed to misread lowercased "LAN"
I've been using a single letter "fake" tld for my internal LAN DNS zone. Looks like ICANN requires 3+ letters in tld applications, so hopefully should be safe for quite a while.
If that were to ever change, I bet there's a certain billionaire who'd be very interested in the .x gTLD.
First ever pTLD?
This being on the front page at the same time as the coffee machine sending 1TB of data, and the icann application being submitted by Coffee Danger LLC is just beautiful
gTLDs were a mistake. I say that as an owner of several domains with gTLDs.
There's almost no value.
Large businesses almost never use them. The potential for scams / phish / etc are now limitless.
Do you also think that of the original 7 gTLDs (.com, .edu, .gov, .int, .mil, .net, and .org)?
They make sense given the history of the Internet, but not in hindsight. Most obviously, .gov, .edu and .mil should be under the .us TLD, but obviously the inventor's prerogative applies.
It's arguably defensible to have a limited number of non-geographic TLDs. "Dot com" was an aesthetic as much as a technical decision. I wonder though, if .com/net/org had never existed, we would have a different sense of aesthetic around domain names, and there's no reason to think that it would be any better or worse than what we have now.
When ICANN reserved .internal a couple years ago, I was saying they should just flip and truncate it to .lan(retni) so everyone's happy.
The .lan domain has been on an rpz blocklist along with several other commonly used names in my networks for quite some time. I have no plans for that domain to ever successfully resolve regardless of whether or not it goes live.
Related:
ICANN Reveals 2026 Round Applications for New Generic Top-Level Domains
https://news.ycombinator.com/item?id=49997301
Debian should apply for this so they can take advantage of case insensitivity and sans-serif fonts so to let people go to DEB.lAN to view their website
Granted I'm someone using a normal TLD across my lan, but I do find it funny some suggesting those obscure alternative ones that are like 50% longer than my entire FQDN. I'd imagine you're hard pressed to get people to commit to something so lengthy and unmemorable.
Can we somehow, as a society, eject all lawyers?
> AGB Q118. What is the meaning/definition of the applied-for gTLD string?
> Lan commonly refers to a broadly recognized term used across a wide range of contexts.
> 1. Describe the mission and purpose of the applied-for gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose.
> The mission of .LAN is to provide a namespace associated with the applied-for string.
21 separate applications for some variation on .agent/.agentic
I'm guessing that'll end up being expensive for someone...
Okay I think this is one of those situations where we should harness our collective autism and prevent the gTLD from going through. As others have pointed out there seems to be a mechanism for objecting.
Just purely from common sense perspective why the fuck should .lan be something that’s an internet/public TLD? Hello? LOCAL Area Network?
While we’re at it let’s update a few RFCs. Plus I don’t want to find out what organisations use .lan for their networks and what will end up leaking to the internet as a consequence of this.
ICANN have locked the name .internal for private network use. Not sure why .lan is needed.
https://www.icann.org/en/board-activities-and-meetings/mater...
.lan is shorter, and has been widely used for many years (since before .internal or .home.arpa were "standardized")
.lan is indicative of topology not necessarily of accessibility.
.internal is all about the boundary between inside and the public internet, regardless of how you define ‘inside’.
Also, .internal was specified two years ago. .lan has been in use for decades.
I'm out of the loop on this, can someone explain who this is and why this is bad?
.lan is widely used (by OpenWRT and Ubiquity and likely others) by home / SMB routers, where all connected devices will automatically be assigned hostname.lan. Technically, .home.arpa and/or .internal are designated for this, but .home.arpa is pretty clunky and they're very new (.home.arpa is from 2018 and .internal from 2024). Usage of .lan for this predates either.
For example I use a PiHole with local DNS records for my services like immich.lan, paperless.lan, etc.
Guess I'll just stick to .local
Aw man, my beloved .lan for my home network
Nooo, don't break my home domain :(
..Why? Just to annoy people?
The applicant appears to be an agglomeration of LLCs and legal diversions to hide responsible parties. It does lead me to assumptions about their motivations, whomever they may be.
Source: the application refers to multiple layers of LLC ownership, and the responsible parties listed are general counsels at some IP financialization company, "Identity Digital"
To sell to scammers for lots of money
so so dumb. Pure greed. This is going to cause so many issues
No.
Good luck with that. We'll see who is stupid enough to buy a .lan domain and never get visitors.
I mean, aside from people who regularly browse HN and have OpenWRT routers and home servers, would "Normies" have any issue with browsing to some-website.lan?
I don't really see what website would use it though. Maybe for networking companies like mikrotik.lan or self hosted services like immich.lan?
[dead]
We need to separate competitive gTLDs from those whose registration is controlled uncompetitively. Very few, e.g. .xyz, are competitive.
Every year around $4B is spent on websites. Where is the money going, who's getting rich?
It's monopolies like Verisign (of the .com tld) that have luxurious profits. No competition, plus they are allowed to raise their prices above inflation while their infrastructure costs go down every year.
"America" has our best interests at heart /s
This feels like a really weird comment on a post about gTLDs that exist in parallel to .com