installation of DNS server application, configuration of BIND as a caching DNS, and setup of Primary Master and Secondary Master. We will also cover some best practices to secure your DNS server.

In this recipe, I will be using four servers. You can create virtual machines if you want to simply test the setup:

ns1: Name server one/Primary Master
ns2: Name server two/Secondary Master
host1: Host system one
host2: Host system two, optional
- All servers should be configured in a private network. I have used the 10.0.2.0/24 network

Install BIND and set up a caching name server through the following steps:

On ns1, install BIND and dnsutils with the following command:

$ sudo apt-get update
$ sudo apt-get install bind9 dnsutils

Open /etc/bind/named.conf.optoins, enable the forwarders section, and add your preferred DNS servers:
```
forwarders {
    8.8.8.8;
    8.8.4.4;
};
```
Now restart BIND to apply a new configuration:
```
$ sudo service bind9 restart
```
Check whether the BIND server is up and running:
```
$ dig -x 127.0.0.1
```

You should get an output similar to the following code:

;; Query time: 1 msec
;; SERVER: 10.0.2.53#53(10.0.2.53)

Use dig to external domain and check the query time:
Dig the same domain again and cross check the query time. It should be less than the first query:

Set up Primary Master through the following steps:

On the ns1 server, edit /etc/bind/named.conf.options and add the acl block above the options block:
```
acl "local" {
    
10.0.2.0/24;  # local network
};
```

Add the following lines under the options block:

recursion yes;
allow-recursion { local; };
listen-on { 10.0.2.53; };  # ns1 IP address
allow-transfer { none; };

Open the /etc/bind/named.conf.local file to add forward and reverse zones:
```
$ sudo nano /etc/bind/named.conf.local
```

Add the forward zone:

zone "example.com" {
    type master;
    file "/etc/bind/zones/db.example.com";
};

Add the reverse zone:

zone "2.0.10.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.10";
};

Create the zones directory under /etc/bind/:
```
$ sudo mkdir /etc/bind/zones
```
Create the forward zone file using the existing zone file, db.local, as a template:
```
$ cd /etc/bind/
$ sudo cp db.local  zones/db.example.com
```
The default file should look similar to the following image:
Edit the SOA entry and replace localhost with FQDN of your server.
Increment the serial number (you can use the current date time as the serial number, 201507071100)
Remove entries for localhost, 127.0.0.1 and ::1.

Add new records:

; name server - NS records
@  IN  NS  ns.exmple.com
; name server A records 
ns  IN  A 10.0.2.53
; local - A records
host1  IN A  10.0.2.58

Save the changes and exit the nano editor. The final file should look similar to the following image:
Now create the reverse zone file using /etc/bind/db.127 as a template:
```
$ sudo cp db.127 zones/db.10
```
The default file should look similar to the following screenshot:
Change the SOA record and increment the serial number.
Remove NS and PTR records for localhost.

Add NS, PTR, and host records:

; NS records
@  IN  NS  ns.example.com
; PTR records
53  IN  PTR  ns.example.com
; host records
58  IN  PTR  host1.example.com

Save the changes. The final file should look similar to the following image:
Check the configuration files for syntax errors. It should end with no output:
```
$ sudo named-checkconf
```

Check zone files for syntax errors:

$ sudo named-checkzone example.com /etc/bind/zones/db.example.com

If there are no errors, you should see an output similar to the following:
```
zone example.com/IN: loaded serial 3
OK
```

Check the reverse zone file, zones/db.10:

$ sudo named-checkzone example.com /etc/bind/zones/db.10

If there are no errors, you should see output similar to the following:
```
zone example.com/IN: loaded serial 3
OK
```
Now restart the DNS server bind:
```
$ sudo service bind9 restart
```
Log in to host2 and configure it to use ns.example.com as a DNS server. Add ns.example.comto /etc/resolve.conf on host2.
Test forward lookup with the nslookup command:
```
$ nslookup host1.example.com 
```

You should see an output similar to following:

$ nslookup host1.example.com
Server: 10.0.2.53
Address: 10.0.2.53#53
Name: host1.example.com
Address: 10.0.2.58

Now test the reverse lookup:
```
$ nslookup 10.0.2.58
```

It should output something similar to the following:

$ nslookup 10.0.2.58
Server: 10.0.2.53
Address: 10.0.2.53#53
58.2.0.10.in-addr.arpa name = host1.example.com

Set up Secondary Master through the following steps:

First, allow zone transfer on Primary Master by setting the allow-transfer option in /etc/bind/named.conf.local:

zone "example.com" {
    type master;
    file "/etc/bind/zones/db.example.com";
    allow-transfer { 10.0.2.54; };
};
zone "2.0.10.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.10";
    allow-transfer { 10.0.2.54; };
};

NOTE

A syntax check will throw errors if you miss semicolons.

Restart BIND9 on Primary Master:
```
$ sudo service bind9 restart
```
On Secondary Master (ns2), install the BIND package.

Edit /etc/bind/named.conf.local to add zone declarations as follows:

zone "example.com" {
    type slave;
    file "db.example.com";
    masters { 10.0.2.53; };
};
zone "2.0.10.in-addr.arpa" {
    type slave;
    file "db.10";
    masters { 10.0.2.53; };
};

Save the changes made to named.conf.local.
Restart the BIND server on Secondary Master:
```
$ sudo service bind9 restart
```
This will initiate the transfer of all zones configured on Primary Master. You can check the logs on Secondary Master at /var/log/syslog to verify the zone transfer.

TIP

A zone is transferred only if the serial number under the SOA section on Primary Master is greater than that of Secondary Master. Make sure that you increment the serial number after every change to the zone file.

How it works…

In the first section, we have installed the BIND server and enabled a simple caching DNS server. Acaching server helps to reduce bandwidth and latency in name resolution. The server will try to resolve queries locally from the cache. If the entry is not available in the cache, the query will be forwarded to external DNS servers and the result will be cached.

In the second and third sections, we have set Primary Master and Secondary Master respectively. Primary Master is the first DNS server. Secondary Master will be used as an alternate server in case the Primary server becomes unavailable.

Under Primary Master, we have declared a forward zone and reverse zone for the example.comdomain. The forward zone is declared with domain name as the identifier and contains the type and filename for the database file. On Primary Master, we have set type to master. The reverse zone is declared with similar attributes and uses part of an IP address as an identifier. As we are using a 24-bit network address (10.0.2.0/24), we have included the first three octets of the IP address in reverse order (2.0.10) for the reverse zone name.

Lastly, we have created zone files by using existing files as templates. Zone files are the actual database that contains records of the IP address mapped to FQDN and vice versa. It contains SOA record, A records, and NS records. An SOA record defines the domain for this zone; A records and AAAA records are used to map the hostname to the IP address.

When the DNS server receives a query for the example.com domain, it checks for zone files for that domain. After finding the zone file, the host part from the query will be used to find the actual IP address to be returned as a result for query. Similarly, when a query with an IP address is received, the DNS server will look for a reverse zone file matching with the queried IP address.

An Introduction to DNS Terminology, Components, and Concepts

PostedFebruary 18, 2014 175.5k DNS LINUX BASICS FAQ

Tutorial Series

This tutorial is part 1 of 7 in the series: An Introduction to Managing DNS

Introduction

DNS, or the Domain Name System, is often a very difficult part of learning how to configure websites and servers. Understanding how DNS works will help you diagnose problems with configuring access to your websites and will allow you to broaden your understanding of what's going on behind the scenes.

In this guide, we will discuss some fundamental DNS concepts that will help you hit the ground running with your DNS configuration. After tackling this guide, you should be ready to set up your domain name with DigitalOcean or set up your very own DNS server.

Before we jump into setting up your own servers to resolve your domain or setting up our domains in the control panel, let's go over some basic concepts about how all of this actually works.

Domain Terminology

We should start by defining our terms. While some of these topics are familiar from other contexts, there are many terms used when talking about domain names and DNS that aren't used too often in other areas of computing.

Let's start easy:

Domain Name System

The domain name system, more commonly known as "DNS" is the networking system in place that allows us to resolve human-friendly names to unique addresses.

Domain Name

