The /etc/hosts file

In small networks, the /etc/hosts file on each host can be used as a simple local name resolver. The SysAdmin would add and manage entries in the hosts file. Maintaining copies of this file on several hosts can become very time-consuming and errors can cause much confusion and wasted time before they are found. Experiment 4-1 shows a simple /etc/hosts file. A default hosts file is always present but it would contain only the first two lines. Those two lines enable internal services and commands to translate the localhost hostname to 127.0.0.1 – this is an explicitly defined standard to enable services and commands to deal with the local host.

I used the /etc/hosts file to manage name services for my network for several years. It ultimately became too much trouble to maintain even with only the usual 8 to 12 computers I usually have operational. As a result, I converted to running my own name server to resolve both internal and external hostnames.

Most networks of any size require centralized management of this service with name services software such as BIND. BIND is called that because it was developed by the University of California Berkeley (UCB) in the early 1980s. Hosts use the Domain Name System (DNS) to locate IP addresses from the names given in software such as web browsers, email clients, SSH, FTP, and many other Internet services.

SOA

The first line of the SOA record contains the name of the server for the zone and the zone administrator, in this case root.

The second line is a serial number. In this example, I use the date in YYYYMMDDXX format where XX is a counter for 00 to 99. The serial number in the SOA record represents the first version of this file on October 15, 2018. This format ensures that all changes to the serial number are incremented in a numerically sequential manner. That is important because secondary name servers only replicate from the primary server when the serial number of the zone file on the primary is greater than the serial number on the secondary. Be sure to increment the serial number when you make changes or the secondary server will not sync up with the modified data.

The rest of the SOA record consists of various times that secondary servers should perform a refresh from the primary and wait for retries if the first refresh fails. It also defines the amount of time before the zone's authoritative status expires.

Times all used to be specified in seconds, but recent versions of BIND allow other options defined with W=week, D=day, H=hour, and M=minute. Seconds are assumed if no other specifier is used.

$ORIGIN

The @ symbol is used as a shortcut for this variable and any occurrence of @ in the file is replaced by the value of $ORIGIN.

NS

Note that the host, studentvm2.example.com, must also have an A record in the zone. The A record can point to the external IP address of the host or to the localhost address, 127.0.0.1.

A

The A record is the most common type of DNS database record.

AAAA

The AAAA records are used for IPv6 addresses in the DNS system. They perform exactly the same function as A records do for IPv4 addresses.

CNAME

It is good practice to have the A record contain the true hostname of the host. All of the other alias hostnames can be set using CNAME records. It is possible to have multiple A records, each with a different hostname, point to the same IP address, but this is not a good practice because it requires more work if the host’s IP address is changed. The lazy SysAdmin types as little as possible and keeps things like configuration files as simple as possible.

Lookups with the dig command on www.example.com and mail.example.com will return the CNAME record for mail or www and the A record for server.example.com. These records contain only the hostnames with no terminating dot (.), so the domain name as defined in the $ORIGIN variable will be appended to the hostname.

PTR

The PTR records are to provide for reverse lookups. This is when you already know the IP address and need to know fully qualified hostname. For example, many mail servers do a reverse lookup on the alleged IP address of a sending mail server to verify that the name and IP address given in the email headers match. PTR records are located in reverse zone files. Reverse lookups can also be used when attempting to determine the source of suspect network packets.

Be aware that not all hosts have PTR records. Most ISPs create and manage the PTR records for home and small business accounts, so reverse lookups may not provide the needed information. For example, I use Spectrum business class for my Internet connection. I use Google Domains to manage my several external domains including both.org, linux-databook.info, and mtc-llc.net. Google Domains does allow me to create PTR records, but my ISP has already created an authoritative PTR record for my external IP address. I have not taken much time to explore whether this can be changed or not but early experiments indicate not.

MX

Domains may have multiple mail servers defined. The number “10” in the above MX record is a priority value. Other servers may have the same priority or different ones. The lower numbers define higher priorities. So if all mail servers have the same priority, they would be used in round-robin fashion. If they have different priorities, the mail delivery would first be attempted to the mail server with the highest priority – the lowest number – and if that mail server did not respond, delivery would be attempted to the mail server with the next highest priority.

Other records

There are other types of records that you may encounter in the DNS database. One type, the TXT records, are used to record comments about the zone or hosts in the DNS database. TXT records can also be used for DNS security. The rest of the DNS record types are outside the scope of this chapter.

Preparation

A caching name server cannot replace our use of /etc/hosts to resolve hostnames on the internal network. Compared to using an ISP or other public name server, however, a caching name server can improve both reliability and performance when resolving external names that are commonly used, such as www.cnn.com. I have experienced loss of DNS services from my ISP many times and have found my own name server is far more reliable than most ISPs. The best part is that setting up a caching name server is quite easy. It is also the first step in creating a primary name server that we can use for name resolution inside our own network.

