From fae13836a33b474a6aa2c147df8334f5b1ffae45 Mon Sep 17 00:00:00 2001 From: Tinderbox User Date: Mon, 12 Jan 2015 03:30:27 +0000 Subject: [PATCH] regen master --- doc/arm/Bv9ARM.ch11.html | 519 +++++++++++++++++++++++++++++++++++++ doc/arm/Bv9ARM.ch12.html | 545 +++++++++++++++++++++++++++++++++++++++ doc/arm/Bv9ARM.ch13.html | 154 +++++++++++ 3 files changed, 1218 insertions(+) create mode 100644 doc/arm/Bv9ARM.ch11.html create mode 100644 doc/arm/Bv9ARM.ch12.html create mode 100644 doc/arm/Bv9ARM.ch13.html diff --git a/doc/arm/Bv9ARM.ch11.html b/doc/arm/Bv9ARM.ch11.html new file mode 100644 index 0000000000..f021e2d709 --- /dev/null +++ b/doc/arm/Bv9ARM.ch11.html @@ -0,0 +1,519 @@ + + + + + +Appendix C. General DNS Reference Information + + + + + + + +
+ + + + + + + +
Appendix C. General DNS Reference Information
+Prev   Next +
+
+
+
+

+Appendix C. General DNS Reference Information

+
+

Table of Contents

+
+
IPv6 addresses (AAAA)
+
Bibliography (and Suggested Reading)
+
+
Request for Comments (RFCs)
+
Internet Drafts
+
Other Documents About BIND
+
+
+
+
+

+IPv6 addresses (AAAA)

+

+ 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. +

+
+
+

+Bibliography (and Suggested Reading)

+
+

+Request for Comments (RFCs)

+

+ 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: +

+

+ http://www.ietf.org/rfc/. +

+
+

+Bibliography

+
+

Standards

+
+

[RFC974] C. Partridge. Mail Routing and the Domain System. January 1986.

+
+
+

[RFC1034] P.V. Mockapetris. Domain Names — Concepts and Facilities. November 1987.

+
+
+

[RFC1035] P. V. Mockapetris. Domain Names — Implementation and + Specification. November 1987.

+
+
+
+

+Proposed Standards

+
+

[RFC2181] R., R. Bush Elz. Clarifications to the DNS + Specification. July 1997.

+
+
+

[RFC2308] M. Andrews. Negative Caching of DNS + Queries. March 1998.

+
+
+

[RFC1995] M. Ohta. Incremental Zone Transfer in DNS. August 1996.

+
+
+

[RFC1996] P. Vixie. A Mechanism for Prompt Notification of Zone Changes. August 1996.

+
+
+

[RFC2136] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the Domain Name System. April 1997.

+
+
+

[RFC2671] P. Vixie. Extension Mechanisms for DNS (EDNS0). August 1997.

+
+
+

[RFC2672] M. Crawford. Non-Terminal DNS Name Redirection. August 1999.

+
+
+

