diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index 134b67b2c2..5c50174e27 100644 --- a/doc/arm/Bv9ARM-book.xml +++ b/doc/arm/Bv9ARM-book.xml @@ -2,7 +2,7 @@ - + @@ -19,7 +19,7 @@ Scope of Document The Berkeley Internet Name Domain (BIND) implements an - Internet nameserver for a number of operating systems. This + domain name server for a number of operating systems. This document provides basic information about the installation and care of the Internet Software Consortium (ISC) BIND version 9 software package for system administrators. @@ -34,7 +34,8 @@ BIND 9 software. The task-oriented section is followed by Section 4, which contains more advanced concepts that the system administrator may need for implementing - certain options. Section 5 describes the BIND 9 lightweight + certain options. Section 5 + describes the BIND 9 lightweight resolver. The contents of Section 6 are organized as in a reference manual to aid in the ongoing maintenance of the software. Section 7 @@ -70,21 +71,16 @@ describe: a pathname, filename, URL, hostname, mailing list name, or new term or concept - Italic + Fixed width literal user input Fixed Width Bold - - variable user -input - Fixed Width Italic - program output - Fixed Width Bold + Fixed Width @@ -104,212 +100,258 @@ describe: keywords - Sans Serif Bold + Fixed Width variables - Sans Serif Italic + Fixed Width -"meta-syntactic" -information (within brackets when optional) -Fixed Width Italic - - -Command line -input -Fixed Width Bold - - -Program output - Fixed Width - - Optional input Text is enclosed in square brackets -Discussion of Domain Name System (<acronym>DNS</acronym>) Basics and -<acronym>BIND</acronym> +The Domain Name System (<acronym>DNS</acronym>) The purpose of this document is to explain the installation -and basic upkeep of the BIND software package, and we begin by reviewing -the fundamentals of the domain naming system as they relate to BIND. -BIND consists of a nameserver (or "daemon") -called named and a resolver library. -The BIND server runs in the background, servicing queries on a well -known network port. The standard port for the User Datagram Protocol -(UDP) and Transmission Control Protocol (TCP), usually port 53, -is specified in /etc/services. -The resolver is a set of routines residing -in a system library that provides the interface that programs can -use to access the domain name services. -Nameservers -A nameserver (NS) is a program that stores information about -named resources and responds to queries from programs called resolvers which -act as client processes. The basic function of an NS is to provide -information about network objects by answering queries. -With the nameserver, the network can be broken into a hierarchy -of domains. The name space is organized as a tree according to organizational -or administrative boundaries. Each node of the tree, called a domain, -is given a label. The name of the domain is the concatenation of -all the labels of the domains from the root to the current domain. -This is represented in written form as a string of labels listed -from right to left and separated by dots. A label need only be unique -within its domain. The whole name space is partitioned into areas -called zones, each starting at a domain and -extending down to the leaf domains or to domains where other zones -start. Zones usually represent administrative boundaries. For example, -a domain name for a host at the company Example, Inc. would -be: -ourhost.example.com -where com is the top level domain to which -ourhost.example.com belongs, -example is -a subdomain of com, and -ourhost is the +and upkeep of the BIND software package, and we +begin by reviewing the fundamentals of the Domain Name System +(DNS) as they relate to BIND. + + + +DNS Fundamentals + +The Domain Name System (DNS) is the hierarchical, distributed +database. It stores information for mapping Internet host names to IP +addresses and vice versa, mail routing information, and other data +used by Internet applications. + +Clients look up information in the DNS by calling a +resolver library, which sends queries to one or +more name servers and interprets the responses. +The BIND 9 software distribution contains both a +name server and a resolver library. + + +Domains and Domain Names + +The data stored in the DNS is identified by domain +names that are organized as a tree according to +organizational or administrative boundaries. Each node of the tree, +called a domain, is given a label. The domain name of the +node is the concatenation of all the labels on the path from the +node to the root node. This is represented +in written form as a string of labels listed from right to left and +separated by dots. A label need only be unique within its parent +domain. + +For example, a domain name for a host at the +company Example, Inc. could be +mail.example.net, +were com is the +top level domain to which +ourhost.example.com belongs, +example is +a subdomain of com, and +ourhost is the name of the host. -The specifications for the domain nameserver are defined in -the RFC 1034, RFC 1035 and RFC 974. These documents can be found -in -/usr/src/etc/named/doc in 4.4BSD or are available -via File Transfer Protocol (FTP) from -ftp://www.isi.edu/in-notes/ -or via the Web at http://www.ietf.org/rfc/. -(See Appendix C for complete information on finding and retrieving -RFCs.) It is also recommended that you read the related man pages: -named and resolver. -Types of Zones + +For administrative purposes, the name space is partitioned into +areas called zones, each starting at a node and +extending down to the leaf nodes or to nodes where other zones start. +The data for each zone is stored in a name +server, which answers queries about the zone using the +DNS protocol. + + +The data associated with each domain name is stored in the +form of resource records (RRs). +Some of the supported resource record types are described in +. + +For more detailed information about the design of the DNS and +the DNS protocol, please refer to the standards documents listed in +. + + +Zones +To properly operate a name server, it is important to understand +the difference between a zone +and a domain. + As we stated previously, a zone is a point of delegation in -the DNS tree. A zone consists of those contiguous parts of the domain -tree for which a domain server has complete information and over which +the DNS tree. A zone consists of +those contiguous parts of the domain +tree for which a a name server has complete information and over which it has authority. It contains all domain names from a certain point downward in the domain tree except those which are delegated to -other zones. A delegation point has one or more NS records in the +other zones. A delegation point is marked by one or more +NS records in the parent zone, which should be matched by equivalent NS records at the root of the delegated zone. -To properly operate a nameserver, it is important to understand -the difference between a zone and a domain. -For instance, consider the example.com domain -which includes names such as host.aaa.example.com -and host.bbb.example.com even -though the example.com -zone includes only delegations for the -aaa.example.com -and bbb.example.com zones. -A zone can map exactly to a single domain, but could also include -only part of a domain, the rest of which could be delegated to other -nameservers. Every name in the DNS tree is a domain, -even if it is terminal, that is, has no subdomains. -Every subdomain is a domain and every domain except the root is -also a subdomain. The terminology is not intuitive and we suggest -that you read RFCs 1033, 1034 and 1035 to gain a complete understanding -of this difficult and subtle topic. -Though BIND is a Domain Nameserver, it deals primarily in -terms of zones. The master and slave declarations in the named.conf file -specify zones, not domains. When you ask some other site if it is willing -to be a slave server for your domain, you are + +For instance, consider the example.com +domain which includes names +such as host.aaa.example.com and +host.bbb.example.com even though +the example.com zone includes +only delegations for the aaa.example.com and +bbb.example.com zones. A zone can map +exactly to a single domain, but could also include only part of a +domain, the rest of which could be delegated to other +name servers. Every name in the DNS tree is a +domain, even if it is +terminal, that is, has no +subdomains. Every subdomain is a domain and +every domain except the root is also a subdomain. The terminology is +not intuitive and we suggest that you read RFCs 1033, 1034 and 1035 to +gain a complete understanding of this difficult and subtle +topic. + +Though BIND is called a "domain name server", +it deals primarily in terms of zones. The master and slave +declarations in the named.conf file specify +zones, not domains. When you ask some other site if it is willing to +be a slave server for your domain, you are actually asking for slave service for some collection of zones. -Each zone will have one primary master (also -called primary) server which loads the zone -contents from some local file edited by humans or perhaps generated -mechanically from some other local file which is edited by humans. -There there will be some number of slave (also -called secondary) servers, which load the zone -contents using the DNS protocol (that is, the secondary servers -will contact the primary and fetch the zone data using TCP). This -set of servers — the primary and all of its secondaries — should be -listed in the NS records in the parent zone and will constitute a delegation. -This set of servers must also be listed in the zone file itself, -usually under the @ name which indicates the top -level or root of the current zone. -You can list servers in the zone's top-level @ NS + + +Authoritative Name Servers + +Each zone is served by at least +one authoritative name server, +which contains the complete data for the zone. +To make the DNS tolerant of server and network failures, +most zones have two or more authoritative servers. + + +Responses from authoritative servers have the the "authoritative +answer" (AA) bit set in the response packets. This makes them +easy to identify when debugging DNS configurations using tools like +dig (). + +The Primary Master + + +The authoritative server where the master copy of the zone data is maintained is +called the primary master server, or simply the +primary. It loads the zone contents from some +local file edited by humans or perhaps generated mechanically from +some other local file which is edited by humans. This file is called +the zone file or master file. + + +Slave Servers +The other authoritative servers, the slave +servers (also known as secondary servers) load +the zone contents from another server using a replication process +known as a zone transfer. Typically the data are +transferred directly from the primary master, but it is also possible +to transfer it from another slave. In other words, a slave server +may itself act as a master to a subordinate slave server. + + +Stealth Servers + +Usually all of the zone's authoritative servers are listed in +NS records in the parent zone. These NS records constitute +a delegation of the zone from the parent. +The authoritative servers are also listed in the zone file itself, +at the top level or apex +of the zone. You can list servers in the zone's top-level NS records that are not in the parent's NS delegation, but you cannot -list servers in the parent's delegation that are not present in -the zone's @. -Any servers listed in the NS records must be configured as authoritative for -the zone. A server is authoritative for a zone when it has been -configured to answer questions for that zone with authority, which -it does by setting the "authoritative answer" (AA) bit in reply -packets. A server may be authoritative for more than one zone. The -authoritative data for a zone is composed of all of the Resource -Records (RRs) — the data associated with names in a tree-structured -name space — attached to all of the nodes from the top node of the -zone down to leaf nodes or nodes above cuts around the bottom edge -of the zone. -Adding a zone as a type master or type slave will tell the -server to answer questions for the zone authoritatively. If the -server is able to load the zone into memory without any errors it -will set the AA bit when it replies to queries for the zone. See -RFCs 1034 and 1035 for more information about the AA bit. -Servers -A DNS server can be master for some zones and slave for others -or can be only a master, or only a slave, or can serve no zones -and just answer queries via its cache. Master -servers are often also called primaries and -slave servers are often also called secondaries. -Both master/primary and slave/secondary servers are authoritative -for a zone. -All servers keep data in their cache until the data expires, -based on a Time To Live (TTL) field which is maintained for all -resource records. -Master Server -The primary master server is the ultimate -source of information about a domain. The primary master is an authoritative -server configured to be the source of zone transfer for one or more -secondary servers. The primary master server obtains data for the -zone from a file on disk. -Slave Server -A slave server, also called a secondary -server, is an authoritative server that uses zone transfers from -the primary master server to retrieve the zone data. Optionally, -the slave server obtains zone data from a cache on disk. Slave servers -provide necessary redundancy. All secondary/slave servers are named -in the NS RRs for the zone. -Caching Only Server -Some servers are caching only servers. -This means that the server caches the information that it receives -and uses it until the data expires. A caching only server is a server -that is not authoritative for any zone. This server services queries -and asks other servers, who have the authority, for the information -it needs. -Forwarding Server -Instead of interacting with the nameservers for the root and -other domains, a forwarding server always forwards -queries it cannot satisfy from its authoritative data or cache to -a fixed list of other servers. The forwarded queries are also known -as recursive queries, the same type as a client would -send to a server. There may be one or more servers forwarded to, +list servers in the parent's delegation that are not present at +the zone's top level. + +A stealth server is a server that is +authoritative for a zone but is not listed in that zone's NS +records. Stealth servers can be used for keeping a local copy of a +zone to speed up access to the zone's records or to make sure that the +zone is available even if all the "official" servers for the zone are +inaccessible. + +A configuration where the primary master server itself is a +stealth server is often referred to as a "hidden primary" +configuration. One use for this configuration is when the primary master +is behind a firewall and therefore unable to communicate directly +with the outside world. + + + + + + +Caching Name Servers + +The resolver libraries provided by most operating systems are +stub resolvers, meaning that they are not capable of +performing the full DNS resolution process by themselves by talking +directly to the authoritative servers. Instead, they rely on a local +name server to perform the resolution on their behalf. Such a server +is called a recursive name server; it performs +recursive lookups for local clients. + +To improve performance, recursive servers cache the results of +the lookups they perform. Since the processes of recursion and +caching are intimately connected, the terms +recursive server and +caching server are often used synonymously. + +The length of time for which a record may be retained in +in the cache of a caching name server is controlled by the +Time To Live (TTL) field associated with each resource record. + + +Forwarding + +Even a caching name server does not necessarily perform +the complete recursive lookup itself. Instead, it can +forward some or all of the queries +that it cannot satisfy from its cache to another caching name server, +commonly referred to as a forwarder. + + +There may be one or more forwarders, and they are queried in turn until the list is exhausted or an answer -is found. A forwarding server is typically used when you do not -wish all the servers at a given site to interact with the rest of +is found. Forwarders are typically used when you do not +wish all the servers at a given site to interact directly with the rest of the Internet servers. A typical scenario would involve a number of internal DNS servers and an Internet firewall. Servers unable to pass packets through the firewall would forward to the server that can do it, and that server would query the Internet DNS servers on the internal server's behalf. An added benefit of using the forwarding feature is that the central machine develops a much more complete -cache of information that all the workstations can take advantage +cache of information that all the clients can take advantage of. -There is no prohibition against declaring a server to be a -forwarder even though it has master and/or slave zones as well; -the effect will still be that anything in the local server's cache -or zones will be answered, and anything else will be forwarded using -the forwarders list. -Stealth Server -A stealth server is a server that answers -authoritatively for a zone, but is not listed in that zone's NS -records. Stealth servers can be used as a way to centralize distribution -of a zone, without having to edit the zone on a remote nameserver. -Where the master file for a zone resides on a stealth server in -this way, it is often referred to as a "hidden primary" configuration. -Stealth servers can also be a way to keep a local copy of a zone -for rapid access to the zone's records, even if all "official" nameservers -for the zone are inaccessible. - + + + + +Name Servers in Multiple Roles + +The BIND name server can simultaneously act as +a master for some zones, a slave for other zones, and as a caching +(recursive) server for a set of local clients. + +However, since the functions of authoritative name service +and caching/recursive name service are logically separate, it is +often advantageous to run them on separate server machines. + +A server that only provides authoritative name service +(an authoritative-only server) can run with +recursion disabled, improving reliability and security. + +A server that is not authoritative for any zones and only provides +recursive service to local +clients (a caching-only server) +does not need to be reachable from the Internet at large and can +be placed inside a firewall. + - + + <acronym>BIND</acronym> Resource Requirements Hardware requirements @@ -523,8 +565,8 @@ of the time: slave will check to see that its version of the zone is the current version and, if not, initiate a transfer. DNS Notify is fully documented in RFC 1996. See also the description - of the zone option also-notify, see . For more information about + of the zone option also-notify, see + . For more information about notify, see . @@ -537,11 +579,11 @@ of the time: and monitoring tools available to the system administrator for controlling and debugging the nameserver daemon. We describe several in this section - + Diagnostic Tools - dig + dig The domain information groper (dig) is a command line tool that can be used to gather information from @@ -619,29 +661,6 @@ behavior, we do not recommend the use of nslookup. Use dig instead. - - named-checkconf - - Checks the syntax of named.conf. - - named-checkconf - filename - - - - - named-checkzone - - Performs syntax and consistency checks on a individual zone. - - named-checkzone - -dq - -c class - zone - filename - - - @@ -649,6 +668,29 @@ Use dig instead. Administrative tools play an integral part in the management of a server. + + check-conf + + Performs syntax consistancy checks on named.conf. + + check-conf + filename + + + + + check-zone + + Perform consistancy checks on a individual zone. + + check-zone + -dq + -c class + zone + filename + + + rndc @@ -699,15 +741,6 @@ of a server. Toggle query logging. - -dumpdb -Dump the current contents of the cache -(or caches if there are multiple views) into the file named by the -dump-file option -(by default, named_dump.db). - - - stop Stop the server, making sure any recent changes @@ -959,22 +992,22 @@ filtering on the network. If everything has been set properly, Example, Inc.'s internal clients will now be able to: - Look up any hostnames in the site1 and -site2.example.com zones. + Look up any hostnames in the site1 and +site2.example.com zones. - Look up any hostnames in the site1.internal and -site2.internal domains. + Look up any hostnames in the site1.internal and +site2.internal domains. Look up any hostnames on the Internet. Exchange mail with internal AND external people. Hosts on the Internet will be able to: - Look up any hostnames in the site1 and -site2.example.com zones. + Look up any hostnames in the site1 and +site2.example.com zones. - Exchange mail with anyone in the site1 and -site2.example.com zones. + Exchange mail with anyone in the site1 and +site2.example.com zones. Here is an example configuration for the setup we just described above. Note that this is only configuration information; @@ -1503,8 +1536,8 @@ $ORIGIN example2.net. company 3600 IN A6 0 1234:5678:90ab:fffa:: - When host.example.com is looked up, + When host.example.com is looked up, the resolver (in the resolver daemon or caching name server) will find two partial A6 records, and will use the additional name to find the remainder of the data. @@ -1576,8 +1609,8 @@ $ORIGIN \[x3ffe805002011860/64].ip6.arpa. need to be maintained. For example, consider a host which has two providers - (example.net and - example2.net) and + (example.net and + example2.net) and therefore two IPv6 addresses. Since the host chooses its own 64 bit host address portion, the provider address is the only part that changes: @@ -1595,7 +1628,7 @@ ipv6net2 A6 0 6666:5555:4:: This sets up forward lookups. To handle the reverse lookups, -the provider example.net +the provider example.net would have: @@ -1603,15 +1636,15 @@ $ORIGIN \[x00aa00bbcccc/48].ip6.arpa. \[xdddd/16] DNAME ipv6-rev.example.com. - and example2.net would have: + and example2.net would have: $ORIGIN \[x666655550004/48].ip6.arpa. \[x0001/16] DNAME ipv6-rev.example.com. - example.com + example.com needs only one zone file to handle both of these reverse mappings: @@ -1646,7 +1679,7 @@ address can be overriden by lwserver lines in /etc/resolv.conf. The daemon will try to find the answer to the questions "what are the addresses for host -foo.example.com?" and "what are +foo.example.com?" and "what are the names for IPv4 address 10.1.2.3?" The daemon currently only looks in the DNS, but in the future it may use other sources such as /etc/hosts, @@ -1698,7 +1731,7 @@ defined by the acl statement. domain_name A quoted string which will be used as -a DNS name, for example "my.test.domain". +a DNS name, for example "my.test.domain". dotted_decimal @@ -3410,7 +3443,7 @@ order. }; will cause any responses for type A records in class IN that -have "host.example.com" as a suffix, to always be returned +have "host.example.com" as a suffix, to always be returned in random order. All other records are returned in cyclic order. If multiple rrset-order statements appear, they are not combined-the last one applies. @@ -3753,7 +3786,7 @@ recommended, since it often speeds server start-up and eliminates a needless waste of bandwidth. Note that for large numbers (in the tens or hundreds of thousands) of zones per server, it is best to use a two level naming scheme for zone file names. For example, -a slave server for the zone example.com might place +a slave server for the zone example.com might place the zone contents into a file called ex/example.com where ex/ is just the first two letters of the zone name. (Most operating systems @@ -3805,12 +3838,9 @@ Classes other than IN have no built-in defaults hints. Class -In general class can now be omitted from -a zone's definition. -It is now inherited for the enclosing view or if -there is no explicit view, from the default -view which is IN -(for Internet). +The zone's name may optionally be followed by a class. If +a class is not specified, class IN (for Internet), +is assumed. This is correct for the vast majority of cases. The hesiod class is named for an information service from MIT's Project Athena. It is used to share information about various systems databases, such @@ -4410,7 +4440,7 @@ domain names. -This example shows two addresses for XX.LCS.MIT.EDU, +This example shows two addresses for XX.LCS.MIT.EDU, each of a different class. Discussion of MX Records As described above, domain servers store information as a @@ -4479,8 +4509,9 @@ pointed to by the CNAME. For example: -Mail delivery will be attempted to mail.example.com and mail2.example.com (in -any order), and if neither of those succeed, delivery to mail.backup.org will +Mail delivery will be attempted to mail.example.com and +mail2.example.com (in +any order), and if neither of those succeed, delivery to mail.backup.org will be attempted. Setting TTLs The time to live of the RR field is a 32 bit integer represented @@ -4769,8 +4800,7 @@ all. The best solution to solving installation and configuration issues is to take preventative measures by setting - up logging files beforehand (see the sample configurations in - ). The log files provide a + up logging files beforehand. The log files provide a source of hints and information that can be used to figure out what went wrong and how to fix the problem. @@ -5068,8 +5098,9 @@ series of technical notes. The standards themselves are defined by the Internet Engineering Task Force (IETF) and the Internet Engineering Steering Group (IESG). RFCs can be obtained online via FTP at ftp://www.isi.edu/in-notes/RFCxxx.txt (where xxx is -the number of the RFC). RFCs are also available via the Web at http://www.ietf.org/rfc/. +the number of the RFC). RFCs are also available via the Web at +http://www.ietf.org/rfc/. +