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.
https://icannwiki.org/Name_Collision_Risk_Management_Framewo...
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.
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.
- 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.
having two levels, for one. "arpa" not being remotely memorably to non-technical people, for another.
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.
Why don't they just put home.arpa or .arpa in their search path?
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/
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.
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
.internal as well I believe
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.
But what if my LAN is in the garage?
well then it's a home for your lan.
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.
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.
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?
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.
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.
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.
.lan should just become reserved