Creating an integrated CentOS nameserver solution

So far in this chapter division, we used Unbound as a caching-only DNS server solution because it is very secure and fast, and BIND as our authoritative-only DNS server because its zone management is highly configurable and customizable. BIND has been around for a long time and is the most used DNS software ever. However, a number of critical bugs have been found (and luckily fixed) in the past. Here in this process, we will combine Unbound with BIND to get the best of both worlds: Only the very secure Unbound service will be directly exposed to your private network and can take and serve DNS queries from your clients. The BIND service stays bound to localhost only as it was configured in a former process and is only allowed to resolve internal hostnames and does not have direct access to the Internet or your clients. If a client connects to your Unbound service and requests to resolve an internal hostname from your private network, Unbound will query the BIND server locally for the DNS resolution and cache the response. On the other hand, if a client requests to resolve an external domain name, Unbound itself will recursively query or forward other remote DNS servers and cache the response. The integration of both DNS server systems makes it the perfect all-round DNS server solution.

To Start With: What Do You Need?

To complete this process, you will require a working installation of the CentOS 7 operating system and a console-based text editor of your choice. It is expected that a caching-only Unbound server (port 53) and an authoritative-only BIND server (port 8053) have been installed and are already running using process found in this chapter division.

The Process

In this process, we will show you how to configure Unbound so it will be able to query our locally running authoritative-only BIND service whenever a client requests an internal hostname. Any other request should go out as a recursive DNS request to a remote root server to construct an answer:

1. Log in as root on our server running the Unbound and BIND service and open Unbound’s main configuration file:
   vi /etc/unbound/unbound.conf
2. First put the following line somewhere in the server: clause:
   local-zone: "168.192.in-addr.arpa." nodefault
3. Next, we will have to allow Unbound to connect to localhost which is disabled by default, search for the line that reads: # do-not-query-localhost: yes, then activate and set it to no:
   do-not-query-localhost: no
4. Next, since our BIND server is not configured using DNSSEC, we need to tell Unbound to use it anyway (Unbound by default refuses to connect to DNS servers not using DNSSEC). Search for the line that starts with # domain-insecure: "example.com", then activate it and change it so it reads as follows:
   domain-insecure: "centos7.home."
domain-insecure: "168.192.in-addr.arpa."
5. Next, we need to tell Unbound to forward all the requests for our internal domain centos7.home. to the locally running BIND server (on port 8053). Append the following at the file’s end:
   stub-zone:
         name: "centos7.home."
         stub-addr: 127.0.0.1@8053
6. Also, we need to tell Unbound to do the same for any reverse lookup to our internal domain using BIND:
   stub-zone:
        name: "1.168.192.in-addr.arpa."
        stub-addr: 127.0.0.1@8053
7. Save and close the file, and then restart the Unbound service:
   unbound-checkconf && systemctl restart unbound

How Does It Work?

Congratulations! You now have a full authoritative and very secure DNS server solution using an integrated approach combining all the good parts from Unbound and BIND. In this process, we have shown you how to configure the Unbound service using stub-zones to connect to an internally running BIND service for both forward and reverse requests. A stub-zone is a special Unbound feature to configure authoritative data to be used that cannot be accessed using the public Internet servers. Its name field defines the zone name for which Unbound will forward any incoming DNS requests and the stub-addr field configures the location (IP address and a port) of the DNS server to access; in our example, this is the locally running BIND server on port 8053. For Unbound to be able to connect to the localhost, we first had to allow this using the do-not-query-localhost: no directive, had to mark our forward and reverse domain as being insecure, and also had to define a new local-zone, which is necessary that Unbound knows that clients can send queries to a stub-zone authoritative server.

There's more…

In order to test our new Unbound/BIND DNS cluster, make one public and one internal hostname DNS request to the Unbound service from another computer in the same network (you can also run similar tests locally on the DNS server itself). If our Unbound/BIND DNS cluster has the IP 192.168.1.7, you should be able to get correct answers for both dig @192.168.1.7 www.packtpub.com and dig @192.168.1.7 client1.centos7.home from any other computer in your network.

If you have to troubleshoot service problems or need to monitor the DNS queries of your new Unbound/BIND DNS server, you can configure logging parameters. For BIND, in the main configuration file named.conf you can set the verbosity of the logging output (or log level). This parameter is called severity and can be found within the logging directive. It is already set to dynamic; which gives the highest amount of logging messages possible. You can then read your current log using tail -f /var/named/data/named.run. For Unbound, you can set the level of verbosity in its main configuration file unbound.conf using the verbosity directive which is set to the lowest level of 1 but can be increased to 5. To learn more about the different levels, use man unbound.conf. Use journald to read the Unbound logging information using the command journalctl -f -u unbound.service (press Ctrl+c key to exit the command).

We can not only log the system and service information but can also enable query logs. For Unbound just use a verbosity of 3 or above to record query information. For BIND, in order to activate the query log (query output will go to the log file named.run), use the command rndc querylog on (to turn it off, use rndc querylog off). Remember to turn off any excessive logging information, such as the query log, when configuring your DNS server on a productive system as it can decrease your service’s performance. You can also install other third-party tools such as dnstop (from the EPEL repository) to monitor your DNS activity.