Install OpenVPN with Ubuntu 18.04

A VPN is a network that allows users to encrypt data that is being sent or received over public networks. This is incredibly useful when accessing the internet over untrusted access points such as coffee shops and hotels to protect your data.

For the purpose of this article, I will be using OpenVPN because it’s an open-sourced, full-featured tool. I will also be setting up OpenVPN on a Ubuntu server. Once we set up OpenVPN we can use the client on Windows, macOS, and Android.

Prerequisites

  • Ubuntu 18.04 as a host for OpenVPN. You will need to create a user with sudo privileges, this user should not be the root user. You should also have your firewall set up prior to starting this tutorial.
  • You also need to spin up a separate server for certificate authority. The user you set up for this server will also need to be a non-root sudo user.

It is recommended to generate SSH keypair for these two servers as having the passwords disabled opens you up to security vulnerabilities. To enable both servers for access you will need to add the public key from the CA machine to the VPN’s authorized_keys file and the same for CA’s authorized_keys file.

 

Install OpenVPN

The first thing we need to do is install OpenVPN.

sudo apt-get update
sudo apt-get install openvpn

 

Install EasyRSA

Since OpenVPN uses TLS/SSL it uses certificates to encrypt your data as it travels from the source to destination. We will use a standalone server, EasyRSA, to issue these certificates using a simple certificate authority (CA). You need to install EasyRSA on both your CA server and your VPN server

wget -P ~/ https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.4/EasyRSA-3.0.6.tgz

To extract the tarball (.tgz) use the following:
cd ~
tar xvf EasyRSA-3.0.4.tgz

 

Create CA and Configure EasyRSA

On the machine, you are setting up your CA on

cd ~/EasyRSA-3.0.6/

There is a file named vars.example. You will need to copy this file without the .example extension

cp vars.example vars

Now, edit the file (I use VI, but feel free to use whichever editor you like)

vi vars

In this file, there are default settings that need to be updated for the server it is for. Also, this section needs to have the ‘#’ removed so that EasyRSA knows to read this part.

set_var EASYRSA_REQ_COUNTRY    "US"

set_var EASYRSA_REQ_PROVINCE   "California"

set_var EASYRSA_REQ_CITY       "San Francisco"

set_var EASYRSA_REQ_ORG        "Copyleft Certificate Co"

set_var EASYRSA_REQ_EMAIL      "me@example.net"

set_var EASYRSA_REQ_OU         "My Organizational Unit"

Save and close this file.

Now we need to initiate the public key on the CA server

./easyrsa init-pki

 

Next, build the ca with the build-ca option. This will create two files ca.crt and ca.key which are your public and private parts of your SSL certificate.

               Note: nopass allows for you to interact with your ca without being prompted for a password each time

./easyrsa build-ca nopass

 

Make Server Certificate

First, go to your VPN server and go to the EasyRSA directory

cd EasyRSA-3.0.6/

Next, we need to initialize easyrsa.

./easyrsa init-pki

Let’s call the EasyRSA again, this time to create the private key and certificate (server.req and server.key) for the server. Copy that file into /etc/openvpn/

./easyrsa gen-req server nopass

                Note: the above command is so that you do not have to enter your password every time you need to use CA. It is optional but recommended 

sudo cp ~/EasyRSA-3.0.6/pki/private/server.key /etc/openvpn/

               Note: “server” is a simple name for OpenVpn’s name. Feel free to change it to what you like, but keep in mind that you will need to continue to use the name you choose when following this article.

Next, use a secure method to copy the server.req file to the CA machine

scp ~/EasyRSA-3.0.4/pki/reqs/server.req your_username@CA_ip:/tmp

On the CA machine go to the EasyRSA directory again

cd EasyRSA-3.0.6/

Import the server.req script you just copied over

./easyrsa import-req /tmp/server.req server

Let’s sign this request

./easyrsa sign-req server server

               Note: For this example, the first “server” is the request type, which can be either client or server, and the second “server” is a common name.

From there you will be prompted to verify the request. Enter “yes”

Now we need to copy the signed certificate over the VPN server

scp pki/issued/server.crt your_username@server_ip:/tmp

Make sure to move over the ca.crt as well

scp pki/ca.crt your_username@server_ip:/tmp

Log into the VPN machine and copy server.cry and ca.crt to /etc/openvpn

sudo cp /tmp/{server.crt,ca.crt} /etc/openvpn/

Go to EasyRSA and create a Diffie-Hellman key.

               Note: Using a Diffie-Hellman key will provide a strongly encrypted key that will keep your data encrypted during exchanges.

./easyrsa gen-dh

Get a cup of coffee, tea, or sparkling water as this might take a few minutes.

Once that key has been created using an HMAC signature to ensure the integrity of the TLS verification and copy the new files to /etc/openvpn

openvpn --genkey --secret ta.key
sudo cp ~/EasyRSA-3.0.6/ta.key /etc/openvpn/
sudo cp ~/EasyRSA-3.0.6/pki/dh.pem /etc/openvpn/

 

Generate Certificate

Let’s start by setting up the directory to store the client’s certificates and keys.

mkdir -p ~/client-configs/keys
chmod -R 700 ~/client-configs

Go back to the EasyRSA directory, we will be making a client-side keys and certificates

cd ~/EasyRSA-3.0.6/
./easyrsa gen-req client1 nopass
cp pki/private/client1.key ~/client-configs/keys/

Like we have been doing, we need to transfer this key over to the CA server

scp pki/reqs/client1.req your_username@CA_ip:/tmp

Log into the CA server so we can import and sign the certificate request

ssh your_username@CA_ip
cd EasyRSA-3.0.6/
./easyrsa import-req /tmp/client1.req client1
./easyrsa sign-req client client1

Enter “yes” to verify the certificate came from a trusted source and copy the client1.crt file back over to the VPN server

scp pki/issued/client1.crt your_username@server_ip:/tmp

Log back into your VPN server and copy the client certificates, ca.crt and ta.key to /client-configs/keys

cp /tmp/client1.crt ~/client-configs/keys/
cp ~/EasyRSA-3.0.4/ta.key ~/client-configs/keys/
sudo cp /etc/openvpn/ca.crt ~/client-configs/keys/

 

Configure OpenVPN

Copy over the example configuration from OpenVPN, unzip it and start to edit the file.

sudo cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
sudo gzip -d /etc/openvpn/server.conf.gz
sudo vi /etc/openvpn/server.conf

Uncomment tls-auth directive and the cipher lines by removing the `;`

tls-auth ta.key 0 # This file is secret
cipher AES-256-CBC

Next, let’s add the auth directive SHA256

auth SHA256

Look for the DH directive and make sure that the directive listed in the example configuration matches the key you generated before. Usually, you just need to remove the 2048 from this line

dh dh.pem

Uncomment the user and group lines by removing the `;`

user nobody
group nogroup

 

If you do not have a need to tunnel your traffic feel free to skip to the “Configure Server Network” step. If not, buckle up buttercup.

Now we are going to make some extra edits to the configuration file we have been working in previously.

Let’s start by uncommenting a few lines by removing the `;`

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

Now, we will adjust the port since OpenVPN uses a default port of 1194 as well as UDP protocol when accepting client connections. Unless you have a specific port you need to use 443 is usually what you want to go with.

port 443

I would also recommend changing the protocol to TCP since UDP is restricted for port 443. When you do this you also need to change the `explicit-exit-notify` value from`1` to `0`.

proto tcp

explicit-exit-notify 0

Save and close the configuration file.

 

Configure Server Network

Edit the file `/etc/sysctl.conf`

sudo vi /etc/sysctl.conf

Remove the `#` to uncomment the line ` net.ipv4.ip_forward`

net.ipv4.ip_forward

Save and close this file.

 

To make our lives easier first find the public network interface of the machine you are in.

ip route | grep default

 

Now, let’s edit your firewall rules

sudo vi /etc/ufw/before.rules

 Somewhere at the beginning of the file place the following:

# START OPENVPN RULES
# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]
# Allow traffic from OpenVPN client to wlp11s0 (change to the interface you discovered!)
-A POSTROUTING -s 10.8.0.0/8 -o [your_network_interface] -j MASQUERADE
COMMIT
# END OPENVPN RULES

