On Tue, Jul 30, 2013 at 10:43:44PM +0200, Christoph Anton Mitterer wrote: > Somme years ago Thomas Hood started a discussion[0] about how the system > hostname should be resolved. > The eventual result[1] was that Debian nowadays ships /etc/hosts like > these per default: > 127.0.0.1 localhost > 127.0.1.1 <host_name>.<domain_name> <host_name> > As also described in the Debian reference[2]. > I had a short mail conversation with Thomas and he proposed bringing up > the following at d-d. > Some background: <snip> What I'm missing your email is a problem statement explaining what it is you're trying to solve. The current implementation has been working reliably for years. If it ain't broke, don't fix it. > - The hostname is not necessarily a domain name, at least not de jure. > But in reality, many programs and people rely or are at least used to to > the hostname being resolvable. > That practise won't change and we cannot do much about it. And we don't need to. The current implementation handles this. > - Most applications that listen to the loopback actually only listen to > 127.0.0.1 (and perhaps ::1) but often not to 127.0.0.0/8. That's correct. If you want to talk to a loopback-only service, you should be connecting to 'localhost', *not* to the hostname. You don't want a server to resolve its hostname to somewhere other than where all the other machines on the network will resolve it. > - The system hostname (and domainname if any) should ALWAYS be > resolvable, whether a network is up or not, regardless of which. > (Assuming that lo is always up, if not, many things break anyway.) The current implementation assures this. > - The current way of having > 127.0.1.1 <host_name>.<domain_name> <host_name> > i.e. the hostname resolving to 127.0.1.1 leads to some issues, > especially that you cannot reach those services that bind to 127.0.0.1 > only. > It also doesn't point to ::1. If the service binds to 127.0.0.1 only, it should be asked by the name 'localhost'. > I) Switch the <host_name>.<domain_name> <host_name> to 127.0.0.1 unless > there is any strong reason to have it on another address. > I made some tests: > /etc/hosts (or the same entries swapped): > 127.0.0.1 localhost > 127.0.0.1 foobar > or (or the same entries swapped: > 127.0.0.1 localhost > 127.0.0.1 foobar.bar.net foobar > or (or the same entries swapped: > 127.0.0.1 localhost localdomain.localhost > 127.0.0.1 foobar.bar.net foobar > all lead to the desired results > $ hostname > foobar > $ hostname -f > foobar respectively foobar.bar.net > $ hostname -d > <nothing> respectively bar.net > even hostname -a works as it should. > So the only thing that needs to be secured for the correct resolution is > that we don't mix up the localhost line with the foobar line. > And the order of the line's entries is important, e.g. it must be: > 127.0.0.1 foobar.bar.net foobar > not > 127.0.0.1 foobar foobar.bar.net > The only question open here is, whether we generate: > 127.0.0.1 localhost > 127.0.0.1 foobar[.bar.net foobar] > or > 127.0.0.1 foobar[.bar.net foobar] > 127.0.0.1 localhost > This controls what reverse resolution leads to (e.g. what tools like > netstat show). > I personally would take the first ordering,... since one sees localhost > then which usually makes it really clear what happens. You have overlooked the fact that only one of these can be the canonical hostname of 127.0.0.1, and having the hostname and localhost canonicalize to each other causes problems. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature