File:  [NetBSD Developer Wiki] / wikisrc / guide / dns.mdwn
Revision 1.1: download - view: text, annotated - select for diffs
Sat Mar 9 00:15:25 2013 UTC (7 years, 6 months ago) by jdf
Branches: MAIN
CVS tags: HEAD
dns Guide -> wiki

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

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb