added content for the DNS practical

Signed-off-by: Olivier Gayot <duskcoder@gmail.com>

2 files changed, 162 insertions, 0 deletions

diff --git a/dns.adoci b/dns.adoci
new file mode 100644
index 0000000..f426e19
--- /dev/null
+++ b/dns.adoci
@@ -0,0 +1,161 @@
+== DNS Practical, Week 8 ==
+
+The purpose of this practical is to install and setup a BIND DNS server on our
+virtual machine.
+
+At the end of the practical, we should be able to use our virtual machine as a
+nameserver. Moreover, we should be able to use our new virtual domain.
+
+=== Problem 1: Setting up an accessible forwarder ===
+
+Whenever our DNS server cannot resolve a domain name, it will query the
+forwarders specified in its configuration file. Setting Google Public DNS as a
+forwarder is often a good idea. Thus, here is what we put in the 'forwarders'
+section of 'named.conf.options'.
+
+    forwarders {
+        8.8.8.8;
+        8.8.4.4;
+    };
+
+After restarting BIND and trying to resolve 'kent.ac.uk' using 'nslookup' from
+the virtual machine, we obtain the following error after some delay:
+
+    $ nslookup isc.org localhost
+    > ;; connection timed out; no servers could be reached
+
+==== Resolution ====
+
+To diagnose such errors, we often use the tool 'traceroute'. After installing
+it with our package manager, we run it this way.
+
+    $ traceroute -n 8.8.8.8 -m 6
+    > traceroute to 8.8.8.8 (8.8.8.8), 6 hops max, 60 byte packets
+    >  1  129.12.44.1  1.975 ms  2.291 ms  2.433 ms
+    >  2  129.12.254.133  0.488 ms  0.488 ms  0.532 ms
+    >  3  * * *
+    >  4  * * *
+    >  5  * * *
+    >  6  * * *
+
+This output confirms that we are unable to communicate with Google Public DNS
+servers. Instead, we will use any DNS server of the university that we can
+reach:
+
+    $ traceroute -n 129.12.4.56 -m 6
+    > traceroute to 129.12.4.56 (129.12.4.56), 6 hops max, 60 byte packets
+    >  1  129.12.44.1  1.214 ms  1.459 ms  1.829 ms
+    >  2  129.12.4.56  0.352 ms  0.343 ms  0.273 ms
+
+Since this server '129.12.4.56' is accessible, we use it instead inside our
+'forwarders' section and restart BIND. Now, our 'nslookup' command seems to
+work fine.
+
+    $ nslookup isc.org localhost
+    > Server:     localhost
+    > Address:    127.0.0.1#53
+    >
+    > Non-authoritative answer:
+    > Name:   isc.org
+    > Address: 149.20.64.69
+
+=== Problem 2: Setting our default name server ===
+
+Although it is possible to update our '/etc/resolv.conf' directly, it is
+advised not to do so because it is very likely to be overwritten.
+
+==== Resolution ====
+
+Instead of messing up with '/etc/resolv.conf' directly, we will use the tool
+'resolvconf' which is a safe way to achieve what we want to do.
+
+First, delete the existing configuration:
+
+    $ sudo resolvconf -d eth0.inet
+
+And then append our new configuration:
+
+    $ cat | sudo resolvconf -a custom
+    nameserver 127.0.0.1;
+
+We can check that everything worked properly:
+
+    $ cat /etc/resolv.conf
+    > # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
+    > #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
+    > nameserver 127.0.0.1;
+
+Now our DNS queries are all using our local DNS server:
+
+    $ nslookup isc.org
+    > Server:     127.0.0.1
+    > Address:    127.0.0.1#53
+    >
+    > Non-authoritative answer:
+    > Name:   isc.org
+    > Address: 149.20.64.69
+
+=== Problem 3: Using our name server from another machine ===
+
+From another machine connected to the university network, we try to use our new
+name server.  Unfortunately, we get the same error as explained in the first
+problem.
+
+    $ nslookup isc.org csvm2C4E.kent.ac.uk
+    > ;; connection timed out; no servers could be reached
+
+Using 'traceroute' again, we see that our machines are actually unable to
+communicate this way. Although it is possible to use 'ssh' from our own machine
+to the virtual machine.
+
+==== Resolution ====
+
+The problem is quite nasty: a machine connected to the university network
+behind the VPN cannot be accessed from the inside. Nevertheless, SSH still
+works because it uses the TCP protocol (which is connection oriented). Since
+DNS queries use the UDP protocol, both machines must be able to connect to each
+other.
+
+Thus, to test our name server, we will connect to the machine 'raptor' from our
+own machine using SSH.
+
+Then, from 'raptor', we can test our name server (only revelant excerpts of the
+output are shown below).
+
+.trying to resolve 'google.com'
+======
+
+    $ nslookup google.com csvm2c4e.kent.ac.uk
+    > Name:   google.com
+    > Address: 216.58.208.46
+
+======
+
+.trying to resolve 'foobarbaz.ac.uk' (our virtual domain)
+======
+
+    $ nslookup foobarbaz.ac.uk csvm2c4e.kent.ac.uk
+    > Name:   foobarbaz.ac.uk
+    > Address: 129.12.44.78
+
+======
+
+.trying to resolve 'www.foobarbaz.ac.uk' (one of our canonical names)
+======
+
+    $ nslookup www.foobarbaz.ac.uk csvm2c4e.kent.ac.uk
+    > www.foobarbaz.ac.uk canonical name = foobarbaz.ac.uk.
+    > Name:   foobarbaz.ac.uk
+    > Address: 129.12.44.78
+
+======
+
+.trying to resolve '129.12.44.78'
+======
+
+    $ nslookup 129.12.44.78 csvm2c4e.kent.ac.uk
+    > 78.44.12.129.in-addr.arpa name = 44.12.129.in-addr.arpa.
+    > 78.44.12.129.in-addr.arpa   name = ns.foobarbaz.ac.uk.
+
+======
+
diff --git a/practicals.adoc b/practicals.adoc
index 119ee08..b92e289 100644
--- a/practicals.adoc
+++ b/practicals.adoc
@@ -2,3 +2,4 @@ include::cover.adoci[]
 include::apache.adoci[]
 include::ldap1.adoci[]
 include::ldap2.adoci[]
+include::dns.adoci[]