Hoping for some advice

Most of our droplets are for fairly small individual client websites, usually 1 droplet per website, but some droplets host more than one for the same client. None of these droplets send email directly, they all proxy through Mailgun. Most of the time, the floating IP of the droplet (and not the IP of the droplet itself) is used for public DNS records.

What should I be naming these droplets/hostnames? It doesn’t seem to make sense to make it the domain name and therefore a FQDN, since this will create a PTR which doesn’t seem to be relevant in this scenario. It also has nothing to do with the IP of the droplet itself.

Let’s say the purpose of a droplet is for hosting “example.com” and maybe “foo.example.com”. Maybe they’ll need a separate database server or another web server down the line.

What should the droplet be named?

example
example.com
example_web1
web01.prd.lon.example.com
web01.prd.lon.mycompany.net
example.web01.prd.lon.mycompany.net
<some irrelevant name>

Thanks in advance
Jamie

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
Submit an Answer
1 answer

Hello,

I would personally go for customer.web01.prd.lon.mycompany.net or customer-web01.prd.lon.mycompany.net having the following things in mind:

  • customer: This allows you to quickly identify which customer the server belongs to.
  • web01: As you mentioned, a client might have multiple web servers and maybe separate database servers (db01), or caching servers (cache01) and etc. Having the first part in the name would help you quickly identify what the role of each server is.
  • prd: If a customer has multiple environments, like Prod, Dev, Staging and etc. this will give you a quick indication of which environment the specific server is part of. This could be specifically useful if you have a monitoring system and the servers pop up there in case of issues, this will let people know if the alert is urgent especially when the production servers are affected.
  • lon: Knowing the location might be beneficial in case that the customer has servers in different regions.
  • mycompany.net: I personally think that it is better to have it under your domain so that in case you had to make any DNS changes, you would be in control and would not have to request this from your customers.

Those are some personal preferences after working in the web hosting industry for quite a while, however, the most important thing is to be consistent. So no matter which naming convention you choose, make sure to be consistent and to follow it for all servers. Consistency is key :)

Hope that this helps!
Best,
Bobby

  • Thank you for taking the time to respond @bobbyiliev that’s really useful information.

    As I was forming my question I was leaning towards that myself and your reasoning is sound.

    Unfortunately naming is not consistent at the moment, but armed with these pointers I’m going to change that.

    I think having customer-web01 is my preference for the very simple reason that by default it’ll be shown in the prompt instead of just “customer”.

    • No problem at all! Yep customer-web01 sounds good! I personally prefer this one too. Good luck with your project!

      • Implemented!

        One thing that’s bugging me though, what is the benefit of a FQDN and having my domain at the end?

        • That’s awesome!

          I personally like it as you would have full control over the DNS for the FQDN.

          For example, if you need to add an A record for customer-web01.prd.lon.mycompany.net to point to the server IP, you would be able to do that, whereas if it was customer-web01.prd.lon.your-customer-domain.net you would need to ask your customer if they were in control of the DNS for their domain.

          This might be handy if you wanted to be able to access the server, via SSH for example, through the FQDN and not only the IP address.

          • I’m only concerned with the droplet’s hostname though.

            I can still create a DNS record pointing to the IP of the droplet, regardless if the droplet’s hostname is a FQDN.

            The only benefit I can see of making the droplet’s hostname a FQDN is that a PTR record is created for it, but since all email is relayed through an external system, it’s not a benefit.

            I could create a droplet hostname of example-web01.prd.lon and create an A record pointing to it of example-web01.prd.lon.mycompany.net.

          • Yes, this is a good point. In this case, you could exclude that part.

            Usually it is handy if you had a control panel like cPanel where you would use the hostname to access the control panel and secure it with an SSL certificate. But in your case, this is not needed.

          • I’ll keep it for now, but it might be that I don’t really need to append the mycompany.net. Although, I guess if it then ended “.lon” would that be considered a FQDN and an (invalid) PTR created.

            There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.