Let 'localhost' be localhost
tools.ietf.org
Let 'localhost' be localhost
1–10 of 117 posts
Re: Let 'localhost' be localhost
#2"Implementation Considerations: This change would make developers sad [...]"
Sad panda.
But it makes total sense.
Re: Let 'localhost' be localhost
#3Maybe someone should standardize internal TLD(s) for corporate and other use cases that would make developers less sad, as at least they have alternatives.
Re: Let 'localhost' be localhost
#4Maybe I'm overthinking this, but wouldn't a better solution be to say that server1.localhost doesn't have to be loopback, but that it must be resolved by asking the DNS server at localhost (or alternatively defined in the hosts file).
edit: I don't really have any expertise or experience with this at all, just a thought.
Re: Let 'localhost' be localhost
#5Maybe someone should standardize internal TLD(s) for corporate and other use cases that would make developers less sad, as at least they have alternatives.
Re: Let 'localhost' be localhost
#6Is there an actual case to be made for pointing localhost to anything other than the loopback device?
Re: Let 'localhost' be localhost
#7Maybe I'm overthinking this, but wouldn't a better solution be to say that server1.localhost doesn't have to be loopback, but that it must be resolved by asking the DNS server at localhost (or alternatively defined in the hosts file). edit: I don't really have any expertise or experience with this at all, just a thought.
I think people already hosting their own DNS server at localhost don't need to worry about real domain allocations as they can spoof whatever they want for development.
I think reserving .localhost for loopback would be great for my workflow. Maybe it would check hosts for overrides before going straight to loopback?
Re: Let 'localhost' be localhost
#8I'm not very networking-wise, got a question: is the "local machine" alwyas a well-defined thing? I'm thinking about stuff like where hosts are transparently distributed. Maybe there are systems out there that take advantage of resolving localhost to other than 127.* in order to make applications easy to transparently migrate when scaling servers out, or something?
Re: Let 'localhost' be localhost
#9What happened to localdomain?
Re: Let 'localhost' be localhost
#10Isn'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 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.
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.
Unnecessary restrictions can have unexpected & unknowable consequences. "Tools not policy".