5 Domain Name System (DNS)

We know from the internet that we nobody uses actual raw IP addresses for any website but instead use names like apple.com, google.com, etc. Although browsers like Chrome use the search engine to help a little bit to translate simple words like apple into fully qualified names such as http://apple.com, the translation from a named server to an IP address is done using the domain name system.

The DNS system is a distributed database where the records that translate between names and IP addresses is distributed over many servers on the internet. Although it might seem like it is only remotely related to web servers, it is a critical part of the web server infrastructure and understanding how the entire system works is important if you are trying to maintain a website on the internet.

5.1 A Real Life Description of DNS

The information in this section is roughly based on a nice description found at: http://www.steves-internet-guide.com/dns-zones-explained/

Before we start hitting technical names involved with DNS lets consider a related real-life type of problem. Suppose that we have a football league called Qatar Football Association (qfa) that has many teams and we want to have a phone directory of the players. Initially it seems very easy, you get everybody’s name and phone number, put it into a book and order alphabetically and perhaps we also divide the book into teams to make it a bit easier to track down individuals then we give a copy of the book to everybody. This initial idea is a centralized book and is the way that a /etc/hosts file would work that we will see in the real section of DNS.

As an alternative to the single phone list, let’s organize everything by team and make the coach of each team be responsible for the phone numbers of the players on his team. This is called decentralized or distributed management.

To keep things small for our discussion, suppose that we have only 3 teams in our league called Duhail, Rayyan and Shamal and we will only list out 2 players plus a manager for each of the team. We will also assume that no two players on the same team have the same name, if they do then we will just make their names longer or add digits to the end of the name.

To start with, lets write up some fictitious names for our teams:

5.1.0.1 Duhail Team

Name	Number	Type
crespo	5133-2212	Manager
musa	4154-9987	Player
karim	2322-1111	Player

5.1.0.2 Rayyan Team

Name	Number	Type
cordova	4544-9077	Manager
younes	7655-3342	Player
hatem	5539-4432	Player

5.1.0.3 Shamal Team

Name	Number	Type
novic	5512-6654	Manager
saberi	3376-3322	Player
hatem	5546-9878	Player

Looking at the name Hatem we notice that we have a small problem, there are two of them. To deal with duplicate names in two different teams we introduce a new concept called the fully qualified name where we include the name of the team. In fact we will even include the qatar football association as part of the name. Therefore we can talk about ‘hatem.shamal.qfq’ and ‘hatem.rayyan.qfa’. I wrote the names like this because of course they look a lot like DNS names. We can get hints from the name about who is responsible for a certain player given their fully qualified name.

We will give each of the team tables to the managers who become responsible for keeping the table up to date and if we need to get a name for a player we can talk to the manager to get their phone number.

How do we find the phone number of the managers? We need one more list that will be maintained by Qatar Football Association containing the names of the managers for each team along with their phone number.

5.1.0.4 qfa

Name	Number	Type
duhail	5133-2212	Manager
rayyan	4544-9077	Manager
shamal	5512-6654	Manager

You will notice that the QFA table is filled only with records about the managers and no players. As long as we have a phone number for the person at QFA who is responsible for the top QFA table, we should be able to find players. Given a name like ‘hatem.shamal.qfa’ means that we need to contact QFA and ask for the phone number of the manager for the Shamal club and then we can call that person and ask for Hatem’s phone number.

Let’s add one additional twist to our situation. How do we deal with the situation when one of the managers is not available because they are traveling and you still need to urgently reach one of the players? We can handle this by introducing assistant managers to the list. We would want to make sure that for each club in the qfa table we have more than one manager. The assistant manager of course would have a copy of the list of the players and phone numbers for that team.

Based on this small example we will now start to introduce some technical terms that are actually used in DNS.

5.1.1 Zone

A zone is a table of information about a particular club. In our case each zone is a single team but we could have given the tables to different people. Suppose we had a team who was undergoing a change in management, we could give the table to QFA to manage until a new manager was put in place (yes, we could also just make one of the players also a manager).

5.1.2 Authority

Consider the phone number for ‘shaberi.shamal.qfa’. Who is the official person who actually knows this number? Chances are we could respond with ‘novic’ since they are the manager for that particular team. If we call ‘novic’ and ask for the phone number they will give us an authoritative answer. Sometimes however the phone number might be known by other people. For example suppose that the Shamal team member Karim is very good friends with Shaberi and calls him frequently. If we ask Karim for Shaberi’s phone number we could still get the number but we would call such a response non-authoritative because it is not coming from the person who is responsible for the Shamal team’s numbers. It doesn’t mean that the response is invalid, it just isn’t authoritative.

5.1.3 ‘A’ Records

In the world of DNS, A records are a type of record that convert names into IP addresses. In terms of our football club, the A record is the line that contains the name of the player and their phone number. In our example we listed only the name of the player but we could have also listed the fully qualified name in the table such as ‘hatem.shamal.qfa’

5.1.4 ‘NS’ Records

