diff --git a/doc/arm/Bv9ARM.ch01.html b/doc/arm/Bv9ARM.ch01.html index 071c920d8b..d772ca3006 100644 --- a/doc/arm/Bv9ARM.ch01.html +++ b/doc/arm/Bv9ARM.ch01.html @@ -232,6 +232,7 @@ CLASS="informaltable" >

also-notify, see Section 6.2.14.7Section 6.2.14.6. For more information about port] [-v view] [-y key] [-z zone] command is one of the following - for named:

is one of the following:

statusa

Display ps(1) status of named.

dumpdb[a]

Dump database and cache to /var/tmp/named_dump.db.

refresh

Force a refresh of specified zone.

reload zone [class [view]]

Reload the given zone.

refresh zone [class [view]]

Schedule zone maintenance for the given zone.

Dump statistics to /var/tmp/named.stats.

Write server statistics to the statistics file.

trace[a]

Increment debugging level by one.

notrace[a] -

Set debugging level to 0.

querylog[a]

stop[a]

Stop the server.

Stop the server, making sure any recent changes +made through dynamic update or IXFR are first saved to the master files +of the updated zones.

restarthalt[a]

Restart the server.

Stop the server immediately. Recent changes +made through dynamic update or IXFR are not saved to the master files, +but will be rolled forward from the journal files when the server +is restarted.

Notes:
anot yet implemented

As noted above, only a limited number of commands are - available in In BIND 9.1. The other - commands, and more, are planned to be implemented for - future releases.

9.1, rndc does not +yet support all the commands of the BIND 8 ndc +utility. Additonal commands will be added in future releases.

A configuration file is required, since all communication with the server is authenticated with @@ -1075,14 +1023,14 @@ CLASS="filename" >, but limited to only three statements, the options{}options, key{}key and server{}server statements. These statements are what associate the secret keys to the servers with which they are meant to @@ -1091,7 +1039,7 @@ CLASS="command" >

The options{}options statement has two clauses: default-server takes the name of key as its argument, as defined by a key{}key statement. In the future a

The key{}key statement names a key with its string argument. The string is required by the server to be a valid domain name, though it need not actually be hierarchical; thus, @@ -1139,7 +1087,7 @@ CLASS="userinput" >" is a valid name. The key{}key statement has two clauses: algorithm

The server{}server statement uses the key clause to associate a key{}key-defined key with a server. The argument to the server{}server statement is a host name or address (addresses must be double quoted). The argument to the key clause is the name of the key as defined by the key{}key statement. A

3.4.2. Signals

4.3. Split DNS
4.5. TKEY
4.6. SIG(0)
4.8. IPv6 Support in BIND

4.3. Split DNS

4.4.1. Generate Shared Keys for Each Pair of Hosts

4.4.1.1. Automatic Generation

4.4.1.2. Manual Generation

4.4.2. Copying the Shared Secret to Both Machines

4.4.3. Informing the Servers of the Key's Existence

4.4.4. Instructing the Server to Use the Key

4.4.5. TSIG Key Based Access Control

4.4.6. Errors

4.5. TKEY

4.6. SIG(0)

4.7.1. Generating Keys

4.7.2. Creating a Keyset

4.7.3. Signing the Child's Keyset

4.7.4. Signing the Zone

4.7.5. Configuring Servers

4.8. IPv6 Support in BIND

4.8.1. Address Lookups Using AAAA Records

4.8.2. Address Lookups Using A6 Records

4.8.2.1. A6 Chains

4.8.2.2. A6 Records for DNS Servers

4.8.3. Address to Name Lookups Using Nibble Format

4.8.4. Address to Name Lookups Using Bitstring Format

4.8.5. Using DNAME for Delegation of IPv6 Reverse Addresses

5.1. The Lightweight Resolver Library

5.1. The Lightweight Resolver Library

6.3. Zone File

6.1.1.1. Syntax

6.1.1.2. Definition and Usage

6.1.2. Comment Syntax

6.1.2.1. Syntax

6.1.2.2. Definition and Usage

6.2.1. acl

6.2.3. controls

6.2.4. controlsRemote Name Daemon Control application in in + Section 3.4.1.2). All commands to the - control channel must be signed by one of its specified keys to +>). All commands to the control channel + must be signed by one of its specified keys to be honored.

For the initial release of BIND 9.0.0, only one command - is possible over the command channel, the command to reload the - server. We will expand command set in future releases.

The UNIX control channel type of BIND

6.2.5. include

6.2.6. include

6.2.7. key

6.2.8. key

6.2.9. loggingsyslog ( syslog_facility ) - | null + | stderr + | null ); [

6.2.10. logginglogging { category "default" { "default_syslog"; "default_debug"; }; - }; +};

In

6.2.10.1. The channel; you can make as many of them as you want.