A domain name is the human-friendly name that we are used to associating with an internet resource. For instance, "google.com" is a domain name. Some people will say that the "google" portion is the domain, but we can generally refer to the combined form as the domain name.

The URL "google.com" is associated with the servers owned by Google Inc. The domain name system allows us to reach the Google servers when we type "google.com" into our browsers.

IP Address

An IP address is what we call a network addressable location. Each IP address must be unique within its network. When we are talking about websites, this network is the entire internet.

IPv4, the most common form of addresses, are written as four sets of numbers, each set having up to three digits, with each set separated by a dot. For example, "111.222.111.222" could be a valid IPv4 IP address. With DNS, we map a name to that address so that you do not have to remember a complicated set of numbers for each place you wish to visit on a network.

Top-Level Domain

A top-level domain, or TLD, is the most general part of the domain. The top-level domain is the furthest portion to the right (as separated by a dot). Common top-level domains are "com", "net", "org", "gov", "edu", and "io".

Top-level domains are at the top of the hierarchy in terms of domain names. Certain parties are given management control over top-level domains by ICANN (Internet Corporation for Assigned Names and Numbers). These parties can then distribute domain names under the TLD, usually through a domain registrar.

Hosts

Within a domain, the domain owner can define individual hosts, which refer to separate computers or services accessible through a domain. For instance, most domain owners make their web servers accessible through the bare domain (example.com) and also through the "host" definition "www" (www.example.com).

You can have other host definitions under the general domain. You could have API access through an "api" host (api.example.com) or you could have ftp access by defining a host called "ftp" or "files" (ftp.example.com or files.example.com). The host names can be arbitrary as long as they are unique for the domain.

SubDomain

A subject related to hosts are subdomains.

DNS works in a hierarchy. TLDs can have many domains under them. For instance, the "com" TLD has both "google.com" and "ubuntu.com" underneath it. A "subdomain" refers to any domain that is part of a larger domain. In this case, "ubuntu.com" can be said to be a subdomain of "com". This is typically just called the domain or the "ubuntu" portion is called a SLD, which means second level domain.

Likewise, each domain can control "subdomains" that are located under it. This is usually what we mean by subdomains. For instance you could have a subdomain for the history department of your school at "www.history.school.edu". The "history" portion is a subdomain.

The difference between a host name and a subdomain is that a host defines a computer or resource, while a subdomain extends the parent domain. It is a method of subdividing the domain itself.

Whether talking about subdomains or hosts, you can begin to see that the left-most portions of a domain are the most specific. This is how DNS works: from most to least specific as you read from left-to-right.

Fully Qualified Domain Name

A fully qualified domain name, often called FQDN, is what we call an absolute domain name. Domains in the DNS system can be given relative to one another, and as such, can be somewhat ambiguous. A FQDN is an absolute name that specifies its location in relation to the absolute root of the domain name system.

This means that it specifies each parent domain including the TLD. A proper FQDN ends with a dot, indicating the root of the DNS hierarchy. An example of a FQDN is "mail.google.com.". Sometimes software that calls for FQDN does not require the ending dot, but the trailing dot is required to conform to ICANN standards.

Name Server

A name server is a computer designated to translate domain names into IP addresses. These servers do most of the work in the DNS system. Since the total number of domain translations is too much for any one server, each server may redirect request to other name servers or delegate responsibility for a subset of subdomains they are responsible for.

Name servers can be "authoritative", meaning that they give answers to queries about domains under their control. Otherwise, they may point to other servers, or serve cached copies of other name servers' data.

Zone File

A zone file is a simple text file that contains the mappings between domain names and IP addresses. This is how the DNS system finally finds out which IP address should be contacted when a user requests a certain domain name.

Zone files reside in name servers and generally define the resources available under a specific domain, or the place that one can go to get that information.

Records

Within a zone file, records are kept. In its simplest form, a record is basically a single mapping between a resource and a name. These can map a domain name to an IP address, define the name servers for the domain, define the mail servers for the domain, etc.

How DNS Works

Now that you are familiar with some of the terminology involved with DNS, how does the system actually work?

The system is very simple at a high-level overview, but is very complex as you look at the details. Overall though, it is a very reliable infrastructure that has been essential to the adoption of the internet as we know it today.

