How to Setup private DNS server on ubuntu 20.04

An important part of the server configuration management discussion involves providing an easy way to check network connections and IP addresses by name by setting up an appropriate “Domain Name System” (DNS). Using FQDNs instead of IP addresses to refer to addresses within the network makes it easier to configure services and applications, and increases the ability to store configuration files. Setting up a personal DNS for a private network is a great way to improve server management. In this article, we try to fully teach you how to setup a private DNS server on ubuntu 20.04. If you need to buy Ubuntu VPS server, you can see the packages available in Eldernode.

Setup private DNS server on ubuntu 20.04

In this article, we will look at how to set up an internal DNS server using server name software (BIND) on Ubuntu 20.04. This name server can be used by your client servers to resolve hosting names and private IP addresses. This provides a centralized way to manage internal hosting names and private IP addresses, which is essential when you need to extend the work environment to more than a few hosts. Follow us in the continuation of this article with the tutorial Setup private DNS server on ubuntu 20.04.

Prerequisites for Setup private DNS server on ubuntu 20.04

To study this tutorial, you must have the following infrastructure. Note that all servers must be in the same data center and have a private network enabled between them:

– A server with the newly installed version of Ubuntu 20.04 as the primary DNS server called ns1

– The second Ubuntu 20.04 server as a secondary DNS server called ns2 (recommended).

– Other servers in the same data center that will use DNS servers.

Note: On each of these additional servers, access permissions must be configured through the sudo user and a firewall must be used.

Sample infrastructures and goals in Setup private DNS server on ubuntu 20.04

Given the objectives of this article, the following are some of our hypotheses:

1. We have two servers that will be used as our name servers. In this article, we will call these servers ns1 and ns2.

2. We have two other client servers that will use the DNS infrastructure we are creating. These servers are called host1 and host2. Of course, you can add as many servers as you like to this infrastructure.

3. All these servers are located in one data center. We assume that the name of this datacenter is nyc3.

4. All these servers have private networking and are located in subnet 10.128.0.0./16. Of course you have to change these according to the specifications of your servers.

5. All servers are connected to a project located on the “example.com” domain. Because our DNS system is completely internal and private, there is no need to purchase a domain name. However, using a domain can help prevent interference with publicly routable domains.

Note: With the above assumptions, it is obvious that the naming scheme called “nyc3.example.com” would be appropriate to refer to a private subnet or zone. Hence the FQDN for host1 would be host1.nyc3.example.com.

Note that your existing settings may be different; But the sample letters and IP addresses provided to illustrate how a DNS server is configured are examples of a fully operational internal DNS. You can easily use these settings by replacing hostnames and private IP addresses in your existing environment. If you use multiple datacenters, you can create an internal DNS inside each corresponding datacenter.

How to install BIND on DNS servers

Note that the items highlighted in red during this tutorial are often variables that you should replace with values based on the specifications of your servers. For example, if you see a variable as host1.nyc3.example.com, you must enter your server’s FQDN instead. Similarly, replace your host1_private_IP with your server’s IP address.

Update the apt package on both DNS servers called ns1 and ns2 by entering the following command:

sudo apt-get update

Now install BIND using the following command:

sudo apt-get install bind9 bind9utils bind9-doc

Learn how to set BIND in IPv4 mode

You must set BIND to IPv4 before proceeding, as our private networking uses IPv4 exclusively. On both servers, edit the default bind9 settings by entering the following command:

sudo nano /etc/default/bind9

Add the value “-4” to the end of the OPTIONS parameter. It goes like this:

...    OPTIONS="-u bind -4"

When done, save and close the file. Then restart BIND for the changes to take effect:

sudo systemctl restart bind9

Now that BIND is installed, you can configure the main DNS server.

How to configure the main DNS server

The BIND configuration consists of several files, all of which are included in the original configuration file named named.conf. The name of these files starts with named, because this is the name of the process that BIND runs. Abbreviation for “domain name daemon”. We start by configuring the options file.

How to configure the Options file on the DNS server

Open the named.conf.options file on the ns1 server for editing:

sudo nano /etc/bind/named.conf.options

Above the options block, create a new ACL called “trusted”.

Note: ACL stands for “Access Control List”.

This is where we define the list of clients that are allowed to return DNS queries. This list includes the servers you own in the same ns1 data center. Using the private IP addresses of the example we introduced earlier, we add ns1, ns2, host1 and hst2 to our list of trusted clients:

acl "trusted" {          10.128.10.11;    # ns1 - can be set to localhost          10.128.20.12;    # ns2          10.128.100.101;  # host1          10.128.200.102;  # host2  };    options {            . . .

Once you have created a list of your trusted DNS clients, you need to edit the options block. Now the beginning of the block is as follows:

        . . .  };    options {          directory "/var/cache/bind";          . . .  }