Every channel definition must include a clause that says whether -messages selected for the channel go to a file, to a particular -syslog facility, or are discarded. It can optionally also limit -the message severity level that will be accepted by the channel -(the default is Every channel definition must include a destination clause that +says whether messages selected for the channel go to a file, to a +particular syslog facility, to the standard error stream, or are +discarded. It can optionally also limit the message severity level +that will be accepted by the channel (the default is +info), and whether to include -a ), and whether to include a +named-generated time stamp, the category name and/or severity level (the default is not to include any).

The word The null as the destination option -for the channel will cause all messages sent to it to be discarded; +> destination clause +causes all messages sent to the channel to be discarded; in that case, other options for the channel are meaningless.

The file clause can include limitations +> destination clause directs the channel +to a disk file. It can include limitations both on how large the file is allowed to become, and how many versions of the file will be saved each time the file is opened.

The argument for the The syslog clause is a +> destination clause directs the +channel to the system log. Its argument is a syslog facility as described in the syslog would print all messages it received from the channel.

The stderr destination clause directs the +channel to the server's standard error stream. This is intended for +use when the server is running as a foreground process, for example +when debugging a configuration.

The server can supply extensive debugging information when it is in debugging mode. If the server's global debug level is greater than zero, then debugging mode will be active. The global debug @@ -2214,11 +2226,7 @@ channel "default_debug" { // current debug level }; channel "default_stderr" { // writes to stderr - file "<stderr>"; // this is illustrative only; - // there's currently no way of - // specifying an internal file - // descriptor in the - // configuration language. + stderr; severity info; // only send priority info // and higher }; @@ -2325,6 +2333,7 @@ CLASS="informaltable" >

6.2.11. lwres

6.2.12. lwres

