[locknitpicker]

> There is no need to come up with "local TLDs" like .vibe, .local, .test and so on -- there is already an industry convention! macOS and most Linux distros support subdomains of localhost, so <anything>.localhost works.

That would work if your goal was to route traffic to localhost.

What if it isn't?

There are reasons why the likes of example.com exists.

[JimDabell]

From the article:

> So I built local.vibe — a friendly dashboard and local .vibe hostname for every local web app on your Mac. No more localhost:3000 vs localhost:5173 roulette.

> The whole thing communicates over a Unix socket acting as a reverse proxy. No external services, no accounts, no telemetry.

We’re discussing a tool that is designed for – and is only capable of – routing traffic to localhost. It’s perfectly reasonable to point out that there’s an easier solution for this use case.

[ButlerianJihad]

It looks like this will win: https://en.wikipedia.org/wiki/.internal

example.com, and the reserved TLD ".example", exist for technical documentation and writing. If you are writing a comment on HN, or a curriculum for a networking class, then you can discuss "foo.example.com connects to bar.example.com" or "Let's hypothesize about two offices called accounts.example and human-resources.example"

The "example" domains are never supposed to reflect anything that is actually deployed onto LANs, or test labs, or the Internet, current situation notwithstanding.

https://en.wikipedia.org/wiki/.example

There are, likewise, IPv4 and IPv6 ranges that are reserved to be used in documentation. Not the 192.168.0.0/24 or 10.0.0.0/8, but separate ranges that writers only write about, and are never deployed, not even in private.

localhost is only ever going to be the loopback interface, never across a network: https://en.wikipedia.org/wiki/.localhost#Conventional_use

See also: https://en.wikipedia.org/wiki/.test

The latter article lists foreign-language TLDs which serve the same purpose.

Some proposals are described here: https://en.wikipedia.org/wiki/.home

[PufPufPuf]

And there's also .local for mDNS on local network!

I've also come across projects using a public DNS record that points to 127.0.0.1 (something like localtest.me?). IMO that's way worse than using .localhost since you're trusting some rando not to change the DNS records and exfiltrate your meant-to-be-local traffic.

[ButlerianJihad]

I did not mention .local, because it is covered in the linked articles: a special-use TLD, reserved for a certain purpose. It has often happened that LAN admins try to name something under ".local" and configure a zone for it in their BIND server. But this is incorrect, because ".local" is already managed by the zeroconf/mDNS protocols. It is a special case; and that is what ".internal" seeks to rectify, by giving y'all a TLD that can be truly internal and truly a zone under DNS server control, whatever that looks like for you.

As for 127.0.0.0/8 in the public DNS: https://utcc.utoronto.ca/~cks/space/blog/sysadmin/HowNotToDo...

As for localnet and localhost in general:

https://utcc.utoronto.ca/~cks/space/blog/sysadmin/LocalhostI...

https://utcc.utoronto.ca/~cks/space/blog/web/LocalhostSurpri...

".vibe" is not a TLD. It is not a registered TLD; it is not a reserved name. It isn't a domain at all. Go ahead, do a WHOIS lookup. Anyone who attempts to use such gibberish, even in documentation, deserves to be rudely surprised, someday in the future.

[andrewaylett]

I've used[0] `.local` to achieve something like this, by advertising service endpoints over mDNS.

Exposing random services to your local network is exactly what mDNS is for, I always thought it was a shame more dev tooling didn't do that.

[0]: https://github.com/andrewaylett/mod_bonjour is a fork of Apple's mod_bonjour, very much unloved of late I'm afraid.