Add highlighted configuration lines below the directory and replace the IP addresses of your ns1 server. So it would be something like this:

        . . .    };    options {          directory "/var/cache/bind";            recursion yes;                 # enables resursive queries          allow-recursion { trusted; };  # allows recursive queries from "trusted" clients          listen-on { 10.128.10.11; };   # ns1 private IP address - listen on private network only          allow-transfer { none; };      # disable zone transfers by default            forwarders {                  8.8.8.8;                  8.8.4.4;          };            . . .  };

When done, save and close the named.conf.options file. The above configuration specifies that only your trusted servers (ie trusted servers) can query DNS servers for external domains.

Next we configure the local file to specify the DNS zones.

Learn how to configure a local file

Open the named.conf.local file on the ns1 server for editing:

sudo nano /etc/bind/named.conf.local

This file should have nothing but a few comments. In this file, we specify our forward and reverse zones. DNS zones are dedicated to managing and defining DNS records. Because our domains are within the “nyc3.example.com” subdomain, we will use it as our forward zone. Since private IP addresses are all in IP 10.128.0.0/16, we set up a reverse zone to define reverse searches within this range.

Add the forward zone with the following commands. Be sure to replace your zone names and add the private IP addresses of the secondary DNS server in the allow-transfer directory:

zone "nyc3.example.com" {      type master;      file "/etc/bind/zones/db.nyc3.example.com"; # zone file path      allow-transfer { 10.128.20.12; };           # ns2 private IP address - secondary  };

Assuming the private subnet is 10.128.0.0/16, you can create a reverse zone by adding the following commands. Note that our reverse zone letters start with 128.10, which is the reverse 10.128:

    . . .  };    zone "128.10.in-addr.arpa" {      type master;      file "/etc/bind/zones/db.10.128";  # 10.128.0.0/16 subnet      allow-transfer { 10.128.20.12; };  # ns2 private IP address - secondary  };

If your servers are spread over multiple subnets; But they are all on the same data center; You need to make sure you create an extra zone as well as a zone file for each separate subnet. When you have finished editing all the desired zones, save and close the named.conf.local file.

Now that the zones are specified in BIND, we need to create the corresponding forward and reverse zone files.

Learn how to create a forward zone file

The forward zone file is where DNS records are stored for forward DNS checks. This means, for example, when DNS receives a name query for “host1.nyc3.example.com“, it looks for the corresponding IP address in the forward zone file to resolve host1.

First we create a directory to put our zone files in. Based on named.conf.local configuration, this location should be etc/bind/zones/:

sudo mkdir /etc/bind/zones

Now we design our forward zone file based on the db.local sample zone file. Copy it to the appropriate location based on the following commands:

sudo cp /etc/bind/db.local /etc/bind/zones/db.nyc3.example.com

Now we edit our forward file:

sudo nano /etc/bind/zones/db.nyc3.example.com

Initially this file is as follows:

$TTL    604800  @       IN      SOA     localhost. root.localhost. (                                2         ; Serial                           604800         ; Refresh                            86400         ; Retry                          2419200         ; Expire                           604800 )       ; Negative Cache TTL  ;  @       IN      NS      localhost.      ; delete this line  @       IN      A       127.0.0.1       ; delete this line  @       IN      AAAA    ::1             ; delete this line

The first step is to edit the SOA record. So we put the FQDN server ns1 instead of localhost and then replace root.localhost with admin.nyc3.example.com. Each time you edit a zone file, you must increase its serial number before restarting the named process. We increase this value to 3 and so it looks like this:

@       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (                                3         ; Serial                                  . . .

Then we delete the three records at the end of the file (after SOA).

Note: If you are not sure which lines to delete, make sure to specify them in the “delete this line” section above.

At the end of the server records file, add the name with the following lines. Be sure to replace the items with your own values. The second column also indicates that these are NS records:

. . .    ; name servers - NS records      IN      NS      ns1.nyc3.example.com.      IN      NS      ns2.nyc3.example.com.

Now add record A to the hosts that belong to this zone. This includes all the servers whose names we want to end with “nyc3.example.com“. Note that you must replace your desired private IP addresses and IP addresses.

We have added A records for ns1, ns2, host1, and host2 using the private IP addresses and addresses specified in this guide:

. . .    ; name servers - A records  ns1.nyc3.example.com.          IN      A       10.128.10.11  ns2.nyc3.example.com.          IN      A       10.128.20.12    ; 10.128.0.0/16 - A records  host1.nyc3.example.com.        IN      A      10.128.100.101  host2.nyc3.example.com.        IN      A      10.128.200.102

Save the db.nyc3.example.com file and exit. The final sample forward zone file will look like this at the end:

$TTL    604800  @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (                    3     ; Serial               604800     ; Refresh                86400     ; Retry              2419200     ; Expire               604800 )   ; Negative Cache TTL  ;  ; name servers - NS records       IN      NS      ns1.nyc3.example.com.       IN      NS      ns2.nyc3.example.com.    ; name servers - A records  ns1.nyc3.example.com.          IN      A       10.128.10.11  ns2.nyc3.example.com.          IN      A       10.128.20.12    ; 10.128.0.0/16 - A records  host1.nyc3.example.com.        IN      A      10.128.100.101  host2.nyc3.example.com.        IN      A      10.128.200.102

Now let’s configure the reverse zone file (s):

How to create Reverse Zone file (s)

The Reverse Zone, where DNS PTR records are defined, is used to respond to reverse DNS queries. That is, when DNS receives a query based on 10.128.100.101, for example, it looks in the inverse zone file (s) to find the corresponding FQDN, which in this case is “host1.nyc3.example.com“.

On the ns1 server, we create an inverse zone file for each inverted zone specified in the named.conf.local file. Reverse zone file (s) are created based on the sample zone file db.127. Copy it to the appropriate location with the following command. Be sure to name your inverted file to match the definition of your inverted zone:

sudo cp /etc/bind/db.127 /etc/bind/zones/db.10.128

Edit the inverted zone file that corresponds to the inverted zone (s) defined in named.conf.local:

sudo nano /etc/bind/zones/db.10.128

Initially this file looks like this:

$TTL    604800  @       IN      SOA     localhost. root.localhost. (                                1         ; Serial                           604800         ; Refresh                            86400         ; Retry                          2419200         ; Expire                           604800 )       ; Negative Cache TTL  ;  @       IN      NS      localhost.      ; delete this line  1.0.0   IN      PTR     localhost.      ; delete this line

As with the forward zone file editing method, we need to change the SOA record and increase the serial value by one. The file looks like this:

@       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (                                3         ; Serial                                  . . .

Now we edit the two records at the end of the file (after the SOA record). If you are not sure which lines to delete; These lines are marked with the comment “delete this line” in the above section. At the bottom of the file, add your name server with the following lines. Be sure to replace your name. Also note that the second column specifies that these are NS records:

. . .    ; name servers - NS records        IN      NS      ns1.nyc3.example.com.        IN      NS      ns2.nyc3.example.com.

Then add PTR records for all servers whose IP address is edited in the subnet file zone.

In the example we are looking at, these include all hosts, because they are all on the subnet at 10.128.0.0/16. Note that the first column contains at least two parts of the server’s private IP address in reverse. Make sure you replace your private letters and IP addresses:

. . .    ; PTR Records  11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11  12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12  101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101  102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102

Save the reverse zone file and exit. If you need to add other inverted zone files, repeat the above steps for them as well. Our final inverse zone file will look something like this:

$TTL    604800  @       IN      SOA     nyc3.example.com. admin.nyc3.example.com. (                                3         ; Serial                           604800         ; Refresh                            86400         ; Retry                          2419200         ; Expire                           604800 )       ; Negative Cache TTL  ; name servers        IN      NS      ns1.nyc3.example.com.        IN      NS      ns2.nyc3.example.com.    ; PTR Records  11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11  12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12  101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101  102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102

Tutorial Check the BIND configuration structure

Run the following command to check the structure of named.conf * files:

sudo named-checkconf

If your named configuration files do not have any structural errors, you will return to the command prompt without seeing any errors. But if there are any problems with the configuration files, you should check the error message and go back to the “Configuring the Main DNS Server” section of this guide and run the named-checkconf command again after fixing the error.

The named-checkzone command is executed to check the correctness of the zone files. The first argument of this command is the name of a zone and the second argument will be the corresponding zone file, both of which must be defined in the named.conf.local file.

For example, to check the “nyc3.example.com” forward zone configuration, run the following command. Be sure to replace the highlighted items with the specifications of your servers:

sudo named-checkzone nyc3.example.com db.nyc3.example.com

Run the following command to check the “128.10.in-addr.arpa” reverse zone configuration. Change the numbers to match your invert zone and your file:

sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

Once you are sure that all the configuration files and zones are error-free, you are ready to restart the BIND service.

How to restart BIND on DNS server

Restart BIND with the following command:

sudo systemctl restart bind9

If you have enabled the UFW firewall, open BIND access with the following command:

sudo ufw allow Bind9

Your main DNS server is now up and running to respond to DNS queries.

How to configure a secondary DNS server

In most cases, setting up a secondary DNS server that responds to queries in the event of a primary server failure is a good idea. Fortunately, configuring a secondary DNS server is much easier.

Open the named.conf.options file on the ns2 server:

sudo nano /etc/bind/named.conf.options

At the beginning of the file, create an ACL with the private IP addresses of all trusted servers:

acl "trusted" {          10.128.10.11;   # ns1          10.128.20.12;   # ns2 - can be set to localhost          10.128.100.101;  # host1          10.128.200.102;  # host2  };    options {            . . .

After the directory, add the following commands:

        recursion yes;          allow-recursion { trusted; };          listen-on { 10.128.20.12; };      # ns2 private IP address          allow-transfer { none; };          # disable zone transfers by default            forwarders {                  8.8.8.8;                  8.8.4.4;          };

Save and close the named.conf.options file. This file should now look exactly like the named.conf.options file on the ns1 server, except that it is configured to listen to the ns2 private IP address. Then open the named.conf.local file:

sudo nano /etc/bind/named.conf.local

Define the zones that correspond to the master zones on the main DNS server. Note that in this case the type will be equal to “slave” and therefore the file does not contain a path and there are masters directories that must be set equal to the original private DNS IP address. If you have defined several inverted zones on the main DNS server, you should make sure to add them all here:

zone "nyc3.example.com" {      type slave;      file "db.nyc3.example.com";      masters { 10.128.10.11; };  # ns1 private IP  };    zone "128.10.in-addr.arpa" {      type slave;      file "db.10.128";      masters { 10.128.10.11; };  # ns1 private IP  };

Now save and close the named.conf.local file. Run the following command to check the configuration files:

sudo named-checkconf

When the review is complete, restart BIND:

sudo systemctl restart bind9

Allow the DNS connection to pass by changing the UFW firewall as follows:

sudo ufw allow Bind9

The primary and secondary DNS servers are now configured to resolve the private network and the corresponding IP addresses. Next we configure the client servers to use private DNS servers.

Learn how to configure DNS clients

Before all the ACL servers called “trusted” can query ACL servers, we must configure each of them to use ns1 and ns2 as name servers. This process depends on the type of operating system; But for most Linux distributions it involves adding name servers to the etc/resolv.conf/ file.

How to configure Ubuntu 20.04 clients

Networking on the Ubuntu 20.04 operating system is configured using Netplan, which allows you to write a standardized network configuration and apply it to backend networking software. To configure DNS, we need to edit the Netplan configuration file.

First find the directory related to your private network by querying the private subnet with the ip address command:

ip address show to 10.128.0.0/16

Output:

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000  inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1  valid_lft forever preferred_lft forever

In this example, the private interface is called eth1. Then create a file called 00-private-nameservers.yaml in etc/netplan/:

sudo nano /etc/netplan/00-private-nameservers.yaml

We put the following content in this file.

Note: You must replace your private network interface, DNS server addresses called ns1 and ns2, and your DNS zone:

network:      version: 2      ethernets:          eth1:                                 # Private network interface              nameservers:                  addresses:                  - 10.128.10.11                # Private IP for ns1                  - 10.132.20.12                # Private IP for ns2                  search: [ nyc3.example.com ]  # DNS zone

Note that Netplan uses the YAML data serialization format for its configuration files. Because YAML uses indentation and space to define its data structure, you need to make sure that your definition has the proper indentation structure so that no errors occur.

In this step, save the file and exit. Then we have to tell Netplan to try to use the new configuration file with the netplan try command. If there is a problem that causes networking to be lost, Netplan will automatically cancel the changes after a certain period of time and restore the status to:

sudo netplan try

Output:

Warning: Stopping systemd-networkd.service, but it can still be activated by:    systemd-networkd.socket  Do you want to keep these settings?      Press ENTER before the timeout to accept the new configuration      Changes will revert in 120 seconds

If the countdown at the output end is done correctly, the new configuration will run at least to the extent that it does not disconnect your SSH connection. Accept the new configuration by pressing the Enter key.

Now check the system DNS resolver to see if DNS configuration is applied:

sudo systemd-resolve –status

Scroll down to see the part related to your private network interface. Probably the private IP addresses of the DNS servers are listed first and then the fallback values are ready. Your domain should appear in the “DNS Domain” section:

Output:

. . .  Link 3 (eth1)        Current Scopes: DNS         LLMNR setting: yes  MulticastDNS setting: no        DNSSEC setting: no      DNSSEC supported: no           DNS Servers: 10.128.10.11                        10.128.20.12                        67.207.67.2                        67.207.67.3            DNS Domain: nyc3.example.com  . . .

Conclusion

In this article, we tried to fully acquaint you with private DNS server and teach you how to setup private DNS server on ubuntu 20.04. You can now specify your private network connections using IP addresses instead of IP addresses. This makes it easier to configure services and applications, because you no longer need to remember their private IP addresses, and files are easier to read and understand. Also, you can now change your configuration to a single location, the main DNS server, so that it points to a new server, and you do not need to edit different configuration files, which makes it easier to maintain.