{"id":4988,"date":"2017-06-01T00:01:05","date_gmt":"2017-06-01T04:01:05","guid":{"rendered":"http:\/\/www.linux-databook.info\/?page_id=4988"},"modified":"2017-05-27T07:40:17","modified_gmt":"2017-05-27T11:40:17","slug":"set-up-a-dns-server-using-bind","status":"publish","type":"page","link":"http:\/\/www.linux-databook.info\/?page_id=4988","title":{"rendered":"Set up a DNS server using BIND"},"content":{"rendered":"

In a\u00a0previous article,\u00a0Introduction to the Domain Name System (DNS)<\/a>, I described how the DNS database is structured and how to configure name services on a client. I also listed and describe some of the more common DNS records you are likely to encounter when building a name server or just trying to interpret the results of a dig<\/b> command.<\/p>\n

In this article I show you how to build your own name server using BIND<\/a>, the Berkeley Internet Name Domain. It is not as difficult as you might think, especially since it can be done in two stages.<\/p>\n

In this article you will start by learning how to create a caching name server. Then you will move on and learn how to upgrade that to a complete primary (master) domain name server for your network complete with forward and reverse zone files.<\/p>\n

Setting up a name server using BIND is quite straightforward so I thought I would show you how to do so on any computer you might happen to have available for experimentation. This little lab project will show you how to install and configure BIND on your computer as a caching name server, test it, then set it up as a primary name server with a zone file that you can use as a name resolver for your network or just for testing.<\/p>\n

It is technically possible to set up a name server on any GNU\/Linux computer you have available because it will not interfere with other hosts on the network or their operation. However you should probably not do this on a computer that you do not own or have the right to modify unless you have explicit permission to do so.<\/p>\n

My setup<\/h2>\n

You only need one computer to perform all but one of the tasks in this lab project. I use this setup on my much more powerful Thinkpad because the name servers provided by DHCP when I connect to non-home networks using either wired or wireless connections can sometimes be unreliable. To show that almost any host can perform well as a name server, I have tested this project on an old ASUS <\/a>Ee<\/a>e<\/a>PC<\/a> 900<\/a> netbook that has the following specifications.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
Item<\/th>\nDescription<\/th>\n<\/tr>\n
Motherboard<\/td>\nASUSTeK 900A<\/td>\n<\/tr>\n
CPU<\/td>\nIntel(R) Atom(TM) CPU N270, <\/span>single core, 32-bit with hyperthreading<\/span><\/td>\n<\/tr>\n
Speed<\/td>\n1.6GHz<\/td>\n<\/tr>\n
RAM<\/td>\n2GB<\/td>\n<\/tr>\n
Swap<\/td>\n2GB<\/td>\n<\/tr>\n
sda<\/td>\nInternal 4GB SSD<\/td>\n<\/tr>\n
sdb<\/td>\n32GB SD card<\/td>\n<\/tr>\n
Operating System<\/td>\nFedora 25 32-bit<\/td>\n<\/tr>\n
Hostname<\/td>\nepc<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

I will use the private IP address of my ASUS for this project but you should use the IP address of the host that you are using.<\/p>\n

The hosts file<\/h2>\n

First let’s take a look at the \/etc\/hosts file. In its default state, there should only be two lines in the hosts file, the first two lines seen in Listing 1, below.<\/p>\n\n\n\n
\n
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 <\/span>\r\n::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 <\/span>\r\n# Lab <\/span>hosts \r\n192.168.25.1      <\/span>server<\/span> \r\n192.168.25.2<\/span>1<\/span>     host1<\/span> \r\n192.168.25.2<\/span>2<\/span>     host2<\/span> \r\n192.168.25.2<\/span>3<\/span>     host3<\/span> \r\n192.168.25.24     host4<\/span><\/span><\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Listing 1: A simple hosts file can be maintained by a user to perform the function of a resolver in small networks.<\/i><\/span><\/span><\/p>\n

 Although you can add hostnames and their respective IP Addresses as shown in Listing 1, that is not an optimal solution to name services, especially when traveling. If there are other entries in your hosts file you may need to comment them out for the duration of this project if they interfere with naming or IP addresses. Most of you will not have any entries other than the two default lines.<\/p>\n
Preparation<\/h2>\n
A caching nameserver cannot replace our use of \/etc\/hosts to resolve hostnames on the internal network but compared to using an ISP or other public nameserver, however, a caching nameserver can improve performance when resolving external names that are commonly used, such as www.cnn.com. The best part is that setting up a caching nameserver is quite easy.\u00a0Before starting, you should prepare by performing the following steps.<\/p>\n
First, make backup copies of the files \/etc\/hosts, \/etc\/named.conf, resolv.conf, and \/etc\/sysconfig\/iptables.<\/p>\n
If they are not already installed, use your distribution’s package manager to install the following BIND RPMs: bind, bind-chroot, and bind-utils. To enable your lab host to use the caching nameserver, you must add a nameserver line to point to your own host in \/etc\/resolv.conf. For example, if your lab host IP Address is 192.168.0.203, as is my epc, add the following line to the top of the nameserver list in \/etc\/resolv.conf:<\/p>\n
nameserver 192.168.<\/b><\/span><\/span><\/span>0.203<\/b><\/span><\/span><\/span><\/span><\/pre>\n
Be sure to use the IP Address of the host on which you are doing this project.<\/i><\/p>\n
You could use the IP Address of your localhost, 127.0.0.1 instead of the external IP address. You should also comment out any lines pointing to other hosts as name servers. Be sure to save the revised resolv.conf file.<\/p>\n
These changes will take effect immediately and no reboot or service restart is required. Now attempt to ping a common public host that does not block ICMP packets; feel free to use my firewall, which is a Raspberry Pi<\/a>.<\/p>\n
ping <\/b><\/span><\/span><\/span>wally2.both.org<\/b><\/span><\/span><\/span><\/span><\/pre>\n
You should get an “unknown host” or “Name or service not known” error because you currently have no working DNS service or resolver defined in the resolv.conf file. Now use the dig command to see if name services is working.<\/p>\n
dig wally2.both.com<\/b><\/span><\/span><\/span><\/pre>\n
You should get the error, \u201cconnection timed out; no servers could be reached.\u201d<\/p>\n
Set up a Caching Nameserver<\/h2>\n
A caching name server is not an authoritative source for any domain. It simply caches the results of all name resolver requests from the network which it serves in order to speed up responses to future requests for the same remote host.<\/p>\n
For the initial setup of the caching name server it is necessary to make a couple modifications to the default \/etc\/named.conf file so edit that file using your favorite editor. First, add the IP address of your local test host to the \u201clisten-on port 53\u201d line as shown in Listing 2, below. This enables named to listen on the external IP Address of your host so that other computers can use it as a nameserver as well.<\/p>\n
Note:<\/b> The named.conf file is very particular about syntax and especially punctuation. Semi-colons are used to delineate the end of an entry and the end of a stanza as well as the end of a line. Be sure to add them in correctly as shown in the samples.<\/i><\/p>\n
By default, BIND refers to the Internet’s root Name Servers to locate the authoritative name servers for a domain. It is possible to specify other servers that are called \u201cForwarders\u201d to which the local instance of BIND will send requests instead of the root servers. This does increase the possibility of DNS hijacking.<\/p>\n
Add a \u201cforwarders\u201d line as shown below. This tells your caching DNS server where to obtain IP Addresses when they are not already cached locally. The IP Addresses in the listing below is for the Google public DNS servers<\/a> You could use your local ISP or OpenDNS or some other public name server as your forwarder. It is not necessary to define any forwarders and, in that case, BIND would use the Internet root servers as defined in the file \/var\/named\/named.ca to locate the authoritative name servers for domains if no forwarders are defined. But for this exercise, please define the forwarders as I have in Listing 2.<\/p>\n
Comment out the IPV6 line as we are not using IPV6 in the lab environment. Note that the \u201c\/\/\u201d two forward slashes denote comments in the named.conf file.<\/p>\n\n\n\n
\n
\/\/<\/span>\r\n\/\/ named.conf<\/span>\r\n\/\/ Provided by Red Hat bind package to configure the ISC BIND named(8) DNS<\/span>\r\n\/\/ server as a caching only nameserver (as a localhost DNS resolver only).<\/span>\r\n\/\/ See \/usr\/share\/doc\/bind*\/sample\/ for example named configuration files.<\/span>\r\n\/\/<\/span>\r\n\/\/<\/span>\r\n\r\noptions {<\/span>\r\n\u00a0 \u00a0 \u00a0listen-on port 53 { 127.0.0.1; <\/span>192.168.<\/b><\/span>0<\/b><\/span>.2<\/b><\/span>03<\/b><\/span>;<\/b><\/span> };<\/span>\r\n\u00a0 \u00a0 \u00a0\/\/ listen-on-v6 port 53 { ::1; };<\/span>\r\n\u00a0 \u00a0 \u00a0forwarders { <\/b><\/span>8.8.8.8<\/b><\/span>; <\/b><\/span>8.8.4.4; <\/b><\/span>};<\/b><\/span>\r\n\u00a0 \u00a0 \u00a0directory \"\/var\/named\";<\/span>\r\n\u00a0 \u00a0 \u00a0dump-file \"\/var\/named\/data\/cache_dump.db\";<\/span>\r\n\u00a0 \u00a0 \u00a0statistics-file \"\/var\/named\/data\/named_stats.txt\";<\/span>\r\n\u00a0 \u00a0 \u00a0memstatistics-file \"\/var\/named\/data\/named_mem_stats.txt\";<\/span>\r\n\u00a0 \u00a0 \u00a0allow-query { localhost; <\/span>192.168.<\/b><\/span>0<\/b><\/span>.0\/24;<\/b><\/span> };<\/span>\r\n\u00a0 \u00a0 \u00a0recursion yes;<\/span>\r\n\u00a0 \u00a0 \u00a0dnssec-enable yes;<\/span>\r\n\u00a0 \u00a0 \u00a0dnssec-validation yes;\r\n<\/span>\u00a0 \u00a0 \u00a0dnssec-lookaside auto;<\/span>\r\n\u00a0 \u00a0 \u00a0\/* Path to ISC DLV key *\/<\/span>\r\n\u00a0 \u00a0 \u00a0bindkeys-file \"\/etc\/named.iscdlv.key\";<\/span>\r\n\u00a0 \u00a0 \u00a0managed-keys-directory \"\/var\/named\/dynamic\";<\/span>\r\n};<\/span>\r\n\r\nlogging {<\/span>\r\n\u00a0 \u00a0 \u00a0channel default_debug {<\/span>\r\n\u00a0 \u00a0 \u00a0file \"data\/named.run\";<\/span>\r\n\u00a0 \u00a0 \u00a0severity dynamic;<\/span>\r\n};<\/span>\r\n};<\/span>\r\n\r\nzone \".\" IN {<\/span>\r\n\u00a0 \u00a0 \u00a0type hint;<\/span>\r\n\u00a0 \u00a0 \u00a0file \"named.ca\";<\/span>\r\n};<\/span>\r\n\r\ninclude \"\/etc\/named.rfc1912.zones\";<\/span>\r\ninclude \"\/etc\/named.root.key\";<\/span><\/span><\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Listing 2: The \/etc\/named.conf file provides the simple configuration required to set up a caching name server. The lines that need to be added or changed are highlighted in bold.<\/i><\/span><\/span><\/p>\n
Add the local network address, 192.168.0.0\/24, to the allow-query<\/b> line. This line specifies the network(s) from which DNS queries will be accepted by this DNS server.<\/p>\n
Start the Name Service<\/h3>\n
Now start the named service and configure the named service to start at every boot. I use the systemctl command on my Fedora 25 host, but the command may be different on your host, depending upon the distribution you are using. Note that the name of the BIND resolver service is named.<\/p>\n
systemctl enable named<\/b><\/span><\/span><\/span>\r\nsystemctl start named<\/b><\/span><\/span><\/span><\/pre>\n
The first test you can perform to ensure that your caching name server is working is to use dig to locate the DNS database information for wally2.both.org. To further test your caching nameserver, use the dig command to obtain the IP Address(es) for some common Internet web sites, such as www.opensource.com, CNN, Wired, and any others you like. The results should now show your host as the responding server.<\/p>\n
At this point your caching nameserver will correctly resolve hosts on the Internet. That is because those DNS requests for public hosts are forwarded to the Google public name servers. Refer to the \u201cforwarders\u201d line in named.conf. However you are still dependent upon the \/etc\/hosts file for internal name services. Creating a primary name server can solve that problem.<\/p>\n
Creating a primary Nameserver<\/h2>\n
Once a caching nameserver has been created, it is not too difficult to convert it into a full-fledged primary nameserver. A primary name server is the authoritative source for the domain it represents.<\/p>\n
We need to change named.conf again and create a couple new files. We will create a domain called example.com which is a domain name reserved for example purposes in documents like this one. The example.com domain does have an IP address on the Internet and a very spare web site, but we can use the name in the rest of our lab project without causing problems for anyone. The example.com domain will be the internal domain name for the rest of this exercise.<\/p>\n
The two new files we will create are the forward and reverse zone files. They will be located in the \/var\/named directory. This location is specified by the \u201cdirectory\u201d directive in the named.conf configuration file.<\/p>\n
Create the Forward Zone File<\/h3>\n
The forward zone file contains \u201cA\u201d records that pair the names of the hosts in the zone, aka domain, with their respective IP addresses. It may also contain CNAME records that are aliases for the real hostnames in the A records, and MX records for mail servers.<\/p>\n
Create a basic forward zone file, \/var\/named\/example.com.zone and add the following lines to it. Your zone file should look like the sample zone file in Listing 3, below, when you are finished.<\/p>\n\n\n\n
\n
; Authoritative data for example.com zone <\/span><\/span><\/span><\/span><\/span>\r\n; <\/span><\/span><\/span><\/span><\/span>\r\n$TTL 1D <\/span><\/span><\/span><\/span><\/span>\r\n@   IN SOA  epc.example.com   root.epc.example.com. ( <\/span><\/span><\/span><\/span><\/span>\r\n                                       2017031301      ; serial <\/span><\/span><\/span><\/span><\/span>\r\n                                       1D              ; refresh <\/span><\/span><\/span><\/span><\/span>\r\n                                       1H              ; retry <\/span><\/span><\/span><\/span><\/span>\r\n                                       1W              ; expire <\/span><\/span><\/span><\/span><\/span>\r\n                                       3H )            ; minimum <\/span><\/span><\/span><\/span><\/span>\r\n\r\n$ORIGIN         example.com. <\/span><\/span><\/span><\/span><\/span>\r\nexample.com.            IN      NS      epc.example.com. <\/span><\/span><\/span><\/span><\/span>\r\nepc                     IN      A       127.0.0.1 <\/span><\/span><\/span><\/span><\/span>\r\nserver                  IN      A       192.168.25.1 <\/span><\/span><\/span><\/span><\/span>\r\nwww                     IN      CNAME   server <\/span><\/span><\/span><\/span><\/span>\r\nmail                    IN      CNAME   server <\/span><\/span><\/span><\/span><\/span>\r\ntest1                   IN      A       192.168.25.21 <\/span><\/span><\/span><\/span><\/span>\r\nt1                      IN      CNAME   test1 <\/span><\/span><\/span><\/span><\/span>\r\ntest2                   IN      A       192.168.25.22 <\/span><\/span><\/span><\/span><\/span>\r\ntest3                   IN      A       192.168.25.23 <\/span><\/span><\/span><\/span><\/span>\r\ntest4                   IN      A       192.168.25.24 <\/span><\/span><\/span><\/span><\/span>\r\n\r\n; Mail server MX record <\/span><\/span><\/span><\/span><\/span>\r\nexample.com.            IN      MX      10      mail.example.com.<\/span><\/span><\/span><\/span><\/span><\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Listing 3: The forward zone file for the example.com domain contains the hostnames and their IP addresses for this domain.<\/i><\/pre>\n

The first non-comment line in Listing 3 is the Time To Live specifier \u2013 in this case one day for all records that are not otherwise specified. D stands for Day. The specifiers in the Start Of Authority (SOA) line are just as obvious. Details of the parameters in the SOA record are described in some detail here<\/a>.<\/p>\n
The NS record must have the fully qualified domain name (FQDN) of the host on which you are performing this lab project. There must also be an A record in the file with a valid IP address for for the host. In this case you should use the localhost IP address of 127.0.0.1.<\/p>\n
The entries shown above will give you a few hostnames to experiment with.<\/p>\n
Be sure to use today’s date and append a counter starting at 01 for the serial number. The serial number above is the first change of March 4, 2017. The serial number is incremented whenever the zone file is changed. If there were secondary name servers that used this one for a primary, they would not be updated unless the serial number is incremented.<\/p>\n
Add the Forward Zone Files to named.conf<\/h3>\n
Before your DNS server will work, however, you need to create an entry in \/etc\/named.conf that will point to your new zone file. Add the following lines below the entry for the top level hints zone but before the \u201cinclude\u201d lines.<\/p>\n\n\n\n
\n
zone \"example.com\" IN {<\/span><\/span><\/span><\/span>\r\n    type <\/span><\/span><\/span><\/span>master<\/span><\/span><\/span><\/span>;<\/span><\/span><\/span><\/span>\r\n    file \"example.com.zone\";<\/span><\/span><\/span><\/span>\r\n};<\/span><\/span><\/span><\/span><\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Listing 4: Add these lines to the named.conf file to add the example.com zone file to the resolver configuration.<\/i><\/span><\/span><\/p>\n
Now restart named to make these changes take effect. Test your name server by using the dig and nsloookup commands to obtain the IP Addresses for the hosts you have configured in the forward zone file. Note that the host does not have to exist on the network for the dig and nslookup commands to return an IP Address.<\/p>\n
\n
dig test1.example.com<\/b><\/span><\/span><\/span><\/span><\/dd>\n
dig t1.example.com<\/b><\/span><\/span><\/span><\/span><\/dd>\n
dig mx example.com<\/b><\/span><\/span><\/span><\/span><\/dd>\n
dig mail.example.com<\/b><\/span><\/span><\/span><\/span><\/dd>\n
nslookup test3.<\/b><\/span><\/span><\/span><\/span>example.com<\/b><\/span><\/span><\/span><\/span><\/dd>\n
dig www.amazon.com<\/b><\/span><\/span><\/span><\/span><\/dd>\n<\/dl>\n
Be aware that it is necessary to use the FQDN for the both commands but not for the nslookup command so long as the domain and search entries of \u201cexample.com\u201d are provided in the \/etc\/resolv.conf file. In this case they probably are not, so just use the FQDNs for all testing in this project.<\/p>\n
Using the root name servers<\/h3>\n
You will notice that the root name servers are given as the authoritative servers for the amazon.com lookup. But remember we are using the Google public name servers as forwarders. Now comment out the forwarders line in named.conf and restart named. Run the above commands again to compare the results that are returned. The results should look similar to the ones below in Listing 5.<\/p>\n\n\n\n
\n
# dig www.amazon.com<\/span><\/span><\/span><\/span>\r\n\r\n; <<>> DiG 9.10.4-P6-RedHat-9.10.4-4.P6.fc25 <<>> www.amazon.com\r\n;; global options: +cmd\r\n;; Got answer:\r\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65004\r\n;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 1\r\n\r\n;; OPT PSEUDOSECTION:\r\n; EDNS: version: 0, flags:; udp: 4096\r\n;; QUESTION SECTION:\r\n;www.amazon.com. IN A\r\n\r\n;; ANSWER SECTION:\r\nwww.amazon.com. 1800 IN CNAME www.cdn.amazon.com.\r\nwww.cdn.amazon.com. 300 IN CNAME d3ag4hukkh62yn.cloudfront.net.\r\nd3ag4hukkh62yn.cloudfront.net. 60 IN A 52.85.147.120\r\nd3ag4hukkh62yn.cloudfront.net. 60 IN A 52.85.147.50\r\nd3ag4hukkh62yn.cloudfront.net. 60 IN A 52.85.147.92\r\nd3ag4hukkh62yn.cloudfront.net. 60 IN A 52.85.147.109\r\n\r\n;; AUTHORITY SECTION:\r\nd3ag4hukkh62yn.cloudfront.net. 1831 IN NS ns-1144.awsdns-15.org.\r\nd3ag4hukkh62yn.cloudfront.net. 1831 IN NS ns-130.awsdns-16.com.\r\nd3ag4hukkh62yn.cloudfront.net. 1831 IN NS ns-2021.awsdns-60.co.uk.\r\nd3ag4hukkh62yn.cloudfront.net. 1831 IN NS ns-824.awsdns-39.net.\r\n\r\n;; Query time: 3857 msec\r\n;; SERVER: 192.168.0.203#53(192.168.0.203)\r\n;; WHEN: Mon Mar 13 09:18:30 EDT 2017\r\n;; MSG SIZE rcvd: 306<\/span><\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Listing 5: The results of a lookup on www.amazon.com have some interesting information including times to live for the various record types.<\/i><\/span><\/span><\/p>\n
When I did this, the first call to resolve the external address for Amazon took 3857ms while the data was located and returned. Subsequent results to perform the same query was 1ms which shows the advantage of caching resolver results locally. Notice the numbers 1800, 300, and 60 in the answer section lines and 1831 in authority section lines. These are TTL \u2013 Times To Live in seconds. If you perform the lookup multiple times, these numbers will change, showing the amount of time that the records have remaining to live in local cache.<\/p>\n
Creating the Reverse Zone File<\/h3>\n
A reverse zone for your domain will provide the ability to do reverse lookups. many organizations do not do these internally, but reverse lookups can be helpful in doing problem determination. Many spam fighting configurations such as SpamAssassin look for reverse lookups to verify valid email servers.<\/p>\n
Create the reverse zone file, \/var\/named\/example.com.rev and add the following contents. Be sure to use an appropriate serial number.<\/p>\n\n\n\n
\n
; Authoritative data for example.com  reverse zone\r\n;\r\n$TTL 1D\r\n@   IN SOA  test1.example.com   root.test1.example.com. (\r\n                                        2017031501      ; serial\r\n                                        1D              ; refresh\r\n                                        1H              ; retry\r\n                                        1W              ; expire\r\n                                        3H )            ; minimum\r\n\r\n@       IN      NS      epc.example.com.\r\nexample.com.    IN      NS      epc.example.com.\r\n1               IN      PTR     mail.example.com.\r\n1               IN      PTR     server.example.com.\r\n21              IN      PTR     test1.example.com.\r\n22              IN      PTR     test2.example.com.\r\n23              IN      PTR     test3.example.com.\r\n24              IN      PTR     test4.example.com.<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Listing 6: Create this reverse zone file, example.com.rev, for your name server.<\/i><\/pre>\n
You could also name your reverse zone file \/var\/named\/25.168.192.in-addr.arpa which follows older conventions. You can actually name it anything you want because you will point to it explicitly in the named.conf file, but using one of the two conventions will make it easier for others to follow your work.<\/p>\n
Add the Reverse Zone to named.conf<\/h3>\n\n\n\n
\n
zone    \"25.168.192.in-addr.arpa\" IN { \r\n       type master; \r\n       file \"example.com.rev\"; \r\n};<\/span><\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Listing 7: Adding this stanza to the named.conf file enables reverse lookups.<\/i><\/span><\/span><\/p>\n

Add the stanza in Listing 7 to the \/etc\/named.conf file to point to the new reverse zone. Now reload named and test your reverse zone using the commands in Listing 8. Your results should look similar to those below.<\/p>\n\n\n\n
\n
# systemctl reload named<\/b><\/span><\/span><\/span>\r\n# <\/span><\/span><\/span>dig -x 192.168.25.23<\/b><\/span><\/span><\/span> \r\n\r\n; <<>> DiG 9.10.4-P6-RedHat-9.10.4-4.P6.fc25 <<>> -x 192.168.25.23 \r\n;; global options: +cmd \r\n;; Got answer: \r\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48607 \r\n;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 \r\n\r\n;; OPT PSEUDOSECTION: \r\n; EDNS: version: 0, flags:; udp: 4096 \r\n;; QUESTION SECTION: \r\n;23.25.168.192.in-addr.arpa.    IN      PTR \r\n\r\n;; ANSWER SECTION: \r\n23.25.168.192.in-addr.arpa. 86400 IN    PTR     test3.example.com. \r\n\r\n;; AUTHORITY SECTION: \r\n25.168.192.in-addr.arpa. 86400  IN      NS      epc.<\/span><\/span><\/span>example.com<\/span><\/span><\/span>. \r\n\r\n;; Query time: 21 msec \r\n;; SERVER: 192.168.0.203#53(192.168.0.203) \r\n;; WHEN: Wed Mar 15 16:18:59 EDT 2017 \r\n;; MSG SIZE  rcvd: 112<\/span><\/span><\/span><\/span><\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Listing 8: After restarting named you should see results similar to these when you do a reverse lookup on an IP address in the reverse zone.<\/i><\/span><\/span><\/pre>\n
Be sure to test some of the other reverse entries in your network. Be sure to try the following as well as other reverse lookups you want to experiment with. The -x option means reverse lookup.<\/p>\n
dig -x 192.168.25.23<\/b>\r\ndig -x 192.168.25.1<\/b>\r\n<\/pre>\n
Note that not all hosts that have entries in the forward zone need to have entries in the reverse zone, but it does make for more consistent results if they do.<\/p>\n
At this point you have a working name server using BIND. However external hosts cannot yet use this name server because the firewall should not yet be configured to allow DNS requests.<\/p>\n
Configuring IPTables for DNS<\/h2>\n
You can do this step if you want other hosts on your local network to use your host as their name server.<\/p>\n
The firewall on your test host probably blocks access to your host for name services. IPTables must be configured to allow UDP packets inbound on your name server in order for other hosts to use it for name resolution. Use the following commands to add the required entries and save them.<\/p>\n
Add a rule to your IPTables or firewalld firewall that allows incoming packets on port 53 (domain) for UDP and save the new ruleset. Be sure to insert the new rule after the \u201c -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT\u201d line, so you will have to count the number of INPUT lines in the filter table in order to do that. The number 7 in the following command means that this rule will be inserted in position number 7 in the existing INPUT rules.<\/p>\n
 iptables -t filter -<\/b><\/span><\/span><\/span><\/span>I<\/b><\/span><\/span><\/span><\/span> <\/b>INPUT<\/b><\/span><\/span><\/span><\/span> <\/b>7<\/b><\/span><\/span><\/span><\/span> <\/b>-p udp -m conntrack --ctstate NEW -m udp --dport 53 -j ACCEPT<\/b><\/span><\/span><\/span><\/span><\/pre>\n
You can save your new firewall rules if you like, and you would if this were to be a permanent installation and not a lab project. Then test this from one of your other hosts using the command in Listing 9, below. The @<\/b>epc<\/b> argument tells the dig command to use the specified name server with the hostname epc. You should substitute either the IP address of the DNS server you have just created, or a resolvable hostname on your network that points to your new name server. Of course you could always add that hostname with its IP address to the \/etc\/hosts file of the host you are using for the remote test.<\/p>\n\n\n\n
\n
# <\/span><\/span><\/span><\/span>dig @<\/b><\/span><\/span><\/span><\/span>epc<\/b><\/span><\/span><\/span><\/span> test1.example.com<\/b><\/span><\/span><\/span><\/span><\/span>\r\n\r\n; <<>> DiG 9.10.4-P6-RedHat-9.10.4-4.P6.fc25 <<>> @epc test1.example.com\r\n; (1 server found)\r\n;; global options: +cmd\r\n;; Got answer:\r\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27957\r\n;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1\r\n\r\n;; OPT PSEUDOSECTION:\r\n; EDNS: version: 0, flags:; udp: 4096\r\n;; QUESTION SECTION:\r\n;test1.example.com. IN A\r\n\r\n;; ANSWER SECTION:\r\ntest1.example.com. 86400 IN A 192.168.25.21\r\n\r\n;; AUTHORITY SECTION:\r\nexample.com. 86400 IN NS epc.both.org.\r\n\r\n;; Query time: 0 msec\r\n;; SERVER: 192.168.0.203#53(192.168.0.203)\r\n;; WHEN: Mon Mar 13 08:45:34 EDT 2017\r\n;; MSG SIZE rcvd: 92<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Listing 9: Testing the name resolver you have created from a different host on the same network.<\/i><\/span><\/span><\/p>\n
<\/span>
Cleanup<\/h2>\n
For cleanup you should perform the following tasks using the tools appropriate for your distribution. You may just wish to keep this name server for your network if you do not already have one.<\/p>\n
    \n
  1. Restore the original \/etc\/hosts file.<\/li>\n
  2. Stop named on the resolver host used for this lab project.<\/li>\n
  3. Disable the named service.<\/li>\n
  4. Delete the zone files.<\/li>\n
  5. Restore the original named.conf file.<\/li>\n
  6. Restore the original resolv.conf file.<\/li>\n<\/ol>\n
    Conclusion<\/h2>\n
    The functioning of name services seemed very obscure to me until I actually created a name server for my network using BIND. It is quite straightforward and can significantly improve DNS lookup performance for a network. Having your own name server can also prevent many of the relatively minor yet annoying name service interruptions cause by poorly maintained ISP name servers.<\/p>\n
    Note that, even though my little EeePC is running with 100% CPU usage for Seti@Home, it responds extremely quickly to resolver requests. You should be able to try this project on any Linux host you have available with miniscule impact. So I would hope that many of you will try to set up your own name server and experiment with it. The specifics of your name server installation will depend upon the details of your host and network.<\/p>\n
    Resources<\/h2>\n
    \n
    Internet Assigned Numbers Authority (IANA)<\/a><\/dd>\n
    Start of Authority (SOA) record<\/a><\/dd>\n
    List of DNS Record Types<\/a><\/dd>\n
    Common DNS records and their uses<\/a><\/dd>\n<\/dl>\n
     <\/p>\n","protected":false},"excerpt":{"rendered":"
    In a\u00a0previous article,\u00a0Introduction to the Domain Name System (DNS), I described how the DNS database is structured and how to configure name services on a client. I also listed and describe some of the more common DNS records you are…<\/p>\n
    Read more →<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"parent":4327,"menu_order":7,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-4988","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-databook.info\/index.php?rest_route=\/wp\/v2\/pages\/4988","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-databook.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-databook.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-databook.info\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-databook.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=4988"}],"version-history":[{"count":12,"href":"http:\/\/www.linux-databook.info\/index.php?rest_route=\/wp\/v2\/pages\/4988\/revisions"}],"predecessor-version":[{"id":5002,"href":"http:\/\/www.linux-databook.info\/index.php?rest_route=\/wp\/v2\/pages\/4988\/revisions\/5002"}],"up":[{"embeddable":true,"href":"http:\/\/www.linux-databook.info\/index.php?rest_route=\/wp\/v2\/pages\/4327"}],"wp:attachment":[{"href":"http:\/\/www.linux-databook.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=4988"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}