Chapter 37
Name Serving with the Domain Name System (DNS)
Humans enjoy naming things. We name our kids, our pets, and often inanimate objects as well. Cars, boats, and computers are not immune. Networked computers are very often named. Remembering names is easier for most of us than remembering numbers. When we must remember numbers, we can; I can still remember the phone number of the house I lived in when I was a kid. However, when we can use a name instead, we tend to prefer to do so; today I can’t remember my daughter’s cell phone number, because it is programmed into my phone and I just select her picture in the directory to call her.
If you are working in a data center, especially one with a large number of servers networked together, you won’t easily remember the IP addresses of all the systems. Besides, it is fun to pick a theme and name everything on the network using that theme: varieties of apples, characters from your favorite science fiction or fantasy world, brands of guitars you wish you owned. It’s much more fun and easier to say, “Hey, Liz, can you go check on sontaran for me? It isn’t responding to my ping requests,” than to say, “Can you check on the server at IP 192.168.2.46?”
Mnemonic devices like these are useful, but we must map the names we give to the numbers the systems actually use. Mapping is just matching, connecting the words with the numbers in a way that allows a human to request https://google.com and get the information stored at https://74.125.224.72.
The Domain Name System (DNS) converts human-readable names given to networked machines to the IP addresses that machines use. (See Chapter 18, “Networking,” for more on IP addresses.) DNS works in the other direction as well, taking IP addresses and giving names.
When you set up a DNS server using the BIND DNS server software discussed in this chapter, you gain the power to set the name/IP details for domains you own, either domains that are internal on your network or Internet domains you have purchased through a registrar like Namecheap.com or GoDaddy. But these registrars run DNS servers and allow you to perform this setup through their lovely web GUIs. Why would anyone want to do this themselves? There are several possible reasons:
▸ You have an internal network, a local area network (LAN) that is not accessible from outside that network—Your internal network assigns and uses private IP addresses, but you want to make things easier for your LAN users by assigning names to the various systems. These domain names will not be assigned by a domain name registrar because they are internal only; they won’t include top-level domains like .com or .net at the end and will be usable only within the network.
▸ You want to improve performance by caching—Most DNS queries are shared by a large number of computers. If those individual computers don’t have to each connect to the Internet and get their domain names resolved by your Internet service provider’s DNS server (or another public DNS server) but can instead get that information from a server on the local network, it could speed things up. This isn’t an issue for most of us, but for large networks, it can be a huge benefit.
▸ You want to ban access to a harmful domain—Maybe an email came in to your company’s employees with a link to a specific website that is distributing viruses and you want to prevent naïve internal network users from accessing that website. You can change the IP address that is served for this domain name so that it instead forwards users to an HTML page you write up describing the problem. Your change only affects computers on your internal network, so this is not something that will make people outside your company angry or that they will even know is happening.
▸ You run a local network at home—You want to make your life a little easier when it comes time to log in to each and perform updates, so you want to give a name to each computer and allow access to each computer using a pet name for each one instead of using the IP address on your network.
No doubt we could come up with other examples. Most of us will not need to set up or run a DNS server, but you are the type of person who reads books like Ubuntu Unleashed, so you probably like to tinker with technology. It is likely that most people reading this just want to play with something new and have some fun. This chapter will get you started.
Understanding Domain Names
Simply put, a domain name is a string of characters that is used to represent an IP address. Domain names are intended to be easier to remember than strings of numbers. Generally, they are set up as a set of letters separated by dots. Each of these sets of letters is called a label. The label on the far right denotes the widest group, or top-level domain (TLD). Each label to the left is a subdomain of the one to the right of it. news.google.com is an example.
Here we see three labels:
▸ The top-level domain here is com. The original set of top-level domains is com, edu, gov, mil, net, and org. Other top-level domains include country-code TLDs such as uk or in, sponsored TLDs like aero for the Société Internationale de Télécommunications Aéronautiques, and geographic TLDs like asia. Others also exist. All TLDs are controlled by a group called ICANN, the Internet Corporation for Assigned Names and Numbers, with which domain names must be registered to work on the Internet (see www.icann.org). The TLD generally defines, with varying firmness, the content permitted on subdomains; some TLDs are far more controlled than others.
▸ The first subdomain, in this case google, is called the root zone. The root zone is required to create a fully qualified domain name (FQDN), which is the combination of the root zone and the TLD. When you register a domain name with a registrar, so you can put a website on the Internet, you register a root zone for a TLD, as in matthewhelmke.com or matthewhelmke.net. The complete FQDN is required for DNS to work across the Internet.
▸ After the first subdomain, others may be created, such as news in our example. These are optional. Some standard ones are www, mail, and ftp, which each denote specific uses for defined subdomains. They are not required, but if you want to host more than one thing using a FQDN, you must define and use subdomains. Subdomains are defined in a DNS server in the same manner as TLDs.
When a full set consisting of TLD and all needed subdomains is put together, this is called a hostname. On a local network, this could be a single word. On the Internet, it requires at least a TLD and root zone and often includes at least one other subdomain, as in www.icann.org. Another way to define a hostname is any domain name that is associated with one or more IP addresses. The “or more” is often used in load balancing between one or more machines. You can have DNS cycle from one IP address to another each time the hostname is requested.
DNS Servers
A DNS server receives a request or query and responds by resolving that query and returning the information mapped to it, if it exists. There is not one canonical DNS server for the entire Internet. Instead, when a domain is registered, that registration is listed on a series of ICANN-run servers scattered around the world. Contained in that registration is information about where the authoritative DNS information is stored for that domain. This is usually, but not necessarily, a DNS server or set of DNS servers operated by the domain name registrar.
DNS requests work in a hierarchical fashion. Here is an example:
A full request comes in to your Internet service provider’s DNS server. If the DNS server knows the information, it responds.
If the DNS server recognized the root name but not a subdomain, it submits a request itself to a known server with information about that root name and, if successful, it returns the information it receives.
If the DNS server cannot find any cached information about the hostname, it contacts an ICANN server using the TLD. The ICANN server can then respond with the information it has, which at a minimum is the registered IP address that correlates to the hostname, if it exists.
This hierarchy causes some DNS requests to take longer than others. Sometimes the search involves multiple DNS servers across a wider and wider set of data. It also means that one server going down is not catastrophic; instead, the information can be searched for and found elsewhere.
DNS Records
All DNS records are placed in a zone file (discussed further later in this chapter, in the section “Setting Up a DNS Server with BIND”). There are several ways to define the IP address/hostname. Some of these DNS records are optional. Many can have multiple entries. The most critical and commonly used ones are listed here, but many more are available, and many more options are also available than are listed here. See https://en.wikipedia.org/wiki/List_of_DNS_record_types for more information.
A
The A record maps a hostname to a 32-bit IPv4 address, as in this example:
example.com IN A 192.0.2.0
The hostname comes first. IN indicates Internet. A indicates that this is an A record. The IPv4 address comes last.
AAAA
The AAAA record maps a hostname to a 128-bit IPv6 address, as in this example:
example.com AAAA 2001:db8::/32
The hostname comes first, followed by four As because 128-bit IPv6 addresses are four times larger than 32-bit IPv4 addresses. (See Chapter 18 for more about IPv4 and IPv6 addresses.) The IPv6 address comes last.
CNAME
The CNAME record maps one or more aliases to the canonical name of a machine. The aliased domain receives all the subdomains and DNS records of the original, canonical name it is matched with. For example, if you have a machine named weirdname.example.com that is set up to be an email server, but you want to use a different URL, you can set up an alias so it also uses mail.example.com, as in this example:
mail.example.com CNAME weirdname.example.com
The alias comes first. CNAME indicates that the alias is being mapped to the canonical name that comes next. The server that has an A record is listed last. CNAME records never point to IP addresses, only to other domain names that are already defined using A or AAAA records.
One neat trick is that you can create a CNAME record for every subdomain on a machine that is running multiple services, such as ftp.example.com, www.example.com, and mail.example.com, and have every one of them point to the same A or AAAA record for the server with the name example.com. That A or AAAA record points to the IP address, so if you ever need to change the IP address, such as when you move your server or establish a new server, you only have to change the IP record in one place.
MX
An MX record maps a domain name to a list of mail servers for that domain. (MX comes from “mail exchange.”) If you do not use a domain for email, this record is not needed. Here is an example of an MX record:
example.com. 14400 IN MX 0 mail.example.com.
First, notice the dot after each of the two domain names. These are vital, and omitting them causes email to be misrouted.
The example says that any email coming in to an address @example.com (leftmost field) should be routed to the server at example.com (rightmost field). The DNS A or AAAA record for mail.example.com or a CNAME record sets the IP address of that mail server. The 14400 defines how often, in seconds, to update the DNS entry in any other server that has cached this record; 14400 is 4 hours and is standard. MX defines this as a mail exchange record.
The 0 indicates preference because you can list more than one MX server. Smaller numbers are preferred over larger numbers. Setting multiple servers to the same value means that a random server with that value is to be used. If there is only one, use 0. A multiple-server MX record looks like this:
example.com. 14400 IN MX 10 mail.example.com. example.com. 14400 IN MX 20 mail2.example.com.
NS
An NS records maps a domain name to a list of DNS servers that are authoritative for that domain. It is most used at domain name registrars and tells any query that comes in to the domain name registrar where to look for the complete DNS record. For example, a request from an ICANN server would look first at the domain name registrar, which would then look wherever it says in the NS record, if the complete DNS is not hosted here. Here is an example:
example.com. IN NS ns1.domainregistrationcompany.com.
The domain comes first, again with a dot at the end. This is followed by IN for Internet and NS for name server. At the end, the name server is listed, again with a dot at the end.
SOA
A start of authority, or SOA, record specifies the DNS server that provides authoritative information about a domain, the email address of the domain administrator, the domain serial number, and configuration for timers related to refreshing the zone. This is a vital part of the zone file. Here is an example:
; name TTL class rr Nameserver email-address example.com. 14400 IN SOA ns.mydomainnameserver.com. root.ns.mydomainnameserver.com. ( 2018080600 ; serial number 86000 ; refresh rate in seconds 7200 ; update retry in seconds 3600000 ; expiration in seconds 600 ; minimum in seconds )
In this file, a semicolon denotes the beginning of a comment, so everything after it is ignored by the system and is intended only for humans reading the file. The first line reminds you how to format the next line. Everything else in the file is contained in the parentheses, the first of which must be on the first line.
This example uses example.com as the domain. Remember the dot at the end.
14400 is the TTL, or time in seconds that you are allowing the record to be cached by other servers before they have to submit a query again. If set to 0, it is not permitted to be cached at all.
IN is the class or type of the record—in this case, Internet. No other options are in use any more.
SOA denotes this is a start of authority record.
This example uses ns.mydomainnameserver.com as the sample domain of the DNS server. Replace this with your DNS server’s domain and remember the dot at the end.
The email address of the domain name administrator is a little confusing because you expect an @ symbol but none exists. In the preceding example, root.ns.mydomainnameserver.com means [email protected]. Replace this with the email address for your admin, using a dot instead of the @ symbol. Remember the dot at the end.
The serial number is a revision numbering system. It is changed every time the file is changed. Convention is to use YYYYMMDDnn, where YYYY is year, MM is month, DD is day, and nn is an extra number to allow you to increment when multiple edits and saves occur in one day. For example, 2018080600 is the first edit on August 6, 2018.
The refresh rate sets the time, in seconds, when the slave DNS server will refresh from the master DNS server.
The retry rate sets how long to wait after a failed refresh before making another attempt.
The expiration sets how long to keep a zone file cached.
Minimum is the default time that slave servers should cache the zone file. If your DNS record changes frequently, you want to set this to a low number, like 12 hours or so. If infrequently, then every one to five days is a good balance between keeping updated and keeping requests served quickly.
TXT
You can put any text you like in a TXT record. This record is most commonly used to implement the Sender Policy Framework (SPF), which is an email validation system designed to help detect and prevent email spam by detecting email spoofing. With spoofing, email is sent out to look like it originated in one location when it actually originated somewhere else. SPF records must indicate the version identifier for SPF and a default mechanism. Here is an example of SPF info in a TXT record:
example.com. TXT "v=spf1 -all"
This indicates to use SFP version 1 and that no servers at this domain send email. If your server does not send email, use this to prevent email/web hosting companies from blocking your domain if someone tries to send email pretending to come from your domain.
If your server sends email, you use something like this:
example.com. TXT "v=spf1 mx -all"
The difference here is that mx has been added to indicate that any servers tied to this domain may send email.
Many more variations of SPF records are available. Itemize what you have and then read the specification at www.openspf.org/SPF_Record_Syntax to learn what you need to write.
Setting Up a DNS Server with BIND
The Berkeley Internet Name Domain (BIND) software has been foundational to the Internet since the 1980s. The original BIND was created at the University of California, Berkeley, using grant funding. It was released as free and open source with the BSD (Berkeley Software Distribution) version of UNIX and was quickly adopted as the standard software for DNS. The Internet Systems Consortium now maintains BIND and provides updates and documentation at www.isc.org.
When you create NS records for your domains with your domain name registrar, pointing at ns1.domainregistrationcompany.com or whatever domain the registrar gives you, you are most likely pointing to a server running BIND, although other options exist. This section shows how to install and set up a very basic DNS server using BIND.
Start by installing bind9 from the Ubuntu software repositories.
Next, use your favorite text editor to open /etc/bind/named.conf.local, which is a configuration file set up with default settings. This is where you must declare the zones you are setting up and associating with the domain. Zones are domain names that are referenced in the DNS server. Leave all the default text in the file and add this to the end of the file, after replacing example.com with your domain name:
# This is the zone definition.
zone "example.com" {
type master;
file "/etc/bind/zones/example.com.db";
};
Save the file and exit.
Next, open the configuration options file at /etc/bind/named.conf.options and modify the section titled forwarders by replacing 8.8.8.8 shown in this example with the IP address of your provider’s DNS server:
forwarders {
8.8.8.8;
};
Save the file and exit.
Now you must create a zone definition file. First, create a directory to hold it:
matthew@seymour:~$ sudo mkdir /etc/bind/zones
Then create a new file but replace example.com in this example with your domain:
matthew@seymour:~$ sudo touch /etc/bind/zones/example.com.db
This zone definition file will contain all the addresses and machine names that you are hosting. This is where you enter all the DNS records discussed in the previous section of the book. Each record gets its own line. For human readability, it is nice to put an empty line after each one and start each record with a comment, using // to begin comment lines. In this example, replace example.com with your domain, replace ns with the domain for your DNS server, and enter whatever other records you want to enter, modifying as the comments note here:
example.com. 14400 IN SOA ns.example.com. admin.ns.example.com. ( 2013080600 ; serial number 86000 ; refresh rate in seconds 7200 ; update retry in seconds 3600000 ; expiration in seconds 600 ; minimum in seconds ) // Replace the following lines as necessary: // example.com = your domain name // ns1 = your DNS server name // mta = your mail server name example.com. IN NS ns1.example.com. example.com. IN MX 10 mta.example.com. // Replace the IP address with your IP addresses. www IN A 192.168.0.2 mta IN A 192.168.0.3 ns1 IN A 192.168.0.1
Now restart BIND:
matthew@seymour:~$ sudo systemctl restart bind9.service
You can also use start, stop, and so on, as you would with other services using systemd.
You should now be all set. To test your DNS server, edit /etc/resolv.conf (after making a backup of the original!) and replace the contents with the following, replacing example.com with your domain name and 192.168.1.1 with the address of your new DNS server:
search example.com nameserver 192.168.1.1
Then test that your DNS server is functioning by using ping to see what it returns for example.com:
matthew@seymour:~$ ping example.com
In addition to the ping utility just mentioned, dig is another excellent tool for reviewing DNS records. You may also find nslookup and whois useful. Also, named-checkzone is included with BIND and may be useful to you.
References
▸ www.bind9.net—A website with tons of useful information about both DNS and BIND
▸ DNS and BIND by Cricket Liu and Paul Albitz—The canonical guide to understanding both of these technologies