The term name server is the entity responsible for converting between a name and an IP address. This sounds like the role of the manager in our small football example. Of course managers are also people so they also have phone numbers. We will see later in the bind configuration that name servers actually have a couple of records associated with them, one saying they are the official person and the second record giving the actual phone number.

5.1.5 Zone Transfers

When we considered that one manager might be unavailable we suggested that we keep a photocopy of the team list. This is called a zone transfer.

5.1.6 Root Servers

The entire phone number system we have developed has one small problem. Everybody needs to know the phone number of QFA in order to find anything else. QFA acts as a root name server for the entire operation. On the internet there are 13 root servers spread around the world who are responsible for answering top level domain inquiries. For example if you are looking for something that ends in “.com” you would go to the root server and they would tell you who to contact.

The root in our example the top level is just .qfa but imagine if we were trying to collect phone numbers for all of the football players in the world? We would also need to create yet another level on top of our organization.

[ put a diagram here of searching for something ]

5.1.7 Caching

The official process for calling a player is this: 1. Call qfa and ask for the phone number of the manager of the team the player is on. 2. Call the manager of the team and ask for the phone number of the player. 3. Call the player.

If you had to repeat this each time that you wanted to call a specific player, you would probably find QFA and the Manager for the team being incredibly overworked. You could of course just save the player’s number in your mobile and call them directly. This is called caching and it is used frequently on the internet in order to reduce the load on the nameservers. Of course the problem with this happens when the phone number of a player changes. In the world of DNS handle these problems using a time to live value with each response that we get from a name server. When you call QFA for example, they could tell you the phone number for the manager of a particular team but they could also tell you that the number is valid only for 7 days and after that time, you should call them back in case the manager has changed their number.

On the internet a lot of TTL values are between 1 and 7 days. If IP addresses are not likely to change then we could pick longer TTL values and if we are about to change the IP address we could reduce the TTL to a couple of hours so that everybody learns of the new number more quickly. Like many things in the world of computing there is always a balance that needs to be maintained.

5.1.8 Resolving Phone Numbers

When it comes to converting a name to a phone number (this is called resolving) there are actually two ways for the system to run.

5.1.9 Recursion versus Iteration

Suppose we need to know the name of hateem.shamal.qfa. We could call QFA and ask for the phone number. Since they know the managers of the team, they could call the manager themselves and request the phone number of the player. This is called a recursive query. It makes the job of the person looking for the phone number very easy but it places a lot of work on QFA.

An alternative to the recursive query we can also work this way. If you call QFA and ask for the phone number of hateem.shamal.qfa, you could be told “We don’t know, but you can call the manager of shamal.qfa with this phone number and ask them”. The work is therefore pushed back to the person doing the query. It adds complexity to the person asking but it reduces the work done on the top level organization, especially if we start to use caching.

5.2 Back to DNS

Now that we have an analogy and even some technical terms lets turn back to the world of DNS.

5.2.1 Host File

In the beginning when the internet was just a few computers it was possible to use a feature of Linux called the /etc/host file and even today, you can do this type of thing:

127.0.0.1 localhost
127.0.1.1 webdemo
192.168.145.2 friend.whatever.com
192.168.144.3 foe.who.org
142.250.201.142 google.com

The first two lines are just definitions for the local server that is being configured. The next two lines appear to be some sort of local server that may we use for testing and the final line is a translation for google.com which would allow you to find the IP address for google.com even if no DNS server was configured.

This approach works for every operating system including windows (the file is located in a different place) but other than for basic testing of a local website it is much better to use DNS instead.

We saw this approach in our football team directory where everybody had a copy of everything. It works as long as there are very few changes but when you start to get a lot of changes it fails quite miserably.

5.2.2 DNS Components

There are two programs involved with the translation between names and IP addresses. A nameserver is the program that runs on a DNS server that is capable of turning names into IP addresses (or vice versa) and a resolver is a local program that programs like your browser communicate with. The resolver knows how to communicate to name servers using the DNS protocol.

In our football team analogy the managers were the nameserver. If you give them the name of a player they could give you a phone number as long as the player was on the team.

5.3 Domain Namespace

Each domain name in the world of DNS is just a path in a large tree, not unlike the tree-like structure that we have in the Linux file system. The root of the tree being just an empty name or a single dot (.). When you include everything right up to the root we call this a fully qualified domain name or FQDN.

[ picture of a tree with a couple of entries in it ]

A domain is a subtree of the domain namespace. For example we have the domain cna-qatar.edu.qa and udst.edu.qa domains both at our institution (although the cna-qatar one will eventually vanish). We can also use the term subdomain to refer to even smaller parts of the domain. For example within out school we have the subdomain ccit.cna-qatar.edu.qa; of course this domain is only available on campus because we do not publish any of our servers outside of the building.

5.3.1 TLD

A the top of the domain system tree you will find what are called the top-level domains (TLD). This list includes the original domains such as .com, and .org but also include the country specific items like .qa and .ca.

