The Domain Name System (DNS) is a fundamental Internet technology. Network emulators like Cloonix offer a way for researchers and students to experiment with the DNS protocol and with the various open-source implementations of DNS, such as BIND.
In this post, I will install Cloonix from the Github source code repository. I will run the Cloonix DNS demo script to create a simple DNS scenario and then run some experiments with DNS. Along the way, I will demonstrate some of the new Cloonix version 33 features.
Cloonix version 33
In this demonstration, I am using Cloonix version 33. I last used Cloonix when it was at version 29 and version 33 offers some significant changes and improvements. Compared to version 29, the major changes in version 33 are:
- The Cloonix source code is now hosted on Github
- The cloonix-ctrl commands have been renamed to cloonix-cli
- The Cloonix lan object is now much simpler
- Cloonix adds a simple GUI called cloonix_zor for managing Cloonix servers that have been started
- The nat object replaces the cloonix slirp LAN
- New demo scripts have been added. One of which, the DNS demo script, we will use in this demonstration
Using Cloonix version 33
If you are not already familiar with using Cloonix, please see my previous posts about using Cloonix. Commands may be slightly different in my older posts but they should still provide you with the information you need to use Cloonix version 33 commands and the Cloonix GUI. Also, please refer to the Cloonix documentation.
Install Cloonix version 33
The Cloonix source code is now hosted on Github. You will need to install git on your system if it is not already installed. To Install Cloonix 33, run the following commands:
cd ~
git clone https://github.com/clownix/cloonix.git
cd cloonix
sudo ./install_depends build
./doitall
New KVM virtual machine images have been created for Cloonix version 33. We’ll download the Debian Jessie filesystem for our DNS experiments.
cd ~
mkdir cloonix_data/bulk
cd cloonix_data/bulk
wget http://cloonix.fr/bulk_stored/jessie.qcow2.xz
unxz jessie.qcow2.xz
Updating Cloonix
The Cloonix development team is very responsive to bug reports. If you find an issue, they will fix it. To install the fix, you need to pull down the changes and reinstall Cloonix.
To reinstall Cloonix, run the following commands:
cd ~/cloonix
git pull
sudo ./allclean
./doitall
Cloonix demo scripts
The Cloonix development team created demo scripts to set up network emulation scenarios that demonstrate different network functions. Look in the demo folder on the Cloonix web site to find demo scripts.
Demo scripts are shell scripts that run cloonix CLI commands to build complex network topologies and to configure the nodes in the created topologies. Demo scripts are small and easy to share because they are just text files. The scripts will use filesystems stored in the ~/cloonix_data/bulk directory so you must download the necessary filesystems separately before running the demo scripts. You may view demo scripts in a text editor and see which filesystems you need to download to support the script.
You may also edit the scripts to modify their behavior. For example: if you were using these scripts in a classroom lab, you might consider modifying the path to the filesystem in the script to point to filesystems that are stored on a local server so students do not need to download any additional files manually.
DNS and BIND demo script
We will use Cloonix to demonstrate the configuration, operation, and troubleshooting of DNS in an emulated network scenario. The Cloonix DNS demo script will set up seven VMs using the jessie.qcow2 filesystem we downloaded earlier, configure them as either DNS servers or as standard clients and servers, and then use DNS to find the IP address of a remote server and start data flow between a client VM and a server VM in the same domain.
After we set up the demo, we will do some troubleshooting and also show how to add hosts to the network so they can be found via DNS.
The DNS demo script is available on the Cloonix web site. Download and run the script.
wget http://cloonix.net/demo_stored/dns.tar.gz
tar -xvf dns.tar.gz
cd dns
./dns.sh
You must be connected to your local network and have access to the Internet to run this script successfully because it will install software — bind9 and dnsutils — from the Debian Linux repositories onto the VMs it creates. The script copies the jessie.qcow2 filesystem we downloaded earlier to create two new filesystems: dnsutils.qcow2 and bind9.qcow2. Then it installs software on these new filesystems and uses them as the base filesystems for creating the VMs in the demonstration scenario.
When the script completes execution, you should see a Cloonix GUI window with six nodes:
Also after the script completes, it starts pinging from client to server.cloon.net, demonstrating that DNS is working correctly.
Press Ctrl-C to stop the script and the ping commands.
Experiments with DNS
Now let’s experiment to see how DNS is configured in this network.
We expect that the first time we try to access server.cloon.net, a request will be sent to the cloondns name server, which will query the netdns name server, which will query the rootdns name server. After that, the DNS information will be cached in the chachedns server so future requests will query the chachedns server (until the chached record times out in ten seconds).
Double-click on the client VM to open a terminal window. Then run the commands:
client# dig +short
rootdns.
client# dig rootdns +short
20.0.0.1
We see the root server is named rootdns and is at IP address 20.0.0.1. Next, let us find the IP address of the server VM. it is in the cloon.net domain:
client# dig server.cloon.net +short
24.0.0.1
We see that the IP address for server.cloon.net is 24.0.0.1.
Now, let’s view the DNS messages that the client VM exchanges with the name servers to determine the IP address of server.cloon.net. First, we add a sniffer to the Cloonix topology. Right-click on the Cloonix GUI and select snf from the menu.
Then connect the new snf object to the lan3 object so it is monitoring traffic on the link to the cachedns name server. Then, start data capture by double-clicking on the snf object so it turns red. It is now capturing network traffic to a pcap file.
Next, ping from client to server. This will cause the client VM to request the IP address of the server VM from its defined name server, cachedns. Now open Wireshark to view the contents of the sniffer’s pcap file. Right-click on the snf object and select Wireshark from the menu:
We see in the packet capture file that the cachedns server receives a query, then queries rootdns, netdns and cloondns in turn to determine the IP address of server.cloon.net, and sends that record to client so it can ping the correct IP address.
If you want to stop data capture, double-click on the snf object again so it turns green.
Add a new node to the network
Cloonix allows users to add VMs while the network emulation is running. We can add a new VM, configure it as a server named server2, and connect it to the same LAN as the original server named server. Then we can show how a network administrator would set up DNS to allow server2 to be found on the network by using its hostname.
First, we need to set up the Cloonix VM template to use the correct configuration. Right-click on the Cloonix GUI and select kvm_conf from the menu:
In the VM configuration window that appears, name the VM “server2”, uncheck the Append: end number box, change the number of CPUs to 1, the RAM to a number that is appropriate for your system, set the Rootfs to use the dnsutils.qcow2 filesystem and set the number of Ethernet ports to “one”. The configuration window should look the same as below:
Click “OK” on the VM configuration window. Next, add the VM by right-clicking on the Cloonix GUI and selecting kvm from the menu:
A VM named server2 will appear on the GUI.Next, add it to the same LAN as the VM named server by connecting it to the lan4 object. Double-click on lan4 so it turns pink, then click on port 0 on the VM named server2.
The completed network will look like the network below. We see server and server2 connected to cloud via lan4.
Configure server2 so it can connect to the LAN, has a default route, and has the correct hostname. Double-click on server2 in the Cloonix GUI to open a terminal window. In the server2 terminal window, enter the following commands:
server2# ip addr add dev eth0 24.0.0.3/24
server2# ip link set dev eth0 up
server2# route -n add default gw 24.0.0.2
server2# rm /etc/hostname
server2# echo "hostname" > /etc/hostname
server2# hostname server2
server2# echo "nameserver 23.0.0.1" > /etc/resolv.conf
Next add server2 to the cloondns zone file. Normally there should be one file with the DNS config but the Cloonix devs split up the config over multiple files referenced from the main file, which is a best practice for large DNS configuration files. The file with the server names in it is: cloondns.
cloondns# echo "server2 IN A 24.0.0.3" >> /etc/bind/cloondns.db
cloondns# service bind9 restart
client# ping server2.cloon.net
PING server2.cloon.net (24.0.0.3) 56(84) bytes of data.
64 bytes from 24.0.0.3: icmp_seq=1 ttl=63 time=1.37 ms
64 bytes from 24.0.0.3: icmp_seq=2 ttl=63 time=1.93 ms
Now we have a new node and other nodes in the network can reach it at server2.cloon.dns. We demonstrated the steps required when adding a new node to a DNS domain.
DNS configuration files
As you do more experiments with this demonstration you may notice that there are some problems with the DNS configuration that need to be fixed by adding information to DNS configuration files on different nodes in the network.
For example, try to ping from server to client and see what happens. Open a terminal window on server and type the following command:
server# ping -c 1 client.cloon.net
This is an opportunity for you to exercise your knowledge of DNS and BIND configuration files to fill in the necessary information to make it possible to find IP addresses from any node in the cloon.net domain. I provide the necessary configuration information below.
Hint: use the dig command to check if a host name is in the DNS database, or if a name server is unavailable. You may use a zone file generator to create zone file examples you can use.
DNS configuration fixes
As we mentioned above, some configurations are missing in this DNS demo. I will describe how to complete the DNS configuration so that the machines server and client may find each other’s DNS records.
We see that we can ping server.cloon.net from any VM in the network. But what if we try to ping the client virtual machine? For example: what if I want to ping client.cloon.net?
client# ping client.cloon.net
ping: unknown host client.cloon.net
To fix this, add the client VM into the cloondns VM’s BIND config file. On the cloondns VM’s terminal, enter the command. Note that the cloondns name server’s named.conf file points to a set of files that split up the configuration into smaller files, and that the file that contains the list of hosts in the domain is the /etc/bind/cloondns.db file.
cloondns# echo "client IN A 25.0.0.1" >> /etc/bind/cloondns.db
cloondns# service bind9 restart
Now client can ping client.cloon.net — that is, ping itself — through the network. But, what if we ping the client VM from the server VM? We get another error. This time, server cannot find a nameserver from which it may request the IP address of client:
server# ping client.cloon.net
ping: unknown host client.cloon.net
We fix this problem by configuring the nameserver for the server VM, which should be the cachedns VM, which has IP address 23.0.0.1.
Enter the following command on VM server:
server# echo "nameserver 23.0.0.1" > /etc/resolv.conf
Now, we should be able to ping in either direction between client and server.
server# ping client.cloon.dns
PING client.cloon.net (25.0.0.1) 56(84) bytes of data.
64 bytes from 25.0.0.1: icmp_seq=1 ttl=63 time=1.00 ms
--- client.cloon.net ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.001/1.001/1.001/0.000 ms
The Cloonix_zor window
Cloonix version 33 now offers another GUI window called Cloonix Hypervizor that displays and manages Cloonix servers. It shows each cloonix object in a list view. It does not seem so useful right now, but might be helpful if you are managing large emulation scenarios with many nodes and other objects where the normal GUI might become difficult to read. It is also useful for managing multiple Cloonix servers.
Start the Cloonix Hypervizor window by running the commands:
$ cloonix_zor
The Cloonix Hypervizor window appears. It will show the currently-running Cloonix server or servers which, in this case, is nemo.
Expand the nemo server and all the objects under it to see every object currently running and managed by Cloonix:
You may interact with objects by expanding them to show available options and then clicking on an option. For example, you may start an SSH terminal connected to a node or you may kill a node. In our case, we want to kill the nemo server to stop the entire network emulation scenario. Click on the “kill” option under the nemo Cloonix server:
After clicking on “kill” you will be asked to confirm. Click on “Kill” in the dialog box that pops up.
The Cloonix graph GUI disappears and the Cloonix server nemo also disappears from the Cloonix Hypervizor window.
At this point, Cloonix is no longer running. You may stop the Cloonix Hypervisor by closing the window or you may start a new Cloonix server or run a new Cloonix demo script.
If you do not want to use cloonix_zor, then end the demonstration and shut down cloonix by running the following command on your host computer:
$ cloonix_cli nemo kil
Conclusion
We used a Cloonix demo script to build a network emulation scenario that demonstrates the operation and configuration of DNS name servers. We reviewed the changes in Cloonix version 33.
The Cloonix development team tells me they are planning to develop more demo scripts over the next few months. Demo scripts add to the utility of the Cloonix network emulator and are useful as either standalone scripts, or as examples to show users how to build complex demo scripts of their own.