About system host names

19 05 | 2011

Written by Tanguy

Classified in : Homepage, Debian, Miscellaneous, To remember

The host name

On Unix systems, the host name is kept in memory by the kernel: it is set and get by the sethostname() and gethostname() functions and their command-line wrapper hostname(1). It can be used by several programs, for instance by the mail server to determine what it should use as its HELO name.

In fact, the host name has two forms: the short one and the fully qualified one. For instance, a host can have muscadet as its short name muscadet and muscadet.example.com as its fully qualified one. From these two forms, a third information can be deduced: the domain name, which is the full name without its first component.

The system host name can be set as either the short name or the fully qualified name. When the full name is used, the short one can be easily deduced, by keeping only its first component. When the short name is used, the full name must be determined by using a more complex heuristic that takes more time and can fail for several reasons.

Determining the short and the fully qualified host name

The command hostname(1) is able to give both the short and the full host name, and also the domain name that can be deduced from them:

-s, --short: Display the short host name. This is the host name cut at the first dot.
-f, --fqdn, --long: Display the FQDN (Fully Qualified Domain Name). A FQDN consists of a short host name and the DNS domain name.
-d, --domain: Display the name of the DNS domain.

Now, given that the kernel only maintains a single host name, this command and the corresponding functions are using heuristics to determine these two forms. I did not look to the code, but here is what I have deduced:

if you have set your system host name to the fully qualified one, it deduces the short one by taking only its first component;
if you have set your system host name to the short one, it deduces the full one by resolving it to an IP address, then resolving it back to a host name: this may use /etc/hosts, the DNS or a more exotic name system depending on your configuration.

The second option, when the kernel only knows the short host name, seems rather inferior, as it uses a more complex algorithm which takes more time (if it uses the DNS, it can use much more time than a fully local query) and can fail for several reasons.

Setting the host name

With Debian, the host name is stored in the file /etc/hostname and set at boot time by the hostname.sh init script. The local hosts table /etc/hosts also contains it, in both forms, for a loopback IPv4 address 127.0.1.1. It is asked at installation time: the most common practice is to give the short host name; you are then asked for the domain name. But you have the option to give the fully qualified domain name, which has the effect to skip the domain name question.

Using a fully qualified system host name

I used to define short system host names, and I switched to fully qualified ones about a year ago. I saw no drawback, but I did see benefits. Postfix, by default, uses the system host name to determine its variables myhostname and mydomain that are used for stuff like the HELO name and the mail domain name. Well, with a short system host name, it fails, and you get default myhostname = muscadet.localdomain and mydomain = localdomain, so you have to set them explicitly in its configuration file, thus duplicating information. Whereas with a fully qualified system host name, it just works, and you can rely on the default values, that will stay in sync if you have to change you host name.

To sum up, it is perfectly possible to use a fully qualified name as the system host name, even though it does not seem to be a common practice. In fact, according to my experience, it is even advisable, as it eases the configuration of programs that rely on the host name, such as mail servers.

Edit: As noticed by Javi, the hostname(1) manpage ends by saying without explaination that /etc/hostname should contain the short host name and not the full one. There may by some drawbacks by doing so but I was not able not identify them.

Tags : hostname, FQDN, DNS, mailserver, muscadet, configuration, Debian, Unix

15 comments

thursday 19 may 2011 à 21:43 Javi said : #1

Why in hostname manpage is written that is not a good idea having fqdn in /etc/hostname ?

Thanks !

thursday 19 may 2011 à 22:11 Tanguy said : #2

@Javi: Good point. No idea, I did not see this warning. All that I can say is that, for what I have experienced, having the FQDN gives better results. And that it must be supported in some ways given that the Debian installer acknowledges it by skipping the domain name prompt.

friday 20 may 2011 à 00:45 Ryukage said : #3

