Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On 2013-07-31 21:01:21 +0800, Thomas Goirand wrote: On 07/31/2013 06:47 PM, Vincent Lefevre wrote: But this wouldn't necessarily solve the mentioned problem anyway. I'm not sure there's a problem anyway. I'm on the side of Steve, which is I think the current setup works quite well. I agree. That's why I've put quotes. Our users can do a minimum of configuration, that's what I expect from anyone running a server/daemon anyway (things who are aimed at our users should be using localhost anyway). Or better, report a bug against the broken software. Otherwise different servers could require conflicting configurations! -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130801225405.ga12...@xvii.vinc17.org
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
]] Russ Allbery Matt Zagrabelny mzagr...@d.umn.edu writes: Does not the Wheezy installer still place hostname.domain.name entries in /etc/hosts for said hostname? We (Stanford) strip them out in FAI. We can, of course, continue to do that, but I thought I'd mention it as a data point. If you have stable DNS, you really don't want to have another shadow source of IP to host mapping on local disk; it's almost certain to cause you problems later. On most of my systems, I solve this by generating /etc/hosts from the host's primary (from ohai's point of view, that is, the one that will be picked for traffic sent to the default route) legacy IP address and IPv6 address. There are of course many ways to skin the cat, this is just mine. (And it gives me best of both worlds.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pptzusca@qurzaw.varnish-software.com
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On 07/31/2013 08:30 AM, Steve Langasek wrote: 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. He did wrote it. 127.0.1.1 breaks because some daemon (many, according to him) bind only on 127.0.0.1, and not 127.0.0.0/8 as they should. IMO, we'd better try to fix these, even if it might be a lot more work. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f8c0d5.2090...@debian.org
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On Wed, Jul 31, 2013 at 03:46:29PM +0800, Thomas Goirand wrote: On 07/31/2013 08:30 AM, Steve Langasek wrote: 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. He did wrote it. 127.0.1.1 breaks because some daemon (many, according to him) bind only on 127.0.0.1, and not 127.0.0.0/8 as they should. I disagree that this is a problem. If you are connecting to a loopback-only service, you should connect to it by the name localhost. If you are connecting to it by hostname, that implies that it's an outward-facing service - one that should be bound to all interfaces by default. Anything else is user / configuration error. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On Wed, 2013-07-31 at 15:46 +0800, Thomas Goirand wrote: On 07/31/2013 08:30 AM, Steve Langasek wrote: 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. He did wrote it. 127.0.1.1 breaks because some daemon (many, according to him) bind only on 127.0.0.1, and not 127.0.0.0/8 as they should. [...] You can't bind a server to an address range, and there's the problem. You have to listen on all addresses and then either immediately close remote connections after accepting them (e.g. using tcp-wrappers) or bind to device 'lo'. Both or which are more complex to implement and configure. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus signature.asc Description: This is a digitally signed message part
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
❦ 31 juillet 2013 09:46 CEST, Thomas Goirand z...@debian.org : 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. He did wrote it. 127.0.1.1 breaks because some daemon (many, according to him) bind only on 127.0.0.1, and not 127.0.0.0/8 as they should. How a daemon could bind to 127.0.0.0/8? bind() only takes an IP address. -- panic(aha1740.c); /* Goodbye */ 2.2.16 /usr/src/linux/drivers/scsi/aha1740.c signature.asc Description: PGP signature
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On 2013-07-31 15:46:29 +0800, Thomas Goirand wrote: On 07/31/2013 08:30 AM, Steve Langasek wrote: 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. He did wrote it. 127.0.1.1 breaks because some daemon (many, according to him) bind only on 127.0.0.1, and not 127.0.0.0/8 as they should. I disagree. If the goal is to accept connections for request to fqdn, then binding on 127.0.0.0/8 wouldn't be a solution, as it wouldn't work if the IP associated with fqdn is not a loopback one. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130731104330.ga24...@xvii.vinc17.org
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On 2013-07-31 11:00:24 +0200, Vincent Bernat wrote: ❦ 31 juillet 2013 09:46 CEST, Thomas Goirand z...@debian.org : He did wrote it. 127.0.1.1 breaks because some daemon (many, according to him) bind only on 127.0.0.1, and not 127.0.0.0/8 as they should. How a daemon could bind to 127.0.0.0/8? bind() only takes an IP address. Perhaps Thomas actually meant accept any address, then drop those outside 127.0.0.0/8? But this wouldn't necessarily solve the mentioned problem anyway. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130731104747.gb24...@xvii.vinc17.org
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On Tue, 2013-07-30 at 23:09 +0100, Ulrich Dangel wrote: If you are in a situation with no stable DNS you can use libnss-myhostname which resolves the hostname to your local configured IP addresses or 127.0.1.1 ::1 if no IP address is configured. Yeah... but this doesn't change the problem that 127.0.1.1. is used... Some technical reasons against my own proposal: 1) I had some off list communication with Thomas Hood in the meantime and one (strong?) reason back then apparently was, that cyclic resolution wouldn't work anymore if both, localhost and the hostname point to 127.0.0.1, e.g. /etc/hosts: 127.0.0.1 localhost 127.0.0.1 hostname[.domainhostname] If you now resolve hostname you get 127.0.0.1, if you reverse-resolve that, you get localhost (and not hostname). Surely this is the case, an Thomas meant it caused many troubles... I tried it, and so far I couldn't find a program which couldn't deal with that (but obviously I only made a few tests). And there is not really any guarantee by the concepts of DNS, that this cyclic resolving will work. So if a daemon makes this assumption it is anyway kinda broken IMHO. The only major example I know where this is used in a sense are mailservers. 2) hosts(5) (also pointed out by Thomas): This file is a simple text file that associates IP addresses with hostnames, one line per IP address. So that would mean that double entries like I proposed were forbidden anyway. I used this however since many years and never found a case where it didn't work. Even things like bash's completion seem to happily work with multiple associations for one address. Not sure if that text line in the manpage is just a relict from the past. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On Wed, 2013-07-31 at 01:30 +0100, Steve Langasek wrote: 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. You even extracted it yourself from my text: - 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. Well why not? Imagine that one server in a cluster serves a debian package repo (e.g. via http)... I have a common sources.list which all point to deb http://somehost.foo/debian main I don't want to make exceptions for the host itself, and have to change it http://localhost/debian there. So the only ways around would be: - set the hostname to the global IP - has several drawbacks as I described originally - let the webserver listen as well on 127.0.1.1,... sure that works but it's rather ugly to make such special handling... and not all services are even able to bind to multiple addresses. - 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. Not sure... IIRC, the installer currently asks, for a static IP, right? And sets this in /etc/hosts for the hostname. As I wrote in (II), experience has shown that that can break more easily than it always being resolved to 127.x.x.x 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. Yeah,... I realised that, too, in the meantime,... but well... I think at least from the DNS side there is no guarantee that this should work. So if you have no hostname set at all in /etc/hosts and let DNS handle this... there is no guarantee that the domain name and reverse entry correspond. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On Wed, 2013-07-31 at 12:47 +0200, Vincent Lefevre wrote: Perhaps Thomas actually meant accept any address, then drop those outside 127.0.0.0/8? That seems really ugly and error prone IMHO. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On 07/31/2013 06:47 PM, Vincent Lefevre wrote: On 2013-07-31 11:00:24 +0200, Vincent Bernat wrote: ❦ 31 juillet 2013 09:46 CEST, Thomas Goirand z...@debian.org : He did wrote it. 127.0.1.1 breaks because some daemon (many, according to him) bind only on 127.0.0.1, and not 127.0.0.0/8 as they should. How a daemon could bind to 127.0.0.0/8? bind() only takes an IP address. Perhaps Thomas actually meant accept any address, then drop those outside 127.0.0.0/8? Correct. But this wouldn't necessarily solve the mentioned problem anyway. I'm not sure there's a problem anyway. I'm on the side of Steve, which is I think the current setup works quite well. Our users can do a minimum of configuration, that's what I expect from anyone running a server/daemon anyway (things who are aimed at our users should be using localhost anyway). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f90aa1.70...@debian.org
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On Tue, 2013-07-30 at 23:15 +0100, Simon McVittie wrote: libnss-myhostname is basically this, and is packaged. It tries to return a public address if possible, only falling back to 127.0.0.2 (upstream), 127.0.1.1 (as patched in Debian) or ::1 (IPv6) if there's nothing more suitable. Sounds nice and as Josh said, why not using it per default? But it wouldn't change the annoyance I was mainly talking about, namely that a non-127.0.0.1 is used. I would be inclined to install libnss-myhostname by default, since it's the 99% solution. People who feel strongly about this sort of thing can uninstall or disable it, and apply whatever manual configuration they want to. Does it first try to determine a global IP, or does it always give 127.x.x.x respectively ::1? I think `getent hosts 127.0.0.1` should always return localhost and `getent hosts localhost` should always return 127.0.0.1 (and possibly also ::1, I'm not sure about that part). I wouldn't have any particular objection to `getent host mymachine` returning 127.0.0.1 *as well* if it makes things work better. If that doesn't break any things... and libnss-myhostname can be made doing that... that would sound the ideal solution to me. [citation needed] for most people - hard-coding a non-loopback IP address is never going to work for a laptop that's used in multiple locations, and I hear those are quite popular these days :-) Sure,... but there are still non-laptops/tablets... and Debian want's to be the universal OS ;-) And as I said, I've seen several weird services which don't work when the hostname doesn't point to the global IP,... of course this is their fault and they are especially quite severely broken in multi-homed setups... but things are as they are and these services probably won't change anytime soon. I suspect it might be quite common in Java apps developed on Windows. Hehe... you hit the point ;-) But dCache is at least not developed in Windows :) I think whether this is viable depends whether your networking is basically static or dynamic. If your networking is basically static (a typical server), almost anything is acceptable, because you won't have to change it very often in any case. If your networking is basically dynamic (a typical laptop), then hostname-to-IP-address configuration will have to be either automatic, loopback-based, or usually broken. Sure... but usually you don't run all too much such services on a laptop anyway. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On Wed, Jul 31, 2013 at 3:01 PM, Thomas Goirand z...@debian.org wrote: On 07/31/2013 06:47 PM, Vincent Lefevre wrote: On 2013-07-31 11:00:24 +0200, Vincent Bernat wrote: ❦ 31 juillet 2013 09:46 CEST, Thomas Goirand z...@debian.org : He did wrote it. 127.0.1.1 breaks because some daemon (many, according to him) bind only on 127.0.0.1, and not 127.0.0.0/8 as they should. How a daemon could bind to 127.0.0.0/8? bind() only takes an IP address. Perhaps Thomas actually meant accept any address, then drop those outside 127.0.0.0/8? Correct. Using SO_BINDTODEVICE ? Does it is limited to root (some time ago it was limited to root but now no mention on man 7 socket). BTW how to detect unsafe usage of 127.0.0.1 ? codesearch of INADDR_LOOPBACK is inconclusive. But this wouldn't necessarily solve the mentioned problem anyway. I'm not sure there's a problem anyway. I'm on the side of Steve, which is I think the current setup works quite well. Our users can do a minimum of configuration, that's what I expect from anyone running a server/daemon anyway (things who are aimed at our users should be using localhost anyway). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f90aa1.70...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAE2SPAbdsonr5G39M_PPN8gm8HOX_cwkaG_uvFhjLaaJ=es...@mail.gmail.com
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On 30-07-13 22:57, Russ Allbery wrote: Christoph Anton Mitterer cales...@scientia.net writes: - 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.) This principal (and the general UNIX tradition of putting the local host and IP address in /etc/hosts) has caused us no end of problems, since that information inevitably gets out of date when systems are moved around or re-IP'd. We now do not put the local hostname anywhere in /etc/hosts, and I believe that's the correct configuration for any system with stable DNS and network. Agreed; however, for mobile systems, assuming stable networking (or even the existence of any networking at all) is just plain wrong; and since there are very good reasons why ping $(hostname) and similar things should work, I think at least a single line with the local hostname should be in /etc/hosts. I think using 127.0.1.1 is a bad idea; I wasn't part of the original discussion, but I've only ever seen problems with it, and I never understood why we switched to that in the first place. The right way, in my opinion, is that /etc/hosts should look like this: 127.0.0.1 localhost 127.0.0.1 hostname.domain hostname or, alternatively: 127.0.0.1 hostname.domain hostnamelocalhost both make hostname output the hostname as specified in /etc/hostname, and hostname --fqdn output the FQDN. It also doesn't result in any problems with IP address changes in my experience, since 127.0.0.1 should always be correct; the only exception is when the hostname is actually _changed_, but then you have to change other files anyway (/etc/hostname, for instance), so at that point it shouldn't matter too much. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f927a1.3050...@debian.org
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On Wed, 2013-07-31 at 01:30 +0100, Steve Langasek wrote: That's correct. If you want to talk to a loopback-only service, you should be connecting to 'localhost', *not* to the hostname. [Christoph Anton Mitterer] Well why not? Imagine that one server in a cluster serves a debian package repo (e.g. via http)... That doesn't sound like a loopback-only service at all. - let the webserver listen as well on 127.0.1.1,... sure that works but it's rather ugly to make such special handling... and not all services are even able to bind to multiple addresses. Special handling? No, I'm pretty sure the default for all web servers in Debian is to listen on INADDR_ANY. That's not special handling at all. Special handling would be to listen on 11.22.33.44 and 127.0.0.1 specifically. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130731214229.ga6...@p12n.org
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
Christoph Anton Mitterer cales...@scientia.net writes: - 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.) This principal (and the general UNIX tradition of putting the local host and IP address in /etc/hosts) has caused us no end of problems, since that information inevitably gets out of date when systems are moved around or re-IP'd. We now do not put the local hostname anywhere in /etc/hosts, and I believe that's the correct configuration for any system with stable DNS and network. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y58n4vge@windlord.stanford.edu
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On Tue, Jul 30, 2013 at 3:57 PM, Russ Allbery r...@debian.org wrote: Christoph Anton Mitterer cales...@scientia.net writes: - 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.) This principal (and the general UNIX tradition of putting the local host and IP address in /etc/hosts) has caused us no end of problems, since that information inevitably gets out of date when systems are moved around or re-IP'd. We now do not put the local hostname anywhere in /etc/hosts, and I believe that's the correct configuration for any system with stable DNS and network. Russ, Does not the Wheezy installer still place hostname.domain.name entries in /etc/hosts for said hostname? Or do you mean some entity other than Debian when you say, we, or is now after the Wheezy release? Cheers, -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3vaz9x-xz4mruhmb_q6sjbndzgx7kedkownhvklhmq...@mail.gmail.com
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
Matt Zagrabelny mzagr...@d.umn.edu writes: Does not the Wheezy installer still place hostname.domain.name entries in /etc/hosts for said hostname? We (Stanford) strip them out in FAI. We can, of course, continue to do that, but I thought I'd mention it as a data point. If you have stable DNS, you really don't want to have another shadow source of IP to host mapping on local disk; it's almost certain to cause you problems later. Or do you mean some entity other than Debian when you say, we Yes, sorry. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fvuv4u63@windlord.stanford.edu
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On Tue, 2013-07-30 at 14:25 -0700, Russ Allbery wrote: We (Stanford) strip them out in FAI. We can, of course, continue to do that, but I thought I'd mention it as a data point. If you have stable DNS, you really don't want to have another shadow source of IP to host mapping on local disk; it's almost certain to cause you problems later. Well so long you have services, which depend on the host resolving to it's local address (whatever that is)... it think it can have security impacts if you leave that information up to some other server (e.g. your DHCP). Consider an application which only accept packets originating from hostname as a security measure.. if the DNS server goes evil... than that might be used by an attacker. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
Christoph Anton Mitterer cales...@scientia.net writes: On Tue, 2013-07-30 at 14:25 -0700, Russ Allbery wrote: We (Stanford) strip them out in FAI. We can, of course, continue to do that, but I thought I'd mention it as a data point. If you have stable DNS, you really don't want to have another shadow source of IP to host mapping on local disk; it's almost certain to cause you problems later. Well so long you have services, which depend on the host resolving to it's local address (whatever that is)... ...it will break horribly when you have an IP address in /etc/hosts that's no longer the host's IP address. Which is the point. it think it can have security impacts if you leave that information up to some other server (e.g. your DHCP). If you trust DNS, you trust DNS. If you don't trust DNS, putting the local host's IP address in /etc/hosts is just the start of your remediation. You had better also put in every other host that host cares about, and you generally have a much more comprehensive problem. Putting the local hostname into /etc/hosts is neither necessary nor sufficient, and therefore basically useless. Consider an application which only accept packets originating from hostname as a security measure.. if the DNS server goes evil... than that might be used by an attacker. And this static file will not help you in the slightest against that attack, since no host is only going to accept packets from itself, and the attacker can just spoof one of those other possible source hostnames. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehaf3dqv@windlord.stanford.edu
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On 30/07/13 21:43, Christoph Anton Mitterer wrote: - Back then, Thomas pointed out several ides on who the resolution could be done (e.g. with a small nsswitch module) libnss-myhostname is basically this, and is packaged. It tries to return a public address if possible, only falling back to 127.0.0.2 (upstream), 127.0.1.1 (as patched in Debian) or ::1 (IPv6) if there's nothing more suitable. Possibly it ought to try RFC1918 addresses before 127.x.y.z, or ought to fall back to 127.0.0.1 instead; I'm sure there are valid arguments each way. I would be inclined to install libnss-myhostname by default, since it's the 99% solution. People who feel strongly about this sort of thing can uninstall or disable it, and apply whatever manual configuration they want to. 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 think `getent hosts 127.0.0.1` should always return localhost and `getent hosts localhost` should always return 127.0.0.1 (and possibly also ::1, I'm not sure about that part). I wouldn't have any particular objection to `getent host mymachine` returning 127.0.0.1 *as well* if it makes things work better. Should the hostname point to a static IP address (or better said an address that is not the loopback)? Most people set the static IP address of a system for their hostname e.g. 127.0.0.1 localhost 66.66.66.66 foobar[.bar.net foobar] [citation needed] for most people - hard-coding a non-loopback IP address is never going to work for a laptop that's used in multiple locations, and I hear those are quite popular these days :-) I must say though, that I have meet several programs which do some weird ways of interface discovery, and these will break when one doesn't set the global IP address. The problem with such is that they don't let you configure the bind address, but always use the hostname to detect it. I suspect it might be quite common in Java apps developed on Windows. InetAddress.getLocalhost() does approximately the same as libnss-myhostname on Windows, so people who primarily test on Windows will tend to assume that InetAddress.getLocalhost() is the right thing (or at least not entirely useless); but on Linux it looks up gethostname() in DNS. Minecraft had this bug, resulting in it listening on 127.0.1.1 on Debian for a while. I would argue that servers intending to listen on externally-accessible addresses should default to listening on 0.0.0.0 and letting the kernel do the work - that way, they'll continue to work correctly if you roam from wired to wifi to 3G or whatever, or if you start them when you didn't yet have an IP address at all. Applications that really need to know about individual IP addresses can't safely make the assumption that you have exactly one non-loopback IP address (because it has never been true in general), and should use netlink. Now some people may argue, that they conveniently use the feature of some programs, which allow to configure the bind addresses via hostnames. If the address changes, you just adapt /etc/hosts,... and all these services will automatically pick it up (at the next start). I think whether this is viable depends whether your networking is basically static or dynamic. If your networking is basically static (a typical server), almost anything is acceptable, because you won't have to change it very often in any case. If your networking is basically dynamic (a typical laptop), then hostname-to-IP-address configuration will have to be either automatic, loopback-based, or usually broken. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f83b03.10...@debian.org
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
* Russ Allbery wrote [30.07.13 22:25]: We (Stanford) strip them out in FAI. We can, of course, continue to do that, but I thought I'd mention it as a data point. If you have stable DNS, you really don't want to have another shadow source of IP to host mapping on local disk; it's almost certain to cause you problems later. If you are in a situation with no stable DNS you can use libnss-myhostname which resolves the hostname to your local configured IP addresses or 127.0.1.1 ::1 if no IP address is configured. Ulrich -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130730220945.GB19874@shell
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
On 30/07/13 22:54, Christoph Anton Mitterer wrote: Consider an application which only accept packets originating from hostname as a security measure.. If you only want to accept packets from yourself, use 127.0.0.1 (or ::1, or a Unix socket). Anything else has more possible failure modes. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f83b98.8050...@debian.org
Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1
Simon McVittie wrote: On 30/07/13 21:43, Christoph Anton Mitterer wrote: - Back then, Thomas pointed out several ides on who the resolution could be done (e.g. with a small nsswitch module) libnss-myhostname is basically this, and is packaged. It tries to return a public address if possible, only falling back to 127.0.0.2 (upstream), 127.0.1.1 (as patched in Debian) or ::1 (IPv6) if there's nothing more suitable. Possibly it ought to try RFC1918 addresses before 127.x.y.z, or ought to fall back to 127.0.0.1 instead; I'm sure there are valid arguments each way. I would be inclined to install libnss-myhostname by default, since it's the 99% solution. People who feel strongly about this sort of thing can uninstall or disable it, and apply whatever manual configuration they want to. I'd like to see this as well (with a corresponding change to the installer to stop putting an entry for the hostname in /etc/hosts). This would get us one step closer to having the hostname configured in only *one* place (namely, /etc/hostname). With dhclient fixed to detect the hostname at runtime, I think nss-myhostname is the last step required before hostname changes become a one-step process of editing /etc/hostname. Note that /etc/hosts will still take precedence over nss-myhostname if it specifies a name for the local system, so you can trivially override nss-myhostname with or without uninstalling it. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130731014035.GA8425@leaf
