.localhost Domains

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

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)

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

> 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

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

You can configure them to send requests through http proxy.

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.

This is used for scenarios where you don't want to hardcode port numbers, like when running multiple projects on your machine at the same time.

Usually you'd have a reverse proxy running on port 80 that forwards traffic to the appropoiate service, and an entry in /etc/hosts for each domain, or a catch all in dnsmasq.

Example: a docker compose setup using traefik as a reverse proxy can have all internal services running on the same port (eg. 3000) but have a different domain. The reverse proxy will then forward traffic based on Host. As long as the host is set up properly, you could have any number of backends and frontends started like this, via docker compose scaling, or by starting the services of another project. Ports won't conflict with eachother as they're only exposed internally.

Now, wether you have a use for such a setup or not is up to you.

you should never trust browsers default behavior

1. not all browsers are the same

2. there is no official standard

3. even if there was, standards are often ignored

4. what is true today can be false tomorrow

5. this is mitigation, not security

nginx validates hostnames per the spec, and to your question specifically it rejects requests that would put a slash in $host: https://github.com/nginx/nginx/blob/b6e7eb0f5792d7a52d2675ee...

There is a draft spec over it, Ill find it later, but they do hardcode it now and never touch dns.

It's probably both. Browsers now have built-in DoH so they usually do their own resolving. Only if you disable "secure DNS" (or you use group policies) will you fall back to the system resolver anymore.

Pretty sure its hard coded in the browser and never touches any resolvers. It does not work the same in safari for example.

Yup, mkcert is used by caddy which is used by localias :)

It's mentioned in the README:

  - If Caddy has not already generated a local root certificate:
     - Generate a local root certificate to sign TLS certificates
     - Install the local root certificate to the system's trust stores, and the Firefox certificate store if it exists and an be accessed.

I think an alternative to local root certs would be to use a public cert + dnsmasq on your LAN to resolve the requests to a local address.

This usually happens because you have a Linux setup that doesn't use systemd-resolved and it also doesn't have myhostname early enough in the list of name resolvers. Not sure how many Linux systems default to this, but if you want this behavior, adjust your NSS configuration, most likely.

That's because your DNS server sends back 127.0.0.1. The query isn't resolved locally.

Not for me, MacOS 15.4:

    $ ping hello.localhost
    ping: cannot resolve hello.localhost: Unknown host

For home it's not that bad, but there could be conflicts at some point. Your clients will send data to the Internet unknowingly when dns is missconfigured.

It's better to use domain you control.

I'm a fan of buying cheapest to extend (like .ovh, great value) and use real Let's Encrypt (via dns challenge) to register any subdomain/wildcard. So that any device will have "green padlock" for totally local service.

To be clear, I didn’t register anything. I just have a configuration that serves records for a zone like “artichoke.” on my DNS server. Internal hosts are then accessible via https://gitlab.artichoke, for example.

I alias home.com to my local house stuff. I don't really understand why anyone thinks it's a bad idea either.

I run a custom (unused) tld with mkcert the same way, with nginx virtual hosts set up for each app.

I think this is ideal. You make a great point that even if you were to use .internal TLD that is reserved for internal use, you wouldn't be able to use letsencrypt to get a SSL certificate for it. Not sure if there are other ssl options for .internal. But, self-signed is a PITA.

I guess the lesson is to deploy a self-signed root ca in your infra early.

If you really want to keep things local without paying any fees, you could also use Smallstep (https://smallstep.com/) to issue certificates for your services. This way you only need to add one CA to your trust store on your devices, and the certificates still renew periodically and satisfy the requirements for TLS.

I suggested using a domain given they already have Caddy set up and it's inexpensive to acquire a cheap domain. It's also less of a headache in my experience.

It's not, just a different way of satisfying the certificate challenge. Look into a DNS-01 challenge vs a HTTP-01 challenge. Let's Encrypt has a good breakdown: https://letsencrypt.org/docs/challenge-types/.

I have no idea why this is not the default solution nor why Docker can not engage in it?

I ended up writing a similar plugin[1] after searching in vain for a way to add temporary DNS entries.

The ability to add host entries via an environment variable turned out to be more useful than I'd expected, though mostly for MITM(proxy) and troubleshooting.

1: https://github.com/aib/nss-userhosts

For anyone unaware, the domain 'example.com' is specifically reserved for the purpose of testing, so you don't have to worry about some rando reading emails sent to "test@gmail.com"