diff options
Diffstat (limited to 'dns.adoci')
| -rw-r--r-- | dns.adoci | 161 |
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. - -====== - |