There are also now specialty domains such as .travel or .info but they have also expanded to include non Latin characters for websites such as https://سماء.شبكة

5.3.2 Delegation

One of the goals of the design of DNS was to decentralize administration so that no one organization was responsible for everything. This is accomplished by way of a technique called delegation.

If we look at the tree like structure as discussed previously we can delegate (hand over control) sub-domains to individual organizations. It doesn’t make any since that the organization that manages edu.qa needs to know anything about udst.edu.qa other than the IP address of the nameserver responsible for the udst.edu.qa subdomain.

The name of the domain that a nameserver manages is called a zone. It is not uncommon for a nameserver to be responsible for different parts of a domain and they will str

In the football phone directory example, each football club was delegated to the manager of the team.

5.3.3 Registrars

Although this is not part of the DNS protocol, there are a series of organization that exist called registrars. When you want to get a new domain for a website say “superdns.com”, you need to contact a registrar who can issue domains in the .com TLD. You fill out a form and pay some money and they will record your name into the name servers for the .COM TLD.

In our course, the instructor will work as the registrar but the good news is that they will not require any money for you to register a new subdomain. Of course the instructor can only offer you subdomains on the domain inft3203.ccit.cna-qatar.edu.qa.

5.4 Record Types

In the world of DNS there are multiple different record types. For example if we think back to our football team directory there are record for the players but there are also records for the managers and records for the team.

5.4.1 A and AAAA Records

The A and AAAA records are the easiest ones to understand. The A record is an entry in the server that indicates the IPv4 address given the machine name. For example the name www.google.com would have an A record that translates this to 172.217.169.228. The AAAA record is the same thing but for IPv6 addresses.

5.4.2 CNAME Records

This is an abbreviation for a canonical name. This type of record points to another name. This can be handy if you have several different names all resolving to the same IP address. We can use the CNAME record for each of the names and then have just a single A record. The idea is that we could change all the values by changing a single record entry. One of the most popular uses of the CNAME record is when people have multiple subdomains that all point to the same server.

host	type	destination
superdemo.tld	A	123.123.123.123
www.superdemo.tld	CNAME	superdemo.tld
mail.superdemo.tld	CNAME	superdemo.tld
support.superdemo.tld	CNAME	superdemo.tld

The records above would be probably be used in a small organization that has just a single server which is hosting all of the sites. This is not like the current domain for our university since we have multiple machines webit.cna-qatar.edu.qa is a physically different machine than say d2l.cna-qatar.edu.qa. However if the IP address changes for superdemo.tld we only need to change a single record.

The downside to using CNAME records is the resolver will need to make a second query to find the IP address if they didn’t already have the A record value.

5.4.3 MX Records

When you want to send email to somebody at a specific domain, your email client needs to know which machine will be running the SMTP server so that the mail can be handed over. This record never turns into a single IP address but provides a name that would need to be resolved.

As an example, if you wanted to send an email to somebody at UDST from your gmail account here is what would happen. You would compose the email and click send. The gmail server would then use DNS to request the MX record for udst.edu.qa which would be returned as udst-edu-qa.mail.protection.outlook.com. The gmail server would then open an SMTP conversation with that server and send the email.

5.4.4 TXT Records

These are human readable messages that can be used for any purpose. One of the most common uses I’ve seen is for indicating validation of email sending domains. Suppose you purchased the domain superslowservers.com and you needed email. One option is to run your own mail server but if you wanted to, you can instead pay Google to host the mail for you. To do this, you just need to configure the MX record to point to aspmx.l.google.com. That is the easy part.

The more tricky part is trying to send email. To send email, you need to contact the destination server but how does the receiving server know to trust the gmail originated message? The usual trick is that you could put TXT records such as: text = “v=spf1 +mx +a +ip4:119.221.112.23 ~all”. This indicates to the receiving message that mail should be coming from the IP address 119.221.112.23 but nowhere else. If a message comes from a different IP address then it would be likely flagged as spam or perhaps not even accepted. Google mail is very picky about receiving messages from unverified senders and will ask you to configure TXT records.

5.4.5 SOA Record

This is the start of authority record which contains information such as who is responsible for the domain as well as the official name server for the domain.

5.4.6 NS Record

The name server record specified the authoritative name server for a particular domain. For example if we wanted to know which name server was official for microsoft.com we could query the NS record to find something like this: microsoft.com nameserver = ns1-39.azure-dns.com.

You may wonder why we have to list the NS record even though we provided the name of the name server in the SOA record. In a typical deployment, you want to have multiple name servers available but you can only list one name server in the SOA which is the name of the primary server. You can list as many NS records as you need for your zone.

5.4.7 Other Records

The list provided here is not an exhaustive list but these are the records that we want to talk about in the course. A quick online search will give you a list of all the possible record types.

5.4.8 Master and Slave Servers

Need to write a paragraph about the use of slave servers.

5.4.9 Forwarders

