How to use domain names for servers in a home environment

📆2021-08-04🍱server

Naming stuff is difficult, especially in the digital world. It's one of the things that you want to get right the first time. So it is scalable and descriptive without having to redo it after a year when you buy a new NAS or move to another home. Naming your pets is probably easy since you don't have that many but if you have up to a hundred different ones you might need a technique.

Many of the existing guides for naming server setups are for enterprises where you have multiple physical locations and different environments like production and development. Even though many naming conventions have similarities, there are some differences for home use I think are worth mentioning.

Get a real domain name

First step is to buy a real domain name if you don't have one already. It doesn't need to be a completely new one since we will use subdomains (sub.example.com), but it needs to be a FQDN you own. You can still use the domain as normal, for email with bob@example.com or a homepage at example.com. It would also be good to use one that doesn't enforce SSL since not all your services may support it, so no .dev domains.

Making up your own TLD in your DNS server is also not recommended since ICANN could register that any time in the future if you're unlucky. I will be using example.com throughout this post, and it will be the base for everything in our network.

Try to pick a domain name registrar that is in your own country. EU based registrars are recommended if you live in the EU, and try to avoid US based services as much as possible.

Name your physical devices

Before even setting up network and services you need to have the hardware. All devices will have a hostname that should point to the actual machine, and it should be a neutral name. That means you should not name a device for what it is doing (like backup or storage) since that could change in the future. Also you might buy two of the same unit so naming a device "raspberrypi" is not recommended.

Since device names should not be reused if it breaks or is replaced you could use a name followed by incrementing, padded numbers. raspberrypi01 will work and is descriptive if you want to now what the device is by name but it will look too similar to other devices of the same type. The most popular approach is to use a naming scheme. Here you can use your favorite food dishes or cartoon characters as device names. Just ensure they are easy to remember, easy to type and aren't limited by number. It's also a good idea to skip geographical and technical categories, it will be confusing if you name your router "xbox", just because you like video games.

Let's say you name your physical devices by color, purple and silver. You don't need to name your client devices like phones and laptops since they're not part of your network infrastructure (well, they are, but you know what I mean 😄).

Add DNS A Records for the hosts

When you add these as your hostnames they will sometimes automatically be available as purple.local or similar depending on operating systems. It could be tempting to use them, as they are already available. This is not recommended as these automatic domain names are often reserved for other tasks and is not reliable in the long run. What we need to do is connect the IP address of the device to our own (as in we own it) domain name. For a home network this is usually an internal IP you need to make static/reserved and set in your own DNS server. You can also set this as a public record directly on your registrar if you don't have your own set up.

purple.example.com. -> (A record) 192.168.1.10
silver.example.com. -> (A record) 192.168.1.11
yellow.example.com. -> (A record) 192.168.1.12

This way it's easier to move the devices between networks/subnets and to point to what machine a service is running on. You can also do something like purple.device.example.com if you use your domain name for many other things and feel there's a need to group devices. As a rule of thumb it's recommended to keep it as simple as possible unless you are 100% sure you need to add an extra layer.

Decide on subdomains for each location

To be able to connect to services at both home and remote locations we need a way to assign a place to that specific service. Since DNS is working hierarchically, that is actually pretty simple, just like the example above with devices. If you set records with *.device.example.com they will all be categorized under device and we will do the same here but with a location instead. The tricky part here is what name to set as the location.

At first, it might seem easy to choose home.example.com and remote.example.com but as mentioned earlier you could have multiple remotes and homes. If you let your family connect to this network, home may not work since it's relative, so maybe we need something more specific. On an enterprise level with servers all across the world, a UN/LOCODE is often used to describe country and city. Stockholm, Sweden would then be se-sto.example.com (or only sto since it's usually unique enough) but this may not work for smaller home usage. All locations could actually be in the same city. So if you move to a new place you don't want to rename everything just because you are living across the street with the exact same equipment.

You can also have multiple locations in your own home with different subnets if you feel the need to separate them. Maybe you run your own company and want to have that separate from normal home use.

