DNS, or Domain Name System, is one of the most integral parts of the internet. Anyone who uses the internet uses the DNS service every day. However, it is also massively overlooked in comparison to other internet frenzies. In short, the DNS service converts URLs to IP addresses. As you should know by now, an IP address is a unique number that identifies everything connected to a network.
If you want to pursue a career in Linux administration, you need to have a strong understanding of how DNS works. This guide gives a working overview of core DNS concepts and practical examples of a Ubuntu DNS server.
Deep Dive Into the Domain Name System (DNS)
Since DNS consists of several services and intricate interactions between them, users must familiarize themselves with the core terminologies to understand what’s happening behind the scene. That’s why we have divided the entire guide into several sections. The first one offers a brief introduction to terms and concepts, while others deal with workflows and configurations.
Overview of the Core DNS Terms and Concepts
When working with DNS, you will face various terms and terminologies such as Hosts, Zones, TLDs, and Resolvers. The below section provides a concise introduction to some of these concepts.
DNS
DNS or Domain Name System is the mechanism that interprets a Fully Qualified Domain Name (FQDN) to a specific IP address. This is the address our systems use for sending and retrieving web resources. DNS consists of multiple systems and performs multi-directional communications to retrieve the IP address associated with an URL.
Domain Name
Domain names are human-readable addresses associated with web resources. They remove the ambiguity of remembering a large number of IP addresses. For example, google.com is the domain name for the Google search engine. When you enter this in your browser’s address bar, it utilizes the DNS system to find the IP address.
IP Address
An IP Address is a unique number assigned to all devices connected to the internet at a given point. IP addresses have several classes and two major versions. Most people use IP version 4 as of now. IPv4 addresses comprise four octets, each separated by a period “.” symbol.
TLD
TLDs or Top Level Domains sit at the highest level in the hierarchy of domain names. These are the most general portions of a domain name and are located at the furthest position to the right. For example, the “com” portion is the TLD of the URL www.example.com. Some popular top-level domains include “com”, “org, “gov”, “net”, and “edu”.
Hosts
Owners of a domain can define several different hosts within that domain. These can be used to access separate services or computers. Most web servers can be accessed through the bare domain, like example.com, or via the host declaration, like www.example.com. The “www” portion is the host here. Another common usage of a host is providing API access like api.example.com.
Sub-Domain
Subdomains are simply a subset of a domain. This allows site owners to have multiple subdomains under a parent domain. For example, a domain called university.edu may have several subdomains for each of its departments, such as www.cs.university.edu or www.phy.university.edu.
The difference between hosts and subdomains is that the former specifies different computers or services, while the latter divides the parent domain into different groups.
Fully Qualified Domain Name
A Fully Qualified Domain Name or FQDN is the absolute domain of a website. It represents the root of the domain in question. A domain usually contains multiple sub-routes or paths, such as www.example.com/new/example.
Here, the www.example.com section is the FQDN. Additionally, the FQDN always ends with a period “.” symbol like “www.example.com.”. But, users are not required to enter this trailing dot as the client program takes care of it.
Name Server
In DNS, a name server is a computer system that translates domain names to addressable IPs. They do most of the actual work within a Ubuntu DNS infrastructure. As name servers have to deal with thousands of requests per second, they often redirect additional requests to new servers.
Moreover, name servers can also work as authoritative servers. In this scenario, they answer queries under their control and serve cached responses from other servers otherwise.
Zone Files
Zone files are actual text files that store the relations between domain names and associated IP addresses. A DNS system retrieves the IP information of an FQDN from this document. They are stored on the name server and specify which resources are accessible for a particular domain. If the information is not available in the zone file, they point to the location that has that data.
Root Server
As discussed already, DNS is a hierarchical system that comprises multi-level components. The root server sits at the top of this hierarchy. These are extremely powerful servers maintained by multiple organizations and are controlled by the ICANN (Internet Corporation for Assigned Names and Numbers).
Currently, there are 13 primary root servers around the world, and each of them is mirrored for increased availability.
When someone asks for a root server, the request is forwarded to the nearest mirror. Root servers handle queries regarding top-level domains. Whenever there is something that a lower-level name server cannot resolve, the root server is presented with that question.
However, root servers do not have IP information. They instead point to the name servers that manage that specific TLD.
TLD Server
TLD servers sit beneath root servers in the DNS hierarchy. Root servers direct DNS request entities toward the TLD server of that request. The TLD server then redirects the requesting entity to the name server, which has the specific IP information for the domain in question.
Domain-Level Name Servers
TLD servers redirect the requesting entity to the domain-level name server. This is the server whose zone file contains the IP mappings for the domain. So, this is the name server with the specific IP address for the requested domain name.
Resolver
A resolver is the request entity that is responsible for retrieving the IP information of a domain from the DNS. Usually, it is configured within the client system, like in the browser or through a custom Ubuntu DNS setting.
Most people use the DNS resolver provided by their ISPs. A resolver is an abstraction that allows the end-user to be ignorant of what’s happening under the hood. It can work recursively until it retrieves the IP address of a given domain.
Records
We have already discussed that the name server stores domain-to-IP mappings in the zone file. The information in the zone files is saved as records. There are many types of records in a zone file. We’re touching on some of the most important ones here.
SOA Records
SOA stands for Start of Authority and is a mandatory record for all zone files. The first actual record in a zone file must be of type SOA. It may take some time before you fully understand SOA records. Till then, remember the following takeaways. First of all, an SOA record looks similar to the following snippet.
example.com. IN SOA ns1.example.com. admin.example.com. ( 12083 ; serial number 3h ; refresh interval 30m ; retry interval 3w ; expiry period 1h ; negative TTL )
The essential parts are the following.
- example.com – This is the root of the zone and specifies that the file is for the “example.com.” domain.
- IN SOA – The “IN” stands for the internet, and SOA represents the fact that this is an SOA record.
- ns1.example.com. – It is the primary name server for the “example.com.” domain. Also, if you’ve configured a dynamic Ubuntu DNS, your primary name server goes here.
- admin.example.com. – It is the email address of the admin responsible for this particular zone. The “@” symbol is substituted with a period “.” symbol for the email address.
- 12083 – This is the serial number for this zone, and you are required to increment this serial each time you update the zone file. This is how secondary servers determine that a change has taken place in this zone.
- 3h – The refresh interval for the zone specifies how longer secondary servers should wait before looking for changes in the zone file of the primary server.
- 30m – The retry interval of a zone specifies how longer secondary servers should wait before trying again to poll the primary server.
- 3w – It is the expiry period and defines how longer secondary servers should try to establish successful communication. If a connection isn’t established within this timeframe, the secondary servers will stop responding as authoritative for this zone.
- 1h – If the name server can not find the requested name in this zone file, it will cache a name error for this time.
A and AAAA Records
The A and AAAA record map a host to an actual IP address. The “A” record maps a host to a working IPv4 address, and the “AAAA” records maps hosts to IPv6 addresses. Below is the general format for these record types.
hostname IN A IPv4Address hostname IN AAAA IPv6Address
Below is an appropriate example using the ns1 name server defined in the SOA record.
ns1.example.com. IN A 111.112.221.222
The next “A” record defines the web server as “www”.
www IN A 111.112.211.212
CNAME Records
CNAME records represent an alias for the name server defined by an A or AAAA record. For example, the following snippet declares a host called “server” using an A record and then creates a “www” alias for that host.
server IN A 111.111.111.111 www IN CNAME server
However, creating aliases may result in a performance decline since they require an additional query to the server. CNAME records are usually used for giving a canonical name to an outside resource.
MX Records
MX records are used to specify mail exchanges for a domain name and help to receive email communications that arrive at your Linux mail server. Unlike most record types, they do not map hosts to IPs because they apply to the entire zone. Below is a simple example of an MX record.
IN MX 10 mail.example.com.
Notice that no host is defined in this record, and it also has a new number, “10”. This is used for indicating preference. If there are multiple MX records, emails will be directed to the server that has the lowest preference number.
NS Records
NS records specify the name servers that are used for a zone. Although it may seem irrelevant since the zone file already exists on the name server, it’s used due to some reasons. Often, the zone file served by a DNS server might be a cached copy of a different server.
IN NS ns1.example.com. IN NS ns2.example.com.
Like MX records, NS records are also defined for an entire zone and do not require host names. Moreover, many Ubuntu DNS serves to consider zone files to be invalid if they don’t contain multiple ns records. So, most zone files define more than one name server.
PTR Records
PTR records specify a name associated with a working IP address and are simply an inverse of the A or AAAA record. They must begin at the .arpa root and are commissioned to the owner of the IP. The delegation of IPs to organizations and service providers is handled by the Regional Internet Registries (RIRs).
222.111.222.111.in-addr.arpa. 33692 IN PTR host.example.com.
The above snippet provides a basic example of a PTR record. It maps the IP 222.111.222.111 to “host.example.com.”.
CAA Records
CAA records define which Certificate Authorities(CA) can issue SSL/TLS certificates for a domain name. If there is no CAA record defined for a domain, any CA can issue a certificate. However, if a CA is defined explicitly, then only that specific authority can issue the certificate.
example.com. IN CAA 0 issue "letsencrypt.org"
A CAA record looks like the above snippet. The host, IN, and CAA fields are DNS-specific, while flags (0), tags (issue), and values (“letsencrypt.org”) are CAA-specific. The CA will ignore the record if the flag is set to “0”, but it must refrain from issuing a certificate if it’s set to “1”.
How does DNS work?
Now that we have learned all the major terms and associated concepts, we can discover how an actual DNS request works. We will offer a simple real-world illustration and analyze the path of the query carefully.
Let’s say we are trying to establish a connection from my Ubuntu-powered laptop device to the website “www.example.com.“. I open an internet browser, type in the URL at the address bar, and press enter. At first, the client or my browser, in this case, will check if the IP of “www.example.com.” already exists in its cache. If it finds that, it will skip all the later steps.
When the client fails to find the IP in the browser cache, it forwards the request to the resolver or the ISP’s name server, in my case. The resolver tries to see if any other users have recently been to this website and, if so, then locates the IP from its cache. Otherwise, the resolver forwards the request to one of the root name servers.
The root server returns the address of the TLD name server for that domain, which is a “.com” name server in this example. Now, the resolver sends a request to the TLD server to see if it has the expected result. However, the TLD server doesn’t have the information but knows which name the server does. It returns the address of that name server with the domain to IP mappings for our URL.
Once the resolver asks the name server for our domain, it returns the appropriate IP. The resolver then sends the actual IP address to the client program, which can now establish the necessary communication.
As you can see, the path of a total Ubuntu DNS request comprises many recursive and iterative queries. Moreover, several layers of caches are added to this mechanism to make things simple and faster.
That’s why most of the time, your browser doesn’t need to wait for a full DNS query. For example, if you’re going to a popular website like YouTube, the chances are that your ISP’s cache already has the IP of that domain.
Moreover, Ubuntu DNS configurations can vary largely based on the application and role of the server. When configured as a caching name server, the DNS server will locate the answer to the client queries and remember the answer for future queries.
If you set your DNS as a primary server instead, it will read the data for a zone from the zone file and be authoritative for that zone only. When configured as a secondary server, it will fetch the data from another name server’s zone file.
Installing and Configuring a Ubuntu DNS Server
Now that we have discussed how DNS works and most of the key concepts, we may start to create our very own DNS server. For this part of the tutorial, we will use the BIND (Berkley Internet Naming Daemon) program, which is the most popular DNS implementation and provides extremely solid performance even under heavy load.
Use the following simple command to install BIND on your Ubuntu machine. We also recommend users download dnsutils, a robust package for testing and troubleshooting issues with your DNS server.
$ sudo apt install bind9 $ sudo apt install dnsutils
The configuration files for BIND are located in the /etc/bind directory of your Linux file system. The main configuration data are saved in the /etc/bind/named.conf file. The /etc/bind/named.conf.options file is used for setting global options, the /etc/bind/named.conf.local for configuring the zones, and the /etc/bind/named.conf.default-zones file for managing the default zones.
Earlier, Ubuntu used the /etc/bind/db.root file for describing the root name servers. Now, it uses the file /usr/share/dns/root.hints instead. This file is thus referenced within the /etc/bind/named.conf.default-zones file.
Moreover, it is possible to configure the same Ubuntu DNS server to be a primary, secondary, and caching server. The roles change based on the zones the server is serving. For example, you can configure your server as the Start of Authority (SOA) for one zone while offering secondary services to a different zone. In the meantime, it can offer caching services for hosts that are on your local LAN.
Primary Server
In this section, we will show how to create Ubuntu DNS configurations for a primary name server. This server will handle queries for the FQDN “example.com“. Replace this domain name with your URL to implement the same configurations.
First, we will need to configure the forward zone file. Open the /etc/bind/named.conf.local file using your favorite Linux text editor and add the following snippets.
$ sudo nano /etc/bind/named.conf.local
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
};
You can configure your BIND DNS server to get automatic updates whenever you change the configuration files. To do this, use the file /var/lib/bind/db.example.com in the above snippet and the following command.
$ sudo cp /etc/bind/db.local /etc/bind/db.example.com
The above command copies an already existing zone file that we will be using as the template for our next steps. Now, we will edit our zone file (/etc/bind/db.example.com) and make some required changes.
$ sudo nano /etc/bind/db.example.com
First of all, we replace “localhost.” with the FQDN of our server, which is “example.com.”. Don’t forget to add the trailing “.” in the FQDN. Now, change “127.0.0.1” to the actual IP of your name server and “root.localhost.” to an active email address. Remember to use a “.” instead of the “@” symbol in your mail address. We also recommend adding a comment documenting the FQDN for this zone file. Our file now looks like the following.
; ; BIND data file for example.com ; $TTL 604800 @ IN SOA example.com. root.example.com. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ------------------------------------------------------------------ ------------------------------------------------------------------
We have only modified the SOA record till now. It’s time to make changes to the NS record and the A records of our zone file. Change the “localhost.” part of the NS record to match your name server, “ns.example.com.” for our demo FQDN. Replace the “127.0.0.1” portion of the first A record with the Ip of your name server. We have used “192.168.1.10”. Finally, create an A record for our name server, “ns.example.com” by adding the last line in the below snippet.
;
; BIND data file for example.com
;
$TTL 604800
@ IN SOA example.com. root.example.com. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
@ IN NS ns.example.com.
@ IN A 192.168.1.10
@ IN AAAA ::1
ns IN A 192.168.1.10
This is how the final configuration will look for our primary server’s forward zone.
Remember to increment the serial number, or else BIND will not notice the changes to its configurations. When you add multiple chances, you don’t need to change the serial each time. If you want to add Ubuntu DNS records, add them below the above options. Once everything is configured, restart BIND by using the below command.
$ sudo systemctl restart bind9.service
Now that our forward zone file is configured properly let’s modify the reverse zone file. This allows the Ubuntu DNS server to resolve an IP to an FQDN. Simply edit the /etc/bind/named.conf.local file and add the below snippets.
$ sudo nano /etc/bind/named.conf.local
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192";
};
You must replace “1.168.192” with the first three octets of your network. Moreover, the zone file should be named accordingly. Replace the “192” portion of the zone file “/etc/bind/db.192” to match the first octet of your network. So, for example, if you are on the network 10.1.1.1/24; your zone file will be “/etc/bind/db.10” and the entry “1.168.192.in-addr.arpa” will be “10.1.1.in-addr.arpa“.
$ sudo cp /etc/bind/db.127 /etc/bind/db.192
We have created the /etc/bind/db.192 file by copying an existing template file. Now, let’s edit this file and make the same modifications to the /etc/bind/db.example.com file.
$ sudo nano /etc/bind/db.192
;
; BIND reverse data file for local 192.168.1.XXX net
;
$TTL 604800
@ IN SOA ns.example.com. root.example.com. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.
10 IN PTR ns.example.com.
Remember to increment the serial number on each successive change to the reverse zone file. Plus, for every A record configured in /etc/bind/db.example.com, you must always add a PTR record in the file /etc/bind/db.192.
Once all of this is done, restart the BIND service.
$ sudo systemctl restart bind9.service
Secondary Server
As we have already said, creating secondary servers is an excellent idea due to several reasons, one of them being increased availability. This will make your Ubuntu DNS servers more resilient and aid in serving more clients. So, check out the below section to create a secondary name server.
First, you need to allow zone transfer on your primary server. Simply edit the forward and reverse zone configurations and add the “allow-transfer” option to the zones.
$ sudo nano /etc/bind/named.conf.local
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
allow-transfer { 192.168.1.11; };
};
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192";
allow-transfer { 192.168.1.11; };
};
Now substitute “192.168.1.11” with the IP address of your secondary server.
Then restart BIND on your primary server by issuing the following command.
$ sudo systemctl restart bind9.service
Now you need to install BIND on the secondary server. Then proceed to edit the /etc/bind/named.conf.local file and add the following for both the forward and reverse zones.
zone "example.com" {
type slave;
file "db.example.com";
masters { 192.168.1.10; };
};
zone "1.168.192.in-addr.arpa" {
type slave;
file "db.192";
masters { 192.168.1.10; };
};
Simply replace “192.168.1.10” with the IP of your primary name server. Restart BIND once more, and you’re good to go.
$ sudo systemctl restart bind9.service
Note that a Ubuntu DNS zone is only transferrable when the serial number on the primary server is greater than that on the secondary server. However, you can circumvent this by adding the option “also-notify { ipaddress; };” to the /etc/bind/named.conf.local file on your primary server. After this, the file should look like the following.
$ sudo nano /etc/bind/named.conf.local
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
allow-transfer { 192.168.1.11; };
also-notify { 192.168.1.11; };
};
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192";
allow-transfer { 192.168.1.11; };
also-notify { 192.168.1.11; };
};
Caching Server
You don’t need to do much to create a caching name server since the default configurations already act as a caching server. Just edit the /etc/bind/named.conf.options file and uncomment the forwarders section. Enter the IP of your ISP’s DNS server, as shown below.
$ sudo nano /etc/bind/named.conf.options
forwarders {
1.2.3.4;
5.6.7.8;
};
Don’t forget to replace the IPs accordingly with actual name servers.
Now open up your favorite Linux terminal emulator and issue the below command for restarting BIND.
$ sudo systemctl restart bind9.service
Testing and Troubleshooting Ubuntu DNS Configurations
Once you are done setting up your DNS name servers, you would want to check if they are working as intended or not. The first step for doing so is to add the IP of the name servers to the resolver of a host machine. The simplest way of doing this is to edit the /etc/resolv.conf file and make sure the nameserver line points to 127.0.0.53 . Then add a search parameter for your FQDN, as illustrated below.
$ sudo nano /etc/resolv.conf
nameserver 127.0.0.53 search example.com
You can easily find out the DNS server used by your local machine’s resolver by using the following command.
$ systemd-resolve --status
Note that you may want to also add the secondary server’s IP to your client configuration. This will provide better availability and make use of that secondary name server you just created.
Another useful way of checking DNS configurations is to use the Linx dig command. Simply use dig against the loopback interface and see if it is listening on port 53 or not.
$ dig -x 127.0.0.1
The below command utilizes the Linux grep command to filter out the relevant information.
$ dig -x 127.0.0.1 | grep -i "53"
If you have configured BIND to be a caching server, use dig to check an outside domain and take note of the query time.
$ dig ubuntu.com
Run the command once more and check if the query time has decreased or not. It should reduce significantly if the caching is successful.
You can also use the Linux ping command to see how clients make use of Ubuntu DNS for resolving hostnames to IPs.
$ ping example.com
Ending Thoughts
A solid understanding of the DNS system is crucial to land a high-paying CS job as a system or network administrator. The purpose of this guide is to help beginners master the principles behind DNS as fast as possible. Moreover, our editors have also provided a working illustration of various Ubuntu DNS configurations for aiding your learning process.
By the end of this tutorial, you should obtain a rigid knowledge of core DNS concepts and hands-on experience. Hopefully, we were able to provide you with the essential insights. Do not forget to comment if you have any more questions or suggestions.