Save and close the file.

 

Next, edit `/etc/default/ufw` file and change the DEFAULT_FORWARD_POLICY from DROP to ACCEPT.

DEFAULT_FORWARD_POLICY="ACCEPT"

Save and close the file.

 

Start OpenVPN

Now we are ready to finally start OpenVPN. To do so we need to tell OpenVPN which configuration file name to read. If you have been following along your server name should `server`

sudo systemctl start openvpn@server

To check that OpenVPN has started run the following:

ip addr show tun

Enable the service to force it to start on boot.

sudo systemctl enable openvpn@server

 

Generate Client Configuration files

For each client, we need to have a configuration file, but for this article, we will go over creating one client configuration. Feel free to use this as a base for making configuration files for different clients.

Make a directory to place your configuration file

mkdir -p ~/client-configs/files

Copy the sample configuration file.

cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf ~/client-configs/base.conf

Edit the configuration file

sudo vi  ~/client-configs/base.conf

Find the remote directive line and update it to have your server’s IP and change 1194 to the port you choose

remote server_ip 1194

Remove the `;` from user and group lines and make sure that the protocol you chose is being used.

user nobody
group nogroup
proto udp

Next, find the ca, cert, key, and tls-auth lines. You will need to comment these out since we previously made these

#ca ca.crt
#cert client.crt
#key client.key
#tls-auth ta.key 1

 While you are in her check the cipher and auth setting to make sure they are what we set up previously. 

Technically you can add the key direction anywhere in the file, but I added it to the end of the file.

key-direction 1

Save and close this file. 

We need to now transfer this file ~/client-configs/base.conf over to the machine that will be the client. Let’s use the following command:

scp your_username@server_ip:client-configs/files/base.conf ~/

 

Install Client

From here things get more straight forward as you will basically be following the instructions from OpenVPN to install the client. 

Windows

  • Copy your configuration file over to C:Program FilesOpenVPNconfig
  • OpenVPN needs to have Admin rights to work properly
  • Once you follow the instructions for the client you are installing you are all set.

Getting Started with vnStat on Ubuntu 18.04

vnStat is a console-based network traffic monitor for Linux and BSD that keeps a log of network traffic for the selected interface(s). It uses the network interface statistics provided by the kernel as information source. This means that vnStat won’t actually be sniffing any traffic and also ensures light use of system resources regardless of network traffic rate.

vnStat is perfect for collecting persistent statistics through system reboots, and can provide a usage summary of 5 minute, hourly, daily, monthly, weekly, yearly intervals, as well as displaying the top days of usage in it’s history.

Prerequisites:

• Cloud Server running Ubuntu 18.04

Step-by-Step:

1) Install the vnstat package:

# sudo apt install vnstat

2) For vnStat to begin capturing data, you need to start the service:

# sudo systemctl start vnstat.service

3) Now let’s make sure vnstat starts on boot automatically:

# sudo systemctl enable vnstat.service

VnStat will now begin capturing data and statistics for traffic on your server’s interfaces. Initially, you won’t be able to get any data reported as vnStat needs to build up some data before it can display it. To display the standard report for vnStat you simply run the following command:

# vnstat

                      rx      /      tx      /     total    /   estimated
 Internet (eth1):
       2020-01     31.90 GiB  /   28.05 GiB  /   59.95 GiB
       2020-02    281.04 MiB  /   99.45 MiB  /  380.49 MiB  /   12.05 GiB
     yesterday      1.23 GiB  /  473.23 MiB  /    1.69 GiB
         today    281.04 MiB  /   99.45 MiB  /  380.49 MiB  /     397 MiB

 Local (eth0):
       2020-01     25.13 GiB  /  116.94 GiB  /  142.07 GiB
       2020-02    234.75 MiB  /    5.03 GiB  /    5.26 GiB  /  170.76 GiB
     yesterday    520.55 MiB  /    2.21 GiB  /    2.72 GiB
         today    234.75 MiB  /    5.03 GiB  /    5.26 GiB  /    5.51 GiB