Setting up the caching name server

It is necessary to make a couple modifications to the /etc/named.conf file. First, add the IP address of your local student host to the “listen-on port 53” line. This enables named to listen on the external IP address of your host so that other computers can use it as a name server as well.

Configuring IPTables for DNS

The firewall on your student host currently blocks everything except SSH. The firewall must be configured to allow UDP and TCP packets inbound on your name server in order for other hosts to use it for name resolution.

We will take this opportunity to switch from firewalld to IPTables. Firewalld is a wrapper around IPTables and it can be used to create complex and flexible rules for IPTables. Firewalld is overly complex for many networks and many of the rules it creates by default are used to create a zoning structure that is simply not required in most environments. A simple IPTables firewall is just as effective and much easier to manage and understand, especially while learning about firewall rules. This falls under the tenet, “Find the Simplicity,” of my book The Linux Philosophy for SysAdmins.⁵ Simple things are easier for us as SysAdmins to manage.

We will discuss firewalls using IPTables in more detail in Chapter 6 in this volume. If you are interested in more information about firewalld, Opensource.com has an excellent article⁶ to get you started.

Start the name service

Now we start the named service and configure the named service to start at every boot.

To test your caching name server, use the dig command to obtain the IP address(es) for some common Internet web sites, such as CNN, Wired, and any others you like. Notice that the results should now show your host as the responding server rather than the virtual router or the Google name server.

Note that on the first attempt, the responding server might be one of the upstream resolvers because your host as client may have timed out waiting for the result from your host as DNS server. Additional attempts will be resolved from the cache of your host as DNS server.

We are not quite finished. The caching name server is working as we expect it to, but we do need to ensure that hosts configured by DHCP services now have the correct IP address for our new name server.

Reconfiguring DHCP

This step is important so that hosts being booted on our virtual network are served the correct IP address for the name server. We do not need to turn off the name server in the virtual router, and we do not want to do that anyway because we are using it as a forwarder. Also, I have not found a way to turn off DNS services on the virtual router.

Now let’s ensure that the host StudentVM1 receives the correct name server.

Using the top-level DNS servers

We could continue to use the forwarders as the source of our DNS information. Forwarders are not a bad thing and they are very useful in many environments. The problem is that most forwarders are configured to be the DNS servers of the ISP providing the Internet connection. My personal experience is that some ISPs DNS reliability is significantly less than stellar. For a while I used public DNS servers to test them, including Google public DNS which is reliable, fast, and not censored. Some other public DNS systems are censored or redirect you to places you did not intend and subject you to things like advertisements or pages flogging domains for sale.

However, I decided years ago that I would use my own DNS server and that I would also use the top-level DNS servers rather than forwarders. One reason for this is that the top-level servers reflect database record changes much faster than down-level servers. As a SysAdmin I find this helpful when I make changes for my own domains. I also use the top-level servers as a learning experience so that I can more fully understand how to manage that environment for my networks and others.

A really good forwarder is perfectly fine, but let’s now use the top-level servers.

Creating the forward zone file

The forward zone files are the name database files that are used to cross-reference hostnames with their assigned IP addresses. Each zone file contains the database for a single domain. Each host has at least one A record entry in the zone file with the name of the host and its IP address. Each host may also have one or more CNAME records that provide aliases for the primary hostname.

We are going to create a simple zone file for our example.com domain. This will be our local test instance of the example.com domain and not the public instance.

Adding the forward zone files to named.conf

Before your DNS server will work, however, you need to create an entry in /etc/named.conf that will point to your new zone file.

Our name server is up and responding to requests but there is more to do.

Adding CNAME records

Now we will add some CNAME records; these are like aliases. These records can be added almost anywhere after the name server (NS) line in the zone file, but I like to keep them with the A record to which they point which makes it easier to find related records. The example.com.zone file below is what yours should look like when you have finished adding the CNAME entries.

Creating the reverse zone file

A reverse zone for your domain will provide the ability to do reverse lookups. Many organizations do not do these internally, but reverse lookups can be helpful in doing problem determination. Many spam-fighting configurations such as SpamAssassin look for reverse lookups to verify valid email servers.

The serial numbers for the named.conf file, and the forward and reverse zones do not need to be the same. It is important to remember to update the serial number of any given file every time its content is altered. This does provide a way to determine the last time a file was modified if you use the same numbering strategy that I do. It is also critical in an environment where the primary server updates secondary name servers when the primary is changed.

Add the reverse zone to named.conf

We need to add a stanza for the reverse zone file to named.conf to complete the reverse lookup function.

At this point, you have a working name server using BIND. Do not turn it off or disable it. You will use your own name server for the rest of these experiments and you will be adding some entries to it.