11–20 of 117 posts
Maybe someone should standardize internal TLD(s) for corporate and other use cases that would make developers less sad, as at least they have alternatives.
.local ? https://en.m.wikipedia.org/wiki/.local
Isn't there a problem here? This draft says: IPv4 loopback addresses are defined in Section 2.1 of [RFC5735] as "127.0.0.0/8". That's not perfectly true. RFC5735 defines 127/8 as loopback addresses, but it leaves the door open for other addresses to be assigned to the loopback interface. And indeed doing so is a common pattern for network devices, and a less common (but very useful) pattern for services. So let's say…
16:04:25 speedy :{~} $ cat /etc/hosts
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
10.1.1.1 servicelocalhostMaybe someone should standardize internal TLD(s) for corporate and other use cases that would make developers less sad, as at least they have alternatives.
.local ? https://en.m.wikipedia.org/wiki/.local
AFAICT current "best practice" for private networks is to use a private subdomain of your real domain. Say, .internal.example.com.
Back in the bad old days only a single user on a physical computer could log into a windows domain, because it was possible look up what user (singular) was on a host. Of course domain logins were also exquisitely sensitive to the nature of the network between client and server as well. It was a nightmare. Localhost is a product of that kind of thinking.
One-per-host resources that have to be shared across all users, security perimeters, vms, containers, etc. are an unwelcome headache. Of course, real systems don't actually share a localhost between all of these things, resulting in the even goofier concept of "which localhost do you mean?" That question was exactly why site-local addressing was deprecated from ipv6 https://tools.ietf.org/html/rfc3879
An actually portable standard for resolving well-known local entities would be great, but more special cases to try to fix the doomed localhost idea is a move in the wrong direction.
-1 from me. 'localhost' is an artifact of a model of network computing that is no longer relevant; it's a special case of the general antipattern of network-topology sensitive design. Back in the bad old days only a single user on a physical computer could log into a windows domain, because it was possible look up what user (singular) was on a host. Of course domain logins were also exquisitely sensitive to the natur…
(And I am not sure this thinking will ever be dead, it's kind of extension of notion of "territory" for physical objects, and you can still pretty safely assume that whatever is in my home is my own.)
Is there an actual case to be made for pointing localhost to anything other than the loopback device?
Maybe someone should standardize internal TLD(s) for corporate and other use cases that would make developers less sad, as at least they have alternatives.
Earlier quoted context omitted.
Unfortunately that is less and less possible due to multicast DNS which hijacked that TLD.
Isn't .private reserved?