diff options
| -rw-r--r-- | dns.adoci | 161 | ||||
| -rw-r--r-- | practicals.adoc | 1 |
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[] |