As an opening introduction before we start to get REALLY technical, let's quickly explain what DNS is. If you already know this, you can skip this section. We've simplified parts of it to make it easier to understand, so please don't worry about telling us "Wellllll, technically it's not like that...").
All directly-internet connected devices, be they servers, your mobile phone, or whatever, have a unique address on the internet called an IP address. This is how devices on the internet communicate with each other, using these addresses. Currently most of these are addresses are in the format of x.x.x.x where x is a number between 0 and 255. Due to the fact that world is running out of them, there is a newer standard for them available where they are much longer, but sadly most of the internet can't use them yet (including our beloved underlying OpenStack, at least in combination with the old format).
We think everyone on the planet knows the name Google, but if you had to remember to type in to your browser
188.8.131.52 every time, it would quickly get REALLY boring, not to mention error-prone! So there is a system that much like a phone book stores a list of human readable names and converts them to these IP addresses. If this was a single central system it would a)be under enormous load and b)be at risk of both cyber attack and error, bringing the whole system to its knees. So the designers of the internet made this system be decentralised.
When you register a domain name with a company like LCN.com you choose the name and extension you want (e.g. example and ".com") and they register it for you with the people responsible for maintaining lists of domain ownerships for their extension. They also save with that registrar generally two or more internet-connected devices that are responsible (authoritative) for describing the IP addresses for any records related to them.
When you want to host a domain name on our Civo nameservers, this is the step you need to amend first. After that you need to set up the records for your domain. There are quite a few different types of records and each serves a slightly different purpose.
If you know the IP address you want to point your domain to (e.g.
184.108.40.206) and want to point a subdomain of your
www) to it, you need to use an Alias record (or
A). An Alias only points a name to an IP address. If you want to set up "Apex" records for your domain (this means not a subdomain of
example.com but literally
example.com itself) you can do this using either your domain name as the
name when creating the record or the special value
@ (not to be confused with the use of
@ in email addresses).
If you don't know the IP address you want to point to, instead it's another hostname, then you need a Canonical-name record (or
CNAME). This is often used with things like Platform-As-A-Service (here's my application's code, just host it for me, I don't want to setup a server) like Heroku.com. You'd need to use a
CNAME to point
my-example-com.herokuapps.com (or whatever you're using).
Email is delivered on the internet from the sender's email server to servers it looks up on the recipient's domain name of a special type called Mail-eXchanger records (or
MX). These have a priority associated with them and the sender's mail server will try to send it to the lowest numbered priority server it can. Therefore it's common to have multiple MX records, your primary server and a backup server that will hold the emails and deliver them to the primary server when it's back available.
A fairly recently used mechanism for storing random data in DNS records is to use TeXT (or
TXT) records. These are used for things like the Sender Policy Framework to describe which outbound mail servers (not your
MX or inbound servers, although they may optionally be the same thing) are allowed to send email from your domain.
This is very common for Microsoft servers such as Active Directory. It's a way of storing a list of service types in DNS and having the server respond with the host name to respond to, a priority/weighting and the socket number (or port) to connect to (sockets are how connections are made between servers - one will "listen on a socket" and the other servers will connect to that socket to send requests and receive responses). The value for SRV records should be in the format of
weight port hostname, e.g.
100 389 ad.example.com.