[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, 3rd, and B. Wellington. Secret Key Transaction Authentication for DNS (TSIG). May 2000.

+
+
+

[RFC2930] D. Eastlake, 3rd. Secret Key Establishment for DNS (TKEY RR). September 2000.

+
+
+

[RFC2931] D. Eastlake, 3rd. DNS Request and Transaction Signatures (SIG(0)s). September 2000.

+
+
+

[RFC3007] B. Wellington. Secure Domain Name System (DNS) Dynamic Update. November 2000.

+
+
+

[RFC3645] S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead, and R. Hall. Generic Security Service Algorithm for Secret + Key Transaction Authentication for DNS + (GSS-TSIG). October 2003.

+
+
+
+

+DNS Security Proposed Standards

+
+

[RFC3225] D. Conrad. Indicating Resolver Support of DNSSEC. December 2001.

+
+
+

[RFC3833] D. Atkins and R. Austein. Threat Analysis of the Domain Name System (DNS). August 2004.

+
+
+

[RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. DNS Security Introduction and Requirements. March 2005.

+
+
+

[RFC4034] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. Resource Records for the DNS Security Extensions. March 2005.

+
+
+

[RFC4035] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. Protocol Modifications for the DNS + Security Extensions. March 2005.

+
+
+
+

Other Important RFCs About DNS + Implementation

+
+

[RFC1535] E. Gavron. A Security Problem and Proposed Correction With Widely + Deployed DNS Software. October 1993.

+
+
+

[RFC1536] A. Kumar, J. Postel, C. Neuman, P. Danzig, and S. Miller. Common DNS Implementation + Errors and Suggested Fixes. October 1993.

+
+
+

[RFC1982] R. Elz and R. Bush. Serial Number Arithmetic. August 1996.

+
+
+

[RFC4074] Y. Morishita and T. Jinmei. Common Misbehaviour Against DNS + Queries for IPv6 Addresses. May 2005.

+
+
+
+

Resource Record Types

+
+

[RFC1183] C.F. Everhart, L. A. Mamakos, R. Ullmann, and P. Mockapetris. New DNS RR Definitions. October 1990.

+
+
+

[RFC1706] B. Manning and R. Colella. DNS NSAP Resource Records. October 1994.

+
+
+

[RFC2168] R. Daniel and M. Mealling. Resolution of Uniform Resource Identifiers using + the Domain Name System. June 1997.

+
+
+

[RFC1876] C. Davis, P. Vixie, T., and I. Dickinson. A Means for Expressing Location Information in the + Domain + Name System. January 1996.

+
+
+

[RFC2052] A. Gulbrandsen and P. Vixie. A DNS RR for Specifying the + Location of + Services. October 1996.

+
+
+

[RFC2163] A. Allocchio. Using the Internet DNS to + Distribute MIXER + Conformant Global Address Mapping. January 1998.

+
+
+

[RFC2230] R. Atkinson. Key Exchange Delegation Record for the DNS. October 1997.

+
+
+

[RFC2536] D. Eastlake, 3rd. DSA KEYs and SIGs in the Domain Name System (DNS). March 1999.

+
+
+

[RFC2537] D. Eastlake, 3rd. RSA/MD5 KEYs and SIGs in the Domain Name System (DNS). March 1999.

+
+
+

[RFC2538] D. Eastlake, 3rd and O. Gudmundsson. Storing Certificates in the Domain Name System (DNS). March 1999.

+
+
+

[RFC2539] D. Eastlake, 3rd. Storage of Diffie-Hellman Keys in the Domain Name System (DNS). March 1999.

+
+
+

[RFC2540] D. Eastlake, 3rd. Detached Domain Name System (DNS) Information. March 1999.

+
+
+

[RFC2782] A. Gulbrandsen. P. Vixie. L. Esibov. A DNS RR for specifying the location of services (DNS SRV). February 2000.

+
+
+

[RFC2915] M. Mealling. R. Daniel. The Naming Authority Pointer (NAPTR) DNS Resource Record. September 2000.

+
+
+

[RFC3110] D. Eastlake, 3rd. RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS). May 2001.

+
+
+

[RFC3123] P. Koch. A DNS RR Type for Lists of Address Prefixes (APL RR). June 2001.

+
+
+

[RFC3596] S. Thomson, C. Huitema, V. Ksinant, and M. Souissi. DNS Extensions to support IP + version 6. October 2003.

+
+
+

[RFC3597] A. Gustafsson. Handling of Unknown DNS Resource Record (RR) Types. September 2003.

+
+
+
+

+DNS and the Internet

+
+

[RFC1101] P. V. Mockapetris. DNS Encoding of Network Names + and Other Types. April 1989.

+
+
+

[RFC1123] Braden. Requirements for Internet Hosts - Application and + Support. October 1989.

+
+
+

[RFC1591] J. Postel. Domain Name System Structure and Delegation. March 1994.

+
+
+

[RFC2317] H. Eidnes, G. de Groot, and P. Vixie. Classless IN-ADDR.ARPA Delegation. March 1998.

+
+
+

[RFC2826] Internet Architecture Board. IAB Technical Comment on the Unique DNS Root. May 2000.

+
+
+

[RFC2929] D. Eastlake, 3rd, E. Brunner-Williams, and B. Manning. Domain Name System (DNS) IANA Considerations. September 2000.

+
+
+
+

+DNS Operations

+
+

[RFC1033] M. Lottor. Domain administrators operations guide. November 1987.

+
+
+

[RFC1537] P. Beertema. Common DNS Data File + Configuration Errors. October 1993.

+
+
+

[RFC1912] D. Barr. Common DNS Operational and + Configuration Errors. February 1996.

+
+
+

[RFC2010] B. Manning and P. Vixie. Operational Criteria for Root Name Servers. October 1996.

+
+
+

[RFC2219] M. Hamilton and R. Wright. Use of DNS Aliases for + Network Services. October 1997.

+
+
+
+

Internationalized Domain Names

+
+

[RFC2825] IAB and R. Daigle. A Tangled Web: Issues of I18N, Domain Names, + and the Other Internet protocols. May 2000.

+
+
+

[RFC3490] P. Faltstrom, P. Hoffman, and A. Costello. Internationalizing Domain Names in Applications (IDNA). March 2003.

+
+
+

[RFC3491] P. Hoffman and M. Blanchet. Nameprep: A Stringprep Profile for Internationalized Domain Names. March 2003.

+
+
+

[RFC3492] A. Costello. Punycode: A Bootstring encoding of Unicode + for Internationalized Domain Names in + Applications (IDNA). March 2003.

+
+
+
+

Other DNS-related RFCs

+
+

Note

+

+ Note: the following list of RFCs, although + DNS-related, are not + concerned with implementing software. +

+
+
+

[RFC1464] R. Rosenbaum. Using the Domain Name System To Store Arbitrary String + Attributes. May 1993.

+
+
+

[RFC1713] A. Romao. Tools for DNS Debugging. November 1994.

+
+
+

[RFC1794] T. Brisco. DNS Support for Load + Balancing. April 1995.

+
+
+

[RFC2240] O. Vaughan. A Legal Basis for Domain Name Allocation. November 1997.

+
+
+

[RFC2345] J. Klensin, T. Wolf, and G. Oglesby. Domain Names and Company Name Retrieval. May 1998.

+
+
+

[RFC2352] O. Vaughan. A Convention For Using Legal Names as Domain Names. May 1998.

+
+
+

[RFC3071] J. Klensin. Reflections on the DNS, RFC 1591, and Categories of Domains. February 2001.

+
+
+

[RFC3258] T. Hardie. Distributing Authoritative Name Servers via + Shared Unicast Addresses. April 2002.

+
+
+

[RFC3901] A. Durand and J. Ihren. DNS IPv6 Transport Operational Guidelines. September 2004.

+
+
+
+

Obsolete and Unimplemented Experimental RFC

+
+

[RFC1712] C. Farrell, M. Schulze, S. Pleitner, and D. Baldoni. DNS Encoding of Geographical + Location. November 1994.

+
+
+

[RFC2673] M. Crawford. Binary Labels in the Domain Name System. August 1999.

+
+
+

[RFC2874] M. Crawford and C. Huitema. DNS Extensions to Support IPv6 Address Aggregation + and Renumbering. July 2000.

+
+
+
+

Obsoleted DNS Security RFCs

+
+

Note

+

+ Most of these have been consolidated into RFC4033, + RFC4034 and RFC4035 which collectively describe DNSSECbis. +

+
+
+

[RFC2065] D. Eastlake, 3rd and C. Kaufman. Domain Name System Security Extensions. January 1997.

+
+
+

[RFC2137] D. Eastlake, 3rd. Secure Domain Name System Dynamic Update. April 1997.

+
+
+

[RFC2535] D. Eastlake, 3rd. Domain Name System Security Extensions. March 1999.

+
+
+

[RFC3008] B. Wellington. Domain Name System Security (DNSSEC) + Signing Authority. November 2000.

+
+
+

[RFC3090] E. Lewis. DNS Security Extension Clarification on Zone Status. March 2001.

+
+
+

[RFC3445] D. Massey and S. Rose. Limiting the Scope of the KEY Resource Record (RR). December 2002.

+
+
+

[RFC3655] B. Wellington and O. Gudmundsson. Redefinition of DNS Authenticated Data (AD) bit. November 2003.

+
+
+

[RFC3658] O. Gudmundsson. Delegation Signer (DS) Resource Record (RR). December 2003.

+
+
+

[RFC3755] S. Weiler. Legacy Resolver Compatibility for Delegation Signer (DS). May 2004.

+
+
+

[RFC3757] O. Kolkman, J. Schlyter, and E. Lewis. Domain Name System KEY (DNSKEY) Resource Record + (RR) Secure Entry Point (SEP) Flag. April 2004.

+
+
+

[RFC3845] J. Schlyter. DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format. August 2004.

+
+
+
+
+
+

+Internet Drafts

+

+ 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. +

+
+
+

+Other Documents About BIND +

+

+
+

+Bibliography

+
+

Paul Albitz and Cricket Liu. DNS and BIND. Copyright © 1998 Sebastopol, CA: O'Reilly and Associates.

+
+
+
+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
Appendix B. A Brief History of the DNS and BIND Home Appendix D. BIND 9 DNS Library Support
+
+

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 @@ + + + + + +Appendix D. BIND 9 DNS Library Support + + + + + + + +
+ + + + + + + +
Appendix D. BIND 9 DNS Library Support
+Prev   Next +
+
+
+
+

+Appendix D. BIND 9 DNS Library Support

+
+

Table of Contents

+
+
BIND 9 DNS Library Support
+
+
Prerequisite
+
Compilation
+
Installation
+
Known Defects/Restrictions
+
The dns.conf File
+
Sample Applications
+
Library References
+
+
+
+
+

+BIND 9 DNS Library Support

+

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.

    • +
+
+

+Prerequisite

+

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.

+
+
+

+Compilation

+
+$ ./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).

