use *.asciidoc(i) extension instead of *.adoc(i)

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

1 files changed, 0 insertions, 161 deletions

diff --git a/dns.adoci b/dns.adoci
deleted file mode 100644
index f426e19..0000000
--- a/dns.adoci
+++ /dev/null
@@ -1,161 +0,0 @@
-== 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.
-
-======
-