Slave DNS Server Details

Details of the slave DNS server are shown below.  The laptop normally operates on wireless networking, but can also operate on wired network just as well using the solution described in this post.  The wlan0 information is shown here.  If the laptop were plugged into a wired connection it would acquire an IP address on this same home network (192.168.1.x). 

A note about listings.  I have listed the code for the relevant files for configuring the networking environment and DNS on the KVM host (Lenovo W520 laptop).  However, for the KVM host, I have also attached the relevant files to this blog post (see end of post).

OpenvSwitch Details

The interface "sw1" shown above is an OpenvSwitch.  This switch provides the management network which connects the KVM guests to all the other KVM guests on that network, and also connects the KVM guests to the KVM host, providing full ssh connectivity host-guest and guest-host.  Connectivity between the KVM guests and the internet is provided by the iptables rules contained in the script below. 

One might ask, "Why not just attach wlan0 (or eth0) to the OpenvSwitch directly?" 

The answer is that attaching wlan0 or eth0  directly to the OpenvSwitch typically interrupts networking and causes direct overlap between the territory of Network Manager and OpenvSwitch.  Several posts on the internet go so far as to rip out Network Manager entirely so that there is no overalp.

As stated previously, one of the goals of this implementation was to implement all the DNS and DHCP services for the KVM guests without affecting Network Manager (and it's use of dnsmasq-base). Thus, these iptables rules are used to provide internet access to the KVM guests without actually attaching the eth0 or wlan0 interfaces directly to the OpenvSwitch.

These iptables rules are taken from the post here by Jean-Jacques Sarton.  The switch sw1 is defined and built at bootup in a script "/home/gstanden/crt_ovs_sw1.sh" from the following file as shown below.  This script is run from the Upstart job file at /etc/init/my-network-up.conf at boot time to configure the OpenvSwitch and related networking as shown below.  The crt_ovs_sw1.sh script owes much to the reference previously mentioned here by Jean-Jacques Sarton.  The work described by Jean-Jacquest was modified here for OpenvSwitch from the original (linux bridge) code. 

UPDATE 2014-08-25 12:47 PM CDT:  Some testing revealed there were some additional configuration changes and improvements that were needed to handle the case of (1) no internet connected interface available, and (2) the case of connection to corporate VPN.  The new and improved "/home/gstanden/crt_ovs_sw1.sh" file is shown below.  Changes were also made to programmatically set $EXTIF at KVM host boot time instead of using a hard-coded value.

KVM Guest Master DNS Installation

First the DNS was installed in a KVM guest chosen among the patch of KVM guests (all on the same 10.207.39.x network) to be the DNS server.  The "oracle651.vmem.org" server was chosen because it is already in use as the SCST iSCSI Linux SAN, and as such, must be started before all of the other KVM guests on this network to provide the iSCSI LUNs to the other servers (the other KVM guests are all Oracle database servers, which use ASM, and therefore need SCST to present multipathed iSCSI LUNs).  Much of the configuration shown below is based on the guide at ostechnix.

Install bind9 in the KVM guest oracle651.vmem.org as shown below.

Configure Bind Service

Start the bind service as shown below and use set bind to start on boot as shown below.

In this setup, iptables is set to off as shown below, so there is no need to configure iptables for this setup. 

However, if using iptables, be sure to also do the steps in the next section "set iptables rules".Te

Set Iptables Rules

My servers have been set to iptables off, but if iptables is on, use the guide here at ostechnix to configure rules to allow communication to the DNS server.  Those rules are reproduced here for convenience as shown below.  The were not used on this implementation because as mentioned, this setup has iptables off.

Note that a secure implementation would not likely allow simply turning iptables off, and the rules shown below would need to be implemented.

[root@masterdns ~]# vi /etc/sysconfig/iptables
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p udp -m state --state NEW --dport 53 -j ACCEPT
-A INPUT -p tcp -m state --state NEW --dport 53 -j ACCEPT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

Test Master DNS Server

Test the Master DNS service as described here at ostechnix.  The tests are reproduced here for convenience.

Check DNS Configuration File

Check the /etc/named.conf file and the /etc/named.rfc1912.zones files as shown below.  The output shown below is correct expected output.

Check Zone Files

Check the zone files as shown below.  The output shown is the correct expected output.  Note that there is some disagreement in the literature about the syntax for the reverse zone check.  This reverse zone file passes both forms of the reverse zone check syntax with no errors, as shown below.

Here is the results for the forward zone file check, as shown below.

Here is the result for the first published syntax of the reverse zone check as shown below.

Here is the result of the alternate published syntax of the reverse zone check as shown below.

Test DNS Servers

Here are the results of the DNS server tests, dig  by master DNS hostname, as shown below.

Here are the results of the DNS server tests, dig by master DNS IP address, as shown below.

Master DNS Server nslookup

Do an nslookup of the master DNS server as shown below.

KVM Host Slave DNS Installation

Install the required packages on the Ubuntu 14.04 KVM host using apt-get as shown below.  Note that "haveged" package is an entropy generator which is not absolutely necessary but which is good to have and helps speed things up when certificates are being generated.

Configure Slave DNS Server

The configuration on Ubuntu differs from the configuration of bind9 on RHEL 6 / CentOs 6 / OEL 6.  The files are in different directory locations, and named.conf is not edited directly.  Instead, the named.conf.options file is edited, as shown below.  Key sections to be set are in bold.  Some revisions to the original /etc/bind/named.conf.options file where made 2014-08-25 which are explained in the comments to this blog post where I make a comment to my own blog.

Note that more work is needed to make this nameserver comply with security best practices.  This configuration file addresses all lookup and connectivity needs, but has not yet been tweaked for security best practice compliance.

The /etc/bind/named.conf file is shown below for reference only.  This file is not edited directly.  It is left at the defaults.

Verify File /etc/hosts 

The /etc/hosts file should look similar to that shown below.  This is the standard auto-generated /etc/hosts file which is the format it will have after a fresh installation of Ubuntu Destkop 14.04 as shown below.

Edit File /etc/nsswitch.conf 

The /etc/nsswitch.conf file should be edited on the hosts line to use DNS as the first lookup method, and files and other methods as secondary methods, as shown below, line to be edited in bold.  Notice that on the "hosts" line that "dns" is the first entry.  This is correct.  The default is for "files" to be the first entry.  This DNS method is using DNS and not /etc/hosts so "dns" is listed as the first method, as shown below.

Verify File /etc/NetworkManager/NetworkManager.conf

Verify that the file /etc/NetworkManager/NetworkManager.conf uses "dnsmasq" as the dns option.  This is the default setting for Network Manager.  This default setting will be kept unchanged. Here it is necessary only to verify it is stil set to the default, as shown below.

Edit File /etc/network/interfaces

Editing of this file will in turn set necessary attributes of the /etc/resolv.conf file.  The required entries are shown below.  The configuration of this file shown below is  for DHCP addressing of the KVM host, and the "dns-domain" line will add "search vmem.org" to the /etc/resolv.conf file (as shown in the next step).  The changes will take effect when the KVM host is rebooted or networking is restarted.  If a static IP is desired for the KVM host, additional configuration will be necessary in this file.  See additional references for static IP addressing on Ubuntu 14.04 on the web in that case.

UPDATE:  2014-08-25  "dns-nameserver 127.0.0.1" was added to /etc/network/interfaces to handle the case of the KVM host (Lenovo W520 laptop) starting up with NO internet-connected interface available (eth0, wlan0, bnep0) all disconnected.  It was found that under that circumstance /etc/resolv.conf would get set to "nameserver 127.0.1.1" which is the NM-controlled dnsmasq-base DNS server.  This caused lookups of KVM guests on my private network to break.  By setting "dns-nameserver 127.0.0.1" explicitly, resolution was always available for my private network. 

That this resolution succeeds is understood clearly from the output of netstat and also from this post here at Stephane Graber's blog which explains that 127.0.0.1 always resolves to dnsmasq.  However, it appears that is true except when there is a bind9 DNS running, in which case the "named" service of bind9 runs on 127.0.0.1, as shown below from the netstat output.  Therefore, this configuration ensures that lookups for the private network will not fail, and also that internet lookups will be forwarded to 127.0.1.1 (dnsmasq) because in the /etc/bind/named.conf.options recursion is set to yes so it finds dnsmasq and uses it for external resolutions, but preferentially hits named at 127.0.0.1 first to get the resolution for the private network.  The output below helps to show the results from some different configurations that might be possible.

Verify File /etc/resolv.conf

Verify that the /etc/resolv.conf file is configured as shown below.  Note that this file is auto-generated by Network Manager, and will change automatically, for example when logging on to a VPN etc.  But in the default case, this file should have only the nameserver shown, namely 127.0.0.1, and should show, in this case, the vmem.org domain. The file also needs to show the "search vmem.org" line as well.  As mentioned, both of these are set in the /etc/network/interfaces file.

Start bind9 Service

Start the bind9 service as shown below.

Verify Zone File Transfer to Slave DNS

Upon start of the slave DNS server, the zone files should have been transferred to the slave DNS server automatically, as shown below. These files are binary files so it is not possible to "cat" them or otherwise look at them.  The best way forward is to proceed to testing the lookups and DNS server.

Test Slave DNS Server

Check DNS Configuration Files

Check the DNS configuration files as shown below.

Check DNS Zone Files

As mentioned above, the zone files on the Ubuntu slave DNS server are in binary format and cannot be checked directly using methods such as "cat".  They are located as shown below.  Modification times can be checked.

Test DNS Servers

Run dig test on the slave DNS FQDN from slave DNS server as shown below.

Run dig test on the master DNS FQDN from slave DNS server as shown below.

Slave DNS Server Lookup

Test Zone File Propagation

Configure Private Network on NM-dnsmasq