+
+
+

+Installation

+
+$ 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.

+
+
+

+Known Defects/Restrictions

+
    +

  • 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 dns.conf File

+

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.)

+
+
+

+Sample Applications

+

Some sample application programs using this API are + provided for reference. The following is a brief description of + these applications. +

+
+

+sample: a simple stub resolver utility

+

+ 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: +

+
+
+ -t RRtype +
+

+ specify the RR type of the query. The default is the A RR. +

+
+ [-a algorithm] [-e] -k keyname -K keystring +
+
+

+ 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. +

+
+
+ -s domain:alt_server_address +
+

+ specify a separate recursive server address for the specific + "domain". Example: -s example.com:2001:db8::1234 +

+
server_address
+

+ an IP(v4/v6) address of the recursive server to which queries + are sent. +

+
hostname
+

+ the domain name for the query +

+
+
+
+

+sample-async: a simple stub resolver, working asynchronously

+

+ 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: +

+
+
+ -s server_address +
+
+ an IPv4 address of the recursive server to which queries are sent. + (IPv6 addresses are not supported in this implementation) +
+
+ -t RR_type +
+
+ specify the RR type of the queries. The default is the A + RR. +
+
+ input_file +
+
+ a list of domain names to be resolved. each line + consists of a single domain name. Example: +


