The *.home.arpa domain in RFC 8375 has been approved for local use since 2018, which is long enough ago that most hardware and software currently in use should be able to handle it.

RFC 8375 seems to have approved it specifically to use in Home Networking Control Protocol, though it also states "it is not intended that the use of 'home.arpa.' be restricted solely to networks where HNCP is deployed. Rather, 'home.arpa.' is intended to be the correct domain for uses like the one described for '.home' in [RFC7788]: local name service in residential homenets."

The OpenWrt wiki on Homenet suggests the project might be dead: https://openwrt.org/docs/guide-user/network/zeroconfig/hncp_...

Anyone familiar with HNCP? Are there any concerns of conflicts if HNCP becomes "a thing"? I have to say, .home.arpa doesn't exactly roll of the tongue like .internal. Some macOS users seem to have issues with .home.arpa too: https://www.reddit.com/r/MacOS/comments/1bu62do/homearpa_is_...

> I have to say, .home.arpa doesn't exactly roll of the tongue like .internal.

In my native language (Finnish) it's even worse, or better, depending on personal preference - it translates directly to .mildew.lottery-ticket.

It would be more like .mold.ticket

Thanks, I always mix up mold and mildew. However, "arpa" is specifically a lottery ticket, whereas there are tickets for concerts, tickets to ride, tickets in Jira etc...

Arpa is used for all kinds of random chance things, not specifically for lottery. I feel like ticket would still be the equivalent but I guess that would be more transliteration and opinion than direct translation? Also my view for lottery may be skewed due to the Finnish lottery culture, and how lottery has more meanings in English. Sorry turned ranty.

Arguably, Jira ‘has issues’.

Check the errata for RFC 7788. .home being listed in it is a mistake. .home has never been designated for this purpose.

home.arpa is for HNCP.

Use .internal.

I simply quoted RFC 8375. It specifically called out that while RFC 7788 mentions ".home" (quoted below), it wasn't reserved, which ".home.arpa" aims to fix. But while you say "home.arpa is for HNCP", I also quoted RFC 8375 stating it's available for other uses as well.

> A network-wide zone is appended to all single labels or unqualified zones in order to qualify them. ".home" is the default; [...]

I have been commandeering .home for the boxes on my LAN since forever. Why change it?

If I were going to do a bunch of extra work messing with configs I'd be far more inclined to switch all my personal stuff over to GNS for security and privacy reasons.

It's ugly and clunky, which is why after seven years it's had very little adoption. Home users aren't network engineers so these things actually do matter even if it seems silly in a technical sense.

Why use that over *.localhost which has been available since 1999 (introduced in RFC 2606)

From RFC 2606:

  The ".localhost" TLD has traditionally been statically defined in
  host DNS implementations as having an A record pointing to the
  loop back IP address and is reserved for such use

The RFC 8375 suggestion (*.home.arpa) allows for more than a single host in the domain. If not in name/feeling, but the strictest readings [and adherence] too.

Too much typing, and Chromium-based browsers don't understand it yet and try to search for mything.internal instead, which is annoying - you have to type out the whole http://mything.internal.

This can be addressed by hijacking an existing TLD for private use, e.g. mything.bb :^)

Isn't just typing the slash at the end enough to avoid it searching? e.g. mything/

mything/ will make the OS resolve various hosts: mything., mything.local (mDNS), mything.whateverdomainyourhomenetworkuses. (which may be what you wanted).

If you want to be sure, use mything./ : the . at the end makes sure no further domains are appended during DNS lookup, and the / makes the browser try to access to resource without Googling it.

> Chromium-based browsers don't understand it yet and try to search for mything.internal instead, which is annoying

That's hardly the only example of annoying MONOBAR behavior.

This problem could have been avoided if we had different widgets for doing different things. Someone should have thought of that.

eh, you can just add search domain via dhcp or static configuration and just type out http://mything/ no need to enter whole domain unless you need todo ssl

In that case I would prefer naming as

  <virtual>.<physical-host>.internal

So for example

  phpbb.mtndew.internal

And I’d probably still add

  phpbb.localhost 

To /etc/hosts on that host like OP does

I wrote a super basic DNS server in go (mostly fun and go practice) which allows you to specify hosts and ips in a json config file. This eliminates the need for editing your /etc/hosts file. If it matches a host in the json config file it returns that ip, else uses Cloudflare public DNS resolver as a fallback. Please; easy on my go code :-). I am a total beginner with go.

https://github.com/nodesocket/godns

.home, .corp and .mail are on ICANN’s “high risk” list so won’t ever be gTLDs, so they are also good (short) options.

Ref: https://www.icann.org/en/board-activities-and-meetings/mater...

It would be great if there was an easy way to get trusted certificates for reserved domains without rolling out a CA. There are a number of web technologies that don't work without a trusted HTTPS origin, and it's such a pain in the ass to add root CAs everywhere.

You can configure them to send requests through http proxy.

*.localhost is reserved for accessing the loopback interface. It is literally the perfect use for it. In fact on many operating systems (apparently not macOS) anything.localhost already resolves to the loopback address.

It seems like it has not been standardized yet:

> As of March 7, 2025, the domain has not been standardized by the Internet Engineering Task Force (IETF), though an Internet-Draft describing the TLD has been submitted.

It's been reserved by ICANN:

https://www.icann.org/en/board-activities-and-meetings/mater...

> Resolved (2024.07.29.06), the Board reserves .INTERNAL from delegation in the DNS root zone permanently to provide for its use in private-use applications.

> Resolved (2024.07.29.06) ... I'm too tired, I read it as a IPv4 adress...