Root Servers

As we said above, DNS is, at its core, a hierarchical system. At the top of this system is what are known as "root servers". These servers are controlled by various organizations and are delegated authority by ICANN (Internet Corporation for Assigned Names and Numbers).

There are currently 13 root servers in operation. However, as there are an incredible number of names to resolve every minute, each of these servers is actually mirrored. The interesting thing about this set up is that each of the mirrors for a single root server share the same IP address. When requests are made for a certain root server, the request will be routed to the nearest mirror of that root server.

What do these root servers do? Root servers handle requests for information about Top-level domains. So if a request comes in for something a lower-level name server cannot resolve, a query is made to the root server for the domain.

The root servers won't actually know where the domain is hosted. They will, however, be able to direct the requester to the name servers that handle the specifically requested top-level domain.

So if a request for "www.wikipedia.org" is made to the root server, the root server will tell not find the result in its records. It will check its zone files for a listing that matches "www.wikipedia.org". It will not find one.

It will instead find a record for the "org" TLD and give the requesting entity the address of the name server responsible for "org" addresses.

TLD Servers

The requester then sends a new request to the IP address (given to it by the root server) that is responsible for the top-level domain of the request.

So, to continue our example, it would send a request to the name server responsible for knowing about "org" domains to see if it knows where "www.wikipedia.org" is located.

Once again, the requester will look for "www.wikipdia.org" in its zone files. It will not find this record in its files.

However, it will find a record listing the IP address of the name server responsible for "wikipedia.org". This is getting much closer to the answer we want.

Domain-Level Name Servers

At this point, the requester has the IP address of the name server that is responsible for knowing the actual IP address of the resource. It sends a new request to the name server asking, once again, if it can resolve "www.wikipedia.org".

The name server checks its zone files and it finds that it has a zone file associated with "wikipedia.org". Inside of this file, there is a record for the "www" host. This record tells the IP address where this host is located. The name server returns the final answer to the requester.

What is a Resolving Name Server?

In the above scenario, we referred to a "requester". What is the requester in this situation?

In almost all cases, the requester will be what we call a "resolving name server" A resolving name server is one configured to ask other servers questions. It is basically an intermediary for a user which caches previous query results to improve speed and knows the addresses of the root servers to be able to "resolve" requests made for things it doesn't already know about.

Basically, a user will usually have a few resolving name servers configured on their computer system. The resolving name servers are usually provided by an ISP or other organizations. For instance Google provides resolving DNS servers that you can query. These can be either configured in your computer automatically or manually.

When you type a URL in the address bar of your browser, your computer first looks to see if it can find out locally where the resource is located. It checks the "hosts" file on the computer and a few other locations. It then sends the request to the resolving name server and waits back to receive the IP address of the resource.

The resolving name server then checks its cache for the answer. If it doesn't find it, it goes through the steps outlined above.

Resolving name servers basically compress the requesting process for the end user. The clients simply have to know to ask the resolving name servers where a resource is located and be confident that they will investigate and return the final answer.

Zone Files

We mentioned in the above process the idea of "zone files" and "records".

Zone files are the way that name servers store information about the domains they know about. Every domain that a name server knows about is stored in a zone file. Most requests coming to the average name server are not something that the server will have zone files for.

If it is configured to handle recursive queries, like a resolving name server, it will find out the answer and return it. Otherwise, it will tell the requesting party where to look next.

The more zone files that a name server has, the more requests it will be able to answer authoritatively.

A zone file describes a DNS "zone", which is basically a subset of the entire DNS naming system. It generally is used to configure just a single domain. It can contain a number of records which define where resources are for the domain in question.

The zone's $ORIGIN is a parameter equal to the zone's highest level of authority by default.

So if a zone file is used to configure the "example.com." domain, the $ORIGIN would be set to example.com..

This is either configured at the top of the zone file or it can be defined in the DNS server's configuration file that references the zone file. Either way, this parameter describes what the zone is going to be authoritative for.

Similarly, the $TTL configures the "time to live" of the information it provides. It is basically a timer. A caching name server can use previously queried results to answer questions until the TTL value runs out.

