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

91–100 of 117 posts

Re: Let 'localhost' be localhost

#91

Post by ekimekim »

yrro wrote: post #40
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...

What happens as soon as two different organizations want to connect their networks together and they both turn otu to be using the same hijacked TLD? Use a real domain name instead.

Surely it's not that hard to come up with a unique, memorable internal TLD? eg. the company name - "git.facebook", "foo.microsoft", "monitoring.dev.google"

Re: Let 'localhost' be localhost

#92

Post by Symbiote »

tominous wrote: post #19
josegonzalez wrote: post #3

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.

Before the gTLDs were expanded it was easy: just choose an unused word. These days I tend to see either subdomains of the main public domain, or a public domain registered solely for internal use.

Are there any reasons not to use a real domain?

Re: Let 'localhost' be localhost

#93

Post by syntheticnature »

Raphmedia wrote: post #64
lambda wrote: post #39

I have had a number of customers who have broken our applications, which have daemons listening on localhost, by editing their /etc/hosts files and removing the localhost entry. I guess various people edit /etc/hosts to prevent applications from talking to licensing servers, and in the process happen to accidentally blow away the localhost entry (since these customers don't know what they're doing). We had this happe…

While some people might edit their host for nefarious purposes, I think it's wrong to attribute all of it to malice. Personally, I set the host file to use https://github.com/StevenBlack/hosts in order to block ads on every computers I touch. I also often use software that manage the host file and ignore the default physical file.

The relevant part of the GP might be "since these customers don't know what they're doing."

Re: Let 'localhost' be localhost

#94

Post by facetube »

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…

And, in fact, 127.0.53.53 already has a special use (try `dig @8.8.8.8 -ta drive` and `dig @8.8.8.8 -tmx drive`)

Re: Let 'localhost' be localhost

#95

Post by drzaiusapelord »

theandrewbailey wrote: post #53
okket wrote: post #48

Earlier quoted context omitted.

Looks like we need eternal IPv4 support, if it is just for 127.0.0.1 :(

I was expecting IPv4 to be around forever, for similar reasons that COBOL and the still emulated 8254 PC beep are: there's too much critical infrastructure using it.

Honestly, when could we ever retire IPv4? We've had, what three or four decades now, of building the world's infrastructure on it. What's a realistic scenario to retire that stuff even if everyone gets on IPv6 in 10 years. Another 50 years? 100? 500?

Our great-great-grandkids will still be troubleshooting the 'hey who deleted localhost from /etc/hosts' problem.

Re: Let 'localhost' be localhost

#96

Post by SysArchitect »

jerf wrote: post #60
mikewest wrote: post #32

Earlier quoted context omitted.

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…

"If you have suggestions for language that make that distinction more clearly than the document currently does, I'm happy to incorporate it. :)" Currently where it says "an IP loopback addresses", it may be worth saying something like "any of the IP loopback addresses for the device". I agree that technically "an IP loopback address" ought to be sufficient, but I have also found it is a very common belief, probably e…

Thankfully IPv6 defined a single "localhost" or loopback IP: ::1/128

There is none of this 127/8 mess.

Re: Let 'localhost' be localhost

#97

Post by SysArchitect »

facetube wrote: post #94
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…

And, in fact, 127.0.53.53 already has a special use (try `dig @8.8.8.8 -ta drive` and `dig @8.8.8.8 -tmx drive`)

https://www.iana.org/domains/root/db/drive.html

It's a valid TLD...

https://www.icann.org/news/announcement-2-2014-08-01-en

shows why drive. was set to return 127.0.53.53.

Same thing happened with prod. and other TLD's. These are all names that were/are being used internally and now are valid TLD's that are going to cause issues for people :/

Re: Let 'localhost' be localhost

#98

Post by SysArchitect »

Scarblac wrote: post #50
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…

I wish whoever owns localhost.org (which resolves to 127.0.0.1) configured it so that *.localhost.org also worked. Would help with the browsers too.

DNS rebinding means you shouldn't allow untrusted domains to resolve to a localhost IP address...

Re: Let 'localhost' be localhost

#99

Post by the8472 »

SysArchitect wrote: post #96
jerf wrote: post #60

Earlier quoted context omitted.

"If you have suggestions for language that make that distinction more clearly than the document currently does, I'm happy to incorporate it. :)" Currently where it says "an IP loopback addresses", it may be worth saying something like "any of the IP loopback addresses for the device". I agree that technically "an IP loopback address" ought to be sufficient, but I have also found it is a very common belief, probably e…

Thankfully IPv6 defined a single "localhost" or loopback IP: ::1/128 There is none of this 127/8 mess.

that "mess" is great for testing though, you can spin up numerous instances each on their own loopback address.

Re: Let 'localhost' be localhost

#100

Post by icedchai »

y0ghur7_xxx wrote: post #61
yrro wrote: post #40

Earlier quoted context omitted.

What happens as soon as two different organizations want to connect their networks together and they both turn otu to be using the same hijacked TLD? Use a real domain name instead.

> What happens as soon as two different organizations want to connect their networks together and they both turn otu to be using the same hijacked TLD? Why "hijacked" TLD? It would be a standard TLD. If two orgs merge, and they both happen to use the same hostnames for some things, like say git.internal, they just refactor those hosts, or merge them since they merge.

How is this simpler than just using real domain names? I use an int.company.com domain for my internal hosts and have for 20+ years.
Post reply on HN