+  www.example.com
+  mx.example.net
+  ns.xxx.example
+

+
+
+
+
+

+sample-request: a simple DNS transaction client

+

+ 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: +

+
+
+ -t RRtype +
+

+ specify the RR type of + the queries. The default is the A RR. +

+
+ server_address +
+

+ an IP(v4/v6) + address of the recursive server to which the query is sent. +

+
+ hostname +
+

+ the domain name for the query +

+
+
+
+

+sample-gai: getaddrinfo() and getnameinfo() test code

+

+ 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 +

+
+
+

+sample-update: a simple dynamic update client program

+

+ 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: +

+
+
+ -a auth_server +
+

+ 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. +

+
+ -k keyfile +
+

+ A TSIG key file to secure the update transaction. The keyfile + format is the same as that for the nsupdate utility. +

+
+ -p prerequisite +
+

+ 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. +

+
+ -r recursive_server +
+

+ 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. +

+
+ -z zonename +
+

+ The domain name of the zone that contains +

+
+ (add|delete) +
+

+ Specify the type of update operation. Either "add" or "delete" + must be specified. +

+
+ "update data" +
+

+ Specify the data to be updated. A typical example of the data + would look like "name TTL RRtype RDATA". +

+
+
+

Note

In practice, either -a or -r must be specified. Others can + be optional; the underlying library routine tries to identify the + appropriate server and the zone name for the update.
+