(Speaking as a user with some knowledge of IETF standards but no real knowledge of the inner workings of the software except what I've gleaned through troubleshooting the following issue,) I've found that having an FQDN in /etc/hostname can cause problems with DHCP. Most DHCP servers supply an FQDN along with the IP address, created by tacking a constant domain onto the hostname supplied by the client. The hostname(1) command doesn't seem to be aware of FQDNs supplied by DHCP, and dhclient seems to send everything in /etc/hostname to the DHCP server as the *short* hostname. This can result in the domain being doubled, and/or the DNS (updated by the DHCP server) disagreeing with the local system over the system's FQDN. Home routers supplied by cable and telcos tend to be especially brain-damaged and easily confused in this regard (at least in the USA), as do public WiFi hotspots. Retail routers are only marginally better.

BTW, on my system "hostname -f" only prints the short hostname ("hostname -d" prints nothing), as does the bash prompt, but ssh, dig, host, and everything else seems to be able to discover the FQDN in spite of this, so I'm not sure gethostname() is actually being used by anything. I'm using Kubuntu, but I don't imagine this part of the stack has diverged much. IIRC, during the time I had an FQDN in /etc/hostname, "hostname -s" printed the FQDN and "hostname -d" still printed nothing (and DNS utils like dig and host printed a doubled domain). That was a while ago, however, so I may not be remembering correctly. What I do remember clearly is that having an FQDN in /etc/hostname was not compatible with the default dhclient config.

friday 20 may 2011 à 00:51 M said : #4

"The local hosts table /etc/hosts also contains it, in both forms, for the loopback IPv4 address 127.0.0.1"

Really? My Debian system gives

127.0.0.1 localhost
nn.nn.nn.nn hostname.example.com hostname

At least in the past, some things would break with this configuration that you suggest:
127.0.0.1 localhost hostname.example.com hostname

friday 20 may 2011 à 01:45 sime said : #5

If the manpage suggests using short name, it's good enough for me.

Good discussion though.

friday 20 may 2011 à 05:21 jerry said : #6

http://bugs.debian.org/626292

friday 20 may 2011 à 08:07 Vincent Bernat said : #7

Using FQDN as host name still implies looking up for the name in "hosts" table (and then a DNS request depending on your configuration). strace hostname -f shows that the libc resolver is called (/etc/hosts is read).

To get the fully qualified name of a host, programs usually do something like this: "getent hosts $(uname -n)".

On the other hand, "uname -n" should return a node name which is usually a short name because the length of this field may be limited in size (8 bytes for old systems, 64 bytes on recent Linux).

Also note that most programs wait for a short name with "uname -n". If they want a short name, taking the first component is usually an heuristic because this is not always the way to go. A short hostname like "www01.prod" is perfectly valid with "ndots" set to 2.

friday 20 may 2011 à 08:42 Tanguy said : #8

@M: Indeed, I made a mistake, the host name is usually associated with another loopback address, 127.0.1.1.

@Vincent: Strange: I made several tests and when using the FQDN as the hostname, hostname -f returns if even if no resolution can return it.

friday 20 may 2011 à 08:52 Jon said : #9

dhclient should probably use gethostname() rather than read /etc/hostname itself.

friday 20 may 2011 à 10:18 Javi said : #10

OpenOffice can have issues if not fqdn is set in your hostname and your dns doesn't resolve yourmachine.(local) in a short time period

See:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619968

How it the correct network configuration in this specific case ?

Thanks!

friday 20 may 2011 à 18:38 Albert said : #11

I agree - I have switched from using short host names in /etc/hostname to using a fqdn and also saw benefits, such as playing nicely with Postfix as you mentioned, but also when setting up Puppet.

I have not seen any drawbacks to using fqdn in /etc/hostname.

friday 20 may 2011 à 18:40 Bruce said : #12

hostname != fqdn
hostname != domain name

hostname.domain.name = DNS name

saturday 21 may 2011 à 00:30 Fernando said : #13

Put the hostname in /etc/hostname. Put 127.0.1.1 name.domain name in /etc/hosts. Now hostname -s will say hostname, and hostname -d will say domain. This is the right approach, I believe.

saturday 21 may 2011 à 07:09 Vincent Bernat said : #14

@Tanguy: a common fallback (and used with hostname) is to just use "uname -n". This explains why this works despite the absence of answers from the resolver.

saturday 21 may 2011 à 15:06 mirabilos said : #15

The hostname manpage on GNU is simply broken. Many OSes seem to think you use the short name and then use the domainname command for the suffix, but that’s wrong – the domainname command is for NIS/YP only. The correct thing is to use the FQDN (foo.bar.com) as hostname, and use either:

127.0.0.1 foo.bar.com foo localhost

or:

127.0.0.1 localhost
1.2.3.4 foo.bar.com foo

as /etc/hosts, depending on whether you have a static (second) or dynamic (first example) primary IPv4 address. (Using 127.0.1.1 will also spectacularily fail in some cases.)

The only drawback I identified so far is the kdm login window in squeeze/sid – but then, the text is too wide for it even when using the short hostname, so why bother? That’s cosmetic after all, and clearly a bug in the theming.

Rss feed of the article's comments

Tanguy Ortolo