Agenda: dns-bind-caching-setup.txt

File dns-bind-caching-setup.txt, 4.8 KB (added by admin, 6 years ago)
Line 
1Building a DNS cache with BIND
2------------------------------
3
41. Check the version of BIND which is installed
5-----------------------------------------------
6
7    $ named -v
8    BIND 9.9.2-P1
9
10
112. Configure your RESOLV host to accept queries from neighbors
12--------------------------------------------------------------
13
14Log in to your RESOLV host if you haven't already done so
15(resolv.grpX.ws.nsrc.org).
16
17Edit the file /etc/namedb/named.conf
18
19$ sudo vi /etc/namedb/named.conf
20
21If you prefer another editor (ee or jed, for example), use that instead of vi
22
23If it is there, find the line:
24
25        listen-on       { 127.0.0.1; };
26
27... and REMOVE it.
28
29Replace it with the following line:
30
31        allow-recursion { 127.0.0.1; 10.10.0.0/16; };
32
33Double check to see that there aren't any zones configured in your
34DNS. For instance, if you see a line like follows:
35
36        zone "10.in-addr.arpa"     { type master; file "/etc/namedb/master/empty.db"; };
37
38... remove it, and save the file.
39
40
41NOTE: Be careful about the semicolons ';' and braces { } - BIND
42will complain if they are not placed correctly
43
44By removing the line "listen-on ..." and adding the line
45"allow-recursion", we are telling BIND:
46
47- please listen to the network for queries, not only on
48  the local interface "127.0.0.1";
49
50- please allow clients in the 10.10.0.0/16 to send queries
51  to me, as well as myself;
52
533. Restart the cache and check it is running
54--------------------------------------------
55
56If you haven't done so earlier, edit `/etc/rc.conf` and add two lines saying:
57
58        named_chrootdir=""
59        named_enable="YES"
60
61NOTE: We would normally not turn off chroot, which is a security
62      mechanism, but we need to do this here in the lab, because of
63      restrictions from the virtualization environment. In a production
64      environment, we wouldn't do this.
65
66Then run these commands:
67
68    $ sudo service named stop
69    $ sudo service named start
70    # ps auxwww | grep named
71    # tail /var/log/messages
72
73Check for successful startup with no error messages (you can ignore errors
74about missing `master/localhost.rev` and `master/localhost-v6.rev`, as well
75as messages regarding managed-keys-zone)
76
77
784. Reconfigure your resolver to use your own cache only
79-------------------------------------------------------
80
81You will do this on all your hosts (AUTH and RESOLV) - you will need to ssh
82to each machine to make the following changes.
83
84If you haven't done so earlier, edit `/etc/resolv.conf` as follows
85(remember to use sudo !)
86
87Remove any existing 'nameserver' lines, or comment them out by inserting '#'
88at the front. 127.0.0.1 is the loopback address; that is, an IP address
89which means 'send the packet to myself', and we'll use it as our nameserver:
90
91    search ws.nsrc.org
92    nameserver 10.10.X.3
93
94... where X is the number of your group, i.e.: group 7, replace X with 7, etc.
95
96Now save and exit.
97
985. Test resolution
99------------------
100
101Issue a query, for instance:
102
103        $ dig google.com NS
104        $ dig noc.ws.nsrc.org A
105
106For each query:
107
1081. Is the server responding ?
1092. How do you know that you are talking to your OWN server ?
1103. What do you notice ?
111
112If your neighbour has got their cache working, then try sending some queries
113to their cache:
114
115    $ dig @10.10.X.1 somedomain.name
116
117... where XXX is the IP of the machine in the class you want to send the
118query to, and "somedomain.name" is the query you would like to perform.
119
120Try and make some of the same queries you did before.  Do the nameservers
121of the other machines answer you ?
122
123Are you getting answers ? What about for ws.nsrc.org ?
124
125Why ?
126
127Help your neighbours to get their cache working if required.
128
1296. Make sure you can resolve hostnames in the class
130---------------------------------------------------
131
132Ping other PCs in the room, where X is 1-32:
133
134    $ ping auth1.grpX.ws.nsrc.org
135    $ ping resolv.grpX.ws.nsrc.org
136    $ ping auth2.grpX.ws.nsrc.org
137
138
1397. Watch the cache in operation
140-------------------------------
141
142You can take a snapshot of the cache contents like this:
143
144    $ sudo ln -s /var/named/var/dump /var/dump
145    $ sudo /usr/sbin/rndc dumpdb
146    $ sudo less /var/named/var/dump/named_dump.db
147
148(Don't do this on a busy cache - you will generate a huge dump file!)
149
150You can watch the cache making queries to the outside world using
151`tcpdump` in a different window (log in again via SSH):
152
153    # tcpdump -n -s1500 -i eth0 udp port 53
154
155Note that your ethernet interface may not necessarily be named `eth0`.
156
157To find out the name if your ethernet interface - e.g. `em0` or `bge0` - run
158"ifconfig"
159
160While tcpdump is running, in the first window flush your cache (so it forgets
161all existing data) and then issue some queries.
162
163    # rndc flush
164    # dig noc.ws.nsrc.org.   -- and watch tcpdump output. What do you see?
165
166    # dig noc.ws.nsrc.org.   -- watch tcpdump again. This time?
167
168NOTE: we now have enabled BIND to be recursive!
169
170Remember that it is not a good idea to run recursive and authoritative
171service on the same server.