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.
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.
- 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.
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.
Search domains work about 90% of the time. It's a second DNS query after the first one misses, so there's a cost in latency, and with more gTLDs being added all the time, there's increasing risk that first query unexpectedly succeeds.
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
> RFCs were originally formalization of what was being used in practice
Not at all; 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.
- 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.
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.
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...
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?
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.
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".
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 block ICANN from doing this.
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.
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
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” (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.
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.
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.
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.
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. 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.)
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.
They make sense given the history of the Internet, but not in hindsight. Most obviously, .gov, .edu and .mil should be under the .us subdomain.
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.
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”!
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.
.... 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.
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.
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
.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 .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.
> 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?
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.
125 comments
[ 0.27 ms ] story [ 36.7 ms ] threadhttps://www.rfc-editor.org/info/rfc8375/
[0]: https://amplifi.com/
- 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 can't fucking _wait_ to type bender.home.arpa instead of bender.lan. Hyped.
Search domain is handy but it's ambiguous.
I don't know what this means, and searching is thorny. Help?
Not at all; 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.
- 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...
It should be logical even without thinking that the request have to be rejected.
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.
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...
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.
https://icannwiki.org/Name_Collision_Risk_Management_Framewo...
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.
i can't understand why AVM don't allow this to be configured!
Also see a .bldg application, which also might conflict with some legacy naming schemes.
The bureaucracy seems precision-engineered to stultify, but apparently the public have 104 days after “String Confirmation Day” (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.
This may very well end up to be determined too risky to be delegated, like .corp, .home and .mail in 2018.
- "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.
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.
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.
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.
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...
at the very least, the .dev stuff should have had people second-guessing their usage of unreserved domains.
That leaves .home.arpa, which is very awkward. 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?
.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
Home.arpa exists, or buy a domain and use that. Or pick something that’s not reserved and run the risk of this happening.
FTFY
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.
There's almost no value.
Large businesses almost never use them. The potential for scams / phish / etc are now limitless.
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.
Fortunately there’s no need to speculate as the application explains this clearly:
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.
.... 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...
ICANN Reveals 2026 Round Applications for New Generic Top-Level Domains
https://news.ycombinator.com/item?id=49997301
I'm guessing that'll end up being expensive for someone...
My tweet on Sep 26, 2026
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"
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
https://www.icann.org/en/board-activities-and-meetings/mater...
.internal is all about the boundary between inside and the public internet, regardless of how you define ‘inside’.