1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
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.
======
|
