Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

So I understand that the hostname should (at least in Debian systems) be set in /etc/hostname. To get the FQDN (through hostname -f) the system finds the IP from the hostname through /etc/hosts and then returns the first entry in the line.

So if the hostname is server1 and this is in /etc/hosts:

192.0.2.1    server1.example.com    server1

It will return server1.example.com. So this is how it is desribed on many websites. But I was thinking: Why not assign the hostname to the loopback address? Like you do with localhost:

127.0.0.1    server1.example.com    server1    localhost

With this approach you don't have to know the external IP address. Also, applications that might use the FQDN will make the requests directly on the system instead of going through the network.

So, why not do it like this? Why are most examples on the internet using the external IP address?

share|improve this question

2 Answers 2

It could be a bad idea, for several reasons

  • if you do have an ip (and communicate to other hosts), its highly recommended to put the hostname in front of the externally known ip.

    • Some protocols could say "tell the other guy your hostname and its ip address" "ok. Other guy, i'm foo.localnetwork(127.0.0.1)". The other guy will receive this packet with, at the IP level the external IP, but at the Protocol level, the 127.0.0.1 IP, so it could have a hard time to exchange if that protocol needs to use the advertised info instead of the IP level ones (SIP, for example, is likely to be problematic with this...)

    • Additionnaly some services bind only on the interface holding the ip associated to the hostname and therefore those services will only be able to talk with the host, via loopback device, no-one else...

share|improve this answer
    
Do you know of any real-world cases where "tell the other guy your hostname" is a problem? Wouldn't the socket reveal the addresses at each end? Wouldn't multhoming / multiple addresses cause problems in this case as well? –  Gerald Combs Jun 10 at 16:51
    
I remember SIP protocols causing all sort of problems with NAT between hosts in different WAN when the advertised adress needed to be the one NAT'ed to instead of the originator's IP (STUN could help). I believe (but can't be sure) it would cause problems if it advertise the loopback's ip instead of the host's ip while talking to other hosts on the same LAN. And I trust other protocols could be even more flaky (don't know whicn ones though). iow, it could cause problems "in some cases" (for an unknown range or even nature of cases...) –  Olivier Dulac Jun 11 at 9:15
1  
I ran into the second case this morning. Configured a server to listen to the IP address given by its fully qualified domain name on a particular port, then tested the connection using telnet, then told a remote collaborator that the server was up and running. He couldn't connect. It turns out neither the server software nor telnet do a DNS lookup: both resolve to 127.0.1.1, so my telnet command was connecting, but no remote connections were possible. –  reinierpost Aug 8 at 12:23

This is the default at least on new ubuntu releases.

Here is mine

127.0.0.1 localhost.localdomain localhost 127.0.1.1 sprinkler.internal.lan sprinkler

It is not problematic in any way and in fact has the bonus efect of not needeng a working dns for some operations.

I personally tend to add few more entries like local apt repo, some builders etc.

share|improve this answer
    
Ok, I wonder then, why do most examples use the external IP? Are there cases it might be more desirable? –  rednaw Jun 10 at 13:11
    
It could be a bad idea, if you do have an ip (and communicate to other hosts). Some protocols could say "tell the other guy your hostname and its ip adress" "ok. Other guy, i'm sprinkler.internal.lan(127.0.0.1)". Additionnaly some services bind only on the interface holding the ip associated to the hostname and therefore will only be able to talk with the host, noone else... –  Olivier Dulac Jun 10 at 16:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.