1: **Contents**
2:
3: [[!toc levels=3]]
4:
5: # The Domain Name System
6:
7: Use of the Domain Name System has been discussed in previous chapters, without
8: going into detail on the setup of the server providing the service. This chapter
9: describes setting up a simple, small domain with one Domain Name System (DNS)
10: nameserver on a NetBSD system. It includes a brief explanation and overview of
11: the DNS; further information can be obtained from the DNS Resources Directory
12: (DNSRD) at <http://www.dns.net/dnsrd/>.
13:
14: ## DNS Background and Concepts
15:
16: The DNS is a widely used *naming service* on the Internet and other TCP/IP
17: networks. The network protocols, data and file formats, and other aspects of the
18: DNS are Internet Standards, specified in a number of RFC documents, and
19: described by a number of other reference and tutorial works. The DNS has a
20: distributed, client-server architecture. There are reference implementations for
21: the server and client, but these are not part of the standard. There are a
22: number of additional implementations available for many platforms.
23:
24: ### Naming Services
25:
26: Naming services are used to provide a mapping between textual names and
27: configuration data of some form. A *nameserver* maintains this mapping, and
28: clients request the nameserver to *resolve* a name into its attached data.
29:
30: The reader should have a good understanding of basic hosts to IP address mapping
31: and IP address class specifications, see
32: [[Name Service Concepts|guide/net-intro#nsconcepts]].
33:
34: In the case of the DNS, the configuration data bound to a name is in the form of
35: standard *Resource Records* (RRs). These textual names conform to certain
36: structural conventions.
37:
38: ### The DNS namespace
39:
40: The DNS presents a hierarchical name space, much like a UNIX filesystem,
41: pictured as an inverted tree with the *root* at the top.
42:
43: TOP-LEVEL .org
44: |
45: MID-LEVEL .diverge.org
46: ______________________|________________________
47: | | |
48: BOTTOM-LEVEL strider.diverge.org samwise.diverge.org wormtongue.diverge.org
49:
50: The system can also be logically divided even further if one wishes at different
51: points. The example shown above shows three nodes on the diverge.org domain, but
52: we could even divide diverge.org into subdomains such as
53: "strider.net1.diverge.org", "samwise.net2.diverge.org" and
54: "wormtongue.net2.diverge.org"; in this case, 2 nodes reside in
55: "net2.diverge.org" and one in "net1.diverge.org".
56:
57: There are directories of names, some of which may be sub-directories of further
58: names. These directories are sometimes called *zones*. There is provision for
59: symbolic links, redirecting requests for information on one name to the records
60: bound to another name. Each name recognised by the DNS is called a *Domain
61: Name*, whether it represents information about a specific host, or a directory
62: of subordinate Domain Names (or both, or something else).
63:
64: Unlike most filesystem naming schemes, however, Domain Names are written with
65: the innermost name on the left, and progressively higher-level domains to the
66: right, all the way up to the root directory if necessary. The separator used
67: when writing Domain Names is a period, ".".
68:
69: Like filesystem pathnames, Domain Names can be written in an absolute or
70: relative manner, though there are some differences in detail. For instance,
71: there is no way to indirectly refer to the parent domain like with the UNIX `..`
72: directory. Many (but not all) resolvers offer a search path facility, so that
73: partially-specified names can be resolved relative to additional listed
74: sub-domains other than the client's own domain. Names that are completely
75: specified all the way to the root are called *Fully Qualified Domain Names* or
76: *FQDN*s. A defining characteristic of an FQDN is that it is written with a
77: terminating period. The same name, without the terminating period, may be
78: considered relative to some other sub-domain. It is rare for this to occur
79: without malicious intent, but in part because of this possibility, FQDNs are
80: required as configuration parameters in some circumstances.
81:
82: On the Internet, there are some established conventions for the names of the
83: first few levels of the tree, at which point the hierarchy reaches the level of
84: an individual organisation. This organisation is responsible for establishing
85: and maintaining conventions further down the tree, within its own domain.
86:
87: ### Resource Records
88:
89: Resource Records for a domain are stored in a standardised format in an ASCII
90: text file, often called a *zone file*. The following Resource Records are
91: commonly used (a number of others are defined but not often used, or no longer
92: used). In some cases, there may be multiple RR types associated with a name, and
93: even multiple records of the same type.
94:
95: #### Common DNS Resource Records
96:
97: * *A: Address* -- This record contains the numerical IP address associated with
98: the name.
99:
100: * *CNAME: Canonical Name* -- This record contains the Canonical Name (an FQDN
101: with an associated A record) of the host name to which this record is bound.
102: This record type is used to provide name aliasing, by providing a link to
103: another name with which other appropriate RR's are associated. If a name has
104: a CNAME record bound to it, it is an alias, and no other RR's are permitted
105: to be bound to the same name.
106:
107: It is common for these records to be used to point to hosts providing a
108: particular service, such as an FTP or HTTP server. If the service must be
109: moved to another host, the alias can be changed, and the same name will reach
110: the new host.
111:
112: * *PTR: Pointer* -- This record contains a textual name. These records are
113: bound to names built in a special way from numerical IP addresses, and are
114: used to provide a reverse mapping from an IP address to a textual name. This
115: is described in more detail in [[Reverse Resolution|guide/dns#bg-reverse]].
116:
117: * *NS: Name Server* -- This record type is used to *delegate* a sub-tree of the
118: Domain Name space to another nameserver. The record contains the FQDN of a
119: DNS nameserver with information on the sub-domain, and is bound to the name
120: of the sub-domain. In this manner, the hierarchical structure of the DNS is
121: established. Delegation is described in more detail in
122: [[Delegation|guide/dns#bg-delegation]].
123:
124: * *MX: Mail eXchange* -- This record contains the FQDN for a host that will
125: accept SMTP electronic mail for the named domain, together with a priority
126: value used to select an MX host when relaying mail. It is used to indicate
127: other servers that are willing to receive and spool mail for the domain if
128: the primary MX is unreachable for a time. It is also used to direct email to
129: a central server, if desired, rather than to each and every individual
130: workstation.
131:
132: * *HINFO: Host Information* -- Contains two strings, intended for use to
133: describe the host hardware and operating system platform. There are defined
134: strings to use for some systems, but their use is not enforced. Some sites,
135: because of security considerations, do not publicise this information.
136:
137: * *TXT: Text* -- A free-form text field, sometimes used as a comment field,
138: sometimes overlaid with site-specific additional meaning to be interpreted by
139: local conventions.
140:
141: * *SOA: Start of Authority* -- This record is required to appear for each zone
142: file. It lists the primary nameserver and the email address of the person
143: responsible for the domain, together with default values for a number of
144: fields associated with maintaining consistency across multiple servers and
145: caching of the results of DNS queries.
146:
147: ### Delegation
148:
149: Using NS records, authority for portions of the DNS namespace below a certain
150: point in the tree can be delegated, and further sub-parts below that delegated
151: again. It is at this point that the distinction between a domain and a zone
152: becomes important. Any name in the DNS is called a domain, and the term applies
153: to that name and to any subordinate names below that one in the tree. The
154: boundaries of a zone are narrower, and are defined by delegations. A zone starts
155: with a delegation (or at the root), and encompasses all names in the domain
156: below that point, excluding names below any subsequent delegations.
157:
158: This distinction is important for implementation - a zone is a single
159: administrative entity (with a single SOA record), and all data for the zone is
160: referred to by a single file, called a *zone file*. A zone file may contain more
161: than one period-separated level of the namespace tree, if desired, by including
162: periods in the names in that zone file. In order to simplify administration and
163: prevent overly-large zone files, it is quite legal for a DNS server to delegate
164: to itself, splitting the domain into several zones kept on the same server.
165:
166: ### Delegation to multiple servers
167:
168: For redundancy, it is common (and often administratively required) that there be
169: more than one nameserver providing information on a zone. It is also common that
170: at least one of these servers be located at some distance (in terms of network
171: topology) from the others, so that knowledge of that zone does not become
172: unavailable in case of connectivity failure. Each nameserver will be listed in
173: an NS record bound to the name of the zone, stored in the parent zone on the
174: server responsible for the parent domain. In this way, those searching the name
175: hierarchy from the top down can contact any one of the servers to continue
176: narrowing their search. This is occasionally called *walking the tree*.
177:
178: There are a number of nameservers on the Internet which are called *root
179: nameservers*. These servers provide information on the very top levels of the
180: domain namespace tree. These servers are special in that their addresses must be
181: pre-configured into nameservers as a place to start finding other servers.
182: Isolated networks that cannot access these servers may need to provide their own
183: root nameservers.
184:
185: ### Secondaries, Caching, and the SOA record
186:
187: In order to maintain consistency between these servers, one is usually
188: configured as the *primary* server, and all administrative changes are made on
189: this server. The other servers are configured as *secondaries*, and transfer the
190: contents of the zone from the primary. This operational model is not required,
191: and if external considerations require it, multiple primaries can be used
192: instead, but consistency must then be maintained by other means. DNS servers
193: that store Resource Records for a zone, whether they be primary or secondary
194: servers, are said to be *authoritative* for the zone. A DNS server can be
195: authoritative for several zones.
196:
197: When nameservers receive responses to queries, they can *cache* the results.
198: This has a significant beneficial impact on the speed of queries, the query load
199: on high-level nameservers, and network utilisation. It is also a major
200: contributor to the memory usage of the nameserver process.
201:
202: There are a number of parameters that are important to maintaining consistency
203: amongst the secondaries and caches. The values for these parameters for a
204: particular domain zone file are stored in the SOA record. These fields are:
205:
206: #### Fields of the SOA Record
207:
208: * *Serial* -- A serial number for the zone file. This should be incremented any
209: time the data in the domain is changed. When a secondary wants to check if
210: its data is up-to-date, it checks the serial number on the primary's SOA
211: record.
212:
213: * *Refresh* -- A time, in seconds, specifying how often the secondary should
214: check the serial number on the primary, and start a new transfer if the
215: primary has newer data.
216:
217: * *Retry* -- If a secondary fails to connect to the primary when the refresh
218: time has elapsed (for example, if the host is down), this value specifies, in
219: seconds, how often the connection should be retried.
220:
221: * *Expire* -- If the retries fail to reach the primary within this number of
222: seconds, the secondary destroys its copies of the zone data file(s), and
223: stops answering requests for the domain. This stops very old and potentially
224: inaccurate data from remaining in circulation.
225:
226: * *TTL* -- This field specifies a time, in seconds, that the resource records
227: in this zone should remain valid in the caches of other nameservers. If the
228: data is volatile, this value should be short. TTL is a commonly-used acronym,
229: that stands for "Time To Live".
230:
231: ### Name Resolution
232:
233: DNS clients are configured with the addresses of DNS servers. Usually, these are
234: servers which are authoritative for the domain of which they are a member. All
235: requests for name resolution start with a request to one of these local servers.
236: DNS queries can be of two forms:
237:
238: * A *recursive* query asks the nameserver to resolve a name completely, and
239: return the result. If the request cannot be satisfied directly, the
240: nameserver looks in its configuration and caches for a server higher up the
241: domain tree which may have more information. In the worst case, this will be
242: a list of pre-configured servers for the root domain. These addresses are
243: returned in a response called a *referral*. The local nameserver must then
244: send its request to one of these servers.
245:
246: * Normally, this will be an *iterative* query, which asks the second nameserver
247: to either respond with an authoritative reply, or with the addresses of
248: nameservers (NS records) listed in its tables or caches as authoritative for
249: the relevant zone. The local nameserver then makes iterative queries, walking
250: the tree downwards until an authoritative answer is found (either positive or
251: negative) and returned to the client.
252:
253: In some configurations, such as when firewalls prevent direct IP communications
254: between DNS clients and external nameservers, or when a site is connected to the
255: rest of the world via a slow link, a nameserver can be configured with
256: information about a *forwarder*. This is an external nameserver to which the
257: local nameserver should make requests as a client would, asking the external
258: nameserver to perform the full recursive name lookup, and return the result in a
259: single query (which can then be cached), rather than reply with referrals.
260:
261: ### Reverse Resolution
262:
263: The DNS provides resolution from a textual name to a resource record, such as an
264: A record with an IP address. It does not provide a means, other than exhaustive
265: search, to match in the opposite direction; there is no mechanism to ask which
266: name is bound to a particular RR.
267:
268: For many RR types, this is of no real consequence, however it is often useful to
269: identify by name the host which owns a particular IP address. Rather than
270: complicate the design and implementation of the DNS database engine by providing
271: matching functions in both directions, the DNS utilises the existing mechanisms
272: and creates a special namespace, populated with PTR records, for IP address to
273: name resolution. Resolving in this manner is often called *reverse resolution*,
274: despite the inaccurate implications of the term.
275:
276: The manner in which this is achieved is as follows:
277:
278: * A normal domain name is reserved and defined to be for the purpose of mapping
279: IP addresses. The domain name used is `in-addr.arpa.` which shows the
280: historical origins of the Internet in the US Government's Defence Advanced
281: Research Projects Agency's funding program.
282:
283: * This domain is then subdivided and delegated according to the structure of IP
284: addresses. IP addresses are often written in *decimal dotted quad notation*,
285: where each octet of the 4-octet long address is written in decimal, separated
286: by dots. IP address ranges are usually delegated with more and more of the
287: left-most parts of the address in common as the delegation gets smaller.
288: Thus, to allow delegation of the reverse lookup domain to be done easily,
289: this is turned around when used with the hierarchical DNS namespace, which
290: places higher level domains on the right of the name.
291:
292: * Each byte of the IP address is written, as an ASCII text representation of
293: the number expressed in decimal, with the octets in reverse order, separated
294: by dots and appended with the in-addr.arpa. domain name. For example, to
295: determine the hostname of a network device with IP address 11.22.33.44, this
296: algorithm would produce the string `44.33.22.11.in-addr.arpa.` which is a
297: legal, structured Domain Name. A normal nameservice query would then be sent
298: to the nameserver asking for a PTR record bound to the generated name.
299:
300: * The PTR record, if found, will contain the FQDN of a host.
301:
302: One consequence of this is that it is possible for mismatch to occur. Resolving
303: a name into an A record, and then resolving the name built from the address in
304: that A record to a PTR record, may not result in a PTR record which contains the
305: original name. There is no restriction within the DNS that the "reverse" mapping
306: must coincide with the "forward" mapping. This is a useful feature in some
307: circumstances, particularly when it is required that more than one name has an A
308: record bound to it which contains the same IP address.
309:
310: While there is no such restriction within the DNS, some application server
311: programs or network libraries will reject connections from hosts that do not
312: satisfy the following test:
313:
314: * the state information included with an incoming connection includes the IP
315: address of the source of the request.
316:
317: * a PTR lookup is done to obtain an FQDN of the host making the connection
318:
319: * an A lookup is then done on the returned name, and the connection rejected if
320: the source IP address is not listed amongst the A records that get returned.
321:
322: This is done as a security precaution, to help detect and prevent malicious
323: sites impersonating other sites by configuring their own PTR records to return
324: the names of hosts belonging to another organisation.
325:
326: ## The DNS Files
327:
328: Now let's look at actually setting up a small DNS enabled network. We will
329: continue to use the examples mentioned in [Chapter 24, *Setting up TCP/IP on
330: NetBSD in practice*](chap-net-practice.html "Chapter 24. Setting up TCP/IP on
331: NetBSD in practice"), i.e. we assume that:
332:
333: * Our IP networking is working correctly
334: * We have IPNAT working correctly
335: * Currently all hosts use the ISP for DNS
336:
337: Our Name Server will be the `strider` host which also runs IPNAT, and our two
338: clients use "strider" as a gateway. It is not really relevant as to what type of
339: interface is on "strider", but for argument's sake we will say a 56k dial up
340: connection.
341:
342: So, before going any further, let's look at our `/etc/hosts` file on "strider"
343: before we have made the alterations to use DNS.
344:
345: **Example strider's `/etc/hosts` file**
346:
347: 127.0.0.1 localhost
348: 192.168.1.1 strider
349: 192.168.1.2 samwise sam
350: 192.168.1.3 wormtongue worm
351:
352: This is not exactly a huge network, but it is worth noting that the same rules
353: apply for larger networks as we discuss in the context of this section.
354:
355: The other assumption we want to make is that the domain we want to set up is
356: `diverge.org`, and that the domain is only known on our internal network, and
357: not worldwide. Proper registration of the nameserver's IP address as primary
358: would be needed in addition to a static IP. These are mostly administrative
359: issues which are left out here.
360:
361: The NetBSD operating system provides a set of config files for you to use for
362: setting up DNS. Along with a default `/etc/named.conf`, the following files are
363: stored in the `/etc/namedb` directory:
364:
365: * `localhost`
366: * `127`
367: * `loopback.v6`
368: * `root.cache`
369:
370: You will see modified versions of these files in this section, and I strongly
371: suggest making a backup copy of the original files for reference purposes.
372:
373: *Note*: The examples in this chapter refer to BIND major version 8, however, it
374: should be noted that format of the name database and other config files are
375: almost 100% compatible between version. The only difference I noticed was that
376: the `$TTL` information was not required.
377:
378: ### /etc/named.conf
379:
380: The first file we want to look at is `/etc/named.conf`. This file is the config
381: file for bind (hence the catchy name). Setting up system like the one we are
382: doing is relatively simple. First, here is what mine looks like:
383:
384: options {
385: directory "/etc/namedb";
386: allow-transfer { 192.168.1.0/24; };
387: allow-query { 192.168.1.0/24; };
388: listen-on port 53 { 192.168.1.1; };
389: };
390:
391: zone "localhost" {
392: type master;
393: notify no;
394: file "localhost";
395: };
396:
397: zone "127.IN-ADDR.ARPA" {
398: type master;
399: notify no;
400: file "127";
401: };
402:
403: 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" {
404: type master;
405: file "loopback.v6";
406: };
407:
408: zone "diverge.org" {
409: type master;
410: notify no;
411: file "diverge.org";
412: };
413:
414: zone "1.168.192.in-addr.arpa" {
415: type master;
416: notify no;
417: file "1.168.192";
418: };
419:
420: zone "." in {
421: type hint;
422: file "root.cache";
423: };
424:
425: Note that in my `named.conf` the root (".") section is last, that is because
426: there is another domain called diverge.org on the internet (I happen to own it)
427: so I want the resolver to look out on the internet last. This is not normally
428: the case on most systems.
429:
430: Another very important thing to remember here is that if you have an internal
431: setup, in other words no live internet connection and/or no need to do root
432: server lookups, comment out the root (".") zone. It may cause lookup problems if
433: a particular client decides it wants to reference a domain on the internet,
434: which our server couldn't resolve itself.
435:
436: Looks like a pretty big mess, upon closer examination it is revealed that many
437: of the lines in each section are somewhat redundant. So we should only have to
438: explain them a few times.
439:
440: Lets go through the sections of `named.conf`:
441:
442: #### options
443:
444: This section defines some global parameters, most noticeable is the location of
445: the DNS tables, on this particular system, they will be put in `/etc/namedb` as
446: indicated by the "directory" option.
447:
448: Following are the rest of the params:
449:
450: * `allow-transfer` -- This option lists which remote DNS servers acting as
451: secondaries are allowed to do zone transfers, i.e. are allowed to read all
452: DNS data at once. For privacy reasons, this should be restricted to secondary
453: DNS servers only.
454:
455: * `allow-query` -- This option defines hosts from what network may query this
456: name server at all. Restricting queries only to the local network
457: (192.168.1.0/24) prevents queries arriving on the DNS server's external
458: interface, and prevent possible privacy issues.
459:
460: * `listen-on port` -- This option defined the port and associated IP addresses
461: this server will run
462: [[!template id=man name="named" section="8"]]
463: on. Again, the "external" interface is not listened here, to prevent queries
464: getting received from "outside".
465:
466: The rest of the `named.conf` file consists of `zone`s. A zone is an area that
467: can have items to resolve attached, e.g. a domain can have hostnames attached to
468: resolve into IP addresses, and a reverse-zone can have IP addresses attached
469: that get resolved back into hostnames. Each zone has a file associated with it,
470: and a table within that file for resolving that particular zone. As is readily
471: apparent, their format in `named.conf` is strikingly similar, so I will
472: highlight just one of their records:
473:
474: #### zone diverge.org
475:
476: * `type` -- The type of a zone is usually of type "master" in all cases except
477: for the root zone `.` and for zones that a secondary (backup) service is
478: provided - the type obviously is "secondary" in the latter case.
479:
480: * `notify` -- Do you want to send out notifications to secondaries when your
481: zone changes? Obviously not in this setup, so this is set to "no".
482:
483: * `file` -- This option sets the filename in our `/etc/namedb` directory where
484: records about this particular zone may be found. For the "diverge.org" zone,
485: the file `/etc/namedb/diverge.org` is used.
486:
487: ### /etc/namedb/localhost
488:
489: For the most part, the zone files look quite similar, however, each one does
490: have some unique properties. Here is what the `localhost` file looks like:
491:
492: 1|$TTL 3600
493: 2|@ IN SOA strider.diverge.org. root.diverge.org. (
494: 3| 1 ; Serial
495: 4| 8H ; Refresh
496: 5| 2H ; Retry
497: 6| 1W ; Expire
498: 7| 1D) ; Minimum TTL
499: 8| IN NS localhost.
500: 9|localhost. IN A 127.0.0.1
501: 10| IN AAAA ::1
502:
503: Line by line:
504:
505: * *Line 1*: This is the Time To Live for lookups, which defines how long other
506: DNS servers will cache that value before discarding it. This value is
507: generally the same in all the files.
508:
509: * *Line 2*: This line is generally the same in all zone files except
510: `root.cache`. It defines a so-called "Start Of Authority" (SOA) header, which
511: contains some basic information about a zone. Of specific interest on this
512: line are "strider.diverge.org." and "root.diverge.org." (note the trailing
513: dots!). Obviously one is the name of this server and the other is the contact
514: for this DNS server, in most cases root seems a little ambiguous, it is
515: preferred that a regular email account be used for the contact information,
516: with the "@" replaced by a "." (for example, mine would be
517: "jrf.diverge.org.").
518:
519: * *Line 3*: This line is the serial number identifying the "version" of the
520: zone's data set (file). The serial number should be incremented each time
521: there is a change to the file, the usual format is to either start with a
522: value of "1" and increase it for every change, or use a value of "YYYYMMDDNN"
523: to encode year (YYYY), month (MM), day (DD) and change within one day (NN) in
524: the serial number.
525:
526: * *Line 4*: This is the refresh rate of the server, in this file it is set to
527: once every 8 hours.
528:
529: * *Line 5*: The retry rate.
530:
531: * *Line 6*: Lookup expiry.
532:
533: * *Line 7*: The minimum Time To Live.
534:
535: * *Line 8*: This is the Nameserver line, which uses a "NS" resource record to
536: show that "localhost" is the only DNS server handing out data for this zone
537: (which is "@", which indicates the zone name used in the `named.conf` file,
538: i.e. "diverge.org") is, well, "localhost".
539:
540: * *Line 9*: This is the localhost entry, which uses an "A" resource record to
541: indicate that the name "localhost" should be resolved into the IP-address
542: 127.0.0.1 for IPv4 queries (which specifically ask for the "A" record).
543:
544: * *Line 10*: This line is the IPv6 entry, which returns ::1 when someone asks
545: for an IPv6-address (by specifically asking for the AAAA record) of
546: "localhost.".
547:
548: ### /etc/namedb/zone.127.0.0
549:
550: This is the reverse lookup file (or zone) to resolve the special IP address
551: 127.0.0.1 back to "localhost":
552:
553: 1| $TTL 3600
554: 2| @ IN SOA strider.diverge.org. root.diverge.org. (
555: 3| 1 ; Serial
556: 4| 8H ; Refresh
557: 5| 2H ; Retry
558: 6| 1W ; Expire
559: 7| 1D) ; Minimum TTL
560: 8| IN NS localhost.
561: 9| 1.0.0 IN PTR localhost.
562:
563: In this file, all of the lines are the same as the localhost zonefile with
564: exception of line 9, this is the reverse lookup (PTR) record. The zone used here
565: is "@" again, which got set to the value given in `named.conf`, i.e.
566: "127.in-addr.arpa". This is a special "domain" which is used to do
567: reverse-lookup of IP addresses back into hostnames. For it to work, the four
568: bytes of the IPv4 address are reserved, and the domain "in-addr.arpa" attached,
569: so to resolve the IP address "127.0.0.1", the PTR record of
570: "1.0.0.127.in-addr.arpa" is queried, which is what is defined in that line.
571:
572: ### /etc/namedb/diverge.org
573:
574: This zone file is populated by records for all of our hosts. Here is what it
575: looks like:
576:
577: 1| $TTL 3600
578: 2| @ IN SOA strider.diverge.org. root.diverge.org. (
579: 3| 1 ; serial
580: 4| 8H ; refresh
581: 5| 2H ; retry
582: 6| 1W ; expire
583: 7| 1D ) ; minimum seconds
584: 8| IN NS strider.diverge.org.
585: 9| IN MX 10 strider.diverge.org. ; primary mail server
586: 10| IN MX 20 samwise.diverge.org. ; secondary mail server
587: 11| strider IN A 192.168.1.1
588: 12| samwise IN A 192.168.1.2
589: 13| www IN CNAME samwise.diverge.org.
590: 14| worm IN A 192.168.1.3
591:
592: There is a lot of new stuff here, so lets just look over each line that is new
593: here:
594:
595: * *Line 9*: This line shows our mail exchanger (MX), in this case it is
596: "strider". The number that precedes "strider.diverge.org." is the priority
597: number, the lower the number their higher the priority. The way we are setup
598: here is if "strider" cannot handle the mail, then "samwise" will.
599:
600: * *Line 11*: CNAME stands for canonical name, or an alias for an existing
601: hostname, which must have an A record. So we have aliased `www.diverge.org`
602: to `samwise.diverge.org`.
603:
604: The rest of the records are simply mappings of IP address to a full name (A
605: records).
606:
607: ### /etc/namedb/1.168.192
608:
609: This zone file is the reverse file for all of the host records, to map their IP
610: numbers we use on our private network back into hostnames. The format is similar
611: to that of the "localhost" version with the obvious exception being the
612: addresses are different via the different zone given in the `named.conf` file,
613: i.e. "0.168.192.in-addr.arpa" here:
614:
615: 1|$TTL 3600
616: 2|@ IN SOA strider.diverge.org. root.diverge.org. (
617: 3| 1 ; serial
618: 4| 8H ; refresh
619: 5| 2H ; retry
620: 6| 1W ; expire
621: 7| 1D ) ; minimum seconds
622: 8| IN NS strider.diverge.org.
623: 9|1 IN PTR strider.diverge.org.
624: 10|2 IN PTR samwise.diverge.org.
625: 11|3 IN PTR worm.diverge.org.
626:
627: ### /etc/namedb/root.cache
628:
629: This file contains a list of root name servers for your server to query when it
630: gets requests outside of its own domain that it cannot answer itself. Here are
631: first few lines of a root zone file:
632:
633: ;
634: ; This file holds the information on root name servers needed to
635: ; initialize cache of Internet domain name servers
636: ; (e.g. reference this file in the "cache . <file>"
637: ; configuration file of BIND domain name servers).
638: ;
639: ; This file is made available by InterNIC
640: ; under anonymous FTP as
641: ; file /domain/db.cache
642: ; on server FTP.INTERNIC.NET
643: ; -OR- RS.INTERNIC.NET
644: ;
645: ; last update: Jan 29, 2004
646: ; related version of root zone: 2004012900
647: ;
648: ;
649: ; formerly NS.INTERNIC.NET
650: ;
651: . 3600000 IN NS A.ROOT-SERVERS.NET.
652: A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
653: ;
654: ; formerly NS1.ISI.EDU
655: ;
656: . 3600000 NS B.ROOT-SERVERS.NET.
657: B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201
658: ;
659: ; formerly C.PSI.NET
660: ;
661: . 3600000 NS C.ROOT-SERVERS.NET.
662: C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
663: ;
664: ...
665:
666: This file can be obtained from ISC at <http://www.isc.org/> and usually comes
667: with a distribution of BIND. A `root.cache` file is included in the NetBSD
668: operating system's "etc" set.
669:
670: This section has described the most important files and settings for a DNS
671: server. Please see the BIND documentation in `/usr/src/dist/bind/doc/bog` and
672: [[!template id=man name="named.conf" section="5"]]
673: for more information.
674:
675: ## Using DNS
676:
677: In this section we will look at how to get DNS going and setup "strider" to use
678: its own DNS services.
679:
680: Setting up named to start automatically is quite simple. In `/etc/rc.conf`
681: simply set `named=yes`. Additional options can be specified in `named_flags`,
682: for example, I like to use `-g nogroup -u nobody`, so a non-root account runs
683: the "named" process.
684:
685: In addition to being able to startup "named" at boot time, it can also be
686: controlled with the `ndc` command. In a nutshell the `ndc` command can stop,
687: start or restart the named server process. It can also do a great many other
688: things. Before use, it has to be setup to communicate with the "named" process,
689: see the [[!template id=man name="ndc" section="8"]]
690: and
691: [[!template id=man name="named.conf" section="5"]]
692: man pages for more details on setting up communication channels between "ndc"
693: and the "named" process.
694:
695: Next we want to point "strider" to itself for lookups. We have two simple steps,
696: first, decide on our resolution order. On a network this small, it is likely
697: that each host has a copy of the hosts table, so we can get away with using
698: `/etc/hosts` first, and then DNS. However, on larger networks it is much easier
699: to use DNS. Either way, the file where order of name services used for
700: resolution is determined is `/etc/nsswitch.conf` (see
701: [[`nsswitch.conf`|guide/net-practice#ex-nsswitch]]. Here is part of a typical
702: `nsswitch.conf`:
703:
704: ...
705: group_compat: nis
706: hosts: files dns
707: netgroup: files [notfound=return] nis
708: ...
709:
710: The line we are interested in is the "hosts" line. "files" means the system uses
711: the `/etc/hosts` file first to determine ip to name translation, and if it can't
712: find an entry, it will try DNS.
713:
714: The next file to look at is `/etc/resolv.conf`, which is used to configure DNS
715: lookups ("resolution") on the client side. The format is pretty self explanatory
716: but we will go over it anyway:
717:
718: domain diverge.org
719: search diverge.org
720: nameserver 192.168.1.1
721:
722: In a nutshell this file is telling the resolver that this machine belongs to the
723: "diverge.org" domain, which means that lookups that contain only a hostname
724: without a "." gets this domain appended to build a FQDN. If that lookup doesn't
725: succeed, the domains in the "search" line are tried next. Finally, the
726: "nameserver" line gives the IP addresses of one or more DNS servers that should
727: be used to resolve DNS queries.
728:
729: To test our nameserver we can use several commands, for example:
730:
731: # host sam
732: sam.diverge.org has address 192.168.1.2
733:
734: As can be seen, the domain was appended automatically here, using the value from
735: `/etc/resolv.conf`. Here is another example, the output of running
736: `host www.yahoo.com`:
737:
738: $ host www.yahoo.com
739: www.yahoo.com is an alias for www.yahoo.akadns.net.
740: www.yahoo.akadns.net has address 68.142.226.38
741: www.yahoo.akadns.net has address 68.142.226.39
742: www.yahoo.akadns.net has address 68.142.226.46
743: www.yahoo.akadns.net has address 68.142.226.50
744: www.yahoo.akadns.net has address 68.142.226.51
745: www.yahoo.akadns.net has address 68.142.226.54
746: www.yahoo.akadns.net has address 68.142.226.55
747: www.yahoo.akadns.net has address 68.142.226.32
748:
749: Other commands for debugging DNS besides
750: [[!template id=man name="host" section="1"]] are
751: [[!template id=man name="nslookup" section="8"]]
752: and
753: [[!template id=man name="dig" section="1"]]. Note
754: that
755: [[!template id=man name="ping" section="8"]]
756: is *not* useful for debugging DNS, as it will use whatever is configured in
757: `/etc/nsswitch.conf` to do the name-lookup.
758:
759: At this point the server is configured properly. The procedure for setting up
760: the client hosts are easier, you only need to setup `/etc/nsswitch.conf` and
761: `/etc/resolv.conf` to the same values as on the server.
762:
763: ## Setting up a caching only name server
764:
765: A caching only name server has no local zones; all the queries it receives are
766: forwarded to the root servers and the replies are accumulated in the local
767: cache. The next time the query is performed the answer will be faster because
768: the data is already in the server's cache. Since this type of server doesn't
769: handle local zones, to resolve the names of the local hosts it will still be
770: necessary to use the already known `/etc/hosts` file.
771:
772: Since NetBSD supplies defaults for all the files needed by a caching only
773: server, it only needs to be enabled and started and is immediately ready for
774: use! To enable named, put `named=yes` into `/etc/rc.conf`, and tell the system
775: to use it adding the following line to the `/etc/resolv.conf` file:
776:
777: # cat /etc/resolv.conf
778: nameserver 127.0.0.1
779:
780: Now we can start named:
781:
782: # sh /etc/rc.d/named restart
783:
784: ### Testing the server
785:
786: Now that the server is running we can test it using the
787: [[!template id=man name="nslookup" section="8"]]
788: program:
789:
790: $ nslookup
791: Default server: localhost
792: Address: 127.0.0.1
793:
794: >
795:
796: Let's try to resolve a host name, for example "www.NetBSD.org":
797:
798: > www.NetBSD.org
799: Server: localhost
800: Address: 127.0.0.1
801:
802: Name: www.NetBSD.org
803: Address: 204.152.190.12
804:
805: If you repeat the query a second time, the result is slightly different:
806:
807: > www.NetBSD.org
808: Server: localhost
809: Address: 127.0.0.1
810:
811: Non-authoritative answer:
812: Name: www.NetBSD.org
813: Address: 204.152.190.12
814:
815: As you've probably noticed, the address is the same, but the message
816: `Non-authoritative answer` has appeared. This message indicates that the answer
817: is not coming from an authoritative server for the domain NetBSD.org but from
818: the cache of our own server.
819:
820: The results of this first test confirm that the server is working correctly.
821:
822: We can also try the
823: [[!template id=man name="host" section="1"]] and
824: [[!template id=man name="dig" section="1"]] commands,
825: which give the following result.
826:
827: $ host www.NetBSD.org
828: www.NetBSD.org has address 204.152.190.12
829: $
830: $ dig www.NetBSD.org
831:
832: ; <<>> DiG 8.3 <<>> www.NetBSD.org
833: ;; res options: init recurs defnam dnsrch
834: ;; got answer:
835: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19409
836: ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 0
837: ;; QUERY SECTION:
838: ;; www.NetBSD.org, type = A, class = IN
839:
840: ;; ANSWER SECTION:
841: www.NetBSD.org. 23h32m54s IN A 204.152.190.12
842:
843: ;; AUTHORITY SECTION:
844: NetBSD.org. 23h32m54s IN NS uucp-gw-1.pa.dec.com.
845: NetBSD.org. 23h32m54s IN NS uucp-gw-2.pa.dec.com.
846: NetBSD.org. 23h32m54s IN NS ns.NetBSD.org.
847: NetBSD.org. 23h32m54s IN NS adns1.berkeley.edu.
848: NetBSD.org. 23h32m54s IN NS adns2.berkeley.edu.
849:
850: ;; Total query time: 14 msec
851: ;; FROM: miyu to SERVER: 127.0.0.1
852: ;; WHEN: Thu Nov 25 22:59:36 2004
853: ;; MSG SIZE sent: 32 rcvd: 175
854:
855: As you can see
856: [[!template id=man name="dig" section="1"]] gives
857: quite a bit of output, the expected answer can be found in the "ANSWER SECTION".
858: The other data given may be of interest when debugging DNS problems.
859:
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb
![[BACK]](/icons/back.gif){kind=icon}
Return to dns.mdwn CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [NetBSD Developer Wiki] / wikisrc / guide