With these possible caveats mentioned spend some time to reflect how you may use it but in this case I will actually use home and work in this post. The first is where I live, the main location, and the other one is where I keep a backup.

Set public DNS records for the locations

If you will never access anything from outside your local network, and you generate SSL certificates with wildcard support you can skip this step.

Next step is to create the DNS records to point to these locations. If you have a static IP it's easy with an A Record, otherwise you'll need to set up a Dynamic DNS and point your domain to that with a CNAME. You should also use a wildcard so all your services for that location will get the same record. It could look like this on your registrar for the public records:

work.example.com. -> (A) 123.123.456.456
*.work.example.com. -> (A) 123.123.456.456
home.example.com. -> (CNAME) home.ddns.tld
*.home.example.com. -> (CNAME) home.ddns.tld

This way you will always be able to connect to the location with one single domain name. With the wildcard you can also reach all the services (as long as they are open to the public). Another reason to point the domains to the public address is that you can now generate SSL certificates with Let's Encrypt for each of your services.

We will discuss the setup of services and how to configure this locally (so you are not using the external address when at home) in the next steps. Also exposing service to the internet can be a security issue and if you don't know if it's needed you should skip this.

Add services to your domains

Now to the fun part that will actually make all this work, adding all your services. Let's say we have Jellyfin and Paperless on the "purple" named machine, a reverse proxy on the "silver" named one and a database on "yellow".

There are two ways to assign all services a domain name and point them to the correct place. Either you can do it with a reverse proxy or add all services, one-by-one, in your own DNS server. Using a reverse proxy is usually much better since you get an extra layer of security, you can add SSL certificates in one place and can ignore ports. We will mainly go that route but still need some DNS records added for those services we don't want to go through the proxy.

So with the previous additions it can look like this:

purple.example.com. -> (A) 192.168.1.10
silver.example.com. -> (A) 192.168.1.11
yellow.example.com. -> (A) 192.168.1.12

postgres.home.example.com -> (CNAME) yellow.example.com
*.home.example.com. -> (CNAME) silver.example.com

// and if you didn't add them as public records, add the remote locations:
work.example.com. -> (A/CNAME) 123.123.456.456 / ddns
*.work.example.com. -> (A/CNAME) 123.123.456.456 / ddns

With the reverse proxy set up you don't need to add much more here since the wildcard is taking care of it all and routing the requests. For a reverse proxy you can use SWAG or NPM but how to configure them will not be discussed here. This is what some of your services will look like.

jellyfin.home.example.com
paperless.home.example.com
postgres.home.example.com
backup-app.work.example.com

That's the basic part of setting up domain names for your self-hosting needs. If you believe this was enough you can stop reading here and grab a cup of coffee instead.

Going even deeper

This will also support sub-services if those exist on a virtual machine or similar. Either set on DNS level or in the reverse proxy. Let's say you have virtual machines where you deploy both dev and test environments of your home project. On each environment you have both back-end and front-end as well as a database.

app.dev.project01.home.example.com
web.dev.project01.home.example.com
sql.dev.project01.home.example.com

app.test.project01.home.example.com
web.test.project01.home.example.com
sql.test.project01.home.example.com

Here you really notice the hierarchy of a DNS structure, where it gets smaller the more to the left you go. You can also have different services on the same host depending on how you run them. All depending on how you want to run things.

app01.dev.projects.home.example.com
web01.dev.projects.home.example.com

Keeping track of all domains

As you've noticed, these have become quite long and at the same time you've probably have quite a few different domains by now. Even if it's tempting to cut some parts of (like home in the above example), you should always keep the same structure for all domains. Even if you only have one location now, you never know what will happen in the future.

About the amount of domains you could of course write everything down in a markdown file but there are many tools created just for solving these problems. If you mostly want to keep track of and access your services you can use tools like Homer or Heimdall, which will give you a nice overview in your browser.

If you completely fell down the rabbit hole you need a configuration management database, CMDB, like Ralph. These tools will keep track of everything you need to know, about all your servers and services (and a thousand more things). Just try not getting lost in the basement where you keep all your server racks formed as a maze.