6.2.13. options] [ transfer-source transfer-source (ip4_addr [ | *) [port ] [ transfer-source-v6 transfer-source-v6 (ip6_addr [ | *) [port ] [ notify-source notify-source (ip4_addr [ | *) [port ] [ notify-source-v6 notify-source-v6 (ip6_addr [ | *) [port

6.2.14. options

These options allow the administrator to set a minimum and maximum refresh and retry time either per-zone, per-view, or per-server. -These options are valid for slave and stub zones, and clamp the SOA +These options are valid for master, slave and stub zones, and clamp the SOA refresh and retry times to the specified values.

@@ -4750,7 +4773,7 @@ CLASS="sect3" >

6.2.14.2. Forwarding

6.2.14.3. Name Checking

The server can check domain names based upon their expected -client contexts. For example, a domain name used as a hostname can -be checked for compliance with the RFCs defining valid hostnames.

Three checking methods are available:

ignore

No checking is done.

warn

Names are checked against their expected -client contexts. Invalid names are logged, but processing continues normally.

fail

Names are checked against their expected -client contexts. Invalid names are logged, and the offending data -is rejected.

The server can check names in three areas: master zone files, -slave zone files, and in responses to queries the server has initiated. -If check-names response fail has been specified, -and answering the client's question would require sending an invalid -name to the client, the server will send a REFUSED response code -to the client.

The defaults are:

    check-names master fail;
-    check-names slave warn;
-    check-names response ignore;
-

check-names may also be specified in the zone statement, -in which case it overrides the options check-names statement. -When used in a zone statement, the area is not -specified because it can be deduced from the zone type.

Note: Name checking is not yet implemented in BIND 9.

6.2.14.4. Access Control6.2.14.3. Access Control

Access to the server can be restricted based on the IP address @@ -4994,6 +4882,7 @@ CLASS="informaltable" >

6.2.14.5. Interfaces6.2.14.4. Interfaces

The interfaces and ports that the server will answer queries @@ -5216,8 +5105,8 @@ CLASS="sect3" >

6.2.14.6. Query Address6.2.14.5. Query Address

If the server doesn't know the answer to a question, it will @@ -5276,7 +5165,7 @@ CLASS="sect3" CLASS="sect3" >6.2.14.7. Zone Transfers6.2.14.6. Zone Transfers

determines which local address will be bound to IPv4 TCP connections used to fetch zones transferred inbound by the server. It also determines -the IPv4 address, and optionaly the UDP port, used for the refresh queries, -notify messages and when updates are forwarded. If not set, it defaults +the source IPv4 address, and optionally the UDP port, used for the +refresh queries and forwarded dynamic updates. If not set, it defaults to a system controlled value which will usually be the address of the interface "closest to" the remote end. This address must appear in the remote end's transfer-source for all zones, but can -be overridden on a per-zone basis by including a +be overridden on a per-view or per-zone basis by including a transfer-source statement within the statement within the +view or zone block @@ -5692,20 +5586,9 @@ VALIGN="MIDDLE" CLASS="command" >notify-source determines -which local address and optionally UDP port, will be used to send NOTIFY -messages. If a notify-source is not specified then -then the transfer-source will be used and if that -is not specified the query-source will be use. -This address must appear in the remote end's masters @@ -5722,10 +5605,10 @@ CLASS="command" CLASS="command" >zone -/ view blocks in the configuration file.

block in the configuration file.

The same as Like notify-source, -except notify messages are sent using IPv6.

6.2.14.8. Resource Limits6.2.14.7. Resource Limits

The server's usage of many system resources can be @@ -5803,6 +5686,7 @@ CLASS="informaltable" >

6.2.14.9. Periodic Task Intervals6.2.14.8. Periodic Task Intervals

6.2.14.10. Topology6.2.14.9. Topology

All other things being equal, when the server chooses a nameserver @@ -6190,7 +6075,7 @@ CLASS="sect3" CLASS="sect3" >6.2.14.11. The 6.2.14.10. The sortlist Statement statement does (Section 6.2.14.10Section 6.2.14.9). Each top level statement in the sortlist6.2.14.12. RRset Ordering6.2.14.11. RRset Ordering

When multiple records are returned in an answer it may be @@ -6424,6 +6309,7 @@ CLASS="informaltable" >

6.2.14.13. Tuning6.2.14.12. Tuning

6.2.14.14. Deprecated Features6.2.14.13. Deprecated Features

6.2.17. trusted-keys

6.2.18. trusted-keys

6.2.19. view

6.2.20. view

6.2.22. zone

6.2.22.1. Zone Types

6.2.22.2. Class

6.2.22.3. Zone Options

allow-query in Section 6.2.14.4Section 6.2.14.3

allow-transfer in Section 6.2.14.4Section 6.2.14.3.

See Section 6.2.14.3.

This option was used in BIND 8 to restrict the character set of +domain names in master files and/or DNS responses received from the +netowrk. BIND 9 does not restrict the character set of domain names +and does not implement the check-names option. +

-

Note: Not yet implemented in BIND 9.

Specify the type of database to be used for storing the +zone data. The string following the database keyword +is interpreted as a list of whitespace-delimited words. The first word +identifies the database type, and any subsequent words are passed +as arguments to the database to be interpreted in a way specific +to the database type.

+

The default is "rbt", BIND 9's native in-memory +red-black-tree database. This database does not take arguments.

+

Other values are possible if additional database drivers +have been linked into the server. Some sample drivers are included +with the distribution but none are linked in by default.

+
max-transfer-idle-in under in Section 6.2.14.7Section 6.2.14.6.

max-transfer-time-out
under in Section 6.2.14.7Section 6.2.14.6.

max-transfer-idle-out under in Section 6.2.14.7Section 6.2.14.6.

notify under in Section 6.2.14.1.

sig-validity-interval under in Section 6.2.14.13Section 6.2.14.12.

Determines which local address will be bound -to the IPv4 TCP connection used to fetch this zone. It also determines -the IPv4 address, and optionaly the UDP port, used for the refresh queries, -notify messages and when updates are forwarded. If not set, -it defaults to a system controlled value which will usually be the -address of the interface "closest to" the remote end. If the remote -end user is an allow-transfer option for this -zone, the address, supplied by the See the description of +transfer-source option, -needs to be specified in that allow-transfer option.

in Section 6.2.14.6 +

transfer-source-v6

transfer-source-v6

See the description of +notify-source determines -which local address, and optionally UDP port, will be used to send NOTIFY -messages. If a notify-source is not specified then -then the transfer-source will be used, if neither -of these are set then the address and port used will be determined by -the view then the options blocks. -This address must appear in the remote end's masters in Section 6.2.14.6 -zone clause.

notify-source-v6

notify-source-v6

The first string represents the -type of database used to store the zone data in the server. The default value -is rbt, a red-black tree. The other defined value is rbt64, a variant of rbt -that allows 2^64 updates. Additional databases may be implemented later or -included. Strings after the first string are optional arguments to -the database driver initialization routine. There are none defined for -rbt or rbt64. -

dialup under in Section 6.2.14.1.

max-transfer-time-in under in Section 6.2.14.7Section 6.2.14.6.

Similar to transfer-source, but for zone transfers -performed using IPv6.

See the description of +transfer-source-v6 in Section 6.2.14.6 +

Similar to notify-source, but notify messages -are sent using IPv6.

See the description of +notify-source-v6 in Section 6.2.14.6. +

6.3. Zone File

6.3.1.1. Resource Records

Section 6.2.14.11Section 6.2.14.10 and Section 6.2.14.12Section 6.2.14.11.

The components of a Resource Record are:

6.3.1.2. Textual expression of RRs

6.3.2. Discussion of MX Records

6.3.4. Inverse Mapping in IPv4

6.3.5. Other Zone File Directives

6.3.5.1. The $ORIGIN

6.3.5.2. The $INCLUDE

6.3.5.3. The $TTL

6.3.6. BIND

7.2. chroot
7.3. Dynamic Updates

7.2. chroot

7.2.1. The chroot

7.2.2. Using the setuid

7.3. Dynamic Updates

8.1. Common Problems
8.2. Incrementing and Changing the Serial Number
8.3. Where Can I Get Help?

8.1. Common Problems

.

Bibliography

Standards

[RFC974] C. Partridge,

[RFC1034] P.V. Mockapetris,

[RFC1035] P. V. Mockapetris,

[RFC2181] R., R. Bush Elz,

[RFC2308] M. Andrews,

[RFC1995] M. Ohta,

[RFC1996] P. Vixie,

[RFC2136] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound,

[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, 3rd, and B. Wellington,

Proposed Standards Still Under Development

[RFC1886] S. Thomson and C. Huitema,

[RFC2065] D. Eastlake, 3rd and C. Kaufman,

[RFC2137] D. Eastlake, 3rd,

Other Important RFCs About DNS

[RFC1535] E. Gavron,

[RFC1536] A. Kumar, J. Postel, C. Neuman, P. Danzig, and S. Miller,

[RFC1982] R. Elz and R. Bush,

Resource Record Types

[RFC1183] C.F. Everhart, L. A. Mamakos, R. Ullmann, and P. Mockapetris,

[RFC1706] B. Manning and R. Colella,

[RFC2168] R. Daniel and M. Mealling,

[RFC1876] C. Davis, P. Vixie, T., and I. Dickinson,

[RFC2052] A. Gulbrandsen and P. Vixie,

[RFC2163] A. Allocchio,

[RFC2230] R. Atkinson,

DNS

[RFC1101] P. V. Mockapetris,

[RFC1123] Braden,

[RFC1591] J. Postel,

[RFC2317] H. Eidnes, G. de Groot, and P. Vixie,

DNS

[RFC1537] P. Beertema,

[RFC1912] D. Barr,

[RFC1912] D. Barr,

[RFC2010] B. Manning and P. Vixie,

[RFC2219] M. Hamilton and R. Wright,

Other DNS

[RFC1464] R. Rosenbaum,

[RFC1713] A. Romao,

[RFC1794] T. Brisco,

[RFC2240] O. Vaughan,

[RFC2345] J. Klensin, T. Wolf, and G. Oglesby,

[RFC2352] O. Vaughan,

Obsolete and Unimplemented Experimental RRs

[RFC1712] C. Farrell, M. Schulze, S. Pleitner, and D. Baldoni,

A.4.3. Other Documents About BIND

Bibliography

Paul Albitz and Cricket Liu,

3.4.2. Signals
4.3. Split DNS
4.4.1. Generate Shared Keys for Each Pair of Hosts
4.4.2. Copying the Shared Secret to Both Machines
4.4.3. Informing the Servers of the Key's Existence
4.4.4. Instructing the Server to Use the Key
4.4.5. TSIG Key Based Access Control
4.4.6. Errors
4.5. TKEY
4.6. SIG(0)
4.7.1. Generating Keys
4.7.2. Creating a Keyset
4.7.3. Signing the Child's Keyset
4.7.4. Signing the Zone
4.7.5. Configuring Servers
4.8. IPv6 Support in BIND
4.8.1. Address Lookups Using AAAA Records
4.8.2. Address Lookups Using A6 Records
4.8.3. Address to Name Lookups Using Nibble Format
4.8.4. Address to Name Lookups Using Bitstring Format
4.8.5. Using DNAME for Delegation of IPv6 Reverse Addresses
5.1. The Lightweight Resolver Library
6.1.2. Comment Syntax
6.2.1. acl
6.2.3. controls
6.2.4. controls
6.2.5. include
6.2.6. include
6.2.7. key
6.2.8. key
6.2.9. logging
6.2.10. logging
6.2.11. lwres
6.2.12. lwres
6.2.13. options
6.2.14. options
6.2.17. trusted-keys
6.2.18. trusted-keys
6.2.19. view
6.2.20. view
6.2.22. zone
6.3. Zone File
6.3.2. Discussion of MX Records
6.3.4. Inverse Mapping in IPv4
6.3.5. Other Zone File Directives
6.3.6. BIND
7.2. chroot
7.2.1. The chroot
7.2.2. Using the setuid
7.3. Dynamic Updates
8.1. Common Problems
8.1.1. It's not working; how can I figure out what's wrong?
8.2. Incrementing and Changing the Serial Number
8.3. Where Can I Get Help?
A.1. Acknowledgements
A.1.1. A Brief History of the DNS
A.3. General DNS
A.3.1. IPv6 addresses (A6)
A.4.3. Other Documents About BIND