When a request is received by a DNS server, the server will usually try to resolve the name first using the local configuration files. If this fails, then the DNS server will attempt to resolve the request by either forwarding the request to a server that will take care of the request or else going through the root hint servers. Both approaches will work fine but a forwarder can produce result faster if the forwarder is quick because the forwarding server might be caching a lot of requests. One of the most common forwarders in use are the IP addresses 8.8.8.8 and 8.8.4.4 which happen to be the public DNS servers provided by Google. Some people do not like to use these servers because they feel that Google might be spying on the URLs that they are visiting but many other people just want DNS to work and they are a very fast public service.

5.5 nslookup

The most critical part of configuration a DNS server is being able to make sure that it is configured correctly. To do this, you need to learn how to use the nslookup tool since it is available on all platforms. This document will not contain all the possible uses and features of the tool, just a few to get you started. Please read through the manual page for more information.

Linux, MacOS and Wondows all come with the tool nslookup that can be used to obtain information from DNS servers. To start the tool you should open the command prompt or a terminal window.

5.5.1 Which Server Are You Using?

The command ‘server’ will report which server is being used.

demo@macbook% nslookup
> server
Default server: 192.168.68.1
Address: 192.168.68.1#53

In this example requests go to the server 192.168.68.1 for resolution. This IP address happens to be a router in my network that is responsible for resolving names into IP addresses. Some of the names comes from the server itself while other names are resolved by sending a request to the Google public DNS server.

You can switch this around to other IP addresses by including the IP address of the server (or a name providing that your DNS server is actually working). For example:

> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53

Keep in mind that setting the DNS server inside nslookup only changes the IP address for the currently running nslookup program. Once you exit from nslookup the next time you run the program, you will be using the machine’s default server. Also note that changing the server inside nslookup does not actually change it for the machine itself. If you need to change the DNS server so that the browser can find a record, you will need to do that from wherever the IP address is set on your computer.

5.5.2 Finding A and AAAA records

When nslookup starts, the query type starts as A. Any name that you type in will be resolved into an A record. If the server doesn’t know the address, it will go and try to find it using the root hint servers.

robertford@Macbook-M2 webservbook % nslookup
> www.google.com
Server:     192.168.68.1
Address:    192.168.68.1#53

Non-authoritative answer:
Name:   www.google.com
Address: 172.217.169.228
> site24x7.com
Server:     192.168.68.1
Address:    192.168.68.1#53

Non-authoritative answer:
Name:   site24x7.com
Address: 136.143.190.226
> 

You will notice that for each name that I typed the response indicates which server was used and what the translated IP address was. The server of course is not the IP address of the destination machine!

If you wanted to find AAAA (IPv6) records you need to use the command ‘set type=aaaa’ before you start to type the requests:

robertford@Macbook-M2 webservbook % nslookup
> set type=aaaa
> www.google.com
Server:     192.168.68.1
Address:    192.168.68.1#53

Non-authoritative answer:
www.google.com  has AAAA address 2a00:1450:4018:801::2004

Authoritative answers can be found from:
> site24x7.com
Server:     192.168.68.1
Address:    192.168.68.1#53

Non-authoritative answer:
*** Can't find site24x7.com: No answer

You can see that www.google.com does actually have an IPv6 address but the site24x7.com does not.

You will also notice that in all of the examples above we are seeing the phrase *Non-authoritative answer”. This simply means that the server providing the answer isn’t actually the official server. The IP addresses are very likely correct,it is just that the 192.168.68.1 server doesn’t officially own the record but it found the record by querying other servers.

Compare this to searching for the name webdemo.villa68.local.

robertford@Macbook-M2 webservbook % nslookup
> webdemo.villa68.local
Server:     192.168.68.1
Address:    192.168.68.1#53

Name:   webdemo.villa68.local
Address: 192.168.68.11

The ‘villa68.local’ domain was something that I created to do some work at home on the web server management course. The DNS server 192.168.68.1 actually contains the A record for the machine and therefore it actually becomes the ‘authoritative’ server which is why we don’t see the Non-Authoritative message like for other domains.

5.5.2.1 Finding Other Records

To find other records you need to use the ‘set type’ command. You can set the type to records such as mx, soa, txt

> set type=cname
> www.microsoft.com
Server:     192.168.68.1
Address:    192.168.68.1#53

Non-authoritative answer:
www.microsoft.com   canonical name = www.microsoft.com-c-3.edgekey.net.

> set type=soa
> www.microsoft.com
Server:     192.168.68.1
Address:    192.168.68.1#53

Non-authoritative answer:
www.microsoft.com   canonical name = www.microsoft.com-c-3.edgekey.net.
www.microsoft.com-c-3.edgekey.net   canonical name = www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net.
www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net    canonical name = e13678.dscb.akamaiedge.net.

Authoritative answers can be found from:
dscb.akamaiedge.net
    origin = n0dscb.akamaiedge.net
    mail addr = hostmaster.akamai.com
    serial = 1681614678
    refresh = 1000
    retry = 1000
    expire = 1000
    minimum = 1800

5.6 BIND