Additional flags can be appended to the vnstat command to get more specific output of the data. Here are some flags you can use and what they will provide:

      -5,  --fiveminutes [limit]   show 5 minutes
      -h,  --hours [limit]         show hours
      -hg, --hoursgraph            show hours graph
      -d,  --days [limit]          show days
      -m,  --months [limit]        show months
      -y,  --years [limit]         show years
      -t,  --top [limit]           show top days

      -b, --begin                  set list begin date
      -e, --end                    set list end date

      --oneline [mode]             show simple parsable format
      --json [mode] [limit]        show database in json format
      --xml [mode] [limit]         show database in xml format

      -tr, --traffic [time]        calculate traffic
      -l,  --live [mode]           show transfer rate in real time
      -i,  --iface                 select interface (default: eth0)

Use "--longhelp" or "man vnstat" for complete list of options.

You now have a working installation of vnStat which you can use to monitor your server’s traffic over multiple interfaces.

Getting Started with vnStat on Debian 10

vnStat is a console-based network traffic monitor for Linux and BSD that keeps a log of network traffic for the selected interface(s). It uses the network interface statistics provided by the kernel as information source. This means that vnStat won’t actually be sniffing any traffic and also ensures light use of system resources regardless of network traffic rate.

vnStat is perfect for collecting persistent statistics through system reboots, and can provide a usage summary of 5 minute, hourly, daily, monthly, weekly, yearly intervals, as well as displaying the top days of usage in it’s history.

Prerequisites:

• Cloud Server running Debian 10

Step-by-Step:

1) Install the vnstat package:

# sudo apt install vnstat

2) For vnStat to begin capturing data, you need to start the service:

# sudo systemctl start vnstat.service

3) Now let’s make sure vnstat starts on boot automatically:

# sudo systemctl enable vnstat.service

VnStat will now begin capturing data and statistics for traffic on your server’s interfaces. Initially, you won’t be able to get any data reported as vnStat needs to build up some data before it can display it. To display the standard report for vnStat you simply run the following command:

# vnstat

                      rx      /      tx      /     total    /   estimated
 Internet (eth1):
       2020-01     31.90 GiB  /   28.05 GiB  /   59.95 GiB
       2020-02    281.04 MiB  /   99.45 MiB  /  380.49 MiB  /   12.05 GiB
     yesterday      1.23 GiB  /  473.23 MiB  /    1.69 GiB
         today    281.04 MiB  /   99.45 MiB  /  380.49 MiB  /     397 MiB

 Local (eth0):
       2020-01     25.13 GiB  /  116.94 GiB  /  142.07 GiB
       2020-02    234.75 MiB  /    5.03 GiB  /    5.26 GiB  /  170.76 GiB
     yesterday    520.55 MiB  /    2.21 GiB  /    2.72 GiB
         today    234.75 MiB  /    5.03 GiB  /    5.26 GiB  /    5.51 GiB

Additional flags can be appended to the vnstat command to get more specific output of the data. Here are some flags you can use and what they will provide:

      -5,  --fiveminutes [limit]   show 5 minutes
      -h,  --hours [limit]         show hours
      -hg, --hoursgraph            show hours graph
      -d,  --days [limit]          show days
      -m,  --months [limit]        show months
      -y,  --years [limit]         show years
      -t,  --top [limit]           show top days

      -b, --begin                  set list begin date
      -e, --end                    set list end date

      --oneline [mode]             show simple parsable format
      --json [mode] [limit]        show database in json format
      --xml [mode] [limit]         show database in xml format

      -tr, --traffic [time]        calculate traffic
      -l,  --live [mode]           show transfer rate in real time
      -i,  --iface                 select interface (default: eth0)

Use "--longhelp" or "man vnstat" for complete list of options.

You now have a working installation of vnStat which you can use to monitor your server’s traffic over multiple interfaces.

Getting Started with vnStat on Fedora 31

vnStat is a console-based network traffic monitor for Linux and BSD that keeps a log of network traffic for the selected interface(s). It uses the network interface statistics provided by the kernel as information source. This means that vnStat won’t actually be sniffing any traffic and also ensures light use of system resources regardless of network traffic rate.

