Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let 'localhost' be localhost

tools.ietf.org

Post reply on HN
Print view View original

71–80 of 117 posts

Re: Let 'localhost' be localhost

#71

Post by zrm »

It seems like the problem with doing this is that there are multiple localhost IPs. If it was as simple as "every A query for [any].localhost is 127.0.0.1, every AAAA query is ::1" then it would be one thing, but the A query could also be 127.0.0.2 etc.

So for example this would mean that if I put an entry for "server5.localhost 127.0.0.5" in my local DNS server then that entry can't be used, because the client's local resolver API will match *.localhost and it now "MUST NOT send queries for localhost names to their configured caching DNS server(s)" so it likely returns 127.0.0.1 instead of 127.0.0.5.

Re: Let 'localhost' be localhost

#72

Post by amyjess »

jabl wrote: post #13
phs318u wrote: post #5

Earlier quoted context omitted.

.local ? https://en.m.wikipedia.org/wiki/.local

Like the linked wikipedia article says, .local is used by mDNS(zeroconf/bonjour/avahi/etc.), so you might see weird stuff if you use it for a "normal" DNS environment. AFAICT current "best practice" for private networks is to use a private subdomain of your real domain. Say, .internal.example.com.

FYI, some Linux distributions default to .localdomain instead.

But for my machines, I just use a domain that I own.

Re: Let 'localhost' be localhost

#74

Post by drostie »

near wrote: post #44

Nice! I'm very much in favor of this change. I develop my webserver locally, and it has many subdomains. So I have "www.localhost", "files.localhost", "doc.localhost", etc. I have to add each subdomain to my /etc/hosts file before I can use it, as you can't have wildcards in that file. And even then, if I type a new one into Chromium, it will try and redirect me to a Google search result, unless I prefix the whole th…

You know that you do not need to use that naming convention, right?

You might as well set up domains for www.pocalhost, files.pocalhost, doc.pocalhost.

Or, why even have that part at all? You can just as easily set up the hosts record in /etc/hosts for www, and then visit http://www/ and it should work just fine on both Windows and Linux.

Re: Let 'localhost' be localhost

#75

Post by devnull42 »

This seems like a bad idea. It seems to be solving for a problem that doesn’t exist while introducing the potential for issues. If you want to prevent latency or lookups localhost should just live in the hosts file.

Re: Let 'localhost' be localhost

#76

Post by shellac »

Pxtl wrote: post #63
y0ghur7_xxx wrote: post #34

Earlier quoted context omitted.

I agree with you. There should exist a standardized tld for internal networks that we can use and be sure that no one else has control over. Buying a domain and use a subdomain of that one is not a good workaround. .internal would be nice and is not used by now. I may go write an rfc now :) related discussion: http://serverfault.com/questions/17255/top-level-domain-doma...

I thought .local was a de-facto standard for this?

.local is used for link-local domains, for resolution by multicast DNS ('zeroconf'). See https://tools.ietf.org/html/rfc6762.

Microsoft used to suggest using it for local networks, but now advise against it.

Re: Let 'localhost' be localhost

#77

Post by drostie »

gant wrote: post #35

I always thought it made sense to address local VMs with .localhost domains in my hostsfile. Apparently not?

You can address them with whatever domains you choose; suffixing them with .localhost is no better than suffixing them with .local, .loc, .qwyjibo, or not suffixing them at all: these are merely personal choices you made to give the domains some look and feel, but they aren't intrinsically privileged by the system.

Re: Let 'localhost' be localhost

#78

Post by inopinatus »

mikewest wrote: post #32
inopinatus wrote: post #10

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…

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. I don't mean to overconstrain the definition of loopback. If you have a good mechanism for specifying a specific IP range as loopback, and…

Hey, thanks for the considered reply. I rustled up alternative language you might consider for section 3.1 paragraph 1:

"Name resolution APIs and libraries MUST recognize localhost names as special, and MUST always return a unicast address that cause the node to send an IP datagram to itself."

This deliberately echoes the language of RFC4291 and RFC6890 when defining loopbacks. Can I also suggest revising references, looks like RFC5735 has been obsoleted by RFC6890.

Overall I think this draft is a helpful clarification, thanks for creating it!

Re: Let 'localhost' be localhost

#79

Post by amluto »

inopinatus wrote: post #10

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…

> So let's say I've assigned 10.1.1.1/32 to a device loopback interface, I'm announcing it in my IGP, and I've bound a particular service to listen on 10.1.1.1:1234. Should the local resolver library be allowed to return 10.1.1.1 for servicename.localhost? Under this draft's (re)definition of loopback addresses, definitely not. So now we've lost that symbolic way to configure a service consumer to connect locally. You're left inventing workarounds such as your own namespace for loopbacks, or changing the service to also bind to, say, 127.1.1.1.

Setting localhost to resolve to 10.1.1.1 works, sometimes, for this particular use case, but it doesn't work particularly well. Consider what happens when your served is multi-homed: which interface's address should "localhost" resolve to? What if you have one service at 10.1.1.1 and another at 192.168.0.1, both are on the same box, and both want to be called "localhost".

If you're single-homed, then why not bind INADDR_ANY and let localhost be 127.0.0.1?

Re: Let 'localhost' be localhost

#80

Post by inopinatus »

amluto wrote: post #79
inopinatus wrote: post #10

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…

> So let's say I've assigned 10.1.1.1/32 to a device loopback interface, I'm announcing it in my IGP, and I've bound a particular service to listen on 10.1.1.1:1234. Should the local resolver library be allowed to return 10.1.1.1 for servicename.localhost? Under this draft's (re)definition of loopback addresses, definitely not. So now we've lost that symbolic way to configure a service consumer to connect locally. Yo…

Ah, I think you've assumed that the assignment of 10.1.1.1/32 to lo in that example is to replace 127.0.0.1/8. It's in-addition-to. The most common case is multi-homed routers that wish to announce a management address into the IGP, but I've also used it for stuff from proxy farms to making containerized/virtualized microservices a bit more portable, and I'm far from the most sophisticated user. There's people out there doing exotic things with anycast or VPNs or VOIP or MPLS that do this too. I once built a Cisco UCCE site that required it as part of ensuring there was a diverse path for their queue state replication that was in a separate routing protocol convergence domain. And so on - it's far from unusual.
Post reply on HN