The first implementation of name server was the Berkeley Internet Name Domain server which got abbreviated to BIND. This is one of the most popular Unix name servers that exist and will be the focus in this course. The O’Reilly book named DNS and BIND is a very good resource for information about how DNS works and how the BIND server can be configured.

5.6.1 Zones

Although a very simple concept, a lot of students seem to get the concept of a zone confused and end up mis-configuring their servers during tests. A zone is simply part of a DNS namespace that is administered by a specific person. Let’s take the DNS name inft3203.ccit.cna-qatar.edu.qa (this is available only from inside the campus in case you are not part of the course). This name consists of 5 zones: * qa - The Qatar zone. Maintained by the Communications Regulatory Committee in Qatar * edu.qa - The Qatar Education Zone. Also maintained by the CRA. * cna-qatar.edu.qa - This is the university domain (it is active while we write this book but we are expecting it to vanish soon). The IT department is responsible for this zone. * ccit.cna-qatar.edu.qa - This is the College of Computing and Information Technology zone. I am currently responsbile for this zone. * inft3203.ccit.cna-qatar.edu.qa - This is the course zone. Again, I am responsible for this zone.

You are allowed to have multiple zones on a single server and you can even create multiple zone files for a single zone (although I don’t recommend it). Think of a zone as part of domain that you are responsible for and keep all records about a single zone in a single file! Some students in the past have taken a single zone and split it into two zone files but that is really not the way it should be done.

5.6.2 Configuration File Layout

Similar to Apache, the configuration for bind9 could be done in one super huge file but it is much better to split this into smaller pieces and the Ubuntu packages are structured as described here. All the configuration files are located in the /etc/bind folder.

The main file is the named.conf file but if you look inside this file, you will find that there is nothing there except for three include statements which are responsible for bringing in additional files. Generally, you wouldn’t want to modify this file. The files that contain the actual configuration statements are named.conf.options, named.conf.local, named.conf.default-zones.

Although you can modify the named.conf.default-zones file to add your own local names, it isn’t advised. This file is really for the owners of the bind9 package and if you make changes here, you might get conflict when doing upgrades. I would suggest leaving that file alone and focus only on the other two files.

5.6.2.1 Options File

The file named.conf.options contains bind configuration that controls how this program operates. This would include things such as allowing computers to use our server as a resolver and how to deal with the forwarding.

Let’s review what is there when we first install bind9 on an Ubuntu machine (I’ve removed the commented lines to make this page as short as possible):

options {
        directory "/var/cache/bind";
        dnssec-validation auto;
        listen-on-v6 { any; };
};

There isn’t much here The directory option indicates where the cached values (see description before about caching) are kept. The dnssec-validation option allows us to configure our DNS servers so that we can guarantee that we are getting responses from the actual servers and we are not being subjected to a man in the middle attack. This is outside of the scope of our course. Finally we have a list-on-v6 which indicates whether or not we should be listening on IPv6 addresses.

5.6.2.2 Forwarding

To configure a forwarder you just include the following item inside the options:

forwarders { 
  8.8.8.8;
  8.8.4.4;
};

If you try to do this, and only this, and attempt to resolve any requests, you will likely get back a query refused. By default bind does not allow computers to resolve any DNS queries in an attempt to prevent you from accidentally supporting queries for all people on the internet.

A very poor option that you could try to implement to do some basic testing is:

allow-query {
  any;
}

This means that your bind configuration will allow queries from any client with any IP address. If your DNS server is behind a NAT firewall and you are just using this as a caching name server, this configuration is okay but generally a DNS server is likely to be in a public network or in the DMZ. For this we need to use access control lists to control the query addresses.

Let’s suppose that we have a small network in which all the addresses are 192.168.30.0/24 and the DNS server is in the DMZ. If we wanted to provide query responses for all the machines on our network we would create a small ACL such as:

acl internal-network {
   192.168.30.0/24;
};

allow-query {
   internal-network;
}

5.6.2.3 named.conf.default-zones

If you open nslookup, point the server to the machine running bind and ask for a host such as www.google.com, you will get an answer even if there is no forwarder configured. How does this work?

If you look at the named.conf.default-zones file you will find this entry at the top:

zone "." {
    type hint;
    file "/usr/share/dns/root.hints";
};

This says for the zone “.” (which is everything) start by looking at the root DNS servers (description of these is elsewhere). If you look in the /usr/share/dns/root.hints file, you will be able to see the IP addresses of these servers.

One thing that you will notice about querying your sever if you try it is that the first time that you ask for an IP address it will take a certain amount of time but then if you ask again, the second response will be much quicker because of the caching that is happening in the background.

5.6.2.4 named.conf.local

The local file is the place where you would put your local configuration for zones that you are supporting. Although you could add your zones to the named.conf.default-zones and everything would work, this is not actually the place to put it, stick with named.conf.local.

5.6.3 Zone File Example

Let’s progress through the configuration of a new zone. Suppose for example we really did want to implement our Qatar Football Association and wanted to use the ficticious domain qfa.sport.qatar.