vnStat is perfect for collecting persistent statistics through system reboots, and can provide a usage summary of 5 minute, hourly, daily, monthly, weekly, yearly intervals, as well as displaying the top days of usage in it’s history.

Prerequisites:

• Cloud Server running Fedora 31

Step-by-Step:

1) Install the vnstat package:

# sudo dnf install vnstat

2) For vnStat to begin capturing data, you need to start the service:

# systemctl start vnstat

3) Now let’s make sure vnstat starts on boot automatically:

# systemctl enable vnstat

VnStat will now begin capturing data and statistics for traffic on your server’s interfaces. Initially, you won’t be able to get any data reported as vnStat needs to build up some data before it can display it. To display the standard report for vnStat you simply run the following command:

# vnstat

                      rx      /      tx      /     total    /   estimated
 Internet (eth1):
       2020-01     31.90 GiB  /   28.05 GiB  /   59.95 GiB
       2020-02    281.04 MiB  /   99.45 MiB  /  380.49 MiB  /   12.05 GiB
     yesterday      1.23 GiB  /  473.23 MiB  /    1.69 GiB
         today    281.04 MiB  /   99.45 MiB  /  380.49 MiB  /     397 MiB

 Local (eth0):
       2020-01     25.13 GiB  /  116.94 GiB  /  142.07 GiB
       2020-02    234.75 MiB  /    5.03 GiB  /    5.26 GiB  /  170.76 GiB
     yesterday    520.55 MiB  /    2.21 GiB  /    2.72 GiB
         today    234.75 MiB  /    5.03 GiB  /    5.26 GiB  /    5.51 GiB

Additional flags can be appended to the vnstat command to get more specific output of the data. Here are some flags you can use and what they will provide:

      -5,  --fiveminutes [limit]   show 5 minutes
      -h,  --hours [limit]         show hours
      -hg, --hoursgraph            show hours graph
      -d,  --days [limit]          show days
      -m,  --months [limit]        show months
      -y,  --years [limit]         show years
      -t,  --top [limit]           show top days

      -b, --begin                  set list begin date
      -e, --end                    set list end date

      --oneline [mode]             show simple parsable format
      --json [mode] [limit]        show database in json format
      --xml [mode] [limit]         show database in xml format

      -tr, --traffic [time]        calculate traffic
      -l,  --live [mode]           show transfer rate in real time
      -i,  --iface                 select interface (default: eth0)

Use "--longhelp" or "man vnstat" for complete list of options.

You now have a working installation of vnStat which you can use to monitor your server’s traffic over multiple interfaces.

Getting Started with vnStat on CentOS 8

vnStat is a console-based network traffic monitor for Linux and BSD that keeps a log of network traffic for the selected interface(s). It uses the network interface statistics provided by the kernel as information source. This means that vnStat won’t actually be sniffing any traffic and also ensures light use of system resources regardless of network traffic rate.

vnStat is perfect for collecting persistent statistics through system reboots, and can provide a usage summary of 5 minute, hourly, daily, monthly, weekly, yearly intervals, as well as displaying the top days of usage in it’s history.

Prerequisites:

• Cloud Server running CentOS 8

Step-by-Step:

1) Install the vnstat package:

# sudo dnf install vnstat

2) For vnStat to begin capturing data, you need to start the service:

# systemctl start vnstat

3) Now let’s make sure vnstat starts on boot automatically:

# systemctl enable vnstat

VnStat will now begin capturing data and statistics for traffic on your server’s interfaces. Initially, you won’t be able to get any data reported as vnStat needs to build up some data before it can display it. To display the standard report for vnStat you simply run the following command:

# vnstat

                      rx      /      tx      /     total    /   estimated
 Internet (eth1):
       2020-01     31.90 GiB  /   28.05 GiB  /   59.95 GiB
       2020-02    281.04 MiB  /   99.45 MiB  /  380.49 MiB  /   12.05 GiB
     yesterday      1.23 GiB  /  473.23 MiB  /    1.69 GiB
         today    281.04 MiB  /   99.45 MiB  /  380.49 MiB  /     397 MiB

 Local (eth0):
       2020-01     25.13 GiB  /  116.94 GiB  /  142.07 GiB
       2020-02    234.75 MiB  /    5.03 GiB  /    5.26 GiB  /  170.76 GiB
     yesterday    520.55 MiB  /    2.21 GiB  /    2.72 GiB
         today    234.75 MiB  /    5.03 GiB  /    5.26 GiB  /    5.51 GiB

