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

31–40 of 117 posts

Re: Let 'localhost' be localhost

#31

Post by sohkamyung »

throwanem wrote: post #28
amingilani wrote: post #25

Just so we're clear. All these domains would just go away? https://iwantmyname.com/?domain=localhost

No. This draft describes a change by which localhost becomes effectively a new TLD in which all names map to the loopback address. Names in other TLDs won't be affected.

Sorry to nitpick, but this is technically a Draft, not a RFC.

Drafts are just that: drafts, not standards. They automatically expire after 6 months if not renewed. As stated in [1]: Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. [...] Internet-Drafts are draft documents, and are valid for a maximum of six months. They may be updated, replaced, or obsoleted by other documents at any time.

- [1] https://datatracker.ietf.org/submit/

Re: Let 'localhost' be localhost

#32

Post by mikewest »

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 that mechanism can be understood by client software and resolution APIs, then I don't see any reason not to allow it.

The salient distinction from my perspective is traffic within a specific host, and traffic that traverses the network. If you have suggestions for language that make that distinction more clearly than the document currently does, I'm happy to incorporate it. :)

I also find it curious that this draft allows only address queries (presumably A and AAAA) under .localhost. I'd like to know the rationale for that restriction. For example, there may well be applications that only use SRV records.

https://twitter.com/dbrower/status/781001487157719040 raises similar concerns. The rationale is simple: I wanted to make the smallest change possible to RFC6761, and item 3 of https://tools.ietf.org/html/rfc6761#section-6.3 already contains the address query restriction.

It's probably reasonable to reconsider it, that's just a larger change than the one I was specifically trying to make. :)

Re: Let 'localhost' be localhost

#34

Post by y0ghur7_xxx »

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.

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...

Re: Let 'localhost' be localhost

#36

Post by gant »

sohkamyung wrote: post #31
throwanem wrote: post #28

Earlier quoted context omitted.

No. This draft describes a change by which localhost becomes effectively a new TLD in which all names map to the loopback address. Names in other TLDs won't be affected.

Sorry to nitpick, but this is technically a Draft, not a RFC. Drafts are just that: drafts, not standards. They automatically expire after 6 months if not renewed. As stated in [1]: Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. [...] Internet-Drafts are draft documents, and are valid for a maximum of six months. They may be updated, replaced, o…

The name "Request for Comments" is historical, but still very confusing. IDs are the literal requests for comments now, and RFCs the standards.

Re: Let 'localhost' be localhost

#37

Post by DiabloD3 »

phs318u wrote: post #5
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.

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

.local is for mdns only. I've been using .lan instead for locally poisoned DNS entries (in my case, dnsmasq being both DNS server and dhcpd to make it easy).

Re: Let 'localhost' be localhost

#38

Post by lambda »

phs318u wrote: post #5
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.

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

No, absolutely not. If people choose that for a local domain, that breaks mDNS.

Re: Let 'localhost' be localhost

#39

Post by lambda »

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 happen enough that we eventually stopped using "localhost" and started using 127.0.0.1 in our code.

Re: Let 'localhost' be localhost

#40

Post by yrro »

y0ghur7_xxx wrote: post #34
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.

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.

Post reply on HN