The zones “.qatar” and “.sport.qatar” assume to already exist and we of course are just going to implement DNS. We will pretend that we have been allocated the ip addresses 187.121.221.23 which we will be using for our main web server and want to be able to access this from the URL www.qfa.sport.qatar. We will also be supporting a second URL called scores.qfa.sport.qatar which will hold scores. We are going to arrange for email to be handled by Google (i.e. somebody will send email to info@qfa.sport.qatar but we will be using the gmail interface to read messages).

The zone that we will be administering is “qfa.sport.qatar”. So we will add the following code into the named.conf.local file:

zone "qfa.sport.qatar" {
    type master;
    file "/etc/bind/db.qfa";
};

This informs bind that the information about the zone will be found in the file /etc/bind/db.qfa. Note that that the name of the file is completely up to you, the only reason why I keep the “db” part is because the other files in the DNS server also start with the same.

You will also notice that we have flagged the record as being the “master”. The master means that we will be the official name server containing the records. Currently we do not cover slaves in this course but please pay attention to what the instructor is doing because that could change very quickly.

Now for the actual zone file db.qfa. The easiest way to cover this is to simply show a working example and then we’ll decode what each of the lines means. For now, I will be configuring some unusual values so please read the description after to understand what I have written and what impact the values have. I will also write up the zone file using a very verbose approach and we will talk about how this can be reduced in size after we get it going.

TTL 0

qfa.sport.qatar. IN SOA ns.qfa.sport.qatar admin.qfa.sport.qatar. (
   0
   0
   0
   0
   0
)

qfa.sport.qatar. IN NS ns.qfa.sport.qatar.
ns.qfa.sport.qatar. IN A 187.121.221.23
qfa.sport.qatar. IN A 187.121.221.23
www.qfa.sport.qatar. IN CNAME qfa.sport.qatar.
scores.qfa.sport.qatar. IN CNAME qfa.sport.qatar.

The first line that starts with $TTL is the default time to live value for the records that show up in the file. The TTL value will be used for caching and after the results have been stored for the amount of time listed here, the servers will forget the values and ask again. Normally we would see values such as 24h for the TTL value but I picked zero here because I am currently in the process of debugging and the IP address could change if I make a mistake.

The next block contains the start of authority (SOA) record. The first line contains the name of the zone, the name server’s name responsible for the zone and the email address of the person responsible. We know that email addresses are suppose to be for the form admin@qfa.sport.qatar but we will be using the @ symbol soon for a different purpose.

The numbers in the start of the zone are used for talking to slave servers. We will skip these for right now and just use zeros but we will return later to cover these once we have other things fixed.

The last part of the zone file contain the other records. The NS record is a required field and although it looks like we already said it in the SOA record, we have no choice but to write it again as it is used when the resolver asks for NS records plus we might have more than one name server available for our domain.

The next two lines of the file are the A records. I really don’t need to have two A records but I’ve done it anyways. The main qfa.sport.qatar will be our actual server’s IP address. The ns.qfa.sport.qatar needs to be there and our validation check would fail if we did not actully tell people what nameserver they should be looking at.

The final two entries are the pointers (the canonical names) to our server. If we now try some nslookup command we can get this:

> www.qfa.sport.qatar
Server:     192.168.29.128
Address:    192.168.29.128#53

www.qfa.sport.qatar canonical name = qfa.sport.qatar.
Name:   qfa.sport.qatar
Address: 187.121.221.23
> qfa.sport.qatar
Server:     192.168.29.128
Address:    192.168.29.128#53

Name:   qfa.sport.qatar
Address: 187.121.221.23

You can see when we search for the www subdomain we got back a CNAME record and then we ran another request looking the IP address of the CNAME value.

5.6.3.1 What is with the dots?

If you look closely at the zone configuration file, you will notice that each name ends in with a “.”. This is not a typo and if you leave it out, things will fail miserably. We can start to introduce some short cuts.

When we write ‘www.qfa.sport.qatar.’, we are informing bind that we want this to be name. However you can also shorten it to be just “www” without the dot. Since the name of the zone is qfa.sport.qatar (from the named.conf.local file) bind will assume that it ends with the zone. The result after applying this shortcut technique is the following zone file:

$TTL 0

qfa.sport.qatar. IN SOA ns admin (
   0
   0
   0
   0
   0
)

qfa.sport.qatar. IN NS ns
ns IN A 187.121.221.23
qfa.sport.qatar. IN A 187.121.221.23
www IN CNAME qfa.sport.qatar.
scores IN CNAME qfa.sport.qatar.

If you were to have the entry www.qfa.sport.qatar (without the ending dot) this would translate into www.qfa.sport.qatar.qfa.sport.qatar!

Is there anything that we can do to help with the lines containing qfa.sport.qatar.? The answer is yes, we can replace this by the symbol @.

$TTL 0

@ IN SOA ns admin (
   0
   0
   0
   0
   0
)