Additional flags can be appended to the vnstat command to get more specific output of the data. Here are some flags you can use and what they will provide:

      -5,  --fiveminutes [limit]   show 5 minutes
      -h,  --hours [limit]         show hours
      -hg, --hoursgraph            show hours graph
      -d,  --days [limit]          show days
      -m,  --months [limit]        show months
      -y,  --years [limit]         show years
      -t,  --top [limit]           show top days

      -b, --begin                  set list begin date
      -e, --end                    set list end date

      --oneline [mode]             show simple parsable format
      --json [mode] [limit]        show database in json format
      --xml [mode] [limit]         show database in xml format

      -tr, --traffic [time]        calculate traffic
      -l,  --live [mode]           show transfer rate in real time
      -i,  --iface                 select interface (default: eth0)

Use "--longhelp" or "man vnstat" for complete list of options.

You now have a working installation of vnStat which you can use to monitor your server’s traffic over multiple interfaces.

Introduction to DNS

This article will take you through a very basic crash course around DNS, what it is, and how it’s used.

What is DNS?

DNS stands for ‘Domain Name System’ and it is the system which computers use to locate one another over networks. In the most basic sense, you can think of DNS as a phone book which ties human readable names like ‘www.google.com’ to an IP address. Servers, computers, etc can then establish the connection to the other device after having determined it’s name.

Terminology

It is important to be familiar with some of the terminology used in DNS. Here are the most common, and useful, terms related to DNS.

• DNS (Domain Name System) – The system of technology designed to convert human-readable domain names into a corresponding IP addresses.

• Domain Name – A broader term given to the human-readable names which are tied to a specific resource on the network. For example ‘yahoo.com’ or ‘google.com’

• TLD (Top-Level Domain) – Top-level domains are the part of the domain name which is situated furthest to the right and separated by a period. The top-level domain you most commonly see is likely to be ‘.com’, but there are many more possible top-level domains such as .org, .gov, and .us.

• Subdomain – A subdomain is a domain that is part of another domain name. For example, ‘www.google.com’ could be considered a subdomain of ‘google.com’. It can become more complicated, for example an internal network might have a subdomain name ‘mx1.mail.domain.com’. In this case, ‘mx1’ is a subdomain of ‘mail.domain.com’, and ‘mail.domain.com’ is a subdomain of ‘domain.com’. For the sake of simplicity, you can consider anything prepended onto the domain name as a subdomain.

• IP Address – IP addresses are the actual numeric ( and alphanumeric in the case of IPv6) addresses of devices that the DNS servers translate domain names into via Domain Name System technology.

• Name Server – A name server is the device which translates the human readable domain name into an IP Address.

• Zone File – Zone files are basic text files which contain the correlations between domain names and IP addresses. This is the file that the nameserver uses to find out which IP address corresponds to the host name it is requested to resolve.

• DNS Record – Within the zone file, are there are usually many DNS records, which are one line entries that define a hostname to an IP address.

• Domain Name Registrar – The Domain Name Registrar (sometimes just called Domain Registrar) is the entity with which you purchase, and register your domain name. Some well-known registrars include GoDaddy, Namecheap, and HostGator. Registrars are also important to DNS, because it is at your registrar that you most often set your Name Servers. Each registrar will usually have a handful of nameservers that they provide you by default, but you also can change these on most platforms to utilize nameservers from other providers or parties.

• DNS Resolution – Resolution is the actual process of translating IP addresses to domain names, or vice versa. Commonly, if a hostname cannot be reached to determine it’s IP address, it will be said that it ‘cannot be resolved.’

• TTL – TTL is a setting for each DNS record that tells the name server for how long it should cache the query before it needs to expire it and fetch a new one.

How does DNS work?

