Big question of the day: Is it time to lock down .localhost? A proposal to tightly lock down localhost as a reserved top-level domain name has bubbled up to the surface again at the Internet Engineering Task Force. The hostname localhost is used just about everywhere: it's useful for referring to the computer you're using in front of you, or whatever machine a piece of software is …
Ah yes, that amusing incident. Some of us look at it as the day so many lazy and unthinking web developers got their just rewards for their lackadaisical approach to software engineering. It was unfortunate, but an inevitable consequence of how the web world just assumes that anything at the end of URLs is constant. Wrong!
As for localhost, well certainly on Windows a lot of AV products ensure that localhost resolves sensibly by having the correct entry in the hosts file. There doesn't seem to be a need for anything more complex than that, but no doubt the IETF will find a way...
gTLDs broke a LOT more internet hardware and software that for some reason included a hardcoded list that it wouldn't deviate from. Heck, some were so bad that they didn't even allow ccTLDs. There are some times when breaking bad assumptions is the only way to go, and given the non-impact on the vast majority of OSes, hardware, and software, might as well just make it happen.
I can't think of a single use-case where we wouldn't be better off using the machines real name or IP. Making a special exception for "localhost" promotes various bad practices in software which generally end up as security issues down the line. Surely using a call to ask the name (or IP) of the host you're running on, and then using that name (or IP) is more reliable in every use-case than hoping that "localhost" is configured to resolve properly. Sure, we could set localhost to always resolve to 127.0.0.1, but the loopback address may not always be 127.0.0.1, it might be 127.3.4.11!
Assumptions are never a good thing in computing, and localhost always breeds assumption about the world around you. I notice the article was also assuming localhost was the tld, but more often than not localdomain is also appended. Then we have the issue of 30 machines all being called localhost on the local network so if we use a DNS server to resolve, we have no idea which machine will be connected to - we can't assume the hosts file is correctly configured either, that's just asking for trouble!
I can't think of a single use-case where we wouldn't be better off using the machines real name or IP
OK, for starters, how about where the machine doesn't have a properly configured name - and by properly configured, where all the right DNS stuff is in place etc. IME it is very common for this to be the case - in fact I'd go so far as to suggest that there are more devices where a name lookup will fail than there are were it won't (especially in home networks).
And then you have the problem of changing addresses - if you bind to an address and it changes, then what ?
And security wise, if you only need intra-device access, binding to localhost rather than an interface address instantly gives you a layer of security.
But what I don't get is why hardcoding localhost in the hosts file is a problem with IPv6 ? A quick look on my older GNU/Linux systems shows that both IPv4 and IPv6 entries have been there for ages.
"OK, for starters, how about where the machine doesn't have a properly configured name"
LOL that's kind of the point I was making. You're basing things on an assumption that localhost is configured properly rather than JUST CHECKING THE FACTS. Lazy lazy lazy and it will lead you into trouble sooner or later.
Machine with dynamic DNS / DHCP but you want to use the local machine for DNS resolution until it's ready.
It's not hard to imagine routers wanting to use themselves for DNS resolution but they have no guaranteed, fixed IP except 127.0.0.1.
And about a billion others (i.e. resolution before external networking is even up, things like DBus, etc.). Basically anywhere you mean "this machine" before this machine has an assigned address.
It exists for lots of very good reasons. "localhost" resolving to it is convention coupled with history. Reserving localhost isn't a bad thing because it stops stupid junk leaking out to the real Internet.
If someone could please shoot the guy who set up the network I'm on, though, who created the entire AD with "companyname.int" thinking that "int" meant internal. No, we don't own that domain, and cannot. And no we can't just rename it, it's too well tied in now and means an entire network re-do. I've just had to add our "companyname.com" as an alternative and change the users to be at that in AD instead, but it's legacy is all over the place.
" resolution before external networking is even up"
You have no reliable way to determine that localhost is pointing at your local machine so that's not a valid use-case actually. You should be asking the machine what addresses it has available and using one of those, not assuming that some magical keyword has been implemented. Sometimes it hasn't, sometimes a different one is used. The number of people who assume (wrongly) that 127.0.0.1 will be available is evidence to this!
I wouldn't use a domain valid outside the LAN for names which should be valid inside the LAN only, and should never be accessible nor discoverable from outside.
IMHO, besides "locahost" a local domain (".local", ".localdomain"?) should be reserved to create internal networks, and ensure they cannot be resolved from outside even if a mistake has been done.
IMHO, besides "locahost" a local domain (".local", ".localdomain"?) should be reserved to create internal networks, and ensure they cannot be resolved from outside even if a mistake has been done.Unfortunately .local has already been taken for the Zeroconf protocol.
I have a similar problem with the company AD being named [company].local
means a host of spiffy email related stuff just doesn't work. Oh, and our madman of a consultant about threw a fit when I told him 'no, I'm not making people sign on with their UPNs and adding [company].com to AD as alternatives.' One world changing thing at a time, folks.
I can't think of a single use-case where we wouldn't be better off using the machines real name or IP.
We have some machines on our network with 10+ interfaces, some physical some virtual, all on different subnets. Which one is the "real" name or IP?
localhost as a name, and it's associated IP addresses, is not just an understood convention, it's built-in to implementations. Most Linuxes/Unixes that I've seen have an explicit loopback device, lo0, that the address is bound to, and that gets special treatment in the IP stack.
As far as DNS resolution goes, IPv4 and v6, does anyone not have
::1 localhost
127.0.0.1 localhost
as the first two lines in /etc/hosts?
> does anyone not have
Newer versions of Windows for a start.
The two lines are are commented out, with "localhost name resolution is handled within DNS itself": MS moved localhost resolution into the local DNS client (probably to stop users messing things up by removing those names).
"MS moved localhost resolution into the local DNS client (probably to stop users messing things up by removing those names)."
OR, so Micro-shaft could hijack them later, and ALSO prevent you from using 'hosts' to stop their ADWARE and SPYWARE...
on a related note... do we need to protect ".local" as well? (I use this for my private network since decades ago, "something.local" with bind serving up resolution for it)
Re: does anyone not have
::1 localhost
127.0.0.1 localhost
as the first two lines in /etc/hosts?
Been there as standard since the mid 1980's and probably earlier, since host look up predates DNS...
Hence I don't really understand West's claim:
"That has resulted, West claims, in people hardcoding localhost to 127.0.0.1 in their system configurations to ensure an external resolver doesn't hijack localhost."
I suggest if you are relying on an external resolver to resolve localhost then you haven't really understand the real purpose of localhost and why you should have an explicit entry for it in your IPv4/IPv6 hosts file.
This post has been deleted by its author
"Well, the inclusion of a hardcoded IPv4 address is only going to cause problems down the line as we slowly move to IPv6. It's just bad engineering."
No its not, its a very effective way of locking down certain IP addresses. IP6? So what, you can have duplicate names in hosts so you map localhost to various IP6 addresses too.
It'd also be nice is something like .lan was protected so that DNS servers can only respond with a private IP to a request, and do not forward the DNS request to an external DNS server if no match is found.
If your DNS server is authoritative for that zone, it shouldn't be queried at externat DNS servers (provided you have your clients configured to use your own DNS server of course).
That scope is too small to be useful - but this is thinking behind .home, which has its own attached controversy as it turns out.
BTW the Windows /hosts file arrives with this comment included:
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
I've filled mine up with lines like this, that help a lot:
0.0.0.0 ad.doubleclick.net
In a previous job, they had a control LAN for various pieces of kit. It was always intended to be a unrouted local network that was only to be used for this purpose. Then they decided to "document" it, and called it "private.lan.com" in the documentation. Not so fast. You see the national airline of Chile is called (wait for it) LAN Airlines. They have a web site "lan.com". The documentation looks pretty silly and I suspect that the name server probably gets LOTS of unwarranted requests from idiots managers who think they know better and like nice documentation.
Yes, reserving ".localhost" and ALWAYS returning "no such name" is probably a good idea. Returning anything other than that (like resolving to 127.0.0.1) is probably a really bad idea. Yes, it should be in the "hosts" file, as it always was.
Yes, reserving ".localhost" and ALWAYS returning "no such name" is probably a good idea.Which is not the same thing as "localhost".
".localhost" is a DNS zone, and as such can have a large number of sub-entries (although putting in a wildcard match would handle returning a consistent reply with one config line).
"localhost" is a key within a zone (roughly - it will depend how you have your name resolver configured). So if you have name resolution configure to search zones, say, ".me", ".info", don't have a specific "localhost" entry defined, look for "localhost" and someone has defined "localhost.me", then you'll get that record.
jira.domain.com, now offers something.jira.domain.com The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