@ IN NS ns
ns IN A 187.121.221.23
@ IN A 187.121.221.23
www IN CNAME @
scores IN CNAME @

It is shorter but I personally find it a bit tough to read. I like the shorted www and scores but my preference is to not use the @ symbols. This does not mean that you cannot use them, it is just my preference. It does cut down certain types of typing errors.

How does bind know that the @ means qfa.sport.qatar? If you go back to the file where we did included the zone file (probably named.conf) then you will see that the directive was zone "qfa.sport.qatar".

5.6.3.2 Checking For Errors

Tracking down errors in bind configuration files is one of the most challenging things that we face in this course. There are two two will help us at least a little bit but they do not guarantee any results. The two commands are named-checkconf and named-checkzone.

The named-checkconf checks for very basic syntax errors on the main configuration file only. The only thing that I have round really useful when running the command is checking for missing semi-colons (;).

The named-checkzone is more useful but it is also more tricky to use since you need to specify the name of the zone that you are checking. Here is an example of it:

root@wsmdemo:/etc/bind# named-checkzone qfa.sport.qatar db.qfa 
zone qfa.sport.qatar/IN: loaded serial 0
OK

One example of a problem that it can correct is when you forget to include the A record for the primary name server (this is an error we frequently see students making). Here is what it looks like if I remove the line that starts with ‘ns’.

root@wsmdemo:/etc/bind# named-checkzone qfa.sport.qataddr db.qfa 
zone qfa.sport.qataddr/IN: NS 'ns.qfa.sport.qataddr' has no address records (A or AAAA)
zone qfa.sport.qataddr/IN: not loaded due to errors.

To interpret the errors, you need to understand what they mean! It is quite clear that the NS record doesn’t have any A or AAAA records associated with it.

The most important place to look for errors is to check the /var/log/syslog file for anything that is complaining about the domains you are trying to make. The easiest way to find problems is to run ‘grep named /var/log/syslog’ which will show all the errors that have been written out by bind9 (it shows in syslog under the process name named).

5.6.3.3 IPv6 Addresses

We might as well see what an IPv6 address looks like inside the zone configuration file. Let’s create a record for lusail.qfa.sport.qatar:

$TTL 0

@ IN SOA ns admin (
   0
   0
   0
   0
   0
)

@ IN NS ns
ns IN A 187.121.221.23
@ IN A 187.121.221.23
www IN CNAME @
scores IN CNAME @
lusail IN AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334

Now to query the address:

robertford@Macbook-M2 ~ % nslookup
> server 192.168.29.128
Default server: 192.168.29.128
Address: 192.168.29.128#53
> lusail.qfa.sport.qatar
Server:     192.168.29.128
Address:    192.168.29.128#53

*** Can't find lusail.qfa.sport.qatar: No answer
> set type=aaaa
> lusail.qfa.sport.qatar
Server:     192.168.29.128
Address:    192.168.29.128#53

lusail.qfa.sport.qatar  has AAAA address 2001:db8:85a3::8a2e:370:7334

You will notice that the first query failed. By default nslookup on the mac only searches for A records. I switched the record searching type to AAAA then then we got back an IP address. You will notice that the IPv6 from nslookup was actually shortened as well.

5.6.3.4 MX Record

We forgot to include the MX record for our domain so we will add it now. According to what I found online we should be configuring MX records to be sent to smtp.google.com. Let’s see what it looks like in the configuration file including the shortcuts:

$TTL 0

@ IN SOA ns admin (
   0
   0
   0
   0
   0
)

@ IN NS ns
ns IN A 187.121.221.23
@ IN A 187.121.221.23
www IN CNAME @
scores IN CNAME @
lusail IN AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334
@ IN MX 1 smtp.google.com.

The very last line of the file indicates that this is the MX record for the domain qfa.sport.qatar. Mail will be transmitted to smpt.google.com (notice that we need the . at the end otherwise it would have translated to smtp.google.com.qfa.sport.qatar). The number between the MX and the destination is the priority. You can configure multiple MX records with different priorities and when the email program tries to deliver email it will start with the MX record with the lowest number and if that fails, it will then move along to the next available server.

5.6.3.5 Making It Work

Our simple domain isn’t real and it isn’t connected to anything real either so nothing would actually work but let’s talk about how we could make it work.

The first problem with out fake domain is that the .qatar TLD doesn’t exist. We would need to start by creating a new TLD zone server (it could go on our same machine as a separate zone) and then convince the people who run the root hint servers that the .qatar zone should be included as part of the internet. Then requests looking for a server like www.qfa.sport.qatar would be delegated to the “.qatar” server. We would then need to also create a server for “.sport.qatar” (again, this could be just the same server) and they would then delegate the request.

In case you were interested, here is what the “qfa.sport.qatar” configuration file would look like for our “qfa” subdomain if they were using the bind package:

qfa IN NS ns.qfa
ns.qfa. IN A 187.121.221.23

What about email? The DNS configuration that we did is correct but we wouldn’t have email quite yet! If Gmail receives an email for an address like info@qfa.sport.qatar, it would just reject the message. If you want to use Gmail for this purpose, you need to pay for a business account. To proof that you actually own the domain that they will be accepting email for, you probably need to add some special TXT record to your DNS. Google assumes that if you have control of the DNS server, you probably are the owner.

5.6.4 TTL Values

We have been using the value 0 as the TTL value. This is a good idea when you are first configuring a server, especially when you are dealing with delegation through multiple DNS servers. Let me explain with a small example of a student taking the web server management course. A student who owned the machine at 192.168.30.145 came to see me because their website just wasn’t working. When I ran nslookup and asked for the IP address of their name I got 192.168.30.180. Although they denied it at first, eventually they admitted that they misconfigured the IP address during one of their testing attempts (likely they copied a friend’s configuration file and forgot to change the record). The problem is that the university’s DNS server, the college DNS server and the course DNS server all saw the 192.168.30.180 IP address and remembered it because of caching and they retained the value for 24 hours. After 24 hours, the name resolved correctly! If the student had set the TTL to zero while creating the configuration file the other name servers would not have cached the value at all and they could have easily fixed it.

The normal approach to TTL values is to start with a very small number, say a minute or even zero, until you have everything working correctly. Then once everything is stable, you increase the TTL value to something much larger. In this course it doesn’t make any sense to have a TTL larger than about 1 hour but in the real world of the internet a typical value is 24 hours. If you know that you need to change the IP address of a server, you would start the day before by reducing the TTL value down to maybe 5 minutes. On the day of the IP address change, you will have only a 5 minute period where the DNS servers are updating their cached values of the IP address then once everything is stable move the TTL value back up to 24 hours again.

5.6.5 Slave Server Values

In the configuration file we currently have the following SOA record:

@ IN SOA ns admin (
   202304161539 ; serial number
   12h ; refresh
   10m ; retry
   1w ; expire
   1h ; negative cache
)

I’ve added comments to each of the lines so that I can talk about what the values mean.

The serial number is a number that is used to identify the version number of the rest of the records in this zone. We could pick a simple monotonic sequence such as 1, 2, 3, … A common method is to write the date and time in YMDhm format. For example if I were to modify the file right now as I am typing this comment I would have written the serial number 202304161539 (April 16, 2023 at 3:39pm). If I change the zone file even a few minutes later the serial number will be larger. Why do we need this? The slave server needs to know that the record has been updated. If the serial number on the slave was 202304151234 then it would realize that the master server has a new record and it will ask for a zone transfer. If the serial number is still the same then it will keep the values that it currently has.

The refresh value indicates how frequently the slave server will query the master server for changes. Typical values are 3 to 12 hours for this but just like our discussion about TTL, if you know things are changing, you probably want to configure more frequent checks.

The retry value is how frequently the slave server will try to request from the master if there was a failure. So suppose we have the refresh set to 3h and the retry configured to 10m. This means that every 3 hours, the slave will contact the server for any updates on the zone. If the connection is fine then the slave goes about its normal work for 3 hours. If the master could not be located, then it will start trying the master server every 10 minutes.

The expire value indicates to the server when to give up and stop giving out any information about the zone. It seems quite common that the value of 1w (week) is used for this. If the master server becomes unavailable for 1 week (the slave trying of course every 10 minutes) then the slave will stop responding to requests about the zone.

The final value is called the negative cache and this requires a bit of explanation. A negative result is when you search for something about a record that doesn’t exist. Suppose for example that we ask a server for sta974.qfa.sport.qatar, we would get a result of “not found”… this is a negative result. If the server caches this value and another person asks for the same then we can quickly respond with a “not found”. This value controls how long the other DNS servers will remember a not found result.

5.6.6 Configure a Slave Server

Configuring a slave server is extremely simple to do! All that you need to do is to create an entry in the named.conf.local file similar to this:

zone "qfa.sport.qatar" {
        type slave;
        file "bak.qfa";
        masters { 192.168.29.100; };
};

Like on the master side the zone is qfa.sport.qatar. The type this time is slave rather than master. The file is the name of the file where the zone information will be stored (it would be found in /var/cache/bind that we set in the options file). The masters are located at the ip address 192.168.29.100. When you restart bind, you could check the syslog file for a message about “Transfer status: success” and of course if you query the new server you should get the same result.

When updating the “db” file on the master you should be changing the serial as well. If you do not change the serial number each time and look in the log you will see messages like this:

May 28 02:27:55 section3 named[35404]: zone rford.inft3203.ccit.cna-qatar.edu.qa/IN: zone serial (2) unchanged. zone may fail to transfer to secondaries.
May 28 02:27:55 section3 named[35404]: zone rford.inft3203.ccit.cna-qatar.edu.qa/IN: loaded serial 2

The zone will still load and the primary server will return the correct address but there is no guarantee that the zone transfer to the secondary servers will work correctly because they won’t be able to notice a change. Eventually once the TTLs have expired the secondary servers will start giving out the correct addresses but this may take time.