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
I would choose a consistent approach across the entire environment. Both solutions work fine and will remain compatible with most applications. There is a difference in manageability, though.
I go with the short name as the HOSTNAME setting, and set the FQDN as the first column in /etc/hosts
for the server's IP, followed by the short name.
I have not encountered many software packages that enforce or display a preference between the two. I find the short name to be cleaner for some applications, specifically logging. Maybe I've been unlucky in seeing internal domains like server.northside.chicago.rizzomanufacturing.com
. Who wants to see that in the logs or a shell prompt?
Sometimes, I'm involved in company acquisitions or restructuring where internal domains and/or subdomains change. I like using the short hostname in these cases because logging, kickstarts, printing, systems monitoring, etc. do not need full reconfiguration to account for the new domain names.
A typical RHEL/CentOS server setup for a server named "rizzo" with internal domain "ifp.com", would look like:
/etc/sysconfig/network:
HOSTNAME=rizzo
...
-
/etc/hosts:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
172.16.100.13 rizzo.ifp.com rizzo
-
[root@rizzo ~]# hostname
rizzo
-
/var/log/messages snippet:
Dec 15 10:10:13 rizzo proftpd[19675]: 172.16.100.13 (::ffff:206.15.236.182[::ffff:206.15.236.182]) - Preparing to
chroot to directory '/app/upload/GREEK'
Dec 15 10:10:51 rizzo proftpd[20660]: 172.16.100.13 (::ffff:12.28.170.2[::ffff:12.28.170.2]) - FTP session opened.
Dec 15 10:10:51 rizzo proftpd[20660]: 172.16.100.13 (::ffff:12.28.170.2[::ffff:12.28.170.2]) - Preparing to chroot
to directory '/app/upload/ftp/SRRID'
Best Answer
Like EEAA said, you can put in basically whatever you want.
That said, I do recommend having some kind of naming strategy for your hosts. Even if you only have a single VPS currently, it's not at all unheard of to grow systems horizontally over time, or to split services that were once co-located on a single server onto different servers.
Such a naming scheme can be as fancy or as boring as you like. You could use for example names of games (
soccer
,chess
, ...), astronomical objects (proxima-centauri
,saturn
, ...), cities, species of animal, or just technical names that directly reflect the function of the particular host (such asns2
ormail1
). If the people you work for lack humor, I recommend purely technical names, or even a simple sequential scheme (to my knowledge, nobody ever got fired for naming a systemserver04
).I also strongly suggest putting the names under a domain name under your control. It's not actually a requirement, but doing so will save you from many headaches in the future. Then add whatever names you come up with to that domain name in DNS.
So if you have registered
example.com
then you might put inluna.example.com
orchess.example.com
or whatever else strikes your fancy.You should strive to pick names that are unlikely to conflict with any public names you might reasonably want to use in the future which aren't guaranteed to be served by this particular host for as long as this particular host exists.
You can then configure the software running on that host to serve content for any host name of your choosing, and publish any host name of your choosing. Just because the physical (or in this case, virtual) host is known by an astronomical name doesn't mean you can't serve
www.example.com
off it.