These days, a system may have multiple interfaces, each with multiple addresses, and each address may even have multiple DNS entries associated with it. So what does a "system hostname" even mean?
Many applications will use the system hostname as a default identifier when they communicate elsewhere. For example, if you're collecting syslog messages at a central server, the messages will all be tagged with the hostname of the originating system. In an ideal world you would probably ignore this (because you don't necessarily want to trust the client), but the default behavior -- if you named all your systems "localhost" -- would result in a bunch of log messages that you wouldn't be able to associate with a specific system.
As other folks have pointed out, the system hostname is also a useful identifier if you find yourself remotely accessing a number of system. If you've got five windows attached to a systems named "localhost" then you're going to have a hard time keeping them straight.
In a similar vein, we try to make the system hostname matches the hostname we use for administrative access to a system. This helps avoid confusion when referring to the system (in email, conversations, documentation, etc).
Regarding DNS:
You want to have proper forward and reverse DNS entries for your applications in order to avoid confusion. You need some forward entry (name -> ip address) for people to be able to access your application conveniently. Having the reverse entry match is useful for an number of reasons -- for example, it helps you correctly identify the application if you find the corresponding ip address in a log.
Note that here I'm talking about "applications" and not "systems", because -- particularly with web servers -- it's common to have multiple ip addresses on a system, associated with different hostnames and services.
Trying to maintain name to ip mappings in your /etc/hosts file quickly becomes difficult as you manage an increasing number of systems. It's very easy to for the local hosts file to fall out of sync with respect to DNS, potentially leading to confusion and in some cases malfunction (because something tries to bind to an ip address that no longer exists on the system, for example).
Your hostname is the name of your computer.
Your fully qualified domain name is your hostname plus the domain your company uses often ending in .local.
So if the name of your computer is bob, and your company's domain is contoso.local, your computer's fully qualified domain name (FQDN) is bob.contoso.local.:
- Hostname:
bob
- Domain:
contoso.com
- FQDN:
bob.contoso.com.
In the case of a domain like contoso.local I did not use an "external" internet domain name. This name doesn't have to be the only way that you address the server.
If you make it available by its IP address you can use DNS or that IP address to allow external users to access it.
The dot at the end of the FQDN is used to indicate the empty top-level domain.
Some more information on DNS:
Edit: Thanks for the comment on .local domains RobM
Best Answer
hostnamereturns what you have configured the system to consider to be its hostname. There may be any number ofA/AAAArecords pointing to IP addresses associated with this system.That in itself is not abnormal. I would, however, expect an
A/AAAArecord for the name beginning withmaximusas well, as that appears to be the canonical name in your example.These are not conceptually the same but the expectation is that there is an overlap. Ie, if you have configured the system to consider
maximus.example.comto be its FQDN, there is an expectation that this name exists in DNS as well (possibly in addition to many other names).hostnamereturns what you have configured the system to consider its hostname (egmaximus).hostname -fwill return the former with the domain appended, forming the FQDN (egmaximus.example.com). The domain is often based on an entry in thehostsfile. Thehostcommand, if that is what you refer to, is a DNS-only tool.