Name Serving with the Domain Name System (DNS) - Ubuntu as a Server - Ubuntu Unleashed 2017 Edition (2017)

Ubuntu Unleashed 2017 Edition (2017)

Part IV: Ubuntu as a Server

Chapter 37. Name Serving with the Domain Name System (DNS)


In This Chapter

Image Understanding Domain Names

Image Setting Up a DNS Server with BIND

Image References


Humans enjoy naming things. We name our kids, our pets, and we often name inanimate objects as well. Cars, boats, and computers are not immune. This is especially true of networked computers. 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 each system. 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. “Hey, Liz, can you go check on sontaran for me? It isn’t responding to my ping requests.” Is so much more fun to say and easy to communicate than “...can you check on the server at IP 192.168.2.46...”

Mnemonic devices like these are useful, but they then 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 http://google.com and get the information stored at http://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 both directions, taking names and giving IP addresses or taking IP addresses and giving names.

When you set up a DNS Server using the Bind 9 DNS server software we discuss in this chapter you gain the power to set the name/IP details for domains you own, either internal on your network or internet domain names 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:

Image You have an internal network, a local area network that is not accessible from outside that network, also called a LAN. 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 of them and will only be use-able within the network.

Image 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.

Image 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 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.

Image You run a local network at home. You want to make your life a little easier when it comes time to login to each and perform updates, so you want to give names to each computer and allow access to each computer using a pet name for each instead of the IP address on your network.

No doubt we could come up with other examples. To be honest, 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 and you like to tinker with technology. It is likely that most people reading this just want to play 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. Here is an example: news.google.com.

Here we see three labels.

Image The top level refers to the top-level domain, in this case com. Other top-level domains include the original set of com, edu, gov, mil, net, and org. Others include country-code TLDs such as uk or in, sponsored TLDs like the Société Internationale de Télécommunications Aéronautiques owned aero, and geographic TLDs like asia. Others also exist. All are controlled by a group called ICANN, the Internet Corporation for Assigned Names and Numbers, with whom 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.

Image 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.

Image 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 are to host more than one thing using a FQDN, then 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 are put together, this is called a host name. 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 host name is any domain name that is associated with one or more IP addresses. The “or more” is often used when 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

DNS servers receive requests or queries and respond 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:

Image A full request comes in to your internet service provider’s DNS server. If it knows the information, it responds.

Image If it recognized the root name, but not a subdomain, it will submit a request itself to a known server with information about that root name and, if successful, it will return the information it receives.

Image If it cannot find any cached information about the host name, it will contact an ICANN server using the TLD. The ICANN server can then respond with the information it has, which at a minimum will be the registered IP that correlates to the hostname, if it exists.

This hierarchy is why some DNS requests take longer than others; sometimes the search involves multiple DNS servers across a wider and wider set of data. It also means that if one server goes down, this is not catastrophic; instead, the information can be searched for and found elsewhere.

DNS Records

All of these are placed in a zone file, which is discussed further in Setting Up a DNS Server with BIND. There are several ways to define the IP/hostname. Some of these DNS records are optional. Many can have multiple entries. The most critical and commonly used ones are listed here, but there are many more available, and many more options available that what is 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 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. The four As next, using four because 128-bit IPv6 addresses are four times larger than 32-bit IPv4 addresses. See Chapter 18, “Networking,” for more about IPv4 and IPv6 addresses. Finally, the IPv6 address.

CNAME

This 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:

Click here to view code image

mail.example.com CNAME weirdname.example.com

The alias comes first. CNAME indicates this 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 CNAME records 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 record:

Click here to view code image

example.com. 14400 IN MX 0 mail.example.com.

First off, notice the important dots after the two domain names. These are vital because omitting them will cause 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 mailserver. 14400 defines in seconds how often 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 zero indicates preference. This is 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:

Click here to view code image

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:

Click here to view code image

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 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:

Click here to view code image

; name TTL class rr Nameserver email-address
example.com. 14400 IN SOA ns.mydomainnameserver.com. root.ns.mydomainnameserver.com. (
2013080600 ; serial number
86000 ; refresh rate in seconds
7200 ; update retry in seconds
3600000 ; expiration in seconds
600 ; minimum in seconds )

In this file, the semicolon denotes the beginning of a comment, so everything after it is ignored by the system and is intended only for the human reading the file. The first line reminds us 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.

We are using example.com as our domain in the example. Remember the dot at the end.

14400 is the TTL or time in seconds that we 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.

Our example uses ns.mydomainnameserver.com as the sample domain of our DNS server. Replace this with your DNS server’s domain. Remember the dot at the end.

The email of the domain name administrator is a little confusing, because we expect an @ symbol and none exists. In the example above, root.ns.mydomainnameserver.com means root@ns.mydomainnameserver.com. 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, 2013080600 is the first edit on the 6th of August in 2013.

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 changes frequently, you want to set this to a low number, like 12 hours or so. If infrequently, then every 1 to 5 days is a good balance between keeping updated and keeping requests served quickly.

TXT

You may put any text you like in a TXT record. It is most 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. Spoofing is where email is sent out to look like it originates in one location, but 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:

Click here to view code image

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 would do something like this:

Click here to view code image

example.com. TXT "v=spf1 mx -all"

The difference 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. Internet Systems Consortium now maintains BIND and provides updates and documentation on their site 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 they give you, you are most likely pointing to a server running BIND, although other options exist. In this section, we will 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 we must declare the zones we are setting up and associating with our 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:

Click here to view code image

# 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 in our example with the IP address of your provider’s DNS server:

forwarders {
8.8.8.8;
};

Save the file and exit.

Now we must create a zone definition file. First, create a directory to hold it:

Click here to view code image

matthew@seymour:~$ sudo mkdir /etc/bind/zones

Then, create a new file, but replace example.com with your domain:

Click here to view code image

matthew@seymour:~$ sudo touch /etc/bind/zones/example.com.db

This zone definition file will contain all of the addresses and machine names that we are hosting. This is where you enter all of 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 between each and start each record with a comment, using // to begin comment lines. In this example, replace example.com with your domain, ns with the domain for your DNS server, and enter whatever other records you wish to enter, modifying as the comments note here:

Click here to view code image

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:

Click here to view code image

matthew@seymour:~$ sudo service bind9 restart

You can also use start, stop, and so on as with other services. You should be all set. To test your DNS server, edit /etc/resolv.conf (make 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 your DNS using ping to see what it returns for example.com:

Click here to view code image

matthew@seymour:~$ dig example.com

Besides the ping utility just mentioned, dig, is an excellent tool for reviewing DNS records. You may also find nslookup and whois useful. Also, named-checkzone is included with BIND9 and may be useful to you.

References

Image www.bind9.net—A website with tons of useful information about both DNS and Bind.

Image DNS and BIND by Cricket Liu and Paul Albitz is the canonical guide to understanding both of these technologies.