When you type ‘google.com’ into your browser, the browser sends a query over the web in order to find the IP address corresponding to ‘google.com’. The first place the query will go, is to what’s known as the ‘Recursive Resolver.’ It is likely operated by your ISP, mobile phone provider, or some third party. The recursive resolver will then ask the ‘Root Server’ for information correlating the hostname google.com to an IP address. The Root Server will then correspond the TLD to a ‘Top Level Domain Name Server’, which will store information for the domain name below the TLD, ‘google’ in this case. The TLD server will answer with the IP address of the domain’s name server, which the recursive resolver sends it’s next query to. The domain name server knows the IP address for the full google.com domain and directs traffic to the appropriate IP address. At this point, your web browser will load the requested website.

DNS Records

There are a number of DNS records which can be used for different purposes. Below are some of the most common record types that you may encounter, and their use cases.

• A – A records are one of the basic DNS record types, responsible for converting hostnames into their corresponding IPv4 addresses. Within a zone file, the record would look similar to this:

domain.com IN A 12.34.56.78

• AAAA – AAAA records are identical to A records, except that they are responsible for converting hostnames into their corresponding IPv6 addresses. Within a zone file, the record would look similar to this:

domain.com IN A 2001:0db8:85a3:0000:0000:8a2e:0370:7334

• CNAME – CNAME records (Canonical Name Record) is a type of record which maps one domain name to another. This is useful for running multiple services on a single IP address. Within a zone file, the record would look similar to this:

www IN CNAME domain.com

This would route www.domain.com to the same IP address domain.com routes to.

• MX – MX Records are used for specifying the mail exchange servers used by a domain. This helps route mail destined for your hostname to the proper mail server. Most mail providers will tell you which MX records to use when utilizing their mail service. Within a zone file, the record would look similar to this:

IN MX 10 mail.domain.com.

In this example, the 10 denotes the priority. If there are multiple MX records, their priority can be adjusted using numerical values with a lower number being a higher priority.

• NS – Nameserver records can delegate a specific domain or subdomain to use another nameserver entirely. Within a zone file, the record would look similar to this:

IN NS namesrv1.domain.com.

• PTR – PTR records are the inverse of A/AAAA records. Instead of associating a hostname to an IP, they associate an IP to a hostname. If you performed a ‘dig -x’ lookup on an IP address with a PTR record configured, it would return to you the hostname. Within a zone file, the record would look similar to this:

78.56.34.12.in-addr.arpa. 900 IN PTR domain.com.

• SOA – SOA records are the one record which is mandatory within the zone file. It must also be the first real record in the file. This record contains information pertaining to which nameserver the domain uses, what email address is on file for the administrator of the zone, a serial number, and TTL related values. Within a zone file, the record would look similar to this:

domain.com.  IN SOA namesrv1.domain.com. administrator.domain.com. (
                                            80544   ; serial number
                                            21600s      ; refresh interval
                                            3600s     ; retry interval
                                            1814400s      ; expiry period
                                            500s      ; negative TTL
)

This is more difficult to breakdown, but you can see first your domain name. Followed by IN which means internet, then SOA to indicate record type. Following this you see the nameserver defined for the domain, and then the adminstrators email address. There is no @ symbol, but first period is indicative of where the @ would be placed. The serial number is a number which counts up with each change made to the zonefile. The secondary nameservers will check this to determine if they need to request a new copy of the zone file. The refresh interval determines how long the secondary nameservers will wait before checking the serial number for changes. The retry interval determines how long the secondary name server will wait before trying to poll the primary name server in the case of it being unreachable. The expiry period tells the secondary name server to no longer consider this the primary name server for this domain if it fails to reach it beyond this period. The negative TTL indicates how long the name server will cache an error if it cannot find it’s sought after entry in the zone file.

• TXT – TXT records are different from the other DNS records as they are used mainly for informative purposes. The most common usage for the TXT record is setting an SPF (Sender Policy Framework) record. SPF Records are used to indicate to mail exchange servers which servers can send mail for that domain.

Conclusion

DNS goes far beyond what’s been covered in this guide, but knowing the basics will go a long way in assisting you in understanding what needs to be configured, what problems may occur, and serve as a foundation for understanding DNS at more complex levels.