Annotation of wikisrc/guide/dns.mdwn, revision 1.2

1.1       jdf         1: # The Domain Name System
                      2: 
1.2     ! jdf         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
1.1       jdf         8: (DNSRD) at [http://www.dns.net/dnsrd/](http://www.dns.net/dnsrd/).
                      9: 
                     10: ## DNS Background and Concepts
                     11: 
1.2     ! jdf        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
1.1       jdf        18: number of additional implementations available for many platforms.
                     19: 
                     20: ### Naming Services
                     21: 
1.2     ! jdf        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
1.1       jdf        24: clients request the nameserver to *resolve* a name into its attached data.
                     25: 
1.2     ! jdf        26: The reader should have a good understanding of basic hosts to IP address mapping
1.1       jdf        27: and IP address class specifications, see
                     28: [[Name Service Concepts|guide/net-intro#nsconcepts]].
                     29: 
1.2     ! jdf        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
1.1       jdf        32: structural conventions.
                     33: 
                     34: ### The DNS namespace
                     35: 
1.2     ! jdf        36: The DNS presents a hierarchical name space, much like a UNIX filesystem,
1.1       jdf        37: pictured as an inverted tree with the *root* at the top.
                     38: 
1.2     ! jdf        39:     TOP-LEVEL                                .org
        !            40:                                                |
        !            41:     MID-LEVEL                             .diverge.org
        !            42:                          ______________________|________________________
        !            43:                         |                      |                        |
1.1       jdf        44:     BOTTOM-LEVEL strider.diverge.org   samwise.diverge.org   wormtongue.diverge.org
                     45: 
1.2     ! jdf        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 diverge.org domain, but
        !            48: we could even divide diverge.org into subdomains such as
        !            49: "strider.net1.diverge.org", "samwise.net2.diverge.org" and
        !            50: "wormtongue.net2.diverge.org"; in this case, 2 nodes reside in
1.1       jdf        51: "net2.diverge.org" and one in "net1.diverge.org".
                     52: 
1.2     ! jdf        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
1.1       jdf        58: of subordinate Domain Names (or both, or something else).
                     59: 
1.2     ! jdf        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
1.1       jdf        63: when writing Domain Names is a period, ".".
                     64: 
1.2     ! jdf        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
1.1       jdf        76: required as configuration parameters in some circumstances.
                     77: 
1.2     ! jdf        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
1.1       jdf        81: and maintaining conventions further down the tree, within its own domain.
                     82: 
                     83: ### Resource Records
                     84: 
1.2     ! jdf        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
1.1       jdf        89: even multiple records of the same type.
                     90: 
                     91: #### Common DNS Resource Records
                     92: 
1.2     ! jdf        93:  * *A: Address* -- This record contains the numerical IP address associated with
1.1       jdf        94:    the name.
                     95: 
1.2     ! jdf        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
1.1       jdf       101:    to be bound to the same name.
                    102: 
1.2     ! jdf       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
1.1       jdf       106:    the new host.
                    107: 
1.2     ! jdf       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
1.1       jdf       111:    is described in more detail in [[Reverse Resolution|guide/dns#bg-reverse]].
                    112: 
1.2     ! jdf       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
1.1       jdf       118:    [[Delegation|guide/dns#bg-delegation]].
                    119: 
1.2     ! jdf       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
1.1       jdf       126:    workstation.
                    127: 
1.2     ! jdf       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,
1.1       jdf       131:    because of security considerations, do not publicise this information.
                    132: 
1.2     ! jdf       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
1.1       jdf       135:    local conventions.
                    136: 
1.2     ! jdf       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
1.1       jdf       141:    caching of the results of DNS queries.
                    142: 
                    143: ### Delegation
                    144: 
1.2     ! jdf       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
1.1       jdf       152: below that point, excluding names below any subsequent delegations.
                    153: 
1.2     ! jdf       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
1.1       jdf       160: to itself, splitting the domain into several zones kept on the same server.
                    161: 
                    162: ### Delegation to multiple servers
                    163: 
1.2     ! jdf       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
1.1       jdf       172: narrowing their search. This is occasionally called *walking the tree*.
                    173: 
1.2     ! jdf       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
1.1       jdf       179: root nameservers.
                    180: 
                    181: ### Secondaries, Caching, and the SOA record
                    182: 
1.2     ! jdf       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
1.1       jdf       191: authoritative for several zones.
                    192: 
1.2     ! jdf       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
1.1       jdf       196: contributor to the memory usage of the nameserver process.
                    197: 
1.2     ! jdf       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
1.1       jdf       200: particular domain zone file are stored in the SOA record. These fields are:
                    201: 
                    202: #### Fields of the SOA Record
                    203: 
1.2     ! jdf       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
1.1       jdf       207:    record.
                    208: 
1.2     ! jdf       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
1.1       jdf       211:    primary has newer data.
                    212: 
1.2     ! jdf       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
1.1       jdf       215:    seconds, how often the connection should be retried.
                    216: 
1.2     ! jdf       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
1.1       jdf       220:    inaccurate data from remaining in circulation.
                    221: 
1.2     ! jdf       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,
1.1       jdf       225:    that stands for "Time To Live".
                    226: 
                    227: ### Name Resolution
                    228: 
1.2     ! jdf       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.
1.1       jdf       232: DNS queries can be of two forms:
                    233: 
1.2     ! jdf       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
1.1       jdf       240:    send its request to one of these servers.
                    241: 
1.2     ! jdf       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
1.1       jdf       247:    negative) and returned to the client.
                    248: 
1.2     ! jdf       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
1.1       jdf       255: single query (which can then be cached), rather than reply with referrals.
                    256: 
                    257: ### Reverse Resolution
                    258: 
1.2     ! jdf       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
1.1       jdf       262: name is bound to a particular RR.
                    263: 
1.2     ! jdf       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*,
1.1       jdf       270: despite the inaccurate implications of the term.
                    271: 
                    272: The manner in which this is achieved is as follows:
                    273: 
1.2     ! jdf       274:  * A normal domain name is reserved and defined to be for the purpose of mapping
        !           275:    IP addresses. The domain name used is `in-addr.arpa.` which shows the
        !           276:    historical origins of the Internet in the US Government's Defence Advanced
1.1       jdf       277:    Research Projects Agency's funding program.
                    278: 
1.2     ! jdf       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
1.1       jdf       286:    places higher level domains on the right of the name.
                    287: 
1.2     ! jdf       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 in-addr.arpa. domain name. For example, to
        !           291:    determine the hostname of a network device with IP address 11.22.33.44, this
        !           292:    algorithm would produce the string `44.33.22.11.in-addr.arpa.` which is a
        !           293:    legal, structured Domain Name. A normal nameservice query would then be sent
1.1       jdf       294:    to the nameserver asking for a PTR record bound to the generated name.
1.2     ! jdf       295: 
1.1       jdf       296:  * The PTR record, if found, will contain the FQDN of a host.
                    297: 
1.2     ! jdf       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
1.1       jdf       304: record bound to it which contains the same IP address.
                    305: 
1.2     ! jdf       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
1.1       jdf       308: satisfy the following test:
                    309: 
1.2     ! jdf       310:  * the state information included with an incoming connection includes the IP
1.1       jdf       311:    address of the source of the request.
                    312: 
                    313:  * a PTR lookup is done to obtain an FQDN of the host making the connection
                    314: 
1.2     ! jdf       315:  * an A lookup is then done on the returned name, and the connection rejected if
1.1       jdf       316:    the source IP address is not listed amongst the A records that get returned.
                    317: 
1.2     ! jdf       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
1.1       jdf       320: the names of hosts belonging to another organisation.
                    321: 
                    322: ## The DNS Files
                    323: 
1.2     ! jdf       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
1.1       jdf       327: NetBSD in practice"), i.e. we assume that:
                    328: 
                    329:  * Our IP networking is working correctly
                    330:  * We have IPNAT working correctly
                    331:  * Currently all hosts use the ISP for DNS
                    332: 
1.2     ! jdf       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
1.1       jdf       336: connection.
                    337: 
                    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.
                    340: 
                    341: **Example strider's `/etc/hosts` file**
                    342: 
                    343:     127.0.0.1       localhost
                    344:     192.168.1.1     strider
                    345:     192.168.1.2     samwise sam
                    346:     192.168.1.3     wormtongue worm
                    347: 
1.2     ! jdf       348: This is not exactly a huge network, but it is worth noting that the same rules
1.1       jdf       349: apply for larger networks as we discuss in the context of this section.
                    350: 
1.2     ! jdf       351: The other assumption we want to make is that the domain we want to set up is
        !           352: `diverge.org`, 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
1.1       jdf       355: issues which are left out here.
                    356: 
1.2     ! jdf       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
1.1       jdf       359: stored in the `/etc/namedb` directory:
                    360: 
                    361:  * `localhost`
                    362:  * `127`
                    363:  * `loopback.v6`
                    364:  * `root.cache`
                    365: 
1.2     ! jdf       366: You will see modified versions of these files in this section, and I strongly
1.1       jdf       367: suggest making a backup copy of the original files for reference purposes.
                    368: 
1.2     ! jdf       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
1.1       jdf       372: the `$TTL` information was not required.
                    373: 
                    374: ### /etc/named.conf
                    375: 
1.2     ! jdf       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
1.1       jdf       378: doing is relatively simple. First, here is what mine looks like:
                    379: 
                    380:     options {
                    381:             directory "/etc/namedb";
                    382:             allow-transfer { 192.168.1.0/24; };
                    383:             allow-query { 192.168.1.0/24; };
                    384:             listen-on port 53 { 192.168.1.1; };
                    385:     };
                    386:     
                    387:     zone "localhost" {
                    388:        type master;
                    389:        notify no;
                    390:        file "localhost";
                    391:     };
                    392:     
                    393:     zone "127.IN-ADDR.ARPA" {
                    394:        type master;
                    395:        notify no;
                    396:        file "127";
                    397:     };
                    398:     
                    399:     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" {
                    400:        type master;
                    401:        file "loopback.v6";
                    402:     };
                    403:     
                    404:     zone "diverge.org" {
                    405:        type master;
                    406:        notify no;
                    407:        file "diverge.org";
                    408:     };
                    409:     
                    410:     zone "1.168.192.in-addr.arpa" {
                    411:        type master;
                    412:        notify no;
                    413:        file "1.168.192";
                    414:     };
                    415:     
                    416:     zone "." in {
                    417:        type hint;
                    418:        file "root.cache";
                    419:     };
                    420: 
1.2     ! jdf       421: Note that in my `named.conf` the root (".") section is last, that is because
        !           422: there is another domain called diverge.org 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
1.1       jdf       424: the case on most systems.
                    425: 
1.2     ! jdf       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,
1.1       jdf       430: which our server couldn't resolve itself.
                    431: 
1.2     ! jdf       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
1.1       jdf       434: explain them a few times.
                    435: 
                    436: Lets go through the sections of `named.conf`:
                    437: 
                    438: #### options
                    439: 
1.2     ! jdf       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
1.1       jdf       442: indicated by the "directory" option.
                    443: 
                    444: Following are the rest of the params:
                    445: 
1.2     ! jdf       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
1.1       jdf       449:    DNS servers only.
                    450: 
1.2     ! jdf       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:    (192.168.1.0/24) prevents queries arriving on the DNS server's external
1.1       jdf       454:    interface, and prevent possible privacy issues.
                    455: 
1.2     ! jdf       456:  * `listen-on port` -- This option defined the port and associated IP addresses
        !           457:    this server will run
        !           458:    [named(8)](http://netbsd.gw.com/cgi-bin/man-cgi?named+8+NetBSD-5.0.1+i386)
        !           459:    on. Again, the "external" interface is not listened here, to prevent queries
1.1       jdf       460:    getting received from "outside".
                    461: 
1.2     ! jdf       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
1.1       jdf       468: highlight just one of their records:
                    469: 
                    470: #### zone diverge.org
                    471: 
1.2     ! jdf       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
1.1       jdf       474:    provided - the type obviously is "secondary" in the latter case.
                    475: 
1.2     ! jdf       476:  * `notify` -- Do you want to send out notifications to secondaries when your
1.1       jdf       477:    zone changes? Obviously not in this setup, so this is set to "no".
                    478: 
1.2     ! jdf       479:  * `file` -- This option sets the filename in our `/etc/namedb` directory where
        !           480:    records about this particular zone may be found. For the "diverge.org" zone,
1.1       jdf       481:    the file `/etc/namedb/diverge.org` is used.
                    482: 
                    483: ### /etc/namedb/localhost
                    484: 
1.2     ! jdf       485: For the most part, the zone files look quite similar, however, each one does
1.1       jdf       486: have some unique properties. Here is what the `localhost` file looks like:
                    487: 
                    488:      1|$TTL    3600
                    489:      2|@              IN SOA  strider.diverge.org. root.diverge.org. (
                    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       127.0.0.1
                    497:     10|               IN      AAAA    ::1
                    498: 
                    499: Line by line:
                    500: 
1.2     ! jdf       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
1.1       jdf       503:    generally the same in all the files.
                    504: 
1.2     ! jdf       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 "strider.diverge.org." and "root.diverge.org." (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
1.1       jdf       513:    "jrf.diverge.org.").
                    514: 
1.2     ! jdf       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
1.1       jdf       520:    the serial number.
                    521: 
1.2     ! jdf       522:  * *Line 4*: This is the refresh rate of the server, in this file it is set to
1.1       jdf       523:    once every 8 hours.
                    524: 
                    525:  * *Line 5*: The retry rate.
                    526: 
                    527:  * *Line 6*: Lookup expiry.
                    528: 
                    529:  * *Line 7*: The minimum Time To Live.
                    530: 
1.2     ! jdf       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,
1.1       jdf       534:    i.e. "diverge.org") is, well, "localhost".
                    535: 
1.2     ! jdf       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
1.1       jdf       538:    127.0.0.1 for IPv4 queries (which specifically ask for the "A" record).
                    539: 
1.2     ! jdf       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
1.1       jdf       542:    "localhost.".
                    543: 
                    544: ### /etc/namedb/zone.127.0.0
                    545: 
1.2     ! jdf       546: This is the reverse lookup file (or zone) to resolve the special IP address
1.1       jdf       547: 127.0.0.1 back to "localhost":
                    548: 
                    549:      1| $TTL    3600
                    550:      2| @              IN SOA  strider.diverge.org. root.diverge.org. (
                    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.
                    558: 
1.2     ! jdf       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: "127.in-addr.arpa". 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 "in-addr.arpa" attached,
        !           565: so to resolve the IP address "127.0.0.1", the PTR record of
1.1       jdf       566: "1.0.0.127.in-addr.arpa" is queried, which is what is defined in that line.
                    567: 
                    568: ### /etc/namedb/diverge.org
                    569: 
1.2     ! jdf       570: This zone file is populated by records for all of our hosts. Here is what it
1.1       jdf       571: looks like:
                    572: 
                    573:      1| $TTL    3600
                    574:      2| @              IN SOA  strider.diverge.org. root.diverge.org. (
                    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   strider.diverge.org.
                    581:      9|                 IN MX   10 strider.diverge.org.   ; primary mail server
                    582:     10|                 IN MX   20 samwise.diverge.org.   ; secondary mail server
                    583:     11| strider         IN A     192.168.1.1
                    584:     12| samwise         IN A     192.168.1.2
                    585:     13| www             IN CNAME samwise.diverge.org.
                    586:     14| worm            IN A     192.168.1.3
                    587: 
1.2     ! jdf       588: There is a lot of new stuff here, so lets just look over each line that is new
1.1       jdf       589: here:
                    590: 
1.2     ! jdf       591:  * *Line 9*: This line shows our mail exchanger (MX), in this case it is
        !           592:    "strider". The number that precedes "strider.diverge.org." is the priority
        !           593:    number, the lower the number their higher the priority. The way we are setup
1.1       jdf       594:    here is if "strider" cannot handle the mail, then "samwise" will.
                    595: 
1.2     ! jdf       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 `www.diverge.org`
1.1       jdf       598:    to `samwise.diverge.org`.
                    599: 
1.2     ! jdf       600: The rest of the records are simply mappings of IP address to a full name (A
1.1       jdf       601: records).
                    602: 
                    603: ### /etc/namedb/1.168.192
                    604: 
1.2     ! jdf       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,
1.1       jdf       609: i.e. "0.168.192.in-addr.arpa" here:
                    610: 
                    611:      1|$TTL    3600
                    612:      2|@              IN SOA  strider.diverge.org. root.diverge.org. (
                    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   strider.diverge.org.
                    619:      9|1              IN PTR  strider.diverge.org.
                    620:     10|2              IN PTR  samwise.diverge.org.
                    621:     11|3              IN PTR  worm.diverge.org.
                    622: 
                    623: ### /etc/namedb/root.cache
                    624: 
1.2     ! jdf       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
1.1       jdf       627: first few lines of a root zone file:
                    628: 
                    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     198.41.0.4
                    649:     ;
                    650:     ; formerly NS1.ISI.EDU
                    651:     ;
                    652:     .                        3600000      NS    B.ROOT-SERVERS.NET.
                    653:     B.ROOT-SERVERS.NET.      3600000      A     192.228.79.201
                    654:     ;
                    655:     ; formerly C.PSI.NET
                    656:     ;
                    657:     .                        3600000      NS    C.ROOT-SERVERS.NET.
                    658:     C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
                    659:     ;
                    660:     ...
                    661: 
1.2     ! jdf       662: This file can be obtained from ISC at <http://www.isc.org/> and usually comes
        !           663: with a distribution of BIND. A `root.cache` file is included in the NetBSD
1.1       jdf       664: operating system's "etc" set.
                    665: 
1.2     ! jdf       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)](http://netbsd.gw.com/cgi-bin/man-cgi?named.conf+5+NetBSD-5.0.1+i386)
1.1       jdf       669: for more information.
                    670: 
                    671: ## Using DNS
                    672: 
1.2     ! jdf       673: In this section we will look at how to get DNS going and setup "strider" to use
1.1       jdf       674: its own DNS services.
                    675: 
1.2     ! jdf       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
1.1       jdf       679: the "named" process.
                    680: 
1.2     ! jdf       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)](http://netbsd.gw.com/cgi-bin/man-cgi?ndc+8+NetBSD-5.0.1+i386)
        !           686: and
        !           687: [named.conf(5)](http://netbsd.gw.com/cgi-bin/man-cgi?named.conf+5+NetBSD-5.0.1+i386)
        !           688: man pages for more details on setting up communication channels between "ndc"
1.1       jdf       689: and the "named" process.
                    690: 
1.2     ! jdf       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
1.1       jdf       698: `nsswitch.conf`:
                    699: 
                    700:     ...
                    701:     group_compat:   nis
                    702:     hosts:          files dns
                    703:     netgroup:       files [notfound=return] nis
                    704:     ...
                    705: 
1.2     ! jdf       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
1.1       jdf       708: find an entry, it will try DNS.
                    709: 
1.2     ! jdf       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
1.1       jdf       712: but we will go over it anyway:
                    713: 
                    714:     domain diverge.org
                    715:     search diverge.org
                    716:     nameserver 192.168.1.1
                    717: 
1.2     ! jdf       718: In a nutshell this file is telling the resolver that this machine belongs to the
        !           719: "diverge.org" 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
1.1       jdf       723: be used to resolve DNS queries.
                    724: 
                    725: To test our nameserver we can use several commands, for example:
                    726: 
                    727:     # host sam
                    728:     sam.diverge.org has address 192.168.1.2
                    729: 
1.2     ! jdf       730: As can be seen, the domain was appended automatically here, using the value from
1.1       jdf       731: `/etc/resolv.conf`. Here is another example, the output of running
                    732: `host www.yahoo.com`:
                    733: 
                    734:     $ host www.yahoo.com
                    735:     www.yahoo.com is an alias for www.yahoo.akadns.net.
                    736:     www.yahoo.akadns.net has address 68.142.226.38
                    737:     www.yahoo.akadns.net has address 68.142.226.39
                    738:     www.yahoo.akadns.net has address 68.142.226.46
                    739:     www.yahoo.akadns.net has address 68.142.226.50
                    740:     www.yahoo.akadns.net has address 68.142.226.51
                    741:     www.yahoo.akadns.net has address 68.142.226.54
                    742:     www.yahoo.akadns.net has address 68.142.226.55
                    743:     www.yahoo.akadns.net has address 68.142.226.32
                    744: 
1.2     ! jdf       745: Other commands for debugging DNS besides
        !           746: [host(1)](http://netbsd.gw.com/cgi-bin/man-cgi?host+1+NetBSD-5.0.1+i386) are
        !           747: [nslookup(8)](http://netbsd.gw.com/cgi-bin/man-cgi?nslookup+8+NetBSD-5.0.1+i386)
1.1       jdf       748: and
1.2     ! jdf       749: [dig(1)](http://netbsd.gw.com/cgi-bin/man-cgi?dig+1+NetBSD-5.0.1+i386). Note
1.1       jdf       750: that
                    751: [ping(8)](http://netbsd.gw.com/cgi-bin/man-cgi?ping+8+NetBSD-5.0.1+i386)
1.2     ! jdf       752: is *not* useful for debugging DNS, as it will use whatever is configured in
1.1       jdf       753: `/etc/nsswitch.conf` to do the name-lookup.
                    754: 
1.2     ! jdf       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
1.1       jdf       757: `/etc/resolv.conf` to the same values as on the server.
                    758: 
                    759: ## Setting up a caching only name server
                    760: 
1.2     ! jdf       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
1.1       jdf       766: necessary to use the already known `/etc/hosts` file.
                    767: 
1.2     ! jdf       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
1.1       jdf       771: to use it adding the following line to the `/etc/resolv.conf` file:
                    772: 
                    773:     # cat /etc/resolv.conf
                    774:     nameserver 127.0.0.1
                    775: 
                    776: Now we can start named:
                    777: 
                    778:     # sh /etc/rc.d/named restart
                    779: 
                    780: ### Testing the server
                    781: 
1.2     ! jdf       782: Now that the server is running we can test it using the
        !           783: [nslookup(8)](http://netbsd.gw.com/cgi-bin/man-cgi?nslookup+8+NetBSD-5.0.1+i386)
1.1       jdf       784: program:
                    785: 
                    786:     $ nslookup
                    787:     Default server: localhost
                    788:     Address: 127.0.0.1
                    789:     
                    790:     >
                    791: 
                    792: Let's try to resolve a host name, for example "www.NetBSD.org":
                    793: 
                    794:     > www.NetBSD.org
                    795:     Server:  localhost
                    796:     Address:  127.0.0.1
                    797:     
                    798:     Name:    www.NetBSD.org
                    799:     Address:  204.152.190.12
                    800: 
                    801: If you repeat the query a second time, the result is slightly different:
                    802: 
                    803:     > www.NetBSD.org
                    804:     Server:  localhost
                    805:     Address:  127.0.0.1
                    806:     
                    807:     Non-authoritative answer:
                    808:     Name:    www.NetBSD.org
                    809:     Address:  204.152.190.12
                    810: 
1.2     ! jdf       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 NetBSD.org but from
1.1       jdf       814: the cache of our own server.
                    815: 
                    816: The results of this first test confirm that the server is working correctly.
                    817: 
1.2     ! jdf       818: We can also try the
        !           819: [host(1)](http://netbsd.gw.com/cgi-bin/man-cgi?host+1+NetBSD-5.0.1+i386) and
        !           820: [dig(1)](http://netbsd.gw.com/cgi-bin/man-cgi?dig+1+NetBSD-5.0.1+i386) commands,
1.1       jdf       821: which give the following result.
                    822: 
                    823:     $ host www.NetBSD.org
                    824:     www.NetBSD.org has address 204.152.190.12
                    825:     $
                    826:     $ dig www.NetBSD.org
                    827:     
                    828:     ; <<>> DiG 8.3 <<>> www.NetBSD.org
                    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:     ;;      www.NetBSD.org, type = A, class = IN
                    835:     
                    836:     ;; ANSWER SECTION:
                    837:     www.NetBSD.org.         23h32m54s IN A  204.152.190.12
                    838:     
                    839:     ;; AUTHORITY SECTION:
                    840:     NetBSD.org.             23h32m54s IN NS  uucp-gw-1.pa.dec.com.
                    841:     NetBSD.org.             23h32m54s IN NS  uucp-gw-2.pa.dec.com.
                    842:     NetBSD.org.             23h32m54s IN NS  ns.NetBSD.org.
                    843:     NetBSD.org.             23h32m54s IN NS  adns1.berkeley.edu.
                    844:     NetBSD.org.             23h32m54s IN NS  adns2.berkeley.edu.
                    845:     
                    846:     ;; Total query time: 14 msec
                    847:     ;; FROM: miyu to SERVER: 127.0.0.1
                    848:     ;; WHEN: Thu Nov 25 22:59:36 2004
1.2     ! jdf       849:     ;; MSG SIZE  sent: 32  rcvd: 175
1.1       jdf       850: 
1.2     ! jdf       851: As you can see
        !           852: [dig(1)](http://netbsd.gw.com/cgi-bin/man-cgi?dig+1+NetBSD-5.0.1+i386) gives
        !           853: quite a bit of output, the expected answer can be found in the "ANSWER SECTION".
1.1       jdf       854: The other data given may be of interest when debugging DNS problems.
                    855: 

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb