8

I just bought a Linode VPS hosting plan and was following this guide to set up. In the "Setting the Hostname" section and "Update /etc/hosts " section, it says the FQDN/hostname to be set here does not need to be related with the websites I am about to host, which makes me confused.

I did my own research by reading lots of articles but am still not very sure what role the hostname/FQDN is playing in my web hosting business. Here are some basic facts I've managed to find out, feel free to correct me if anything wrong:

  1. FQDN must be something like xxx.somedomain.com, if "xxx." is omitted then it is not a FQDN.
  2. the xxx, which I think could be loosely called a subdomain, can also be referred to as "hostname", according to https://kb.iu.edu/d/aiuv.

  3. In my local machine, by adding the following line to the hosts file

    63.117.14.58 www.yahoo.com whatever

every network requests for "www.yahoo.com" or "whatever" will be redirected to IP address 63.117.14.58(which is google.com's IP). It is a way to block unwanted sites in local machine.

Now the tutorial suggests adding this line to the "hosts" file in my server

12.34.56.78(//my server's IP) myhostname.anything.com myhostname

It mentions that in the above line, domain name may or may not be the domain I am about to host, but the hostname should be the one I have already set during previous steps. My questions are:

1)Based on Facts#3, I think this line redirects any requests on the server for myhostname.anything.com or myhostname to my IP address, but what does this mean? Shouldn't any request for myhostname.anything.com from a user's computer already be translated to a certain IP address(Be it or not my IP address)? Why do I have to redirect it on my server? My understanding about how a HTTP request works is when user type in the domain name into the browser, the browser will contact the domain server, and the domain server will direct it to a DNS server based on the domain's DNS record, and then the DNS server will resolve the IP address, and then browser fetch data from that IP address. This procedure of my understanding seems having nothing to do with the "hosts" file on my server.

2) A.In regards of the FQDN, why the hostname has to be same with the hostname I set on my server and the domain name doesn't?

B.What will happen if I do set a different hostname here?

C.And what is the purpose to set or not set my domain name as the FQDN here?

D.And what will happen if I only set a FQDN but not the hostname? like this

12.34.56.78(//my server's IP) myhostname.anything.com

Lots of questions but I believe the answers to some of them are overlapped, and overall I think the big question is "What part does setting hostname/editting hosts file play in my webhosting business?"

Thank you for your time in advance.

shenkwen
  • 197
  • 2
  • 12

1 Answers1

15

It's going to be rough for people to answer this question because it starts with a simpler premise and proceeds to go down a deep rabbit hole from there. Let's start from the beginning.

Host file vs. DNS

I don't think this needs much explanation, so I'll keep it brief. The purpose of the hosts file is to define host to IP address mappings that do not rely upon DNS. The most important of these for a server is the device's own name, because it's silly for a problem with your DNS server to prevent your device from being able to refer to itself by name.

So long as we're only using host files, we don't need to use domains at all. DNS isn't involved, so who cares? Unfortunately as our network grows, it becomes less sustainable to have each device independently tracking the name of all devices on our network. That leads us to using DNS, and introduces some new logistical hurdles.

Hostname vs. FQDN

Hostnames are device names, or node names if you prefer. It's a uniquely identifying name that is meaningful to the device owner, and not necessarily meaningful or even exposed to people consuming the services on the device. This is what Linode means when it says that the name doesn't need to have anything to do with the services that you're hosting.

For example, let's say you own a company named Contoso, and you operate a website called example.com. The website is hosted on six machines, named dalek01 through dalek06. All the outside world needs to know is that they can get the website they want if they plug www.example.com into their web browser. Overly inquisitive Time Lords need not concern themselves with the fact that their request for www.example.com was serviced by dalek03.

By itself, a hostname doesn't necessarily have anything to do with DNS at all. It's just the name of the device, and it doesn't even necessarily have a domain suffix associated with it. So far it's simple!

Now we make things a little trickier. Story time!

  • Your company, Contoso, owns many desktop machines that communicate with the dalek cluster over a private network.
  • When there is a problem on one of the servers, you need to log into the specific device with the problem. We can't just connect to www.example.com, because it's hosted by several different machines. It's a good thing we have a uniquely identifying name for the server with a problem!
  • Since we have a large network of devices, it's most common for us to want to manage it with DNS. This means that we need to stick the hostnames dalek01 through dalek06 into a DNS domain somewhere. Fortunately we own contoso.com (named after our company), completely separate from www.example.com, which might be one of our customers.
  • Because the internet doesn't need to know our internal IP addresses, we maintain a private DNS domain called corp.contoso.com. All of our desktop machines are configured with a DNS search suffix of corp.contoso.com. This means that if we create a DNS entry called dalek01.corp.contoso.com, anyone on our network can get to that machine simply by connecting to dalek01 with their SSH client. Convenient!
  • dalek01 knows that it's called dalek01 because we put it in the hosts file. We want it to know that it's also called dalek01.corp.contoso.com, but we don't want it to rely on DNS to know its own name. That would be silly. Therefore we define an alias for dalek01.corp.contoso.com in the hosts file on dalek01 so that it knows all of its names.
  • In the meantime people continue to use www.example.com, oblivious to the fact that you have six servers named dalek01 through dalek06, the fact that your company is named Contoso (your customers aside), or that to make things convenient for your employees you created DNS records for dalek01 through dalek06.corp.contoso.com.

Putting it all together

  • Your hostname is meaningful to you and the people who run the server, not necessarily the people who use its services.
  • The hostnames need not be stored in DNS (or have a DNS domain at all) unless you own multiple devices sharing a private network.
  • It is silly for a server to rely upon DNS to talk to itself.
  • Putting your hostnames in DNS creates a need to also define that FQDN in your host file, so that it doesn't rely on DNS to talk to itself using the FQDN. (which as stated, would be silly)

Hopefully this covers all the bases.

Andrew B
  • 31,858
  • 12
  • 90
  • 128
  • 1
    +1 for the Timelord references! Oh, and great answer. :-) – Aaron Jan 05 '16 at 04:29
  • So, if I understand right, in the "hosts" file, it is a good practice to set the FQDN as the website I am about to host, otherwise the server would be "silly" for not knowing what it is when talking to itself. If so, then on what condition people will set a FQDN other than the website they are about to host? Also I am also confused about the hostname being unique. When referring to "unique", what namespace are we talking about? I can understand in your example, machines should have unique hostname like d01-d06, but I can't relate this to my scenario. – shenkwen Jan 05 '16 at 18:45
  • 1
    In the hosts file, I would put the hostname and the FQDN of the hostname (if applicable). The name of the website itself would be optional, but that's fine so long as you don't plan to host that website on multiple servers. RE: unique, the context is "unique to your company". My example was deliberately larger in scale than what you are operating so that you could see how the individual concepts end up relating to each other. Your confusion seemed to stem from not having enough context to understand why things are done this way, so the larger picture helps. – Andrew B Jan 05 '16 at 19:09
  • Thank you! I actually have nearly zero knowledge about linux server managing and just begun learning. I hadn't paid much attention to hostname/FQDN until I tried to install [virtualmin](https://www.virtualmin.com/download.html), a cPanel alternative, which says I need to make sure FQDN has been set before installing. I guess I should just set FQDN as my website in this case. – shenkwen Jan 06 '16 at 02:37
  • I start to get the idea. After I install webmin, I am able to access webmin page through browser by URL like `www.myFQDN.com:10000`, here `www.myfqdn.com` is not the website I am about to host but a way to address my remote linux machine from my local computer. – shenkwen Jan 08 '16 at 03:11
  • This answer would be perfect if you would also post what should be in `/etc/hostname` and `/etc/hosts` on dalek01, for example. – ernesto che May 06 '17 at 18:25
  • What would be a use case for a server e.g. dalek01 to know its FQDN ? In DNS domain names are used for keeping a hierarchy of authority, while these local self-FQDNs look like they are instead flat and can be set arbitrarily. – Alexander Gonchiy Sep 13 '21 at 13:40
  • @AlexanderGonchiy If building a small environment of your own, I agree - flat names are generally simpler and a FQDN for FQDN's sake brings no value. That said, many enterprise admins won't find themselves in that situation. It is common at many companies for server management interfaces to have their own DNS entry on a private network (in an internally facing DNS zone), and the domain component of a server's FQDN on such servers is often set to match its name in the internal zone. – Andrew B Sep 24 '21 at 23:39