Table of Contents
+ ++ IPv6 addresses are 128-bit identifiers for interfaces and + sets of interfaces which were introduced in the DNS to facilitate + scalable Internet routing. There are three types of addresses: Unicast, + an identifier for a single interface; + Anycast, + an identifier for a set of interfaces; and Multicast, + an identifier for a set of interfaces. Here we describe the global + Unicast address scheme. For more information, see RFC 3587, + "Global Unicast Address Format." +
++ IPv6 unicast addresses consist of a + global routing prefix, a + subnet identifier, and an + interface identifier. +
++ The global routing prefix is provided by the + upstream provider or ISP, and (roughly) corresponds to the + IPv4 network section + of the address range. + + The subnet identifier is for local subnetting, much the + same as subnetting an + IPv4 /16 network into /24 subnets. + + The interface identifier is the address of an individual + interface on a given network; in IPv6, addresses belong to + interfaces rather than to machines. +
++ The subnetting capability of IPv6 is much more flexible than + that of IPv4: subnetting can be carried out on bit boundaries, + in much the same way as Classless InterDomain Routing + (CIDR), and the DNS PTR representation ("nibble" format) + makes setting up reverse zones easier. +
++ The Interface Identifier must be unique on the local link, + and is usually generated automatically by the IPv6 + implementation, although it is usually possible to + override the default setting if necessary. A typical IPv6 + address might look like: + 2001:db8:201:9:a00:20ff:fe81:2b32 +
++ IPv6 address specifications often contain long strings + of zeros, so the architects have included a shorthand for + specifying + them. The double colon (`::') indicates the longest possible + string + of zeros that can fit, and can be used only once in an address. +
++ Specification documents for the Internet protocol suite, including + the DNS, are published as part of + the Request for Comments (RFCs) + 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/RFCxxxx.txt
+
+
+ (where xxxx is
+ the number of the RFC). RFCs are also available via the Web at:
+
[RFC1876] A Means for Expressing Location Information in the + Domain + Name System. January 1996.
++ Note: the following list of RFCs, although + DNS-related, are not + concerned with implementing software. +
++ Internet Drafts (IDs) are rough-draft working documents of + the Internet Engineering Task Force. They are, in essence, RFCs + in the preliminary stages of development. Implementors are + cautioned not + to regard IDs as archival, and they should not be quoted or cited + in any formal documents unless accompanied by the disclaimer that + they are "works in progress." IDs have a lifespan of six months + after which they are deleted unless updated by their authors. +
+BIND 9.11.0pre-alpha
+ + diff --git a/doc/arm/Bv9ARM.ch12.html b/doc/arm/Bv9ARM.ch12.html new file mode 100644 index 0000000000..06d20e521d --- /dev/null +++ b/doc/arm/Bv9ARM.ch12.html @@ -0,0 +1,545 @@ + + + + + +Table of Contents
+ +This version of BIND 9 "exports" its internal libraries so + that they can be used by third-party applications more easily (we + call them "export" libraries in this document). In addition to + all major DNS-related APIs BIND 9 is currently using, the export + libraries provide the following features:
+The newly created "DNS client" module. This is a higher + level API that provides an interface to name resolution, + single DNS transaction with a particular server, and dynamic + update. Regarding name resolution, it supports advanced + features such as DNSSEC validation and caching. This module + supports both synchronous and asynchronous mode.
The new "IRS" (Information Retrieval System) library. + It provides an interface to parse the traditional resolv.conf + file and more advanced, DNS-specific configuration file for + the rest of this package (see the description for the + dns.conf file below).
As part of the IRS library, newly implemented standard + address-name mapping functions, getaddrinfo() and + getnameinfo(), are provided. They use the DNSSEC-aware + validating resolver backend, and could use other advanced + features of the BIND 9 libraries such as caching. The + getaddrinfo() function resolves both A and AAAA RRs + concurrently (when the address family is unspecified).
An experimental framework to support other event + libraries than BIND 9's internal event task system.
GNU make is required to build the export libraries (other + part of BIND 9 can still be built with other types of make). In + the reminder of this document, "make" means GNU make. Note that + in some platforms you may need to invoke a different command name + than "make" (e.g. "gmake") to indicate it's GNU make.
++$+./configure --enable-exportlib+$[other flags]make+
+ This will create (in addition to usual BIND 9 programs) and a
+ separate set of libraries under the lib/export directory. For
+ example, lib/export/dns/libdns.a is the archive file of the
+ export version of the BIND 9 DNS library. Sample application
+ programs using the libraries will also be built under the
+ lib/export/samples directory (see below).
+$+cd lib/export+$make install+
+ This will install library object files under the directory + specified by the --with-export-libdir configure option (default: + EPREFIX/lib/bind9), and header files under the directory + specified by the --with-export-includedir configure option + (default: PREFIX/include/bind9). + Root privilege is normally required. + "make install" at the top directory will do the + same. +
+
+ To see how to build your own
+ application after the installation, see
+ lib/export/samples/Makefile-postinstall.in.
Currently, win32 is not supported for the export + library. (Normal BIND 9 application can be built as + before).
The "fixed" RRset order is not (currently) supported in + the export library. If you want to use "fixed" RRset order + for, e.g. named while still building the + export library even without the fixed order support, build + them separately: +
++$+./configure --enable-fixed-rrset+$[other flags, but not --enable-exportlib]make+$./configure --enable-exportlib+$[other flags, but not --enable-fixed-rrset]cd lib/export+$make+
+
+The client module and the IRS library currently do not + support DNSSEC validation using DLV (the underlying modules + can handle it, but there is no tunable interface to enable + the feature).
RFC 5011 is not supported in the validating stub + resolver of the export library. In fact, it is not clear + whether it should: trust anchors would be a system-wide + configuration which would be managed by an administrator, + while the stub resolver will be used by ordinary applications + run by a normal user.
Not all common /etc/resolv.conf
+ options are supported
+ in the IRS library. The only available options in this
+ version are "debug" and "ndots".
The IRS library supports an "advanced" configuration file
+ related to the DNS library for configuration parameters that
+ would be beyond the capability of the
+ resolv.conf file.
+ Specifically, it is intended to provide DNSSEC related
+ configuration parameters. By default the path to this
+ configuration file is /etc/dns.conf.
+ This module is very
+ experimental and the configuration syntax or library interfaces
+ may change in future versions. Currently, only the
+ trusted-keys
+ statement is supported, whose syntax is the same as the same name
+ of statement for named.conf. (See
+ the section called “trusted-keys Statement Grammar” for details.)
Some sample application programs using this API are + provided for reference. The following is a brief description of + these applications. +
++ It sends a query of a given name (of a given optional RR type) to a + specified recursive server, and prints the result as a list of + RRs. It can also act as a validating stub resolver if a trust + anchor is given via a set of command line options.
++ Usage: sample [options] server_address hostname +
++ Options and Arguments: +
++ specify the RR type of the query. The default is the A RR. +
+ specify a command-line DNS key to validate the answer. For + example, to specify the following DNSKEY of example.com: +
+
+ example.com. 3600 IN DNSKEY 257 3 5 xxx
+
+ specify the options as follows: +
+
+
+ -e -k example.com -K "xxx"
+
+
++ -e means that this key is a zone's "key signing key" (as known + as "secure Entry point"). + When -a is omitted rsasha1 will be used by default. +
++ specify a separate recursive server address for the specific + "domain". Example: -s example.com:2001:db8::1234 +
+ an IP(v4/v6) address of the recursive server to which queries + are sent. +
+ the domain name for the query +
+ Similar to "sample", but accepts a list + of (query) domain names as a separate file and resolves the names + asynchronously.
++ Usage: sample-async [-s server_address] [-t RR_type] input_file
++ Options and Arguments: +
+
+ www.example.com
+ mx.example.net
+ ns.xxx.example
+
+ It sends a query to a specified server, and + prints the response with minimal processing. It doesn't act as a + "stub resolver": it stops the processing once it gets any + response from the server, whether it's a referral or an alias + (CNAME or DNAME) that would require further queries to get the + ultimate answer. In other words, this utility acts as a very + simplified dig. +
++ Usage: sample-request [-t RRtype] server_address hostname +
++ Options and Arguments: +
++ specify the RR type of + the queries. The default is the A RR. +
+ an IP(v4/v6) + address of the recursive server to which the query is sent. +
+ the domain name for the query +
+ This is a test program + to check getaddrinfo() and getnameinfo() behavior. It takes a + host name as an argument, calls getaddrinfo() with the given host + name, and calls getnameinfo() with the resulting IP addresses + returned by getaddrinfo(). If the dns.conf file exists and + defines a trust anchor, the underlying resolver will act as a + validating resolver, and getaddrinfo()/getnameinfo() will fail + with an EAI_INSECUREDATA error when DNSSEC validation fails. +
++ Usage: sample-gai hostname +
++ It accepts a single update command as a + command-line argument, sends an update request message to the + authoritative server, and shows the response from the server. In + other words, this is a simplified nsupdate. +
++ Usage: sample-update [options] (add|delete) "update data" +
++ Options and Arguments: +
++ An IP address of the authoritative server that has authority + for the zone containing the update name. This should normally + be the primary authoritative server that accepts dynamic + updates. It can also be a secondary server that is configured + to forward update requests to the primary server. +
+ A TSIG key file to secure the update transaction. The keyfile + format is the same as that for the nsupdate utility. +
+ A prerequisite for the update (only one prerequisite can be + specified). The prerequisite format is the same as that is + accepted by the nsupdate utility. +
+ An IP address of a recursive server that this utility will + use. A recursive server may be necessary to identify the + authoritative server address to which the update request is + sent. +
+ The domain name of the zone that contains +
+ Specify the type of update operation. Either "add" or "delete" + must be specified. +
+ Specify the data to be updated. A typical example of the data + would look like "name TTL RRtype RDATA". +
+ Examples: assuming the primary authoritative server of the + dynamic.example.com zone has an IPv6 address 2001:db8::1234, +
+
+$ sample-update -a sample-update -k Kxxx.+nnn+mmmm.key add "foo.dynamic.example.com 30 IN A 192.168.2.1"
++ adds an A RR for foo.dynamic.example.com using the given key. +
+
+$ sample-update -a sample-update -k Kxxx.+nnn+mmmm.key delete "foo.dynamic.example.com 30 IN A"
++ removes all A RRs for foo.dynamic.example.com using the given key. +
+
+$ sample-update -a sample-update -k Kxxx.+nnn+mmmm.key delete "foo.dynamic.example.com"
++ removes all RRs for foo.dynamic.example.com using the given key. +
++ It checks a set + of domains to see the name servers of the domains behave + correctly in terms of RFC 4074. This is included in the set of + sample programs to show how the export library can be used in a + DNS-related application. +
++ Usage: nsprobe [-d] [-v [-v...]] [-c cache_address] [input_file] +
++ Options +
++ run in the "debug" mode. with this option nsprobe will dump + every RRs it receives. +
+ increase verbosity of other normal log messages. This can be + specified multiple times +
+ specify an IP address of a recursive (caching) name server. + nsprobe uses this server to get the NS RRset of each domain and + the A and/or AAAA RRsets for the name servers. The default + value is 127.0.0.1. +
+ a file name containing a list of domain (zone) names to be + probed. when omitted the standard input will be used. Each + line of the input file specifies a single domain name such as + "example.com". In general this domain name must be the apex + name of some DNS zone (unlike normal "host names" such as + "www.example.com"). nsprobe first identifies the NS RRsets for + the given domain name, and sends A and AAAA queries to these + servers for some "widely used" names under the zone; + specifically, adding "www" and "ftp" to the zone name. +
BIND 9.11.0pre-alpha
+ + diff --git a/doc/arm/Bv9ARM.ch13.html b/doc/arm/Bv9ARM.ch13.html new file mode 100644 index 0000000000..f3d0471914 --- /dev/null +++ b/doc/arm/Bv9ARM.ch13.html @@ -0,0 +1,154 @@ + + + + + +Table of Contents
+rndc.conf — rndc configuration file
+BIND 9.11.0pre-alpha
+ +