+ 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. +

+
+
+

+nsprobe: domain/name server checker in terms of RFC 4074

+

+ 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 +

+
+
+ -d +
+

+ run in the "debug" mode. with this option nsprobe will dump + every RRs it receives. +

+
+ -v +
+

+ increase verbosity of other normal log messages. This can be + specified multiple times +

+
+ -c cache_address +
+

+ 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. +

+
+ input_file +
+

+ 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. +

+
+
+
+
+

+Library References

+

As of this writing, there is no formal "manual" of the + libraries, except this document, header files (some of them + provide pretty detailed explanations), and sample application + programs.

+
+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
Appendix C. General DNS Reference Information Home Manual pages
+
+

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 @@ + + + + + +Manual pages + + + + + + + +
+ + + + + + + +
Manual pages
+Prev   Next +
+
+
+
+
+

+Manual pages

+
+
+
+

Table of Contents

+
+
+dig — DNS lookup utility +
+
+host — DNS lookup utility +
+
+delv — DNS lookup and validation utility +
+
+dnssec-checkds — A DNSSEC delegation consistency checking tool. +
+
+dnssec-coverage — checks future DNSKEY coverage for a zone +
+
+dnssec-dsfromkey — DNSSEC DS RR generation tool +
+
+dnssec-importkey — Import DNSKEY records from external systems so they can be managed. +
+
+dnssec-keyfromlabel — DNSSEC key generation tool +
+
+dnssec-keygen — DNSSEC key generation tool +
+
+dnssec-revoke — Set the REVOKED bit on a DNSSEC key +
+
+dnssec-settime — Set the key timing metadata for a DNSSEC key +
+
+dnssec-signzone — DNSSEC zone signing tool +
+
+dnssec-verify — DNSSEC zone verification tool +
+
+named-checkconf — named configuration file syntax checking tool +
+
+named-checkzone — zone file validity checking or converting tool +
+
+named — Internet domain name server +
+
+named-journalprint — print zone journal in human-readable form +
+
+named-rrchecker — A syntax checker for individual DNS resource records +
+
+nsupdate — Dynamic DNS update utility +
+
+rndc — name server control utility +
+
+rndc.conf — rndc configuration file +
+
+rndc-confgen — rndc key generation tool +
+
+ddns-confgen — ddns key generation tool +
+
+arpaname — translate IP addresses to the corresponding ARPA names +
+
+genrandom — generate a file containing random data +
+
+isc-hmac-fixup — fixes HMAC keys generated by older versions of BIND +
+
+nsec3hash — generate NSEC3 hash +
+
+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
Appendix D. BIND 9 DNS Library Support Home dig
+
+

BIND 9.11.0pre-alpha

+ +