Record Types

Within the zone file, we can have many different record types. We will go over some of the more common (or mandatory types) here.

SOA Records

The Start of Authority, or SOA, record is a mandatory record in all zone files. It must be the first real record in a file (although $ORIGIN or $TTL specifications may appear above). It is also one of the most complex to understand.

The start of authority record looks something like this:

domain.com.  IN SOA ns1.domain.com. admin.domain.com. (
                                            12083   ; serial number
                                            3h      ; refresh interval
                                            30m     ; retry interval
                                            3w      ; exiry period
                                            1h      ; negative TTL
)

Let's explain what each part is for:

domain.com.: This is the root of the zone. This specifies that the zone file is for the domain.com.domain. Often, you'll see this replaced with @, which is just a placeholder that substitutes the contents of the $ORIGIN variable we learned about above.
IN SOA: The "IN" portion means internet (and will be present in many records). The SOA is the indicator that this is a Start of Authority record.
ns1.domain.com.: This defines the primary master name server for this domain. Name servers can either be master or slaves, and if dynamic DNS is configured one server needs to be a "primary master", which goes here. If you haven't configured dynamic DNS, then this is just one of your master name servers.
admin.domain.com.: This is the email address of the administrator for this zone. The "@" is replaced with a dot in the email address. If the name portion of the email address normally has a dot in it, this is replace with a "\" in this part (your.name@domain.com becomes your\name.domain.com).
12083: This is the serial number for the zone file. Every time you edit a zone file, you must increment this number for the zone file to propagate correctly. Slave servers will check if the master server's serial number for a zone is larger than the one they have on their system. If it is, it requests the new zone file, if not, it continues serving the original file.
3h: This is the refresh interval for the zone. This is the amount of time that the slave will wait before polling the master for zone file changes.
30m: This is the retry interval for this zone. If the slave cannot connect to the master when the refresh period is up, it will wait this amount of time and retry to poll the master.
3w: This is the expiry period. If a slave name server has not been able to contact the master for this amount of time, it no longer returns responses as an authoritative source for this zone.
1h: This is the amount of time that the name server will cache a name error if it cannot find the requested name in this file.

A and AAAA Records

Both of these records map a host to an IP address. The "A" record is used to map a host to an IPv4 IP address, while "AAAA" records are used to map a host to an IPv6 address.

The general format of these records is this:

host     IN      A       IPv4_address
host     IN      AAAA    IPv6_address

So since our SOA record called out a primary master server at "ns1.domain.com", we would have to map this to an address to an IP address since "ns1.domain.com" is within the "domain.com" zone that this file is defining.

The record could look something like this:

ns1     IN  A       111.222.111.222

Notice that we don't have to give the full name. We can just give the host, without the FQDN and the DNS server will fill in the rest with the $ORIGIN value. However, we could just as easily use the entire FQDN if we feel like being semantic:

ns1.domain.com.     IN  A       111.222.111.222

In most cases, this is where you'll define your web server as "www":

www     IN  A       222.222.222.222

We should also tell where the base domain resolves to. We can do this like this:

domain.com.     IN  A       222.222.222.222

We could have used the "@" to refer to the base domain instead:

@       IN  A       222.222.222.222

We also have the option of resolving anything that under this domain that is not defined explicitly to this server too. We can do this with the "*" wild card:

*       IN  A       222.222.222.222

All of these work just as well with AAAA records for IPv6 addresses.

CNAME Records

CNAME records define an alias for canonical name for your server (one defined by an A or AAAA record).

For instance, we could have an A name record defining the "server1" host and then use the "www" as an alias for this host:

server1     IN  A       111.111.111.111
www         IN  CNAME   server1

Be aware that these aliases come with some performance losses because they require an additional query to the server. Most of the time, the same result could be achieved by using additional A or AAAA records.

One case when a CNAME is recommended is to provide an alias for a resource outside of the current zone.

MX Records

MX records are used to define the mail exchanges that are used for the domain. This helps email messages arrive at your mail server correctly.

Unlike many other record types, mail records generally don't map a host to something, because they apply to the entire zone. As such, they usually look like this:

        IN  MX  10   mail.domain.com.

Note that there is no host name at the beginning.

Also note that there is an extra number in there. This is the preference number that helps computers decide which server to send mail to if there are multiple mail servers defined. Lower numbers have a higher priority.

The MX record should generally point to a host defined by an A or AAAA record, and not one defined by a CNAME.

So, let's say that we have two mail servers. There would have to be records that look something like this:

        IN  MX  10  mail1.domain.com.
        IN  MX  50  mail2.domain.com.
mail1   IN  A       111.111.111.111
mail2   IN  A       222.222.222.222

In this example, the "mail1" host is the preferred email exchange server.

We could also write that like this:

        IN  MX  10  mail1
        IN  MX  50  mail2
mail1   IN  A       111.111.111.111
mail2   IN  A       222.222.222.222

NS Records

This record type defines the name servers that are used for this zone.

You may be wondering, "if the zone file resides on the name server, why does it need to reference itself?". Part of what makes DNS so successful is its multiple levels of caching. One reason for defining name servers within the zone file is that the zone file may be actually being served from a cached copy on another name server. There are other reasons for needing the name servers defined on the name server itself, but we won't go into that here.

Like the MX records, these are zone-wide parameters, so they do not take hosts either. In general, they look like this:

        IN  NS     ns1.domain.com.
        IN  NS     ns2.domain.com.

You should have at least two name servers defined in each zone file in order to operate correctly if there is a problem with one server. Most DNS server software considers a zone file to be invalid if there is only a single name server.

As always, include the mapping for the hosts with A or AAAA records:

        IN  NS     ns1.domain.com.
        IN  NS     ns2.domain.com.
ns1     IN  A      111.222.111.111
ns2     IN  A      123.211.111.233

There are quite a few other record types you can use, but these are probably the most common types that you will come across.

PTR Records

The PTR records are used define a name associated with an IP address. PTR records are the inverse of an A or AAAA record. PTR records are unique in that they begin at the .arpa root and are delegated to the owners of the IP addresses. The Regional Internet Registries (RIRs) manage the IP address delegation to organization and service providers. The Regional Internet Registries include APNIC, ARIN, RIPE NCC, LACNIC, and AFRINIC.

Here is an example of a PTR record for 111.222.333.444 would look like:

444.333.222.111.in-addr.arpa.   33692   IN  PTR host.example.com.

This example of a PTR record for an IPv6 address shows the nibble format of the reverse of Google's IPv6 DNS Server 2001:4860:4860::8888.

8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.

The command line tool dig with the -x flag can be used to look up the reverse DNS name of an IP address.

Here is an example of a dig command. The +short is appended to reduce the output to the reverse DNS name.


dig -x 8.8.4.4 +short

The output for the dig command above will be the domain name in the PTR record for the IP address:

google-public-dns-b.google.com.

Servers on the Internet use PTR records to place domain names within log entries, make informed spam handling decisions, and display easy-to-read details about other devices.

Most commonly-used email servers will look up the PTR record of an IP address it receives email from. If the source IP address does not have a PTR record associated with it, the emails being sent may be treated as spam and rejected. It is not important that the FQDN in the PTR matches the domain name of the email being sent. What is important is that there is a valid PTR record with a corresponding and matching forward A record.

Normally network routers on the Internet are given PTR records that correspond with their physical location. For example you may see references to 'NYC' or 'CHI' for a router in New York City or Chicago. This is helpful when running a traceroute or MTR and reviewing the path Internet traffic is taking.

Most providers offering dedicated servers or VPS services will give customers the ability to set a PTR record for their IP address. DigitalOcean will automatically assign the PTR record of any Droplet when the Droplet is named with a domain name. The Droplet name is assigned during creation and can be edited later using the settings page of the Droplet control panel.

Note: It is important that the FQDN in the PTR record has a corresponding and matching forward A record. Example: 111.222.333.444 has a PTR of server.example.com and server.example.com is an A record that points to 111.222.333.444.

Conclusion

You should now have a pretty good grasp on how DNS works. While the general idea is relatively easy to grasp once you're familiar with the strategy, this is still something that can be difficult for inexperienced administrators to put into practice.

dns