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.
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).
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.
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.