Test is best used in temporary setups that you use for testing things.
Example is best used in documentation only.
Invalid is weird and confusing.
Localhost as a TLD should still be on the machine itself. Keeping in mind that 127.0.0.1 is not the only loopback address at your disposal – you have the whole /8. You could bind different services on different loopback ip addresses and then assign host names in the .localhost tld to those.
So for example you could run different Wordpress instances locally on your machine on ips 127.87.80.2, 127.87.80.3, and 127.87.80.4, so that each can run on port 80 without colliding with one another, and without resorting to having non-80/non-443 ports.
Then have corresponding entries in /etc/hosts
127.87.80.2 dogblog.localhost
127.87.80.3 cooking.localhost
127.87.80.4 travel.localhost
And use those domains to access each of those from your browser. Then you don’t even need to keep all services behind the same Nginx instance for example, as you otherwise would do if you had different domain names but was using 127.0.0.1 and port 80 for all of them.
Whereas having the localhost tld refer to hosts elsewhere on a physical network.. that’s about equally as weird and confusing as “invalid”.
I think .test is the TLD is the one most likely to work as expected as for all use cases as .localhost might be expected to only ever point to the loopback IP address. If anyone does something more complicated (like using a vagrant private network ip address), you might find some tools break unexpectedly.
Edit: the newer version of the docs have more details (in section 6) on the differences to be expected between test, localhost, example and invalid domains. see: https://tools.ietf.org/html/rfc6761
If you run tests through the loopback interface, you should be able to use any of the 127.0.0.0/8 addresses, instead of 127.0.0.1 (a.k.a ”localhost”). Each address has its independent port space, so you would avoid collisions/contention.
In a well-configured machine second-level domains for .localhost are also supposed to loopback, per the RFC.
(It's useful as a development tool as you can Virtual Host project1.localhost and project2.localhost to different in development sites if your OS and server support it, which tend to be in similar ways to how they generally support Virtual Hosts.)
‘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. Any other use would conflict with widely deployed code which assumes this use.’
Reading that sentence implies a single loop back address. I appreciate that IPv6 “fixed” this confusion by having a single loop back address of ::1. While you are correct that IPv4 reserved the entire /8 in practice the expectation is generally that 127.0.0.1 is the loopback address, and using other addresses in the 127/8 space tends to lead to unexpected issues across many pieces of software. The intention of the .localhost domain is to ensure that DNS resolutions never resolves to something external, for security reasons.
mysite.localhost works fine for very simple development, but can easily fall down with containers, VMs, or multi-machine development. Technically, you can point it to a non-loopback IP, but I wouldn't do that. .localdomain is used some places as well, but I don't know how reliable it is.
.test is a bit more flexible, and what I use now. I'd prefer if .dev was reserved as well, but that ship has sailed.
Which developers? I’ve never heard of anyone using whatever.localhost in their code, assuming it will map to loopback? Sane developers use localhost, or localhost.localdomain in some cases.
As I understood it, that simply states that if any of those domains were implemented, they should loopback, as opposed to all domains containing "localhost" ARE implemented.
Nitpicky point here, but that's not localhost - localhost is typically 127.0.0.1 (although the entire /8 is reserved for loopback use, this is the only address defined in a typical hosts file).
Yeah, and you can also have multiple loopback interfaces in the 127.0.0.0/8 range if you want, no reason why you can only have one. That said, enough stuff out there assumes localhost = 127.0.0.1 = loopback interface that I wouldn't want to make my life complicated by breaking the convention.
Also, that comment was already a bit muc, and I opted to simplify a bit.
For local testing you can simply use the whole 127.0.0.0/8 subnet. If your webserver's listening socket is bound to the any-local address (0.0.0.0) then you can setup 127.0.0.1, .2, ... , 127.255.255.254 as vhosts.
But `localhost` is also an alias specifically for the loopback address (typically `127.0.0.1`), so "serve on localhost" can reasonably be interpreted as "serve on 127.0.0.1" which will only be available to other programs on that host, and not to others devices on the local network.
> 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. Any other use would conflict with widely deployed code which assumes this use.
So it might work but it could be problematic if the intent is to use ".localhost" as a local network domain rather than just the local host.
That would account for the case where my local machine doesn't have a host entry for "localhost" but would break if I don't have an IPV4 loopback (if, say, I only have a IPV6 one).
Both of those are pretty odd cases, so I'm not sure how much they're worth worrying about.
Everything there is an example, not actual best practice. But a lot of admins probably just go with 'eh, my textbook used 1.1.1.1, so will I'.
Really the only place I saw 1.1.1.1 regularly though is to set the router ID, and making a loopback address is not the best way to do that to begin with.
The latter. You can always set your /etc/hosts or equivalent to map "localhost" to some random IP that is not loopback. Or a proxy could proxy that hostname, etc.
In the new setup proxies can't proxy localhost unless you set a pref to explicitly let them do that, and for "localhost" and hostnames ending in ".localhost" Firefox won't even ask the DNS stack for the IP, assuming loopback instead.
Example is best used in documentation only.
Invalid is weird and confusing.
Localhost as a TLD should still be on the machine itself. Keeping in mind that 127.0.0.1 is not the only loopback address at your disposal – you have the whole /8. You could bind different services on different loopback ip addresses and then assign host names in the .localhost tld to those.
So for example you could run different Wordpress instances locally on your machine on ips 127.87.80.2, 127.87.80.3, and 127.87.80.4, so that each can run on port 80 without colliding with one another, and without resorting to having non-80/non-443 ports.
Then have corresponding entries in /etc/hosts
127.87.80.2 dogblog.localhost
127.87.80.3 cooking.localhost
127.87.80.4 travel.localhost
And use those domains to access each of those from your browser. Then you don’t even need to keep all services behind the same Nginx instance for example, as you otherwise would do if you had different domain names but was using 127.0.0.1 and port 80 for all of them.
Whereas having the localhost tld refer to hosts elsewhere on a physical network.. that’s about equally as weird and confusing as “invalid”.
reply