[0]: https://amplifi.com/
* 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...
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).
I hope the gTLD application gets struck down.
- 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?
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'.
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...
RFC 8244 is an interesting read on the topic: https://datatracker.ietf.org/doc/rfc8244/
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.
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.
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.
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.
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...
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).
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!
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