Put in remaining pages and wiki contents.
[ikiwiki.git] / docs / handbook / handbook-network-dns.mdwn
1 \r
2 \r
3 ## 19.11 DNS \r
4 \r
5 ***Contributed by Chern Lee. ***\r
6 \r
7 ### 19.11.1 Overview \r
8 \r
9 DragonFly utilizes, by default, a version of BIND (Berkeley Internet Name Domain), which is the most common implementation of the DNS protocol. DNS is the protocol through which names are mapped to IP addresses, and vice versa. For example, a query for `www.dragonflybsd.org` will receive a reply with the IP address of The DragonFly Project's web server, whereas, a query for `ftp.dragonflybsd.org` will return the IP address of the corresponding FTP machine. Likewise, the opposite can happen. A query for an IP address can resolve its hostname. It is not necessary to run a name server to perform DNS lookups on a system.\r
10 \r
11 DNS is coordinated across the Internet through a somewhat complex system of authoritative root name servers, and other smaller-scale name servers who host and cache individual domain information.\r
12 \r
13 This document refers to BIND 9.x.\r
14 \r
15 RFC1034 and RFC1035 dictate the DNS protocol.\r
16 \r
17 Currently, BIND is maintained by the [Internet Software Consortium (www.isc.org)](http://www.isc.org/).\r
18 \r
19 ### 19.11.2 Terminology \r
20 \r
21 To understand this document, some terms related to DNS must be understood.\r
22 \r
23 [[!table  data="""
24 | Term | Definition 
25  Forward DNS | Mapping of hostnames to IP addresses 
26  Origin | Refers to the domain covered in a particular zone file 
27   **named** , BIND, name server | Common names for the BIND name server package within DragonFly 
28  Resolver | A system process through which a machine queries a name server for zone information 
29  Reverse DNS | The opposite of forward DNS; mapping of IP addresses to hostnames 
30  Root zone | The beginning of the Internet zone hierarchy. All zones fall under the root zone, similar to how all files in a file system fall under the root directory. 
31  Zone | An individual domain, subdomain, or portion of the DNS administered by the same authority |\r
32 """]]\r
33 Examples of zones:\r
34 \r
35
36 * `.` is the root zone\r
37
38 * `org.` is a zone under the root zone\r
39
40 * `example.org` is a zone under the `org.` zone\r
41
42 * `foo.example.org.` is a subdomain, a zone under the `example.org.` zone\r
43
44 * `1.2.3.in-addr.arpa` is a zone referencing all IP addresses which fall under the 3.2.1.* IP space.\r
45 \r
46 As one can see, the more specific part of a hostname appears to its left. For example, `example.org.` is more specific than `org.`, as `org.` is more specific than the root zone. The layout of each part of a hostname is much like a filesystem: the `/dev` directory falls within the root, and so on.\r
47 \r
48 ### 19.11.3 Reasons to Run a Name Server \r
49 \r
50 Name servers usually come in two forms: an authoritative name server, and a caching name server.\r
51 \r
52 An authoritative name server is needed when:\r
53 \r
54
55 * one wants to serve DNS information to the world, replying authoritatively to queries.\r
56
57 * a domain, such as `example.org`, is registered and IP addresses need to be assigned to hostnames under it.\r
58
59 * an IP address block requires reverse DNS entries (IP to hostname).\r
60
61 * a backup name server, called a slave, must reply to queries when the primary is down or inaccessible.\r
62 \r
63 A caching name server is needed when:\r
64 \r
65
66 * a local DNS server may cache and respond more quickly than querying an outside name server.\r
67
68 * a reduction in overall network traffic is desired (DNS traffic has been measured to account for 5% or more of total Internet traffic).\r
69 \r
70 When one queries for `www.dragonflybsd.org`, the resolver usually queries the uplink ISP's name server, and retrieves the reply. With a local, caching DNS server, the query only has to be made once to the outside world by the caching DNS server. Every additional query will not have to look to the outside of the local network, since the information is cached locally.\r
71 \r
72 ### 19.11.4 How It Works \r
73 \r
74 In DragonFly, the BIND daemon is called  **named**  for obvious reasons.\r
75 \r
76 [[!table  data="""
77 | File | Description 
78   **named**  | the BIND daemon 
79  `ndc` | name daemon control program 
80  `/etc/namedb` | directory where BIND zone information resides 
81  `/etc/namedb/named.conf` | daemon configuration file |\r
82 """]]\r
83 Zone files are usually contained within the `/etc/namedb` directory, and contain the DNS zone information served by the name server.\r
84 \r
85 ### 19.11.5 Starting BIND \r
86 \r
87 Since BIND is installed by default, configuring it all is relatively simple.\r
88 \r
89 To ensure the named daemon is started at boot, put the following modifications in `/etc/rc.conf`:\r
90 \r
91     \r
92     named_enable="YES"\r
93 \r
94 \r
95 To start the daemon manually (after configuring it)\r
96 \r
97     \r
98     # ndc start\r
99 \r
100 \r
101 ### 19.11.6 Configuration Files \r
102 \r
103 #### 19.11.6.1 Using `make-localhost` \r
104 \r
105 Be sure to:\r
106 \r
107     \r
108     # cd /etc/namedb\r
109     # sh make-localhost\r
110 \r
111 \r
112 to properly create the local reverse DNS zone file in `/etc/namedb/localhost.rev`.\r
113 \r
114 #### 19.11.6.2 `/etc/namedb/named.conf` \r
115 \r
116     \r
117     // $DragonFlyBSD$\r
118     //\r
119     // Refer to the named(8) manual page for details.  If you are ever going\r
120     // to setup a primary server, make sure you've understood the hairy\r
121     // details of how DNS is working.  Even with simple mistakes, you can\r
122     // break connectivity for affected parties, or cause huge amount of\r
123     // useless Internet traffic.\r
124     \r
125     options {\r
126             directory "/etc/namedb";\r
127     \r
128     // In addition to the "forwarders" clause, you can force your name\r
129     // server to never initiate queries of its own, but always ask its\r
130     // forwarders only, by enabling the following line:\r
131     //\r
132     //      forward only;\r
133     \r
134     // If you've got a DNS server around at your upstream provider, enter\r
135     // its IP address here, and enable the line below.  This will make you\r
136     // benefit from its cache, thus reduce overall DNS traffic in the\r
137     Internet.\r
138     /*\r
139             forwarders {\r
140                     127.0.0.1;\r
141             };\r
142     
143 */\r
144 \r
145 \r
146 Just as the comment says, to benefit from an uplink's cache, `forwarders` can be enabled here. Under normal circumstances, a name server will recursively query the Internet looking at certain name servers until it finds the answer it is looking for. Having this enabled will have it query the uplink's name server (or name server provided) first, taking advantage of its cache. If the uplink name server in question is a heavily trafficked, fast name server, enabling this may be worthwhile.\r
147 \r
148  **Warning:** `127.0.0.1` will ***not*** work here. Change this IP address to a name server at your uplink.\r
149 \r
150     \r
151             /*\r
152     
153 * If there is a firewall between you and name servers you want\r
154     
155 * to talk to, you might need to uncomment the query-source\r
156     
157 * directive below.  Previous versions of BIND always asked\r
158     
159 * questions using port 53, but BIND 8.1 uses an unprivileged\r
160     
161 * port by default.\r
162     
163 */\r
164             // query-source address * port 53;\r
165     \r
166             /*\r
167     
168 * If running in a sandbox, you may have to specify a different\r
169     
170 * location for the dumpfile.\r
171     
172 */\r
173             // dump-file "s/named_dump.db";\r
174     };\r
175     \r
176     // Note: the following will be supported in a future release.\r
177     /*\r
178     host { any; } {\r
179             topology {\r
180                     127.0.0.0/8;\r
181             };\r
182     };\r
183     
184 */\r
185     \r
186     // Setting up secondaries is way easier and the rough picture for this\r
187     // is explained below.\r
188     //\r
189     // If you enable a local name server, don't forget to enter 127.0.0.1\r
190     // into your /etc/resolv.conf so this server will be queried first.\r
191     // Also, make sure to enable it in /etc/rc.conf.\r
192     \r
193     zone "." {\r
194             type hint;\r
195             file "named.root";\r
196     };\r
197     \r
198     zone "0.0.127.IN-ADDR.ARPA" {\r
199             type master;\r
200             file "localhost.rev";\r
201     };\r
202     \r
203     zone\r
204     "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" {\r
205             type master;\r
206             file "localhost.rev";\r
207     };\r
208     \r
209     // NB: Do not use the IP addresses below, they are faked, and only\r
210     // serve demonstration/documentation purposes!\r
211     //\r
212     // Example secondary config entries.  It can be convenient to become\r
213     // a secondary at least for the zone where your own domain is in.  Ask\r
214     // your network administrator for the IP address of the responsible\r
215     // primary.\r
216     //\r
217     // Never forget to include the reverse lookup (IN-ADDR.ARPA) zone!\r
218     // (This is the first bytes of the respective IP address, in reverse\r
219     // order, with ".IN-ADDR.ARPA" appended.)\r
220     //\r
221     // Before starting to setup a primary zone, better make sure you fully\r
222     // understand how DNS and BIND works, however.  There are sometimes\r
223     // unobvious pitfalls.  Setting up a secondary is comparably simpler.\r
224     //\r
225     // NB: Don't blindly enable the examples below. :-)  Use actual names\r
226     // and addresses instead.\r
227     //\r
228     // NOTE!!! DragonFly runs bind in a sandbox (see named_flags in rc.conf).\r
229     // The directory containing the secondary zones must be write accessible\r
230     // to bind.  The following sequence is suggested:\r
231     //\r
232     //      mkdir /etc/namedb/s\r
233     //      chown bind:bind /etc/namedb/s\r
234     //      chmod 750 /etc/namedb/s\r
235 \r
236 \r
237 For more information on running BIND in a sandbox, see [network-dns.html#NETWORK-NAMED-SANDBOX Running named in a sandbox].\r
238 \r
239     \r
240     /*\r
241     zone "example.com" {\r
242             type slave;\r
243             file "s/example.com.bak";\r
244             masters {\r
245                     192.168.1.1;\r
246             };\r
247     };\r
248     \r
249     zone "0.168.192.in-addr.arpa" {\r
250             type slave;\r
251             file "s/0.168.192.in-addr.arpa.bak";\r
252             masters {\r
253                     192.168.1.1;\r
254             };\r
255     };\r
256     
257 */\r
258 \r
259 \r
260 In `named.conf`, these are examples of slave entries for a forward and reverse zone.\r
261 \r
262 For each new zone served, a new zone entry must be added to `named.conf`\r
263 \r
264 For example, the simplest zone entry for `example.org` can look like:\r
265 \r
266     \r
267     zone "example.org" {\r
268         type master;\r
269         file "example.org";\r
270     };\r
271 \r
272 \r
273 The zone is a master, as indicated by the `type` statement, holding its zone information in `/etc/namedb/example.org` indicated by the `file` statement.\r
274 \r
275     \r
276     zone "example.org" {\r
277         type slave;\r
278         file "example.org";\r
279     };\r
280 \r
281 \r
282 In the slave case, the zone information is transferred from the master name server for the particular zone, and saved in the file specified. If and when the master server dies or is unreachable, the slave name server will have the transferred zone information and will be able to serve it.\r
283 \r
284 #### 19.11.6.3 Zone Files \r
285 \r
286 An example master zone file for `example.org` (existing within `/etc/namedb/example.org`) is as follows:\r
287 \r
288     \r
289     $TTL 3600\r
290     \r
291     example.org. IN SOA ns1.example.org. admin.example.org. (\r
292                             5               ; Serial\r
293                             10800           ; Refresh\r
294                             3600            ; Retry\r
295                             604800          ; Expire\r
296                             86400 )         ; Minimum TTL\r
297     \r
298     ; DNS Servers\r
299     @       IN NS           ns1.example.org.\r
300     @       IN NS           ns2.example.org.\r
301     \r
302     ; Machine Names\r
303     localhost       IN A    127.0.0.1\r
304     ns1             IN A    3.2.1.2\r
305     ns2             IN A    3.2.1.3\r
306     mail            IN A    3.2.1.10\r
307     @               IN A    3.2.1.30\r
308     \r
309     ; Aliases\r
310     www             IN CNAME        @\r
311     \r
312     ; MX Record\r
313     @               IN MX   10      mail.example.org.\r
314 \r
315 \r
316 Note that every hostname ending in a ***.*** is an exact hostname, whereas everything without a trailing ***.*** is referenced to the origin. For example, `www` is translated into `www + origin`. In our fictitious zone file, our origin is `example.org.`, so `www` would translate to `www.example.org.`\r
317 \r
318 The format of a zone file follows:\r
319 \r
320     \r
321     recordname      IN recordtype   value\r
322 \r
323 \r
324 The most commonly used DNS records:\r
325 \r
326 SOA:: start of zone authorityNS:: an authoritative name serverA:: A host addressCNAME:: the canonical name for an aliasMX:: mail exchangerPTR:: a domain name pointer (used in reverse DNS)\r
327 \r
328     \r
329     example.org. IN SOA ns1.example.org. admin.example.org. (\r
330                             5               ; Serial\r
331                             10800           ; Refresh after 3 hours\r
332                             3600            ; Retry after 1 hour\r
333                             604800          ; Expire after 1 week\r
334                             86400 )         ; Minimum TTL of 1 day\r
335 \r
336 \r
337 `example.org.`:: the domain name, also the origin for this zone file.`ns1.example.org.`:: the primary/authoritative name server for this zone`admin.example.org.`:: the responsible person for this zone, email address with @ replaced. (`<[mailto:admin@example.org admin@example.org]>` becomes `admin.example.org`)`5`:: the serial number of the file. this must be incremented each time the zone file is modified. Nowadays, many admins prefer a `yyyymmddrr` format for the serial number. 2001041002 would mean last modified 04/10/2001, the latter 02 being the second time the zone file has been modified this day. The serial number is important as it alerts slave name servers for a zone when it is updated.\r
338 \r
339     \r
340     @       IN NS           ns1.example.org.\r
341 \r
342 \r
343 This is an `NS` entry. Every name server that is going to reply authoritatively for the zone must have one of these entries. The `@` as seen here could have been `example.org.` The `@` translates to the origin.\r
344 \r
345     \r
346     localhost       IN A    127.0.0.1\r
347     ns1             IN A    3.2.1.2\r
348     ns2             IN A    3.2.1.3\r
349     mail            IN A    3.2.1.10\r
350     @               IN A    3.2.1.30\r
351 \r
352 \r
353 The A record indicates machine names. As seen above, `ns1.example.org` would resolve to `3.2.1.2`. Again, the origin symbol, `@`, is used here, thus meaning `example.org` would resolve to `3.2.1.30`.\r
354 \r
355     \r
356     www             IN CNAME        @\r
357 \r
358 \r
359 The canonical name record is usually used for giving aliases to a machine. In the example, `www` is aliased to the machine addressed to the origin, or `example.org` (`3.2.1.30`). `CNAME`s can be used to provide alias hostnames, or round robin one hostname among multiple machines.\r
360 \r
361     \r
362     @               IN MX   10      mail.example.org.\r
363 \r
364 \r
365 The `MX` record indicates which mail servers are responsible for handling incoming mail for the zone. `mail.example.org` is the hostname of the mail server, and 10 being the priority of that mail server.\r
366 \r
367 One can have several mail servers, with priorities of 3, 2, 1. A mail server attempting to deliver to `example.org` would first try the highest priority MX, then the second highest, etc, until the mail can be properly delivered.\r
368 \r
369 For in-addr.arpa zone files (reverse DNS), the same format is used, except with `PTR` entries instead of `A` or `CNAME`.\r
370 \r
371     \r
372     $TTL 3600\r
373     \r
374     1.2.3.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. (\r
375                             5               ; Serial\r
376                             10800           ; Refresh\r
377                             3600            ; Retry\r
378                             604800          ; Expire\r
379                             3600 )          ; Minimum\r
380     \r
381     @       IN NS   ns1.example.org.\r
382     @       IN NS   ns2.example.org.\r
383     \r
384     2       IN PTR  ns1.example.org.\r
385     3       IN PTR  ns2.example.org.\r
386     10      IN PTR  mail.example.org.\r
387     30      IN PTR  example.org.\r
388 \r
389 \r
390 This file gives the proper IP address to hostname mappings of our above fictitious domain.\r
391 \r
392 ### 19.11.7 Caching Name Server \r
393 \r
394 A caching name server is a name server that is not authoritative for any zones. It simply asks queries of its own, and remembers them for later use. To set one up, just configure the name server as usual, omitting any inclusions of zones.\r
395 \r
396 ### 19.11.8 Running  **named**  in a Sandbox \r
397 \r
398 For added security you may want to run [named(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#named&section8) as an unprivileged user, and configure it to [chroot(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=chroot&section=8) into a sandbox directory. This makes everything outside of the sandbox inaccessible to the  **named**  daemon. Should  **named**  be compromised, this will help to reduce the damage that can be caused. By default, DragonFly has a user and a group called `bind`, intended for this use.\r
399 \r
400  **Note:** Various people would recommend that instead of configuring  **named**  to `chroot`, you should run  **named**  inside a [jail(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#jail&section8). This section does not attempt to cover this situation.\r
401 \r
402 Since  **named**  will not be able to access anything outside of the sandbox (such as shared libraries, log sockets, and so on), there are a number of steps that need to be followed in order to allow  **named**  to function correctly. In the following checklist, it is assumed that the path to the sandbox is `/etc/namedb` and that you have made no prior modifications to the contents of this directory. Perform the following steps as `root`.\r
403 \r
404
405 * Create all directories that  **named**  expects to see:\r
406       \r
407       # cd /etc/namedb\r
408       # mkdir -p bin dev etc var/tmp var/run master slave\r
409       # chown bind:bind slave var/*./imagelib/callouts/1.png\r
410   \r
411   [network-dns.html#CHOWN-SLAVE ./imagelib/callouts/1.png]::  **named**  only needs write access to these directories, so that is all we give it.\r
412
413 * Rearrange and create basic zone and configuration files:\r
414       \r
415       # cp /etc/localtime etc./imagelib/callouts/1.png\r
416       # mv named.conf etc && ln -sf etc/named.conf\r
417       # mv named.root master\r
418       # sh make-localhost && mv localhost.rev localhost-v6.rev master\r
419       # cat > master/named.localhost\r
420       $ORIGIN localhost.\r
421       $TTL 6h\r
422       @ IN      SOA     localhost. postmaster.localhost. (\r
423                         1       ; serial\r
424                         3600    ; refresh\r
425                         1800    ; retry\r
426                         604800  ; expiration\r
427                         3600 )  ; minimum\r
428         IN      NS      localhost.\r
429         IN      A               127.0.0.1\r
430       ^D\r
431   \r
432   [network-dns.html#LOCALTIME ./imagelib/callouts/1.png]:: This allows  **named**  to log the correct time to [syslogd(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#syslogd&section8)\r
433
434 * Use [cp(1)](http://leaf.dragonflybsd.org/cgi/web-man?command#cp&section1) to copy `named-xfer` in `/usr/libexec` into your sandbox.\r
435
436 * Make a `dev/null` that  **named**  can see and write to:\r
437       \r
438       # cd /etc/namedb/dev && mknod null c 2 2\r
439       # chmod 666 null\r
440   \r
441
442 * Symlink ` /var/run/ndc` to `/etc/namedb/var/run/ndc`:\r
443       \r
444       # ln -sf /etc/namedb/var/run/ndc /var/run/ndc\r
445   \r
446    **Note:** This simply avoids having to specify the `-c` option to [ndc(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#ndc&section8) every time you run it. Since the contents of /var/run are deleted on boot, if this is something that you find useful you may wish to add this command to root's crontab, making use of the `@reboot` option. See [crontab(5)](http://leaf.dragonflybsd.org/cgi/web-man?command=crontab&section=5) for more information regarding this.\r
447
448 * Configure [syslogd(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#syslogd&section8) to create an extra `log` socket that  **named**  can write to. To do this, add `-l /etc/namedb/dev/log` to the `syslogd_flags` variable in `/etc/rc.conf`.\r
449
450 * Arrange to have  **named**  start and `chroot` itself to the sandbox by adding the following to `/etc/rc.conf`:\r
451       \r
452       named_enable="YES"\r
453       named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf"\r
454   \r
455    **Note:** Note that the configuration file `***/etc/named.conf***` is denoted by a full pathname ***relative to the sandbox***, i.e. in the line above, the file referred to is actually `/etc/namedb/etc/named.conf`.\r
456 \r
457 The next step is to edit `/etc/namedb/etc/named.conf` so that  **named**  knows which zones to load and where to find them on the disk. There follows a commented example (anything not specifically commented here is no different from the setup for a DNS server not running in a sandbox):\r
458 \r
459     \r
460     options {\r
461             directory "/";./imagelib/callouts/1.png\r
462             named-xfer "/bin/named-xfer";./imagelib/callouts/2.png\r
463             version "";         // Don't reveal BIND version\r
464             query-source address * port 53;\r
465     };\r
466     // ndc control socket\r
467     controls {\r
468             unix "/var/run/ndc" perm 0600 owner 0 group 0;\r
469     };\r
470     // Zones follow:\r
471     zone "localhost" IN {\r
472             type master;\r
473             file "master/named.localhost";./imagelib/callouts/3.png\r
474             allow-transfer { localhost; };\r
475             notify no;\r
476     };\r
477     zone "0.0.127.in-addr.arpa" IN {\r
478             type master;\r
479             file "master/localhost.rev";\r
480             allow-transfer { localhost; };\r
481             notify no;\r
482     };\r
483     zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" {\r
484         type master;\r
485         file "master/localhost-v6.rev";\r
486         allow-transfer { localhost; };\r
487         notify no;\r
488     };\r
489     zone "." IN {\r
490             type hint;\r
491             file "master/named.root";\r
492     };\r
493     zone "private.example.net" in {\r
494             type master;\r
495             file "master/private.example.net.db";\r
496         allow-transfer { 192.168.10.0/24; };\r
497     };\r
498     zone "10.168.192.in-addr.arpa" in {\r
499             type slave;\r
500             masters { 192.168.10.2; };\r
501             file "slave/192.168.10.db";./imagelib/callouts/4.png\r
502     };\r
503 \r
504 \r
505 [network-dns.html#DIRECTORY ./imagelib/callouts/1.png]:: The `directory` statement is specified as `/`, since all files that  **named**  needs are within this directory (recall that this is equivalent to a ***normal*** user's `/etc/namedb`.[network-dns.html#NAMED-XFER ./imagelib/callouts/2.png]:: Specifies the full path to the `named-xfer` binary (from  **named** 's frame of reference). This is necessary since  **named**  is compiled to look for `named-xfer` in `/usr/libexec` by default.[network-dns.html#MASTER ./imagelib/callouts/3.png]:: Specifies the filename (relative to the `directory` statement above) where  **named**  can find the zonefile for this zone.[network-dns.html#SLAVE ./imagelib/callouts/4.png]:: Specifies the filename (relative to the `directory` statement above) where  **named**  should write a copy of the zonefile for this zone after successfully transferring it from the master server. This is why we needed to change the ownership of the directory `slave` to `bind` in the setup stages above.\r
506 \r
507 After completing the steps above, either reboot your server or restart [syslogd(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#syslogd&section8) and start [named(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=named&section=8), making sure to use the new options specified in `syslogd_flags` and `named_flags`. You should now be running a sandboxed copy of  **named** !\r
508 \r
509 ### 19.11.9 Security \r
510 \r
511 Although BIND is the most common implementation of DNS, there is always the issue of security. Possible and exploitable security holes are sometimes found.\r
512 \r
513 It is a good idea to subscribe to [CERT](http://www.cert.org/) and [../handbook/eresources.html#ERESOURCES-MAIL freebsd-security-notifications] to stay up to date with the current Internet and FreeBSD security issues.\r
514 \r
515  **Tip:** If a problem arises, keeping sources up to date and having a fresh build of named would not hurt.\r
516 \r
517 ### 19.11.10 Further Reading \r
518 \r
519 BIND/named manual pages: [ndc(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#ndc&section8) [named(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=named&section=8) [named.conf(5)](http://leaf.dragonflybsd.org/cgi/web-man?command=named.conf&section=5)\r
520 \r
521
522 * [Official ISC Bind Page](http://www.isc.org/products/BIND/)\r
523
524 * [BIND FAQ](http://www.nominum.com/getOpenSourceResource.php?id=6)\r
525
526 * [O'Reilly DNS and BIND 4th Edition](http://www.oreilly.com/catalog/dns4/)\r
527
528 * [RFC1034 - Domain Names - Concepts and Facilities](ftp://ftp.isi.edu/in-notes/rfc1034.txt)\r
529
530 * [RFC1035 - Domain Names - Implementation and Specification](ftp://ftp.isi.edu/in-notes/rfc1035.txt)\r
531 \r
532 \r
533 \r
534 CategoryHandbook\r
535 CategoryHandbook-advancednetworking\r
536 \r
537 [http%3A%2F%2Ffloopityjoop.com%2FLast+Name+Meanings.html Last Name Meanings]\r